[bitc-dev] lexical scoping and first class functions?

[Jonathan S. Shapiro]

On Mon, 2005-12-05 at 16:23 -0800, Greg Buchholz wrote:
> A couple quick questions.  From the BitC spec...
> 
>     In contrast to ML, BitC syntax is designed to discourage currying.
>   Currying encourages the formation of closures that capture non-global
>   state. This requires dynamic storage allocation to instantiate these
>   closures at runtime. Since there are applications of BitC in which
>   dynamic allocation is prohibited, currying is an inappropriate idiom 
>   for this language.
> 
> ...with that in mind, what does the following program (forgive the
> Scheme syntax) mean...
> 
> > (define foo
> >   (lambda (n)
> >     (lambda (x) (* n x))))
> 
> ...When invoked, does it allocate a closure on the heap like in a
> lexically scoped language? 

Yes, with the caveat that the *prototype* compiler does not support
inner procedures that capture references to locals. This is purely so
that we can get self-hosted faster. The language specification requires
what you expect.

>  Is BitC lexically scoped? 

Yes, with the exception of catch blocks, which are dynamically scoped in
the usual way.

>  Is the example
> completely invalid because of the dynamic allocation issue?

There is a compilation model in which capture of locals (thereby
requiring a run-time closure construction) may be disallowed, but this
is true only in the restricted language runtime that is intended for
kernel construction. I am coming to the conclusion that we were
restricting the wrong thing, and that the right approach is to verify a
memory bound rather than restrict this type of operation.

>   Is there
> some malloc/free function calls that could be inserted to make it valid?

Not in that model.

> A more basic question is "Are functions first class values?"  Section
> 7.8 doesn't make that clear.

Yes, subject to some restrictions in the non-GC'd language.

> 
>     And on a side note, I assume the "lambda" keyword is for
> semi-historical reasons.  Has any thought been given to changing it?

Yes, it's a reference to scheme. The keyword "fn" is already used to
describe procedure types. We are desperately avoiding introducing more
kinds of parentheses, because we will need some of those when we get to
BitC/L.


shap