Thank you for taking the time to look at the language. Yes, I agree that there is a problem with a lot of @s and vars littering the code. A consequence of the small syntax seems to be that working with variables and scope is very verbose. My goal with the language is to keep the syntax very very small, but at the same time be able to express the typical things we expect from modern programming languages. Maybe some syntactic sugar could help. But I am not sure what kind of sugar would work best to avoid all the @s. Any ideas?
And yes, the documentation of system provided services is indeed lacking. I have made an issue for it and plan to address it asap: https://github.com/holgerl/hilvl/issues/9
I have an idea, but I'm not sure it's ok: Since @ is used most of the time, it could be the default.
To do that you might make a rule that all services must start with a capital letter(or a number or " or be "true" or be "false"), and only services can.
Then you can make:
foo bar baz
change to:
@ foo bar baz
while:
Foo bar baz
Remains the same. If you don't like the idea of every service starting uppercase, you could just check if the word is a service.
Now an unrelated issue, accessing and modifying a variable:
@ set foo = 4
Even if we ignore the @ (because it's a different problem):
set foo = 4
It would be better to write just:
foo = 4
And it makes sense: variable service foo, action =, argument 4.
Now accessing a variable:
4 + @.foo
I should be able to write:
4 + foo
This is a bit more complicated.
To allow the foo = 4 part foo must be a variable service.
But in this case it should act as a number service.
I see two ways to solve this: or variable services gain new actions based on their type,
or when a service is called without an action, a standard action is called, which by default returns the service itself, but can be overwritten, for example in variables, where it returns the variable value.
That is a good idea. And it will make the code much prettier. Here is what I think the fibonacci example would look like:
var fibonacci :
var scope :
var result = (.argument)
.argument > 1 then
set result =
fibonacci (.result - 1) + (fibonacci (.result - 2))
.result
scope (.argument)
fibonacci 7
//result: 13
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 ";".
As you have suggested, a solution for this could be to instead check if the service exist at all in the scope. 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. This makes a dilemma between unconstrained, small syntax and prettier code with quirky reserved words. Do you agree?
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:
foo + 4
Can you explain more on how your other solution to this would work? I did not quite understand it.
By the way, if variable services could also represent their value, it should be very simple to implement some sort of lazy evaluation in the language. That would be cool.
"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 :)
