Syntax matters

[AndreVanDelft]

I would like to see that the following syntactic rules related to Scala value expressions will all effective in the preprocessor. I am not sure to what extend they are already.

The goal is to support a lot of syntax, so that the user rarely needs to write parentheses.
E.g. while b and while !b should be allowed.
But there are several different kind of SubScript expressions where Scala values may occur.
Each kind may have its own restrictions on the Scala value expression syntax, in order not to have ambiguities withe the SubScript syntax.

There will be ambiguities anyway, mainly with [brackets], For those the solving rule should be that in if there is no white space before the opening bracket, then it belongs to the Scala value expression, else it is an bracketed script expression.

if expression

The if expression may be any Scala expression. The end is discoverable because of the mandatory then keyword.

while expression

The while expression may be a Scala expression that does not contain binary operators and infix method calls. As inversion prefix operators are allowed, we call this a ScalaSimplePrefixExpression.

colon-call parameters

A 'colon-call' is a script call of the form scriptName: param1, param2, param3.
Here the parameters may also be a ScalaSimplePrefixExpression

postfix tests

A parameter postfix test such as in key: ?c ?if !c.isUpper may also have a ScalaSimplePrefixExpression

annotations

Probably ScalaSimplePrefixExpression applies to @annotation:

script expression value terms

Script expression terms that are meant to denote a Scala expression, the
ScalaSimplePrefixExpression is almost sufficient. However, they should not start with an inversion prefix operator such as ~, !, -, because those are also prefixes for script expressions.
So we name this restricted kind of value a ScalaSimpleExpression

script expression value terms starting with ^

If there is a prefix caret then subsequent inversion prefix operators cannot do harm.
Hence ScalaSimplePrefixExpression again.

Examples of ScalaSimpleExpression

literals such as: null, true, 1, 1.0, 'a', "a", s"a", `a`, 'a
(anyScalaExpresion)
{anyScalaStatementSequence}
p
p.q
p(r)
p.q(r)
p.q[T](r,s)

Handling script expression value terms

Script expression value terms are handled according to their type:

• Unit: method call, in a tiny code fragment
• Script[T] for some T: script call. Q: Does this really work so nicely for all script calls?
• some other type T: there must be an implicit conversion to Script[U] for some U; a script call results

Open issues

The colon-call syntax applies for script calls and method calls.
In script calls there are question marks allowed preceding parameters; and
even postfix tests for the parameters. We could also allow this extended parameter
syntax for method calls; it would be useful in libraries such as swing.Scripts.
Maybe they are already allowed there, I don't know.

[anatoliykmetyuk]

So far, all of that works, except the following:

• Simple scala exprs can't be prefixed
• while's short version is while: a, not while a - is that OK?
• Value paramenters can't have if guards when passing them to scripts AFAIK

[AndreVanDelft]

While's short version: ok, it is like if so no semicolon.

I'd like to see this enabled:
x ~~> while
i.e. no parameter inside the arrow, so the RHS should be a parameterized process lambda, i.e. of the type (parameter) => [scriptExpression].
So in such case, would it be possible to parse while without expecting a condition, and treating it as if it said: (b: Boolean) ==> while(b)
?

[AndreVanDelft]

Value parameters can't have if guards when passing them to scripts AFAIK

But such guards should be allowed for output parameters, and passed to a new subscript.vm.ActualConstrainedParameter.

[anatoliykmetyuk]

I'd like to see this enabled:
x ~~> while

FTTB we don't have the ~~> syntax at all, AFAIK, only ~~(foo)~~>

So in such case, would it be possible to parse while without expecting a condition, and treating it as if it said: (b: Boolean) ==> while(b)
?

Since while's no ordinary script, it won't be easy to do so, but I think with some hacking we can have that working. Maybe have two rules, one While = while ~ spaces ~ prefixedExpr | while, and bare while will map to a script lambda.

I don't know whether it is a good idea to remove a colon from while - if has then to serve as parentheses for the condition, but for while it may be not very clear in cases like while a b (meaning while(a) b).

[anatoliykmetyuk]

Also, prefexed exprs already work for while and nice script calls.

[AndreVanDelft]

The normal 'while' should just bind the next term; I don't think that while a b will be confusing.
Otherwise people may still write while(a) b.

I hope the ~~> syntax will be supported one of these days, but other things may be more important FTTB.

What I wrote about while in RHS position should also apply to print etc. So we could have:
mySlickQuery ~~> println
which executes the query in the background and then prints the results.

[AndreVanDelft]

What about nested colon calls, as in: option: myScriptCall: param
E.g. for
script option[T](s: Script[T]): Script[T] = break? s^ or ... = [+] + s^

[AndreVanDelft]

Another thing:
allow colons inside script names, at the definition headers, e.g., a:b(i:Integer, s:String).
Then call this as
a:1, b:"s"
Much like Smalltalk, only with the comma between the parameters.
Useful for special control scripts, e.g.
launch: aCustomerProcess, every: 5*minute

[anatoliykmetyuk]

The normal 'while' should just bind the next term; I don't think that while a b will be confusing.
Otherwise people may still write while(a) b.

Ok, I've implemented it.

What about nested colon calls, as in: option: myScriptCall: param
E.g. for
script option[T](s: Script[T]): Script[T] = break? s^ or ... = [+] + s^

This is not supported: since myScriptCall is in a parameter position, it is the realm of normal Scala code, I didn't touch that.

Another thing:
allow colons inside script names, at the definition headers, e.g., a:b(i:Integer, s:String).
Then call this as
a:1, b:"s"
Much like Smalltalk, only with the comma between the parameters.
Useful for special control scripts, e.g.
launch: aCustomerProcess, every: 5*minute

I don't know whether this is a good idea. Scala already has named parameters, so why introduce more? In any case, it is not critical for the first public release. I think we should refrain from doing further modifications of the language before the release. Modifications require testing and troubleshooting, we risk ending up with an unstable version again, thus postponing the promotion. I propose focusing on the stability, usability and bugs FTTB, leaving the further language modifications to the future. Ok?

[AndreVanDelft]

it is the realm of normal Scala code, I didn't touch that.

I see. Do you think it would be possible, without clashing with Scala conventions?

Scala already has named parameters, so why introduce more?

Named parameters are ugly; writing the formal parameter name again does not add much value. Besides you need these parentheses again. Better is to write a verb or adverb. E.g. compare:

if: condi then: [exp1] else: [exp2]
if( condition=cond, thenPart = [exp1], elsePart: [exp2])

I have published a similar mechanism in 2013, in the ACM paper.
It gets time that we implement it. I really like this to be implemented.
We may stay quiet about it for the time being, and see whether it works well.

So TBD: in a script call with colon syntax, after a comma, if the parser sees an identifier ending in a colon, then append it to the called scriot name, with a colon as separator. No trailing colon for the script name that we lookup.
And allow the colon in the script name in the definition.

Ok?

[anatoliykmetyuk]

Can you please give an exact semantics of the ifs in constrained parameters? And how exactly that colon syntax should be defined? What if there are 3 parameters - do you have to define a script with 3 colons? a:b:c(x,y,z)? What's the meaning of a colon in the script call a: b, c: d? Can we write whatever we want in place of c, since in is a second argument in any case? Also, colons may clash with the type definitions.