Named parameter support is on the roadmap. However, it's not a v2 goal, and it probably won't be supported with command syntax due to ambiguity.
I don't intend to remove dynamic variables, but I'm interested to hear the arguments for and against.
At the moment I'm working on changing the way variable declarations are stored so that "global" declarations persist after the closing brace of the function has been parsed. This has a few benefits:
[*:3cn4u552]Double-derefs in assume-local functions will only deref locals or declared
globals, eliminating a common source of confusion.
[*:3cn4u552]Parsing of derefs in expressions can be postponed until the full expression-parsing stage, simplifying the implementation.
[*:3cn4u552]"Static x" won't put assume-local mode into effect, so the following (which currently causes a load-time error) will be allowed:
local y ; Previously had to be ABOVE static x.
z := 1 ; Global.
As a side-effect of the second point, questionable things like the following will not be possible:
x := 1 ; Set global x.
local x := 2 ; Set local x.
In my current build, these cases are detected as errors. However, depending on how things work it, the earlier x might be treated as a local. Declaring the same static twice or redeclaring a previously declared variable as a different type of variable (e.g. local x ... static x) will be considered an error. Declaring the same global or local twice won't
be considered an error, to allow things like this:
global y := Bar(x)
global y := Baz(x)
This will lead on to super-globals and #MustDeclare. My current plan is for "global x" outside
of any function to be essentially equivalent to declaring that global inside every assume-local function, while its usage inside
functions will remain the same. Ordinary global variables will be declared with "var name
". A function beginning with the line "global", "static" or "local" will be exempt from #MustDeclare. Conversely, a function with both "global x" and "local y" (which is not assume-static) will have #MustDeclare behaviour applied to it regardless of whether the directive was used.
Sorry but for #Delimiter you are wrong. There are guys who use it, I am one of them. For Unichars (http://unichars.sourceforge.net) it is mandatory otherwise the character | cannot be used in codes. I replaced the delimiter by chr(1)
I intended to reply to this sooner but it slipped my mind. It sounds like you've confused the #Delimiter directive with something else. #Delimiter changes the command arg delimiter from comma (,) to a character of your choosing, and has nothing to do with |. The only advantage to using it might be that you wouldn't need to escape commas in literal text.
To make the syntax more legible, the php syntax could be used
My current plan is to support %(expression returning a variable name
in expressions and %(expression returning a string
I think a new directive should be created to allow statements to be terminated with a character other than a newline.
I've already said 'I will not add any new directives aimed at "customizing" the language.'