[coyotos-dev] Accept GCJ into the tool chain?
starfirex at comcast.net
Mon Nov 27 13:01:30 CST 2006
You mention scheme? Scheme seems more suited to the constraints of
the task, assuming you have people who can learn it. Scheme is a
little out there, but it's an extremely useful language.
On Nov 27, 2006, at 10:13 AM, Jonathan S. Shapiro wrote:
> On Mon, 2006-11-27 at 11:48 +0000, Sam Mason wrote:
>> I'd be interested in knowing what you see Java being used for. Your
>> original email mentioned application development and you just
>> the build chain now. Java for application development I can see as
>> a good thing, but wouldn't something ML or Haskell be good for the
>> build/tool chain?
> Let me back up on the Java question and explain where this is
> coming from.
> I'm interested in Java from three perspectives:
> 1. As an application language for general users. I don't intend to use
> it this way, but it will be important to some customers and sooner or
> later we need to support it. In addition, we will ultimately need
> to run
> some things that use Java as an embedded language, so eventually we
> Java no matter what. HOWEVER, this is a long-term issue, and not one
> that should influence our development path right now.
> 2. As a language for writing utility domains, where the domains are
> "sealed" (all symbols resolved at compile time, no run-time class
> loaders) and the code is **statically compiled**.
> In this context, the role of Java is mainly to provide memory safety.
> BitC would be my first choice here, but it isn't mature enough yet.
> Note that I'm not stuck on Java per se here. What I'm after is a safe
> programming language that can be used to write domain code that is not
> performance critical. Other languages, including C#, ML, Haskell, or
> even Scheme, would meet this goal. While ML and Haskell are great
> languages, I rule them out mainly because of the lack of
> programmers who
> know them. I would frankly prefer C# to Java, but I don't see a stable
> statically compiled implementation that is available *today*.
> Another alternative would be D, but that also has the problem of a
> limited pool of programmers.
> 3. As a language for crafting some of our cross-development tools
> is the immediate issue]. For example, mkimage could very quickly be
> moved to Java and this would allow us to stop worrying about memory
> management and adopt a reasonable exceptions model, which would be
> helpful. This is actually an area where I would *really* prefer BitC.
> And I should acknowledge that the two main candidates here: mkimage
> capidl, are both tools where exit() is probably the correct
> implementation of GC. Neither program generates much garbage, and both
> programs hang on to most of their state until they exit.
> Today, we are relying on the Boehm collector for both of these, and
> appears to be working. I am very nervous about this, because
> porting the
> Boehm collector is difficult and the collector itself is not always
> predictable in its behavior.
> So let me back up here:
> For things like compilers, where GC and exception handling are
> useful, what languages are people using that I may be failing to
> coyotos-dev mailing list
> coyotos-dev at smtp.coyotos.org
More information about the coyotos-dev