On Sat, 2008-01-19 at 18:26 -0500, Swaroop Sridhar wrote:
> Jonathan S. Shapiro wrote:
> > 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?
>
> Implementing return itself is not hard. I guess the intension here is to
> implement return throughout the compiler (that is, emit a return in the
> C code), rather than an AST transformation into try/catch? I think
> handling returns is easy enough, and a try/catch block around every
> "return"ing function will be expensive.
I was not proposing that we should actually use a try/catch block. I was
identifying that as a possible *hypothetical* implementation to show
that RETURN doesn't add any new semantics to the core language.
I actually don't care how it is emitted in C code. What is really going
on in my mind is that the new s-block language syntax will require a
return statement, and if we implement it in the current compiler then
the necessary AST and supporting checking, inference, and transformation
will already exist.
> > 2. TAIL RECURSION
> I wrote a tail recursive version of the same function using GCC
> expression syntax as below:
>
> int
> f(int x, int sum)
> {
> f_begins:
> return ({
> int ans;
> if(x <= 0) {
> ans = sum;
> }
> else {
> sum = sum + x;
> x = x - 1;
> goto f_begins;
> }
> ans;
> });
> }
>
> This function compiles and works fine. So, the problem is not that we
> cannot perform a goto across the expression block.
Correct. I believe the problem is that we cannot goto a label that is
*inside* an expression block.
> > The unfortunate side effect of the SSA pass is that the output
> > C code is not readable at all.
>
> In a way, there is also an advantage to the SSA pass. It produces code
> that has reasonable unambiguous C semantics...
For some value of "reasonably", but yes, you are correct. But the
*problem* created by the SSA pass is a political issue. The question
from the programmer perspective is: "If I take a risk on BitC, will I be
able to get my code back out in some useful form?" And the debugging
issue is very real. One reason that CFRONT was survivable was that you
could single-step through the output and sort of understand what you
were looking at.
I am not sure if this can (in principle) be solved.
> > 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?
>
> So, in the second approach, symbols such as + - * / will be special,
> and out of the legal identifier space?
Yes. If we go to an s-block syntax, I will *probably* restrict
identifiers to the more conventional C-style identifier names.
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
