I am starting to think about moving to a more usable surface syntax for
BitC. The new syntax should be a statement/block syntax, so there are
some things we did not do that we need to go back and look at. I would
very much like reactions from *everyone* on these points.
1. RETURN statement
We intentionally left this out. It can be simulated by a TRY/CATCH block
wrapping the lambda body, so I don't think it introduces any new core
semantics. How much work would it be to introduce this as a syntactic
form and propagate it through the current compiler?
2. TAIL RECURSION
We chose to limit tail recursion so that we could target C code, but
even so we were forced to do an SSA pass. The unfortunate side effect of
the SSA pass is that the output C code is not readable at all. Given
that we have a looping construct, I am wondering whether we should
change the DO form into a core form and eliminate the tail recursion
requirement entirely.
Personally, I would much prefer to retain tail recursion. The problem
here is the SSA pass.
Do inner procedures *also* cause us to run the SSA pass? If so, we can
drop this entire issue.
3. Built-in Operators
In the s-block syntax, BitC will parse infix and prefix arithmetic,
boolean, and bit operators with the customary precedence rules. Since
these symbols are actually type class methods, we have two choices:
1. Admit these symbols as identifiers in general.
2. Define these symbols to have canonical rewritings to legal
identifiers, and do not alter the legal identifier name space.
I mildly prefer the second approach. Any objections?
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
