On Thu, 2008-07-10 at 00:53 +0100, David-Sarah Hopwood wrote:
> I agree. I also think that something equivalent to C's 'break'
> (as used to break from a loop) and 'continue' are needed.
Funny that you should mention this, because it came up in another
context today. I was looking at translating various C constructs into
BitC, and ran my head rather firmly into the absence of RETURN. I was
holding off on this note until I had a chance to talk to Swaroop about
one issue.
The behavior of RETURN can be simulated with exceptions. It isn't
pleasant, but it does demonstrate that RETURN is not a core construct.
The problem (to me) with RETURN is that in a language with first-class
procedures, it can be a bit confusing which procedure exits when the
RETURN is invoked.
Separately, it has been noted that continuations are fine so long as
they are not re-entrant. I really DO NOT want to introduce continuations
into BitC, because ensuring non-reentrancy requires region typing.
What I proposed today was a lexically scoped, non-capturable
continuation form:
(escape-via escape-ident expr)
with the intended meaning that /escape-ident/ is in scope within /expr/
as a procedure label whose invocation returns from the escape-via
construct. The return type must agree with the overall expression return
type. This construct seems equivalent to:
(begin
(defexception escape-ident value: 'a)
(try expr
(catch id (escape-ident value))
(default (throw id))))
except that we don't currently permit local exception definitions and we
don't permit polymorphic exception field values.
In any case, this allows something like:
(define (fact x)
(escape-via return
(cond ((< x 0) (return -1))
((== x 0) (return 1))
(default (return (* x (fact (- x 1))))))))
The cute part is that it would subsume break and continue as well.
On a separate note, I have just realized that the THROW keyword is
completely redundant outside of a catch block. The mere construction of
an exception is sufficient to indicate a need to throw. I'm not
convinced that THROW should go away, but it's always interesting to
notice these things.
Swaroop: we don't allow alpha types in exceptions at global scope
because of the problems for polyinstantiation, but I can't think of any
analogous problem for locally defined exceptions. Is it possible to use
a polymorphic type variable in the way that I have sketched above, or is
this usage going to require monomorphism?
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
