You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, there's quite a bit of duplication in operators. One rationale for that is that it allows users coming from different languages to feel comfortable. After all, that's how Imba started.
With 2.0, I think all such duplication should be removed and we should settle on the best option in each case as seen by the community (and primarily the Imba developers).
To counter the effect of missing syntax, I propose adding macros to the language. A 'macro' would be a piece of comment that would be added to the top of the source code which would apply from that point on to any Imba code in the same module. The comment would specify a pattern and a replacement for the pattern.
For example:
#macro$x ? $y : $z==>if$xthen$yelse$y
The placeholders that begin with $ are treated as "any valid expression", or at least "any value or variable reference". In the macro body, the expressions referenced by placeholders will be inserted as is.
The compiler would also have the ability to use a macro file during compilation which contains multiple macros that are applied to any Imba modules compiled.
With macros, users would have the ability to add back any syntax that would be removed in 2.0, and the project could also publish a macro file containing such syntax for those that may like to stick to the old syntax or have an easier transition.
Macros could also open the door for custom operators like:
#macro$xeq$y==>deepEquals$x, $y
Multi-line macros would have a newline right after ==> and span multiple lines until #endmacro
#macro [$x..$y] ==>
#(do# var i = $x# while i < $i# ++i
#)()
#endmacro
Now if we use the above in the code:
varx= [40..100]
it would be treated by the compiler as if the following was written
varx= (dovari=40whilei<100++i
)()
Of course, there are potential pitfalls with this, as the example macro would also mean that arr[1..20] would yield wonky results. But that's on the user pretty much. With great power, comes great responsibility. :)
The text was updated successfully, but these errors were encountered:
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Currently, there's quite a bit of duplication in operators. One rationale for that is that it allows users coming from different languages to feel comfortable. After all, that's how Imba started.
With 2.0, I think all such duplication should be removed and we should settle on the best option in each case as seen by the community (and primarily the Imba developers).
To counter the effect of missing syntax, I propose adding macros to the language. A 'macro' would be a piece of comment that would be added to the top of the source code which would apply from that point on to any Imba code in the same module. The comment would specify a pattern and a replacement for the pattern.
For example:
The placeholders that begin with
$
are treated as "any valid expression", or at least "any value or variable reference". In the macro body, the expressions referenced by placeholders will be inserted as is.The compiler would also have the ability to use a macro file during compilation which contains multiple macros that are applied to any Imba modules compiled.
With macros, users would have the ability to add back any syntax that would be removed in 2.0, and the project could also publish a macro file containing such syntax for those that may like to stick to the old syntax or have an easier transition.
Macros could also open the door for custom operators like:
Multi-line macros would have a newline right after
==>
and span multiple lines until#endmacro
Now if we use the above in the code:
it would be treated by the compiler as if the following was written
Of course, there are potential pitfalls with this, as the example macro would also mean that
arr[1..20]
would yield wonky results. But that's on the user pretty much. With great power, comes great responsibility. :)The text was updated successfully, but these errors were encountered: