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 script parameters may be enclosed in parentheses, but a notation with just comma's is also supported:
println("hello")
println, "hello"
the second notation would be useful in case of an implicit conversion with more than 1 parameter (to be implemented using an implicit conversion with a tuple), e.g.,
"(", nws
In a syntax definition could be implicit for parse("(", nws) with nws a switch for "no white space" (before the symbol).
IMO the comma notation would only be good for such implicit script calls.
For other purposes, with an explicit name of the called script, it would be clearer to use a Smalltalk-like colon notation:
println: "hello"
If there are multiple parameters, these would be separated by comma's. E.g. a poisson process spawner would be in the old syntax
Note that in the definition we would not write the extra colon for the trailing tag, and in case there is only one parameter we would not write a colon at all.
Could the colon notation also support variable argument lists? Probably, but then for the group of arguments the tag would not be repeated. E.g.,
myPrint: "a", "b", "c"
would call
myPrint( args:String* )
The text was updated successfully, but these errors were encountered:
Currently script parameters may be enclosed in parentheses, but a notation with just comma's is also supported:
the second notation would be useful in case of an implicit conversion with more than 1 parameter (to be implemented using an implicit conversion with a tuple), e.g.,
In a syntax definition could be implicit for
parse("(", nws)
with nws a switch for "no white space" (before the symbol).IMO the comma notation would only be good for such implicit script calls.
For other purposes, with an explicit name of the called script, it would be clearer to use a Smalltalk-like colon notation:
If there are multiple parameters, these would be separated by comma's. E.g. a poisson process spawner would be in the old syntax
In the new syntax:
or even with a closing tag:
Such a script could be defined as:
Note that in the definition we would not write the extra colon for the trailing tag, and in case there is only one parameter we would not write a colon at all.
Could the colon notation also support variable argument lists? Probably, but then for the group of arguments the tag would not be repeated. E.g.,
would call
The text was updated successfully, but these errors were encountered: