> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org [mailto:squeak-dev-
> admin at lists.squeakfoundation.org] On Behalf Of Bert Freudenberg
> Sent: Monday, February 11, 2002 2:09 AM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: RE: lets co-opt the .net engines
> 
> On Sat, 9 Feb 2002, PhiHo Hoang wrote:
> 
> > On that note, a backend for Squeak compiler to generate CIL would be
> > very cool.
> >
> > http://research.microsoft.com/projects/ilx/
> 
> Does it provide support for dynamically typed languages? How
officially
> supported is it? You know, MS-research ~= MS ...
> 
> AFAIK, David Simmons had to basically implement his own VM on top of
.net
> to support SmallScript (correct me if I'm wrong).

.NET has some facilities for invoking methods dynamically. 

They are not as fast as one might like if you want performance that is
competitive with classic Smalltalk VM implementations.

There are a number of other issues that one must craft to provide
support for features like blocks, contexts, etc. There are many things
one must do to provide core-class/framework correspondence. There are no
facilities in .NET v1 for GC space enumeration of objects by reference
or by instance. 

However, all that said, the .NET architecture has excellent metadata
facilities and due to my interaction with Microsoft, sufficient opcodes
to implement portable IL based custom binding and dispatch mechanisms
[unlike the JVM]. So while the .NET architecture is not ideal for
dynamically typed [dynamic/scripting] languages, it has a solid
extensible architecture for creating implementations with acceptable
performance. 

It is not possible to obtain state-of-the-art dynamic language
performance, that would have to crafted directly into the .NET jit [and
that work has not been done, but I believe that Microsoft would like to
have such capabilities in future versions].

However the biggest issues are with Smalltalk itself, not the CLR. To
really interact with other languages means that Smalltalk needs
additional facilities to support the full range of cross-language object
model features defined by the CLR. This is a very big issue if you want
to subclass, or be subclassed by other languages. And it is a big issue
for consuming/invoking methods properly throughout the libraries, or
producing libraries for other languages to consume. If you are willing
to write a lot of "hand-glue" libraries in C# then you can work around
this issue on an assembly-by-assembly (case-by-case) basis. 

However, a case-by-case basis is really unworkable in a general ASP
scripting world, or for general components and applications. I think it
is unacceptable to have to write C# wrappers to access ordinary code.
I.e., this is equivalent to having to write primitives to access C/C++
libraries in a classic world.

I strongly assert that classic Smalltalk requires additional features
including optional types to support fully automatic code integration. It
is those very kinds of features which SmallScript provides.

-- Dave S. [SmallScript LLC]

SmallScript for the AOS & .NET Platforms
David.Simmons at SmallScript.com | http://www.smallscript.org

> 
> -- Bert
>