Closed edsko closed 9 years ago
What about local function definitions, would they still use "in"?
fun f() {
fun g() {
....
};
c1 >>> g()
Related to this would be: should we require a semi-colon (As the example above). This is even more general, for instance currently in a list of commands we would require semicolon even after "}". E.g:
seq {
times 3 {
x <- take;
emit x;
};
bar()
}
Currently inside function bodies you can have declarations without "in" already, and semi colons are already optional I think (?).
Oh you are right, I had forgotten about this! So maybe we can simply drop the "in" for function definitions, nested or not? That may be a bit more uniform?
Well in lists of commands this is a general pattern, right. Whenever we support let <decl> in <comp>
in an expression, we support the corresponding let <decl>
in a list of commands. Lists of commands are special that way :) But the top-level Ziria program is not a list of commands, so it doesn't automatically follow.
Ok it sounds to me that it may be a good idea to treat the top-level as a list of binding commands and then the need for this top-level "in" will go away. But we will have to have a distinguished "main" label as you say. @bradunov what are your thoughts? I quite like this elimination of "in" at the top-level.
Have the top-level be a list of declarations, so that we can write
instead of
This is more natural and opens up the possibility of separate compilation. Only problem is that this will require the definition of a label
which would replace the final. This means that we need an AST transformation to turn the list of declarations, one of which is for
main
, into the big expression that is it expecting now (or an equivalent change to the compiler).