Itcy-BitC closures and curries

[Justin Johansson]

Yigal Chripun wrote:
> On 21/11/2009 15:41, Justin Johansson wrote:
>> Having noticed that the BitC PL http://www.bitc-lang.org/ has been
>> mentioned in passing before on this forum, I wonder if any of the D
>> community have any comment on the following aspect of the design of
>> BitC, particularly as may be relevant to D and GC.
>>
>> 1.1 About the Language
>>
>> http://www.bitc-lang.org/docs/bitc/spec.html
>>
>> "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."
>>
>> I don't have any particular agenda in asking this question but feel that
>> some interesting discussion might result out of.
>>
>> There's also a design note for Closure Implementation in BitC by Dr.
>> Jonathan Shapiro, 2005, though I'm unsure if this is currently
>> implemented in BitC or if the article now out of date.
>>
>> http://www.bitc-lang.org/docs/bitc/closures.html
>>
>> Cheers to all,
>>
>> Justin Johansson
>>
> 
> Dr. Jonathan Shapiro works on modern u-kernels and his latest project is 
> the coyotos project which is a capability based design (a very neat 
> design if I may add). BitC was mainly created to facilitate writing that 
> kernel and prove its correctness and thus it makes perfect sense that it 
> was designed that way. Does BitC even has a GC? I thought it was 
> compiled to C.

 > I thought it was compiled to C

Think that's just for bootstrapping the BitC compiler.

At http://www.bitc-lang.org/ it says "The BitC bootstrap compiler 
compiles to portable ANSI C code".

 > Does BitC even has a GC?

 From http://www.bitc-lang.org/docs/bitc/closures.html , it seems that 
BitC is trying to implement some higher-order PL constructs using 
stack-based allocations *where possible* thereby reducing any impact on 
GC.  A GC is not precluded though as this statement (from that page) 
implies:

"The main issue for generating C concerns the relationship between the C 
code and the garbage collector."

Some of the objectives of BitC sound pretty noble which is why I thought 
this might strike a chord with some D people:

See http://www.bitc-lang.org/ Objectives