www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Itcy-BitC closures and curries

reply Justin Johansson <no spam.com> writes:
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
Nov 21 2009
parent reply Yigal Chripun <yigal100 gmail.com> writes:
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.
Nov 21 2009
parent reply Justin Johansson <no spam.com> writes:
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
Nov 21 2009
parent reply Jonathan S. Shapiro <shap eros-os.org> writes:
I hadn't been aware of BitC surfacing here on the D discussion group.
I want to be careful to respect the fact that this is a place for
discussing D, but many of the objectives of the two languages are
similar, so as long as Walter doesn't feel I'm intruding it may be
useful to share some ideas and thoughts.

The current BitC implementation does not have a GC. For prototype
purposes we rely on the Boehm collector. I'm well aware of the
pitfalls of that collector from bitter experience, and we view it as
a placeholder solution only. Given where we are at the moment, it
would be very easy to implement Fergus Henderson's techniques, and
contrary to what the MAGPIE people have to say, that extends pretty
readily to multithreading. The problem with the Henderson technique
is that it doesn't address inter-operation with C code. Boehm, in any
case, is certainly good enough to serve for bootstrap purposes, and
eventually we'll go to native code in any case.

While we are interested in stack allocation, I don't have any plan to
put energy into automating that at this time. It's an important
optimization, but right now we're focused on trying to get the
language specification, its formal semantics, and its final surface
syntax nailed down. I have a list of issues on my semantics "hit
list" for that, and that's where my main attention is going.


shap (Jonathan S. Shapiro)
Apr 22 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Jonathan S. Shapiro:


 I hadn't been aware of BitC surfacing here on the D discussion group.


I guess I'm the cause for that :-)
Welcome here, it's an honour to see you here.



 I want to be careful to respect the fact that this is a place for
 discussing D, but many of the objectives of the two languages are
 similar, so as long as Walter doesn't feel I'm intruding it may be
 useful to share some ideas and thoughts.


I'm sure Walter doesn't think of you as an intruder, he is an accepting person,
and your knowledge of computer science is probably higher than most people here.

Indeed BitC and D share some purposes, but there are also significant
differences. One of the main ones is that D is designed to not innovate unless
it's required, so D steals ideas from other languages, and it does it only when
such ideas are already tested as useful. D2 language has some new features, but
for many of its features and characteristics it's still a traditional C-class
language.

Regarding your sharing of ideas, I think that's not how this newsgroup works. D
devs are more practical people :-) So you have to be more focused in your
proposals, questions, suggestions, etc, if you want answers and comments. Keep
in mind that D is not an academic language, and several advanced ideas from
functional languages are not so understood here (despite D2 now has some basic
functional features). Personally I have understood only half of your post, but
I'm not a D dev, I'm more like the Jester.



 The current BitC implementation does not have a GC. For prototype
 purposes we rely on the Boehm collector. I'm well aware of the
 pitfalls of that collector from bitter experience, and we view it as
 a placeholder solution only.



(or they wish someday) to develop a good GC. I can't help but see a strong
duplication of efforts here. One problem is that they have different
requirements and needs.

Bye,
bearophile
Apr 22 2010