"But, unfortunately the language will be much more constrained if all services must consist of letters. I have an explicit goal that any service name goes except some very few reserved characters. The reason is that it should be possible to create DSL-like APIs with service names like "$", "&", "->", "+", or even "{" and ";"."
Yes, probably you are right here.
"As you have suggested, a solution for this could be to instead check if the service exist at all in the scope."
Yes, actually I thought of having all service names starting uppercase to check if a name is a service faster.
"Service names that do not exist can be assumed to be actions on the @ service. This is a more unconstrained solution. But it means that all actions on @ can never be used as service names."
I think you should be able to shadow @'s names, and then, if you need them, call them with the @.
"This makes a dilemma between unconstrained, small syntax and prettier code with quirky reserved words. Do you agree?"
I think that if you use the approach I just said (you can shadow the @'s names) you wont make your language more constrained. However, yes, you will add new syntax, which you consider a bad thing.
"Now for your other suggestion. Yes, I agree! I have thought about it before, and I think it might have no drawbacks. The fact that you also noticed it makes it even more probable that it is a good solution. The challenge will then be, as you also noticed, how a variable service can be the variable and the value at the same time.
I think it is not good enough to simply check if there are no actions on foo, because then foo must always be the last value. I.e. this has to work:"
Yes, it would not be an improvement.
"Can you explain more on how your other solution to this would work? I did not quite understand it."
Imagine a service which supports both int/number's actions and variable actions. You could write:
foo = 4
and it would call the variable action =. And here:
foo + 4
it would call the number action +.
However in this case:
4 + foo
things are more complicated. I looked at your "+" implementation, and it expects that it's argument is a js number. You can make a check, like if the argument isn't a number and it is a service, you try to call a getvalue action, and if it returns a number, you use it. Or maybe change something about accessing the value of an number (or string), but I don't know how services are implemented (yet), so I can't tell precisely.
> I think you should be able to shadow @'s names, and then, if you need them, call them with the @.
Ah, that is a good idea! That can work
> Imagine a service which supports both int/number's actions and variable actions. [...]
I see. I really think that would be an awesome improvement of the language. I have made a git issue for it. And when I have the time I would love to branch the code and make an attempt at it.
Really appreciate your input on the language. Now I just need some spare time to do these things :)
