Re: bytecode unification for scripting languages

[Shriram Krishnamurthi <sk@cs.brown.edu>]

Noel Welsh wrote:

> [.NET]
> Do you think it is appropriate for Scheme?  

Fairly so, yes.

>					      I assumed
> the CIL would have forced you into a single dispatch
> OO world, possibly without closures (which you'd have
> to fake with classes).  

Lookit, the same goes for standard hardware, but I don't see anyone
arguing that the x86 or SPARC is inappropriate for Scheme.  The wins
with any intermediate format of this sort are:

- a run-time system (object/value creation, GC, etc)
- native code generation made easy
- interoperability
- a big run-time library

In each category, .NET seems to stack up very nicely against the JVM.
I don't know how Parrot or any of these other projects would stack,
but then they don't exist, either.  There are several ways in which
.NET seems better than the JVM, the most dramatic being tail calls.

We don't get multiple dispatch.  But PLT Scheme doesn't use multiple
dispatch anyway.  (This isn't to say I'm not a pretty big fan of
multiple dispatch, just that as a practical matter, it's not yet an
issue for us.)

We don't get native closures.  But we do get first-class methods,
which is better than objects-only.  Also, there was talk at MS that
the next major release (and hence C#) may come with native closures.

Units would be a bit of work, but perhaps less so than on the JVM,
since .NET does have a reference semantics (if you want to implement
units as importing boxes rather than values).  And it's not like some
other VM is going to see the light and implement units anyway.

It may actually be possible to get mixins right!  I'm still looking
into this.

The standard classes probably don't feel very Schemey.  You could, on
the other hand, at least in theory, use Haskell's or ML's standard
library if the mood struck you.  But do tell: does GUI programming in
MrEd feel very Schemey?

Shriram