> > > I would be very interested to know which situations *you* have in > mind, and *why* GC is inappropriate for those situation. >
Cell Phone Applications. Three reasons: 1: The iPhone docs (but not the official agreement) disallows GC. The default garbage collector for the Cocoa SDK is disabled in the iPhone SDK. Using alternate forms of GC is discouraged. 2: Dynamic Linking is disallowed in official iPhone apps. So using a GC as an .so (which is commonly done with the boehm GC) is disallowed. This is obviously easy to work around. 3: The Boehm conservative GC is, well, quite conservative. Memory is still a limited resource (and paging not an option) on handheld platforms. I first discovered BitC when I began looking around for a way to describe complex predicate trees and limited AI algorithms in a language more succinct than C. I don't think it is unreasonable to ask for HoFs and pattern matching in a statically typed language. I was hoping to find a simple Scheme that compiled to C. My top candidates are BitC and Scheme48's PreScheme, both offer a non-gc mode. I am excited about the prospect of an ML-like syntax. I wasn't expecting to get that given my requirements. I'm more impressed with the syntax, tools and tests available for BitC. Even though it's still a very young project, it offers much more than PreScheme. I would be happy to use BitC a feature limited mode. It would be nice if there were a "strict" compiler option that would warn me if I were to use a construct that required malloc. Because I'll likely not be linking to the Boehm GC.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
