- Processes:
- Grammar contains inject and drop. Both produce processes from names. Inject is not implemented in the compiler.
- Top level production: In the spec only a contract declaration may be at the top level, but in the grammar any non-par process may be at the top level, and with braces, any process may be at the top level.
- Pattern binding: In grammar, each bind may have its own conditional. In spec, there is a single conditional associated with all the binds.
- Select branches may include a conditional in the grammar. In the spec, they may not.
- Foldl and FoldR aren't in the spec
- Print is also missing from the spec.
- Semantics for sending more than one process? It's in both grammars.
- For channels, grammar currently only supports quoted process and variables. No other channels supported in grammar.
- Quantities: Grammar supports richer group of quantities. Map(), Double, String, are not in spec.
- In grammar quantities also support arithmetic. This suggests we'll want typing rules and checking for the expressions.
- Grammar supports field access via dot. I've seen this used in example contracts, but it's not in the spec
- Variables:
- In the 0.1 spec all variables hold names. Quantities are values. This would suggest that adding two variables should look like *x + *y. That won't even compile. What actually happens is that variables that hold names quoting quantity processes are implicitly *'ed, and cannot be explicitly starred because of the syntax.
- Entities: Most of the entity types in the spec are commented out in the grammar. Only characters and tuples are left. It's not obvious why a string is a quantity and a char is an entity.
- Patterns:
- Val pattern in grammar allows matching of structs, but entity grammar prevents construction of structs.
- No Array or struct pattern in grammar.
- Inject present again.
- For process patterns, grammar allows new, and contract construction.
- Most pattern matching is unimplemented in the compiler. How much do we need for Mercury, and should we take out the patterns we won't match from the grammar?
Continuation Saturated Form
...
Do we want to fold par applications down to a list
Compiler
...
question:
Does everything have to go through the tuple space? It would be nice to optimize by skipping that wherever possible.