"Rich Hickey" <····@NOSPAMagentradio.com> writes:
> Does anyone know of a project or company working to produce a
> version of Common Lisp that will run on Microsoft's .NET runtime?
I guess I have to ask. Who cares?
People developing on that platform will use C#, and I can't think of a
single benefit of using that OS. It seems like marketing bull to me.
dave
In article <··············@cadet.dsl.speakeasy.net>, David Bakhash
<·····@alum.mit.edu> wrote:
> "Rich Hickey" <····@NOSPAMagentradio.com> writes:
>
> > Does anyone know of a project or company working to produce a
> > version of Common Lisp that will run on Microsoft's .NET runtime?
>
> I guess I have to ask. Who cares?
Maybe developers who want to deliver software using
Microsoft's .NET platform?
> People developing on that platform will use C#,
I wonder why Microsoft then is investing time in
the "Common Language Runtime"?
http://msdn.microsoft.com/msdnmag/nettop.asp?page=/msdnmag/issues/0900/WebPlatform/WebPlatform.asp&ad=ads.ddj.com/msdnmag/premium.htm
...
Common Language Runtime
The runtime loads and runs code written in any runtime-aware
programming language. Code that targets the runtime is called managed
code. Managed code simply means that there is a defined contract of
cooperation between natively executing code and the runtime itself.
Responsibility for tasks like creating objects, making method calls,
and so on is delegated to the runtime, which enables the runtime to
provide additional services to the executing code.
The runtime features cross-language integration, self-describing
components, simple deployment and versioning, and integrated security
services. Let's take a quick look at each of these features.
The runtime makes use of a new common type system capable of expressing
the semantics of most modern programming languages. The common type
system defines a standard set of types and rules for creating new
types. The runtime understands how to create and execute these types.
Compilers and interpreters use runtime services to define types, manage
objects, and make method calls instead of using tool or
language-specific methods.
The primary design goal for the type system is to enable deep
multilanguage integration. Code written in one language can now inherit
implementation from classes written in another language; exceptions can
be thrown from code written in one language and caught in code written
in another; and operations such as debugging and profiling work
seamlessly regardless of the languages used to write the code. This
means that developers of reusable class libraries no longer need to
create versions for each programming language or compiler, and
developers using class libraries are no longer limited to libraries
developed for the programming language they are using.
Self-describing components, which are now possible on the Microsoft
.NET Framework, simplify development and deployment and improve system
reliability. Let me explain how this works. Many services provided by
the runtime are driven by metadata, information that supplements the
executable code. Since all the information is stored together, the
executables are referred to as self-describing components.
A key advantage of self-describing components is that no other files
are needed to use the components. Separate header files are not
required for class definitions; the definitions can be obtained from
the component itself by inspecting the metadata. Separate IDL files,
type libraries, or proxy/stubs are not required to access a component
across language or process boundaries; the necessary information is
located in the component's metadata. Separate configuration information
does not need to be deployed to identify developer requested service
attributes. And best of all, since the metadata is generated from the
source code during the compilation process and stored with the
executable code, it is never out of sync with the executable.
In addition to improvements in deploying individual components, the
Microsoft .NET Framework defines an application deployment model that
addresses customer issues with the complexities of application
installation and DLL versioning (commonly known as "DLL Hell").
Services to support this model are provided by the runtime.
The Microsoft .NET Framework introduces the notion of an assembly. An
assembly is a group of resources and types, along with metadata about
those resources and types, that is deployed as a unit. The metadata is
called an assembly manifest and includes information such as a list of
types and resources visible outside the assembly. The manifest also
includes information about dependencies, such as the version of the
assemblies used when the assembly was built. Developers can specify
versioning policies to indicate whether the runtime should load the
latest version of a dependent assembly installed on the system, a
specific version, or the version used at build time.
It has always been possible for multiple copies of a software component
to reside on the same system. In general, however, only one of these
copies can be registered with the operating system or loaded for
execution. The policy for locating and loading components is global to
the system. The .NET Framework common language runtime adds the
infrastructure necessary to support per-application policies that
govern the locating and loading of components, which is generally
referred to as side-by-side deployment.
Assemblies can be private to an application or shared by multiple
applications. Multiple versions of an assembly can be deployed on a
machine at the same time. Application configuration information defines
where to look for assemblies, thus the runtime can load different
versions of the same assembly for two different applications that are
running concurrently. This eliminates issues that arise from
incompatibilities between component versions, improving overall system
stability. If necessary, administrators can add configuration
information, such as a different versioning policy, to assemblies at
deployment time, but the original information provided at build time is
never lost.
Because assemblies are self-describing, no explicit registration with
the operating system is required. Application deployment can be as
simple as copying files to a directory tree. (Things are slightly more
complicated if unmanaged components must be installed for the
application to work.) Configuration information is stored in XML files
that can be edited by any text editor.
Finally, the runtime also supplies integrated, pervasive security
services to ensure that unauthorized users cannot access resources on a
machine and that code cannot perform unauthorized actions. This
improves overall system safety and reliability. Since the runtime is
used to load code, create objects, and make method calls, the runtime
can perform security checks and enforce security policy as managed code
is loaded and executed.
The Microsoft .NET Framework provides both code access security and
role-based security. With code access security, developers can specify
the required permissions their code needs to accomplish work. For
example, code may need permission to write a file or access environment
variables. This information is stored at the assembly level, along with
information about the identity of the code. At load time and on method
calls, the runtime verifies that the code can be granted the
permissions it has asked for. If not, a security violation is reported.
Policies for granting permissions, known as trust policies, are
established by system administrators, and are based on evidence about
the code such as who published the code and where it was obtained from,
as well as the identity and requested permissions found in the
assembly. Developers can also specify permissions they explicitly don't
want, to prevent malicious use of their code by others. Programmatic
security checks can be written if the permissions required depend on
information that isn't known until runtime.
In addition to code access security, the runtime supports role-based
security. Role-based security builds on the same permissions model as
code access security, except that the permissions are based on user
identity rather than code identity. Roles represent categories of users
and can be defined at development or deployment time. Policies for
granting permissions are assigned to each defined role. At runtime, the
identity of the user on whose behalf the code is running is determined.
The runtime determines what roles the user is a member of and then
grants permissions based on those roles.
...
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Rainer Joswig <······@corporate-world.lisp.de> writes:
> I wonder why Microsoft then is investing time in
> the "Common Language Runtime"?
>
> http://msdn.microsoft.com/msdnmag/nettop.asp?page=/msdnmag/issues/0900/WebPlatform/WebPlatform.asp&ad=ads.ddj.com/msdnmag/premium.htm
Is anything more technical available?
--
--Per Bothner
···@bothner.com http://www.bothner.com/~per/
In article <··············@bothner.com>, Per Bothner <···@bothner.com>
wrote:
> Rainer Joswig <······@corporate-world.lisp.de> writes:
>
> > I wonder why Microsoft then is investing time in
> > the "Common Language Runtime"?
> >
> > http://msdn.microsoft.com/msdnmag/nettop.asp?page=/msdnmag/issues/0900/WebPlatform/WebPlatform.asp&ad=ads.ddj.com/msdnmag/premium.htm
>
> Is anything more technical available?
You may look at the SDK you can download from their developer web site.
Maybe there is more info. It's 86 Mb. Sigh.
http://msdn.microsoft.com/downloads/default.asp?URL=/code/sample.asp?url=/msdn-files/027/000/976/msdncompositedoc.xml
See for more info:
http://www.microsoft.com/presspass/features/2000/jul00/07-11.NETframework.asp
http://www.4guysfromrolla.com/webtech/071700-1.shtml
(know your enemy)
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
"David Bakhash" <·····@alum.mit.edu> wrote
> "Rich Hickey" <····@NOSPAMagentradio.com> writes:
>
> > Does anyone know of a project or company working to produce a
> > version of Common Lisp that will run on Microsoft's .NET runtime?
>
> I guess I have to ask. Who cares?
I do or I wouldn't be asking.
> People developing on that platform will use C#,
That ends it then ;-)
>and I can't think of a
> single benefit of using that OS.
Well, it's not for everyone, but I certainly don't think yet another OS
flame war would be interesting or productive.
> It seems like marketing bull to me.
It may well be. Nevertheless, I am interested in whether the Common Language
Runtime (CLR) is rich enough to support Common Lisp. It seems they have
built a simple object model (no MI, no generics so far) right into the
'intermediate language', potentially leading to homogenization/constraint of
the languages that support it. MS has announced CLR support from themselves
and others for VB, C#, Eiffel, Cobol, Python, Perl, APL, Smalltalk, Scheme,
ML, Haskell, Oberon and others. Common Lisp is notably absent.
I, personally, and without advocating others even consider doing the same,
would like to be able to use Common Lisp to build software that runs under
the .NET runtime, and to utilize libraries and frameworks written by others
in other languages, conveniently and transparently, whenever it is
productive to do so.
"Rich Hickey" <····@NOSPAMagentradio.com> writes:
> It may well be. Nevertheless, I am interested in whether the Common Language
> Runtime (CLR) is rich enough to support Common Lisp. It seems they have
> built a simple object model (no MI, no generics so far) right into the
> 'intermediate language', potentially leading to homogenization/constraint of
> the languages that support it. MS has announced CLR support from themselves
> and others for VB, C#, Eiffel, Cobol, Python, Perl, APL, Smalltalk, Scheme,
> ML, Haskell, Oberon and others. Common Lisp is notably absent.
Generics would be handled before converting to the VM code. Also, you
don't need to have a correspondence between VM objects and CL
objects. If they can support Eiffel, they certainly can support MI. In
order to use the constant Pi, you need to inherit from a class Math in
that language. And if they can support ML with its functors between
structures, you have all you need to build generics. A VM is simply an
abstract machine to compile for. If the object model is simple, you
can either ignore it or build upon it. That this isn't simple to do
with the Java VM has to do with the security model and the bytecode
verifier.
BTW, I missed the announcement about Scheme. Which Scheme and is it
supported with full continuations?
--
Lieven Marchand <···@bewoner.dma.be>
Lambda calculus - Call us a mad club
"Lieven Marchand" <···@bewoner.dma.be> wrote in message
···················@localhost.localdomain...
> "Rich Hickey" <····@NOSPAMagentradio.com> writes:
>
> > It may well be. Nevertheless, I am interested in whether the Common
Language
> > Runtime (CLR) is rich enough to support Common Lisp. It seems they have
> > built a simple object model (no MI, no generics so far) right into the
> > 'intermediate language', potentially leading to
homogenization/constraint of
> > the languages that support it. MS has announced CLR support from
themselves
> > and others for VB, C#, Eiffel, Cobol, Python, Perl, APL, Smalltalk,
Scheme,
> > ML, Haskell, Oberon and others. Common Lisp is notably absent.
>
> Generics would be handled before converting to the VM code.
They _could_ be, but MS has indicated they would really like to have
generics understood by the underlying runtime, eventually. See:
http://windows.oreilly.com/news/hejlsberg_0800.html
> Also, you don't need to have a correspondence between VM objects and CL
> objects.
That's true, and I'd settle for the ability to call the rest of the world
without trying to expose, and in doing so possibly constrain, Lisp'isms at
all. Some of the languages are making a lot of the fact that they'll support
cross-language implementation inheritance, but that's not a good fit for
Lisp, nor very important to me at least. However, interface implementation
will likely be necessary in order to interoperate, and could be a bear for
Lisp as it doesn't directly support the notion of class-scoped 'member
functions'. The presumption that a language provides such support pervades
what little I've seen about the .NET runtime and common type system.
> If they can support Eiffel, they certainly can support MI.
One might conclude that, but the version of Eiffel they currently support is
called Eiffel#, and has no MI, and no 'Eiffel Agents' (closures?) Who knows
what's missing from the other languages.
> BTW, I missed the announcement about Scheme. Which Scheme and is it
> supported with full continuations?
Don't know the details - a list of supported languages and their sponsors is
at:
http://www.microsoft.com/presspass/press/2000/Jul00/PDCGroundswellPR.asp
"Rich Hickey" <····@NOSPAMagentradio.com> writes:
> That's true, and I'd settle for the ability to call the rest of the world
> without trying to expose, and in doing so possibly constrain, Lisp'isms at
> all. Some of the languages are making a lot of the fact that they'll support
> cross-language implementation inheritance, but that's not a good fit for
> Lisp, nor very important to me at least. However, interface implementation
> will likely be necessary in order to interoperate, and could be a bear for
> Lisp as it doesn't directly support the notion of class-scoped 'member
> functions'.
It seems just the same problem as exporting functionality to the CORBA
or COM world which a number of CL implementations are doing just fine
now.
--
Lieven Marchand <···@bewoner.dma.be>
Lambda calculus - Call us a mad club
In article <··············@localhost.localdomain>,
Lieven Marchand <···@bewoner.dma.be> wrote:
> "Rich Hickey" <····@NOSPAMagentradio.com> writes:
> > MS has announced CLR support from themselves
> > and others for VB, C#, Eiffel, Cobol, Python, Perl, APL, Smalltalk,
Scheme,
> > ML, Haskell, Oberon and others. Common Lisp is notably absent.
This from http://www.smalltalkconsulting.com/html/CampSmalltalk2d2.html
"Why did the Lisp people bail? Rumor is that the Lisp people felt they
would loose their intellectual property regarding multiple dispatching
so no deal."
> ... A VM is simply an
> abstract machine to compile for. If the object model is simple, you
> can either ignore it or build upon it. That this isn't simple to do
> with the Java VM has to do with the security model and the bytecode
> verifier.
Also from above link:
"Next we got an example of the bytecode, the first issue David had was
that classes aren't first class objects, but you can build a first
class object using the class information. The UVM also doesn't support
dynamic messaging in the raw VM, so David needed to build a dynamic
dispatcher, Microsoft is aware of these problems and this could change."
dm
Sent via Deja.com http://www.deja.com/
Before you buy.
"Lieven Marchand" <···@bewoner.dma.be> wrote in message
···················@localhost.localdomain...
> "Rich Hickey" <····@NOSPAMagentradio.com> writes:
>
> > It may well be. Nevertheless, I am interested in whether the Common
Language
> > Runtime (CLR) is rich enough to support Common Lisp. It seems they have
> > built a simple object model (no MI, no generics so far) right into the
> > 'intermediate language', potentially leading to
homogenization/constraint of
> > the languages that support it. MS has announced CLR support from
themselves
> > and others for VB, C#, Eiffel, Cobol, Python, Perl, APL, Smalltalk,
Scheme,
> > ML, Haskell, Oberon and others. Common Lisp is notably absent.
>
> Generics would be handled before converting to the VM code. Also, you
> don't need to have a correspondence between VM objects and CL
> objects. If they can support Eiffel, they certainly can support MI. In
> order to use the constant Pi, you need to inherit from a class Math in
> that language. And if they can support ML with its functors between
> structures, you have all you need to build generics. A VM is simply an
> abstract machine to compile for. If the object model is simple, you
> can either ignore it or build upon it. That this isn't simple to do
> with the Java VM has to do with the security model and the bytecode
> verifier.
>
> BTW, I missed the announcement about Scheme. Which Scheme and is it
> supported with full continuations?
The scheme implementation is being done at NorthWestern.
http://sourceware.cygnus.com/ml/kawa/2000/msg00168.html
http://msdn.microsoft.com/events/pdc/event/special.asp
http://robot-lab.ils.nwu.edu/software/index.htm
>
> --
> Lieven Marchand <···@bewoner.dma.be>
> Lambda calculus - Call us a mad club
-- Dave S. [www.qks.com - SmallScript incl/MS.NET]
"Rich Hickey" <····@NOSPAMagentradio.com> wrote in message
······························@news.randori.com...
> "David Bakhash" <·····@alum.mit.edu> wrote
> > "Rich Hickey" <····@NOSPAMagentradio.com> writes:
> >
> > > Does anyone know of a project or company working to produce a
> > > version of Common Lisp that will run on Microsoft's .NET runtime?
> >
> > I guess I have to ask. Who cares?
>
> I do or I wouldn't be asking.
>
> > People developing on that platform will use C#,
>
> That ends it then ;-)
>
> >and I can't think of a
> > single benefit of using that OS.
>
> Well, it's not for everyone, but I certainly don't think yet another OS
> flame war would be interesting or productive.
>
> > It seems like marketing bull to me.
>
> It may well be. Nevertheless, I am interested in whether the Common
Language
> Runtime (CLR) is rich enough to support Common Lisp. It seems they have
> built a simple object model (no MI, no generics so far) right into the
> 'intermediate language', potentially leading to homogenization/constraint
of
> the languages that support it. MS has announced CLR support from
themselves
> and others for VB, C#, Eiffel, Cobol, Python, Perl, APL, Smalltalk,
Scheme,
> ML, Haskell, Oberon and others. Common Lisp is notably absent.
I'm the architect and principal implementor for the Smalltalk (SmallScript)
implementation that targets the Microsoft .NET platform. The SmallScript
language supports optional typing, multi-methods, and behavioral-types
(interfaces) which are effectively a dynamic form of multiple inheritance.
Smalltalk-2000/SmallScript requires a very rich reflective object model and
includes namespaces, first-class types, closures, first-class functions (as
opposed to methods) that incl/FFI's, hi-performance BigNums, and a large set
of other language extensions above and beyond QKS Smalltalk-98.
There are some real challenges to implementing efficient dynamic language
systems and specifically multi-methods on Version-1 of the .NET platform. We
currently have very hi-performance multi-methods in the next version of our
own VM (AOS Platform) and we are working to achieve something that is at
least acceptibly comparable on the Microsoft .NET platform.
As far as static multiple-inheritance, the .NET platform does not support a
common MI model -- well actually it doesn't support MI but like many
unsupported elements it really comes down to 3rd party solutions being
standardized. However, the Microsoft Visual C++ folks have addressed the
challenges with "a solution". I.e., VC++ supports the .NET platform. The
.NET platform has a rich and extensible static-metadata system that plays a
fundamental role in addressing many of these kind of cross-language
challenges.
>
> I, personally, and without advocating others even consider doing the same,
> would like to be able to use Common Lisp to build software that runs under
> the .NET runtime, and to utilize libraries and frameworks written by
others
> in other languages, conveniently and transparently, whenever it is
> productive to do so.
At this time, I see no technical reason why an implementation can't be built
for the .NET platform. There are certainly some real challenges for
achieving good/acceptable performance but what makes .NET really interesting
are the benefits of a successful implementation effort for the .NET
platform: the cross-language interop/debugging and related Microsoft ASP/Web
Services, the Microsoft integrated cross-language IDE development and design
center, and the security. It is also worth noting that Microsoft has
indicated that the first general (MSDN) beta of the .NET technology won't
even be out of for another couple months and the golden release is probably
a year away.
I believe the Franz guys looked at .NET early on. I believe there are other
folks considering doing a Lisp implementation at this time. We at QKS are
pondering the idea of a scheme implementation to be included with
SmallScript.
-- Dave Simmons [www.qks.com - SmallScript incl/MS.NET]
Rich Hickey wrote:
> I am interested in whether the Common Language
> Runtime (CLR) is rich enough to support Common Lisp. It seems they have
> built a simple object model (no MI, no generics so far) right into the
> 'intermediate language', potentially leading to homogenization/constraint of
> the languages that support it. MS has announced CLR support from themselves
> and others for VB, C#, Eiffel, Cobol, Python, Perl, APL, Smalltalk, Scheme,
> ML, Haskell, Oberon and others. Common Lisp is notably absent.
remember Microsoft "Bob" ? I don't expect MS to like CL at all. but some of
those others are pretty obscure...
the CLR biz is the equiv of saying "all object models are alike", when we know
they aren't.
sounds like Microslug is trying to end-run Java...it also sounds like the
1980-era UCSD p-system: you'd compile whatever into p-code, which was an
intermediate byte-code, and that would get interpreted on-the-fly at runtime. I
don't know how many languages ever had compilers for it, but I recall the pascal
being reasonably usable...
-- clint
David Bakhash <·····@alum.mit.edu> wrote in message
···················@cadet.dsl.speakeasy.net...
> "Rich Hickey" <····@NOSPAMagentradio.com> writes:
>
> > Does anyone know of a project or company working to produce a
> > version of Common Lisp that will run on Microsoft's .NET runtime?
>
> I guess I have to ask. Who cares?
>
> People developing on that platform will use C#, and I can't think of a
> single benefit of using that OS. It seems like marketing bull to me.
Actually, of all the stuff the MS has dumped on the market in the past, this
Common Runtime thing is probably the most interesting.
The real market here is the server side business market, the market where
Java seems to being doing pretty well. Server side Java is at the point
where is pretty much runs "fast enough", and is actually pretty portable
across machines.
MS Runtime is clearly looking at the same kind of thing. Sure, I guess you
can write client apps using standard Windows controls and what not, but if
the Common Runtime ports to, say, a Unix box, those client apps most
probably won't.
MS is trying to out Java Sun by making a more flexible VM that is more
adaptable to other languages and has a built in component object model. It's
one of those things that sounds pretty promising, but I'm going to wait 2
years to see what comes out of it. Specifically if they release the Runtime
and port it. IBM has already mentioned that they'd support it if MS frees it
up.
You'd think from a Lisp point view, that CLISP would be able to port fairly
quickly, depending on how close the respective VMs match. It would certainly
be a bonus for CLISP, as it would (theoretically) get a "free" compiler out
of the deal.
It's going to be interesting to see these other languages try to lever on
the constructs of the VM that aren't native to the language, like interfaces
and such, so that they'll support the runtime more completely and be able to
be a better MS citizen.
Of course, it's all probably a trick, and we know about the wizard behind
the curtain, but from a server side program point of view, I think whole
idea is pretty good. Port the runtime across platforms, then port Java to
the runtime, and then interesting things can happen.
Will Hartung
(······@home.com)
And Rich Hickey writes:
- Does anyone know of a project or company working to produce a version of
- Common Lisp that will run on Microsoft's .NET runtime?
A quality one could be, um, painful. CL has all sorts of nice floating-
point routines that work correctly. MS's NGWS runtime does not. For
example, CL has the FLOATING-POINT-INEXACT condition type, but the .NET
VM does not give access to FP hardware exceptions, so you'll have to
determine that the hard way. That's a shame, as all hardware that
currently runs MS OSes either has fine FP hardware or no FP hardware.
The rounding mode is also fixed, so an implementation of interval
arithmetic will need to go the difficult, slow way. I'm also unsure
of their treatment of +/- 0, so getting branch cuts correct may prove
a challenge.
[They also have some fun with conversions, but I don't know how badly
that will hurt CL. A double-float that's outside the range of a
single-float will turn into a NaN, but a +/- Inf won't, afaict. I
guess a CL implementation can say all floats are the same, but the
CLR is going to hit a brick wall when going between CL and managed
Fortran / C. sigh...]
Note that all this is from reading the architecture document and VM
spec. I don't have the magical versions of various MS things handy
anywhere (and I don't want them), so I can't run it and check. And
then there's the issue of handling multiple dispatch and making it
apparent through the CLR...
Jason
···@lotus.CS.Berkeley.EDU (Edward Jason Riedy) writes:
> And Rich Hickey writes:
> - Does anyone know of a project or company working to produce a version of
> - Common Lisp that will run on Microsoft's .NET runtime?
>
> A quality one could be, um, painful. CL has all sorts of nice floating-
> point routines that work correctly. MS's NGWS runtime does not. For
> example, CL has the FLOATING-POINT-INEXACT condition type, but the .NET
> VM does not give access to FP hardware exceptions, so you'll have to
> determine that the hard way. That's a shame, as all hardware that
> currently runs MS OSes either has fine FP hardware or no FP hardware.
> The rounding mode is also fixed, so an implementation of interval
> arithmetic will need to go the difficult, slow way. I'm also unsure
> of their treatment of +/- 0, so getting branch cuts correct may prove
> a challenge.
>
> [They also have some fun with conversions, but I don't know how badly
> that will hurt CL. A double-float that's outside the range of a
> single-float will turn into a NaN, but a +/- Inf won't, afaict. I
> guess a CL implementation can say all floats are the same, but the
> CLR is going to hit a brick wall when going between CL and managed
> Fortran / C. sigh...]
>
It would be in line with the standard to take the floating point
implementation the VM provides as definitive and not the hardware
one. Also, given the far more heterogeneous FP hardware that was
around at the time of the standard work, there are not many guarantees
about FP in it. In general, for things like FLOATING-POINT-INEXACT, it
is implementation dependent whether they are signalled. I think this
design is more reasonable than the Java VM, which mandates one
specific hardware FP implementation. To implement a fully conforming
Java VM on the Alpha, you take a large performance hit in FP to
conform for some very exceptional cases almost nobody will care about.
Anyways, I don't see the numerical mathematics crows converting to
something that runs on a VM any day yet.
> Note that all this is from reading the architecture document and VM
> spec. I don't have the magical versions of various MS things handy
> anywhere (and I don't want them), so I can't run it and check. And
> then there's the issue of handling multiple dispatch and making it
> apparent through the CLR...
Is the spec available somewhere in a reasonable format without having
to have all sort of Windows stuff running?
--
Lieven Marchand <···@bewoner.dma.be>
Lambda calculus - Call us a mad club
Lieven Marchand <···@bewoner.dma.be> wrote:
> Anyways, I don't see the numerical mathematics crows converting to
> something that runs on a VM any day yet.
I may be sorely mistaken, but from what little I remember of an
interview with Anders Hejlsberg(sp?) there seem to be (plans for) two or
three different implementations of the Intermediate Language that is at
the core of the Common Language Runtime. One was a compiler from IL to
native code. Another one, meant for smaller devices, was an interpreter.
Michael
--
Michael Schuerig
···············@acm.org
http://www.schuerig.de/michael/