On Wed, Feb 4, 2009 at 7:31 PM, Sam Rushing <[email protected]> wrote: > > BitC appears to be muuuuch further along than I am, but it also seems to > have a pretty big footprint. Whereas BitC is several MB of code, the > Irken tarball is a piddling 150KB of Python code. It would be wrong to > call it more than a 'prototype' by comparison. 8^)
There was a time when we had a simple python prototype too. I probably still have it around someplace. > > I've been trying to get BitC running... first I made the mistake of > trying it on osx/ppc (something related to gc has not been ported?)... We haven't got the asm trampoline built yet to call procedures that require a closure environment. Paul Snively has been helping on that, and I think we should have a solution very shortly. > > then > tried freebsd/x86 - some kind of bison problem. Yes. Both freebsd and osx ship horribly old versions of bison. > > Ok, now to my issue with the C stack. Am I correct in thinking that > BitC generates separate C functions and uses the C calling convention? > As I said in my other post to LtU, I want to avoid the big disconnect > between the high-level and low-level languages. My plan is to implement > call/cc in the low-level language and use it in both levels. I'll take up the issue of threads and the C stack in a separate email, but the short version is that you really don't want call/cc. It's a semantic nightmare, and the general form of call/cc in scheme is not justified by any real-world use case. > Things I'd like to have in both languages: > > lightweight threads The term "lightweight threads" means very different things to different people. We left concurrency out of the BitC language spec because nobody knows how to do concurrency "right" yet. What is it that you actually want? > continuations Respectfully, no, I don't think you want this, and I'll explain why in my next email. > generators What do you mean by "generators"? > > exceptions BitC has this. > > ability to dump and load an image BitC does not have this. While we are looking at building an interactive BitC environment, and such an environment certainly needs a dump mechanism, BitC is primarily focused on being a static compiler. One problem with the interactive approach is that it doesn't handle cross compilation very well... > marshalling a continuation, maybe sending it to another machine Well, this assumes that you want continuations, but more to the point, this is definitely not "in scope" for BitC. > massive scalability (and thus a small footprint per 'thread') This should be in scope for BitC. Saying "a small footprint per 'thread'" doesn't mean anything. What is the concrete problem that you anticipate, and why do you believe that a conventional stack is inappropriate? shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
