Given the thread "Lot's of new (incompatible) Lisp dialects" and the
reaction on this newsgroup to Rich Hickey's DotLisp (paraphrasing:
"What's the point of not implementing /all/ of CL on .NET before
releasing it."), what *IS* the approach to take with .NET, assuming
you don't mind Microsoft's approach with .NET?
That is, if you really want to start with all of CL you have to bend
all of the CL internal implementation to the .NET Framework internally
and hide all of .NET from the CL user, then decide which parts of .NET
to allow as CL extensions.
To follow the Microsoft way you end up with CL.NET, something that's
not exactly compatible with CL, but has essentially the same
functionality with .NET features as first class extensions to the
CL.NET system.
Specifically, I'm really asking, assuming the latter is the a useful
way to go (and I know MS-haters and others won't agree with that
assumption), what CL implementation can be used as a base for .NET
development of a CL.NET platform?
Regards,
Mark Hurd, B.Sc.(Ma.)(Hons.)
Mark Hurd wrote:
> Given the thread "Lot's of new (incompatible) Lisp dialects" and the
> reaction on this newsgroup to Rich Hickey's DotLisp (paraphrasing:
> "What's the point of not implementing /all/ of CL on .NET before
> releasing it."), what *IS* the approach to take with .NET, assuming
> you don't mind Microsoft's approach with .NET?
MS has a history of abandoning research projects... On a related
note, when Sun first released Java, several interoperable languages
sprung up targetting the JVM bytecode -- where did they go?
> That is, if you really want to start with all of CL you have to bend
> all of the CL internal implementation to the .NET Framework internally
> and hide all of .NET from the CL user, then decide which parts of .NET
> to allow as CL extensions.
>
> To follow the Microsoft way you end up with CL.NET, something that's
> not exactly compatible with CL, but has essentially the same
> functionality with .NET features as first class extensions to the
> CL.NET system.
>
> Specifically, I'm really asking, assuming the latter is the a useful
> way to go (and I know MS-haters and others won't agree with that
> assumption), what CL implementation can be used as a base for .NET
> development of a CL.NET platform?
Common Lisp is an ANSI standard for Lisp systems. It is a norm for
what Lisp is or should be; it is the specification for a particular
class of implementation. If you want to base a Lisp system on .NET,
great; but its not Common Lisp until it meets the spec.
My two cents,
Daniel
On Aug 20, 11:05 am, D Herring <········@at.tentpost.dot.com> wrote:
> Mark Hurd wrote:
> > Given the thread "Lot's of new (incompatible) Lisp dialects" and the
> > reaction on this newsgroup to Rich Hickey's DotLisp (paraphrasing:
> > "What's the point of not implementing /all/ of CL on .NET before
> > releasing it."), what *IS* the approach to take with .NET, assuming
> > you don't mind Microsoft's approach with .NET?
>
> MS has a history of abandoning research projects... On a related
> note, when Sun first released Java, several interoperable languages
> sprung up targetting the JVM bytecode -- where did they go?
.NET is a lot more than a research project now, but as a VB6 developer
I know your sentiment is still valid.
> > That is, if you really want to start with all of CL you have to bend
> > all of the CL internal implementation to the .NET Framework internally
> > and hide all of .NET from the CL user, then decide which parts of .NET
> > to allow as CL extensions.
>
> > To follow the Microsoft way you end up with CL.NET, something that's
> > not exactly compatible with CL, but has essentially the same
> > functionality with .NET features as first class extensions to the
> > CL.NET system.
>
> > Specifically, I'm really asking, assuming the latter is the a useful
> > way to go (and I know MS-haters and others won't agree with that
> > assumption), what CL implementation can be used as a base for .NET
> > development of a CL.NET platform?
>
> Common Lisp is an ANSI standard for Lisp systems. It is a norm for
> what Lisp is or should be; it is the specification for a particular
> class of implementation. If you want to base a Lisp system on .NET,
> great; but its not Common Lisp until it meets the spec.
Yeah, but that's the 'Microsoft way' for .NET I mention above. C# is a
new language for .NET, but VB.NET is VB with .NET changes, J# has .NET
specifics (and isn't necessarily a good example for other legal
reason), even C++ has been modified for .NET (though it is the least
modified against the standard -- extensions excluded of course). Third
party languages I'm not as familiar with but AFAIK they all say
they're Language.NET, not Language as per current standard with .NET
extensions.
Regards,
Mark Hurd, B.Sc.(Ma.)(Hons.)
(message (Hello 'Mark)
(you :wrote :on '(Mon, 20 Aug 2007 01:28:27 -0000))
(
MH> Specifically, I'm really asking, assuming the latter is the a useful
MH> way to go (and I know MS-haters and others won't agree with that
MH> assumption), what CL implementation can be used as a base for .NET
MH> development of a CL.NET platform?
there's already some 5 pseudo-CLs for .NET, of which about 3 are
more-or-less alive; are you sure you want to implement 6th crappy-lisp?
on the other hand, I can tell about my experience with ABCL -- it's
implementation of CL for JVM. it aim's to be standard-compliant (and it
almost is, except few bugs), and at same time interfacing with Java is very
easy. built-in FFI is somewhat too low-level, but there are at least two
more FFI solutions:
1. jfli-abcl (jfli interface to ABCL FFI). it requires you to declare which
classes you need, it maps Java packages onto Lisp packages, and requires you
to write full class names, like that:
(Query.setQueryType query *Query.queryTypeSelect*)
a bit more verbose that in Java, but i think it's not problem at all, as
long as Lisp features allow to write more compact code.
2. dynamic FFI (don't remember the name, afaik it's 'stolen' from some
Scheme-on-JVM implementation) -- it allows to write only method name, it
resolves which method to call automatically in runtime, thus has some
overhead.
i'm using jfli-abcl and i'm quite happy with it -- i can work with many Java
libraries in quite natural way. certainly, if i'm working with library
intensively, i'm writing wrappers -- because simply Java libraries do not
have niceties like first-order functions, macros and dynamic typing. if i'd
like to work exactly like in Java, i'd use Java, right?
interfacing in other way is quite easy too -- it's possible to implement
Java classes in Lisp. well, afair it's not possible to implement class
statically -- so it will be seen by Java on load, but i think we have all
machinery for this and it won't be to complex to implement this if there
would be a need.
so, there is no excuse to not implement full Common Lisp under .NET.
implementation is interesting as long as it is full CL -- so it's possible
to write code using CL spec as documentation, load CL libraries and
programs, and be able to switch to other CL implementation (porting foreign
calls, of course).
if it's Lisp, but not CL, very few people would like to do anything serious
with it, as their code will be locked-in in single implementations, that can
be freaky, buggy, and die one day without a notice. (if it would be freaky,
buggy, but CL they would at least have chance to migrate to other CL).
certainly, implementation can take best from two worlds, implementing both
full CL language and .net-integrated language for easy FFI etc. if that
would be finely integrated, that can attract both CL developers and .net
developers. but it's quite a lot of work to implement full CL. although
ABCL's author have proved that it's doable by a single person (some code is
borrowed from other open source Lisps, but i don't think it's a problem).
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"choose no life")
On Aug 20, 5:27 pm, "Alex Mizrahi" <········@users.sourceforge.net>
wrote:
> (message (Hello 'Mark)
> (you :wrote :on '(Mon, 20 Aug 2007 01:28:27 -0000))
> (
>
> MH> Specifically, I'm really asking, assuming the latter is the a useful
> MH> way to go (and I know MS-haters and others won't agree with that
> MH> assumption), what CL implementation can be used as a base for .NET
> MH> development of a CL.NET platform?
>
> there's already some 5 pseudo-CLs for .NET, of which about 3 are
> more-or-less alive; are you sure you want to implement 6th crappy-lisp?
If I did, it would be extending DotLisp to CL, but as a Lisp-1
interpreter only at the moment, it would be a lot of work. (I've had a
go at a compiler, but it was based upon some .NET features that aren't
yet as functional as I expected. As I restructured it I broke it and
haven't had time to get it going again.)
> on the other hand, I can tell about my experience with ABCL -- it's
<snip good review of ABCL and FFIs>
OK So it looks like ABCL is at least one answer to my question above
(especially seeing as C# was meant to be a Java killer :-) ). [I do
recall Rich didn't want to use GPL because it wasn't compatible with
The Mono Project.]
Regards,
Mark Hurd, B.Sc.(Ma.)(Hons.)
(message (Hello 'Mark)
(you :wrote :on '(Mon, 20 Aug 2007 09:59:43 -0000))
(
MH> OK So it looks like ABCL is at least one answer to my question above
MH> (especially seeing as C# was meant to be a Java killer :-) ).
it might be even possible to convert some stuff from Java to C#
automatically..
i know it sounds too wild, but i've just tried JConvert (utility in
MSVS2003, implemented in CL btw) to convert org.armedbear.lisp.DoubleFloat
to C#.
i didn't check if it's compilable, but result seems to be more-or-less sane
C# file.
certainly it won't be possible to reuse ABCL's compiler, but bytecode
compiler is not absolutely required by CL. still it might be possible to use
some ideas from JVM compiler
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"choose no life")
From: John Thingstad
Subject: Re: What Common Lisp base implementation to use for .NET?
Date:
Message-ID: <op.txcvt21upqzri1@pandora.upc.no>
P� Mon, 20 Aug 2007 03:28:27 +0200, skrev Mark Hurd <·········@gmail.com>:
> Given the thread "Lot's of new (incompatible) Lisp dialects" and the
> reaction on this newsgroup to Rich Hickey's DotLisp (paraphrasing:
> "What's the point of not implementing /all/ of CL on .NET before
> releasing it."), what *IS* the approach to take with .NET, assuming
> you don't mind Microsoft's approach with .NET?
>
> That is, if you really want to start with all of CL you have to bend
> all of the CL internal implementation to the .NET Framework internally
> and hide all of .NET from the CL user, then decide which parts of .NET
> to allow as CL extensions.
>
> To follow the Microsoft way you end up with CL.NET, something that's
> not exactly compatible with CL, but has essentially the same
> functionality with .NET features as first class extensions to the
> CL.NET system.
>
> Specifically, I'm really asking, assuming the latter is the a useful
> way to go (and I know MS-haters and others won't agree with that
> assumption), what CL implementation can be used as a base for .NET
> development of a CL.NET platform?
>
> Regards,
> Mark Hurd, B.Sc.(Ma.)(Hons.)
>
Interfacing to .NET is difficult.
You need a approach as in Visual C++ which has two class systems and can
also compile C++ to CLR to make the experience plesant. Foil and RDNZL are
libraries that can interface .NET.
You have dotlisp which is not ANSI CL compatible (at all) you can
experiment with..
Perhaps the easiest path is porting Aremered bear CL to CLR. Alaa this has
not been done.