Has anyone looked at how Lisp might coexist with .net, without having
to compile to the IL? Can "unmanaged" code still easily use an
interface to managed code?
Or if that doesn't work, maybe there is a push to extend Mono's .net
implementation to be more Lisp-friendly, so it's reasonable to compile
Lisp to their IL?
Please no religious flames. I would love to use Lisp, and I think it
would really be the beatdown if I could access features from
mainstream platforms easily in Lisp.
It depends upon the granularity of interoperation desired.
The easiest route for fine-grained interop is to expose the .Net stuff as
COM objects and consume COM as per normal on the legacy (CL) side, or ,if
you want to go in the other direction, expose your CL stuff as COM for
consumption by .Net. .Net interop with COM is very good, and all necessary
wrapper generation is automatic. Unfortunately, COM support varies quite a
bit amongst CLs - you didn't mention which one you're using.
Or, you can host the CLR in a managed C++ bridge, then expose an interface
to that for consumption via FFI. This is likely to be a lot of work, as each
entry point will have to be reflected in the FFI layer, with no automated
support.
For large-grained interop the answer is undoubtedly to have full
bi-directional SOAP and WSDL support in CL. This would allow CL to interop
with the rest of the world, and open many doors for CL as an application
server. Unfortunately, CL seems to be one of the few languages without
support for SOAP and WSDL. I would gladly pay for a portable, industrial
strength implementation.
Very fine-grained, ad hoc, transparent interop requires a language meet .Net
halfway, IMO. The end result wouldn't be CL, but could be a Lisp. I think
the Mono folks have their hands full implementing the subset they have
chosen, nevermind extensions, and I'm not sure that anyone knows what those
extensions ought to be. IL is, after all, rich enough to support C++ and
could theoretically support the recompilation of any CL with a C/C++ core.
FFI-style interop would then be a matter of some extended FFI on the CL
side, if that's all that was desired. I haven't heard word of any IL ports
on the way though....
"Robert Hanlin" <··············@yahoo.com> wrote in message
·································@posting.google.com...
> Has anyone looked at how Lisp might coexist with .net, without having
> to compile to the IL? Can "unmanaged" code still easily use an
> interface to managed code?
"Rich Hickey" <··········@NOSPAMcovad.net> writes:
> It depends upon the granularity of interoperation desired.
>
...
>
> Very fine-grained, ad hoc, transparent interop requires a language meet .Net
> halfway, IMO. The end result wouldn't be CL, but could be a Lisp. I think
> the Mono folks have their hands full implementing the subset they have
> chosen, nevermind extensions, and I'm not sure that anyone knows what those
> extensions ought to be. IL is, after all, rich enough to support C++ and
> could theoretically support the recompilation of any CL with a C/C++ core.
> FFI-style interop would then be a matter of some extended FFI on the CL
> side, if that's all that was desired. I haven't heard word of any IL ports
> on the way though....
>
For the benefit of those who do not know much about MS stuff, could
you tell us what 'IL', 'SOAP' and ' WDSL' are?
As for your comment that "the end result wouldn't be CL, but could be
a Lisp.", I really do not think it is acceptable.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Marco Antoniotti wrote:
>
> "Rich Hickey" <··········@NOSPAMcovad.net> writes:
>
>> It depends upon the granularity of interoperation desired.
>>
> ...
>>
>> Very fine-grained, ad hoc, transparent interop requires a language meet
>> .Net halfway, IMO. The end result wouldn't be CL, but could be a Lisp. I
>> think the Mono folks have their hands full implementing the subset they
>> have chosen, nevermind extensions, and I'm not sure that anyone knows
>> what those extensions ought to be. IL is, after all, rich enough to
>> support C++ and could theoretically support the recompilation of any CL
>> with a C/C++ core. FFI-style interop would then be a matter of some
>> extended FFI on the CL side, if that's all that was desired. I haven't
>> heard word of any IL ports on the way though....
>>
>
> For the benefit of those who do not know much about MS stuff, could
> you tell us what 'IL', 'SOAP' and ' WDSL' are?
IL (Intermediate Language) is the assembly-language for the bytecode
language the .NET languages compiles to. There is an extension called ILX
which enhances IL to make implementation of functional languages like ML or
Scheme easier and to support facilities like closures to be shared between
languages. AFAIK ILX is implemented as some kind of preprocessor which
compiles to regular IL.
SOAP is an RPC mechanism that uses XML for marshalling data and HTTP or
SMTP as transport layer. It is the ".NET Webservices" equivalent to IIOP in
CORBA.
WSDL (Web Service Description Language): What IDL Files are for CORBA WSDL
is for SOAP.
> As for your comment that "the end result wouldn't be CL, but could be
> a Lisp.", I really do not think it is acceptable.
There is no reason why the end result should not be like CL if one adds
support for SOAP/WSDL to CL. It is nothing special.
ciao,
Jochen
--
http://www.dataheaven.de
"Jochen Schmidt" <···@dataheaven.de> wrote in message ·················@rznews2.rrze.uni-erlangen.de...
>
> SOAP is an RPC mechanism that uses XML for marshalling data and HTTP or
> SMTP as transport layer.
SMTP?! I can see it now:
(loop for i >From 1 to limit
(format t "Format string can no longer break ~=
across multiple lines."))
Oops! "Joe Marshall" <·············@attbi.com> was seen spray-painting on a wall:
> "Jochen Schmidt" <···@dataheaven.de> wrote in message ·················@rznews2.rrze.uni-erlangen.de...
>>
>> SOAP is an RPC mechanism that uses XML for marshalling data and HTTP or
>> SMTP as transport layer.
>
> SMTP?! I can see it now:
>
> (loop for i >From 1 to limit
> (format t "Format string can no longer break ~=
> across multiple lines."))
Wrongo. Here's a little sample of such a message...
Return-Path: <····@sample.org>
Content-Disposition: inline
Content-Transfer-Encoding: base64
Content-Type: text/xml
MIME-Version: 1.0
Date: Thu, 28 Mar 2002 18:55:31 UT
To: ······@sample.org
From: ······@sample.org
Subject: >SOAP message
X-Mailer: SOAP::Lite/Perl/0.52
Soapaction: "http://www.soaplite.com/My/Examples#getStateName"
Message-Id: <·························@sample.org>
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48U09BUC1FTlY6RW52ZWxvcGUg
eG1sbnM6U09BUC1FTkM9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW5jb2Rpbmcv
IiBTT0FQLUVOVjplbmNvZGluZ1N0eWxlPSJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy9zb2Fw
L2VuY29kaW5nLyIgeG1sbnM6U09BUC1FTlY9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3Nv
YXAvZW52ZWxvcGUvIiB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvWE1MU2NoZW1h
LWluc3RhbmNlIiB4bWxuczp4c2Q9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvWE1MU2NoZW1hIj48
U09BUC1FTlY6Qm9keT48bmFtZXNwMTpnZXRTdGF0ZU5hbWUgeG1sbnM6bmFtZXNwMT0iaHR0cDov
L3d3dy5zb2FwbGl0ZS5jb20vTXkvRXhhbXBsZXMiPjxjLWdlbnN5bTMgeHNpOnR5cGU9InhzZDpp
bnQiPjEyPC9jLWdlbnN5bTM+PC9uYW1lc3AxOmdldFN0YXRlTmFtZT48L1NPQVAtRU5WOkJvZHk+
PC9TT0FQLUVOVjpFbnZlbG9wZT4=
There may be many potentially bletcherous things about SOAP, XML, and
SMTP; inability to express multi-line strings is certainly _NOT_ one
of those things...
--
(concatenate 'string "aa454" ·@freenet.carleton.ca")
http://www.cbbrowne.com/info/soap.html
"Ah, the 20th century, when the flight from reason crash-landed into
the slaughterhouse." --- James Ostrowski
"Christopher Browne" <········@acm.org> wrote in message ···················@chvatal.cbbrowne.com...
> Oops! "Joe Marshall" <·············@attbi.com> was seen spray-painting on a wall:
> > "Jochen Schmidt" <···@dataheaven.de> wrote in message ·················@rznews2.rrze.uni-erlangen.de...
> >>
> >> SOAP is an RPC mechanism that uses XML for marshalling data and HTTP or
> >> SMTP as transport layer.
> >
> > SMTP?! I can see it now:
> >
> > (loop for i >From 1 to limit
> > (format t "Format string can no longer break ~=
> > across multiple lines."))
>
> Wrongo. Here's a little sample of such a message...
[One thousand three hundred four characters,
representing an RPC,
encoded as XML,
superencoded as base64,
wrapped with MIME headers and non-standard email headers
elided]
Ah, ok. I was wrong. This *is* a good idea after all.
In the last exciting episode, "Joe Marshall" <·············@attbi.com> wrote::
> "Christopher Browne" <········@acm.org> wrote in message ···················@chvatal.cbbrowne.com...
>> Oops! "Joe Marshall" <·············@attbi.com> was seen spray-painting on a wall:
>> > "Jochen Schmidt" <···@dataheaven.de> wrote in message ·················@rznews2.rrze.uni-erlangen.de...
>> >>
>> >> SOAP is an RPC mechanism that uses XML for marshalling data and HTTP or
>> >> SMTP as transport layer.
>> >
>> > SMTP?! I can see it now:
>> >
>> > (loop for i >From 1 to limit
>> > (format t "Format string can no longer break ~=
>> > across multiple lines."))
>>
>> Wrongo. Here's a little sample of such a message...
>
> [One thousand three hundred four characters,
> representing an RPC,
> encoded as XML,
> superencoded as base64,
> wrapped with MIME headers and non-standard email headers
> elided]
>
> Ah, ok. I was wrong. This *is* a good idea after all.
Glad to see you can see reason... :-)
More seriously, the wrong you named _isn't_ one of the legitimate
wrongs. Using XML-based RPC schemes have quite enough wrongs already
without making up spurious ones... You may have named some of
them...
By the way, that 1.3K message is generated by:
SOAP::Lite
-> uri($uri)
-> proxy(············@$domain", From => ·······@$domain",
Subject => "$subject - using SMTP",
smtp => $smtp)
-> getStateName(12);
There's effectively two bytes of _actual data_ there...
--
(reverse (concatenate 'string ·············@" "enworbbc"))
http://www.cbbrowne.com/info/advocacy.html
He's not dead. He's electroencephalographically challenged.
"Christopher Browne" <········@acm.org> wrote in message ···················@chvatal.cbbrowne.com...
>
> By the way, that 1.3K message is generated by:
> SOAP::Lite
> -> uri($uri)
> -> proxy(············@$domain", From => ·······@$domain",
> Subject => "$subject - using SMTP",
> smtp => $smtp)
> -> getStateName(12);
>
> There's effectively two bytes of _actual data_ there...
That explains the high compression factor (on the order of
dividing the original message size by 2^-10).
Couple this with a typical email delay, and the stellar track
record of sendmail and I bet you can squeeze a few dozen baud out of
this baby on a good day.
I guess this is ideal if you implement your RPC server as a
little old man in a back room with a dull pencil.
Oops! "Joe Marshall" <·············@attbi.com> was seen spray-painting on a wall:
> "Christopher Browne" <········@acm.org> wrote in message ···················@chvatal.cbbrowne.com...
>>
>> By the way, that 1.3K message is generated by:
>> SOAP::Lite
>> -> uri($uri)
>> -> proxy(············@$domain", From => ·······@$domain",
>> Subject => "$subject - using SMTP",
>> smtp => $smtp)
>> -> getStateName(12);
>>
>> There's effectively two bytes of _actual data_ there...
>
> That explains the high compression factor (on the order of
> dividing the original message size by 2^-10).
You're off by about a binary order of magnitude. It's only 2^-9,
(There were 2 bytes to start with; not 1...)
> Couple this with a typical email delay, and the stellar track
> record of sendmail and I bet you can squeeze a few dozen baud out of
> this baby on a good day.
This would indeed be a dramatically stupid use of SOAP, the same way
that searches through large linear lists are a dramatically stupid use
of lists. There's nothing wrong with searches of small lists; the
"wrong" of SMTP messages diminishes in the opposite way, when the amount
of "real" payload increases, thereby diminishing the (at 2 bytes)
pathological inefficiency to more of a "dull roar."
> I guess this is ideal if you implement your RPC server as a
> little old man in a back room with a dull pencil.
Consider also that SMTP provides no guarantees of delivery time or of
delivery actually occurring and it makes such a transport scheme of
rather limited use.
--
(reverse (concatenate 'string ·············@" "enworbbc"))
http://www.cbbrowne.com/info/lsf.html
"The wrath of Holloway is nothing compared to the wrath of Moon."
-- Fred Drenckhahn
Jochen Schmidt <···@dataheaven.de> writes:
> Marco Antoniotti wrote:
>
> >
> > "Rich Hickey" <··········@NOSPAMcovad.net> writes:
> >
> >> It depends upon the granularity of interoperation desired.
> >>
> > ...
> >>
> >> Very fine-grained, ad hoc, transparent interop requires a language meet
> >> .Net halfway, IMO. The end result wouldn't be CL, but could be a Lisp. I
> >> think the Mono folks have their hands full implementing the subset they
> >> have chosen, nevermind extensions, and I'm not sure that anyone knows
> >> what those extensions ought to be. IL is, after all, rich enough to
> >> support C++ and could theoretically support the recompilation of any CL
> >> with a C/C++ core. FFI-style interop would then be a matter of some
> >> extended FFI on the CL side, if that's all that was desired. I haven't
> >> heard word of any IL ports on the way though....
> >>
> >
> > For the benefit of those who do not know much about MS stuff, could
> > you tell us what 'IL', 'SOAP' and ' WDSL' are?
>
> IL (Intermediate Language) is the assembly-language for the bytecode
> language the .NET languages compiles to. There is an extension called ILX
> which enhances IL to make implementation of functional languages like ML or
> Scheme easier and to support facilities like closures to be shared between
> languages. AFAIK ILX is implemented as some kind of preprocessor which
> compiles to regular IL.
>
> SOAP is an RPC mechanism that uses XML for marshalling data and HTTP or
> SMTP as transport layer. It is the ".NET Webservices" equivalent to IIOP in
> CORBA.
>
> WSDL (Web Service Description Language): What IDL Files are for CORBA WSDL
> is for SOAP.
Thanks.
>
> > As for your comment that "the end result wouldn't be CL, but could be
> > a Lisp.", I really do not think it is acceptable.
>
> There is no reason why the end result should not be like CL if one adds
> support for SOAP/WSDL to CL. It is nothing special.
From what you said, it does not seem all that bad, as long as you
stick to SOAP and WSDL. So the problems are confined to IL and CLE,
isn't it?
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
In the last exciting episode, Marco Antoniotti <·······@cs.nyu.edu> wrote::
> Jochen Schmidt <···@dataheaven.de> writes:
>> Marco Antoniotti wrote:
>> There is no reason why the end result should not be like CL if one adds
>> support for SOAP/WSDL to CL. It is nothing special.
>
> From what you said, it does not seem all that bad, as long as you
> stick to SOAP and WSDL. So the problems are confined to IL and CLE,
> isn't it?
Yes and no.
Apparently Microsoft has been patenting everything under the sun,
which probably includes stuff that you might have implemented five
years ago in CL. That doesn't prevent them from saying "we've got a
patent; see us in court!"
--
(concatenate 'string "chris" ·@cbbrowne.com")
http://www.cbbrowne.com/info/rdbms.html
Rules of the Evil Overlord #170. "I will be an equal-opportunity
despot and make sure that terror and oppression is distributed fairly,
not just against one particular group that will form the core of a
rebellion." <http://www.eviloverlord.com/>
Marco Antoniotti <·······@cs.nyu.edu> wrote in message news:<···············@octagon.mrl.nyu.edu>...
> For the benefit of those who do not know much about MS stuff, could
> you tell us what 'IL', 'SOAP' and ' WDSL' are?
SOAP and WSDL are not MS stuff. They have wide support amongst
platforms/languages/vendors. These came up as first hits on Google for
"soap" and "wsdl":
http://www.w3.org/TR/SOAP/
http://www.w3.org/TR/wsdl
Here are some links on the MS stuff:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconmicrosoftintermediatelanguagemsil.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpovrintroductiontonetframeworksdk.asp
Rich Hickey wrote:
>
> Marco Antoniotti <·······@cs.nyu.edu> wrote in message news:<···············@octagon.mrl.nyu.edu>...
>
> > For the benefit of those who do not know much about MS stuff, could
> > you tell us what 'IL', 'SOAP' and ' WDSL' are?
>
> SOAP and WSDL are not MS stuff. They have wide support amongst
> platforms/languages/vendors. These came up as first hits on Google for
> "soap" and "wsdl":
>
> http://www.w3.org/TR/SOAP/
> http://www.w3.org/TR/wsdl
>
Err..."not MS stuff" in the sense that most of the
specs' authors work for Microsoft?
Ian Wild <···@cfmu.eurocontrol.be> wrote in message news:<·················@cfmu.eurocontrol.be>...
> Rich Hickey wrote:
> > SOAP and WSDL are not MS stuff. They have wide support amongst
> > platforms/languages/vendors. These came up as first hits on Google for
> > "soap" and "wsdl":
> >
> > http://www.w3.org/TR/SOAP/
> > http://www.w3.org/TR/wsdl
>
> Err..."not MS stuff" in the sense that most of the
> specs' authors work for Microsoft?
SOAP is as not MS as C++. It was mostly developed by Dave Winer.
The last time I looked (and I don't care enough to look), there were
dozens of interoperable implementations of which a couple were MS.
If the MS taint bothers you, SOAP is almost XML-RPC, which is very
"not MS".
If you want to see how "not MS" SOAP, XML-RPC, and even web services
can be, read Winer's Scripting News (www.scripting.com). Yes, he
writes about other stuff, so if SOAP is all you're interested in,
you get to search. (Winer doesn't seem to be a huge fan of WDSL.)
-andy
In <····························@posting.google.com>,
······@earthlink.net (Andy Freeman) wrote:
| SOAP is as not MS as C++. It was mostly developed by Dave Winer.
That is not my understanding. Dave Winer developed XML-RPC. SOAP was a
Microsoft initiative. The names on the early versions of the SOAP spec
were a shill for M$ "solutions", a clown from M$, some ciphers from M$,
and Winer.
| If the MS taint bothers you, SOAP is almost XML-RPC, which is very
| "not MS".
That's like saying a tank is almost a dune buggy.
As with all things Microsoft, documents have a way of vanishing. By now
it's SOAP 1.2, so the SOAP 1.0 spec isn't easy to find. Instead, one is
supposed to rely on histories provided by principals, eg
http://www.xml.com/pub/a/2001/04/04/soap.html
http://davenet.userland.com/1999/09/12/anEndToTheUberoperatingSystem
There's tons of stuff in the xml-dev mailing list archives, and this:
http://www.oasis-open.org/cover/soap.html
"Andy Freeman" <······@earthlink.net> wrote
> Ian Wild <···@cfmu.eurocontrol.be> wrote in message
> > Rich Hickey wrote:
> > > SOAP and WSDL are not MS stuff. They have wide support amongst
> > > platforms/languages/vendors. These came up as first hits on Google for
> > > "soap" and "wsdl":
> > >
> > > http://www.w3.org/TR/SOAP/
> > > http://www.w3.org/TR/wsdl
> >
> > Err..."not MS stuff" in the sense that most of the
> > specs' authors work for Microsoft?
>
> SOAP is as not MS as C++. It was mostly developed by Dave Winer.
> The last time I looked (and I don't care enough to look), there were
> dozens of interoperable implementations of which a couple were MS.
Yes, but M$ and IBM have patents on SOAP, WDSL and UDDI.
It seems that they finally agreed to the W3C royalty free charter, but are
still trying to impose licenses on other protocols extensions.
Look at :
http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2861123,00.html
All this patents stuff is really annoying.
Marc
Ian Wild <···@cfmu.eurocontrol.be> wrote in message news:<·················@cfmu.eurocontrol.be>...
> Rich Hickey wrote:
> >
> > Marco Antoniotti <·······@cs.nyu.edu> wrote in message news:<···············@octagon.mrl.nyu.edu>...
> >
> > > For the benefit of those who do not know much about MS stuff, could
> > > you tell us what 'IL', 'SOAP' and ' WDSL' are?
> >
> > SOAP and WSDL are not MS stuff. They have wide support amongst
> > platforms/languages/vendors.
>
> Err..."not MS stuff" in the sense that most of the
> specs' authors work for Microsoft?
Not MS stuff in the sense that one can write to the specs and happily
converse with Java (or Python or Perl or Linux or Oracle...), for
instance, without any MS involvement.
I don't think it matters if it is the spawn of Microsoft, or if it's
an ideal spec, or if XML is worse than sexprs or whatever. Everyone
else has agreed to use it and the sooner CL supports it, the better,
IMO.
"Rich Hickey" <··········@covad.net> wrote in message ·································@posting.google.com...
>
> I don't think it matters if it [SOAP, etc.] is the spawn of Microsoft,
> or if it's an ideal spec, or if XML is worse than sexprs or whatever.
> Everyone else has agreed to use it and the sooner CL supports it, the
> better, IMO.
And if everyone else jumped off a bridge...?
As it happens, I think improving Lisp interoperability with popular,
but idiotic ideas is a fine way to show off the advantages of Lisp,
but the argument that `everyone else has agreed to do it' just makes
me feel contrary.
"Joe Marshall" <·············@attbi.com> wrote in message news:<·····················@typhoon.ne.ipsvc.net>...
> "Rich Hickey" <··········@covad.net> wrote in message ·································@posting.google.com...
>
> >
> > I don't think it matters if it [SOAP, etc.] is the spawn of Microsoft,
> > or if it's an ideal spec, or if XML is worse than sexprs or whatever.
> > Everyone else has agreed to use it and the sooner CL supports it, the
> > better, IMO.
>
> And if everyone else jumped off a bridge...?
>
> As it happens, I think improving Lisp interoperability with popular,
> but idiotic ideas is a fine way to show off the advantages of Lisp,
> but the argument that `everyone else has agreed to do it' just makes
> me feel contrary.
Sorry, I should have said 'almost everyone else...'. However, I
didn't, and don't, advocate as a general rule doing things just
because everyone else does. What we are discussing is an interop spec,
and in the case of interop specs, everyone else matters, as does the
degree to which they agree to agree. Certainly there are many factors,
including performance and security (which are issues for SOAP), that
must be considered in the _application_ of an interop technology, but
near-universal adoption seems adequate justification for providing
support for it from a programming language. No one would be forced to
use it.
Hopefully supporting SOAP and WSDL should prove less self-destructive
than bridge jumping. (And, if one can survive the fall, the water's
not bad and there are many interesting non-idiots swimming in it).
··············@yahoo.com (Robert Hanlin) writes:
> Has anyone looked at how Lisp might coexist with .net, without having
> to compile to the IL? Can "unmanaged" code still easily use an
> interface to managed code?
>
> Or if that doesn't work, maybe there is a push to extend Mono's .net
> implementation to be more Lisp-friendly, so it's reasonable to compile
> Lisp to their IL?
>
> Please no religious flames. I would love to use Lisp, and I think it
> would really be the beatdown if I could access features from
> mainstream platforms easily in Lisp.
I think your questions are well posed. I would not mind seeing a well
thought out critique of why the .NET architecture is so unfriendly to
Common Lisp.
I also like your idea of asking the developers of Mono to "embrace and
extend" (pun intended :) ) their architecture to accommodate CL.
Whether they will accept it or not, it is another problem.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
From: Duane Rettig
Subject: Re: Accessing .net features without the .evil
Date:
Message-ID: <4it5z283k.fsf@beta.franz.com>
Marco Antoniotti <·······@cs.nyu.edu> writes:
> ··············@yahoo.com (Robert Hanlin) writes:
>
> > Has anyone looked at how Lisp might coexist with .net, without having
> > to compile to the IL? Can "unmanaged" code still easily use an
> > interface to managed code?
> >
> > Or if that doesn't work, maybe there is a push to extend Mono's .net
> > implementation to be more Lisp-friendly, so it's reasonable to compile
> > Lisp to their IL?
> >
> > Please no religious flames. I would love to use Lisp, and I think it
> > would really be the beatdown if I could access features from
> > mainstream platforms easily in Lisp.
>
> I think your questions are well posed. I would not mind seeing a well
> thought out critique of why the .NET architecture is so unfriendly to
> Common Lisp.
See
http://groups.google.com/groups?q=g:thl826061951d&dq=&hl=en&selm=47kp4j52c.fsf%40beta.franz.com
This list may be out-of-date, since it's been several years since we were
asked by MS to port to .NET. So it may be that things have changed, though I
doubt it, since the issues are fairly fundamental. It was well-researched
and thought out at the time, though.
> I also like your idea of asking the developers of Mono to "embrace and
> extend" (pun intended :) ) their architecture to accommodate CL.
> Whether they will accept it or not, it is another problem.
We asked MS to extend CRL (the VM architecture behind .NET) at the
time we saw these problems. They declined to make any changes at
that time. Perhaps they've reconsidered since then.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
This old post on google mentions three items:
1. Variable argument lists: .NET CLR has support for vararg
calls. It is unverifiable, so you won't see any MS language use it.
2. Multiple-inheritance: Smalltalk and Eiffel will/have implemented
multiple inheritance on .NET. It's a pain; basically, you generate
you're own dispatch tables at runtime.
3. Static method dispatch: Again, you'll need your own dispatcher. You
can get access to the type token, which would allow you to build
relatively efficient dispatch tables (i.e., you don't need to rely
on isinst or castclass, which are dead slow).
Performance will still suffer because (1) small values must be boxed
to pass it as a class, (2) tail call is painfully slow, (3) isinst and
castclass (discovering type info at runtime) are slow.
(1) means: (int+ x y) can use unboxed integers, but (+ x y) would
need to be boxed to pass into a generic + op.
Perl and Python from Activestate are taking the FFI approach. A little
shim on .NET sends all Perl/Python code to their runtime, which is
running as a COM object outside .NET.
Another alternative is to host the .NET runtime within Lisp as a
COM-object. A mild deviation of Activestate's approach.
Pinku
>>>>> Duane Rettig writes:
Duane> See
Duane> http://groups.google.com/groups?q=g:thl826061951d&dq=&hl=en&selm=47kp4j52c.fsf%40beta.franz.com
Duane> This list may be out-of-date, since it's been several years
Duane> since we were asked by MS to port to .NET. So it may be
Duane> that things have changed, though I doubt it, since the
Duane> issues are fairly fundamental. It was well-researched and
Duane> thought out at the time, though.
>> I also like your idea of asking the developers of Mono to
>> "embrace and extend" (pun intended :) ) their architecture to
>> accommodate CL. Whether they will accept it or not, it is
>> another problem.
Duane> We asked MS to extend CRL (the VM architecture behind .NET)
Duane> at the time we saw these problems. They declined to make
Duane> any changes at that time. Perhaps they've reconsidered
Duane> since then.
--
"Trying is the first step towards failing." -- Homer Simpson
Thanks
I remembered that post. I guess I'd like something more detailed.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
On 07 May 2002 11:43:23 -0400, Marco Antoniotti <·······@cs.nyu.edu> wrote:
> I think your questions are well posed. I would not mind seeing a well
> thought out critique of why the .NET architecture is so unfriendly to
> Common Lisp.
Some time ago Duane Rettig posted here a fairly detailed article on this
issue. And no, I unfortunately don't have a reference.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
From: Chris Double
Subject: Re: Accessing .net features without the .evil
Date:
Message-ID: <usn53dk77.fsf@double.co.nz>
··············@yahoo.com (Robert Hanlin) writes:
> Has anyone looked at how Lisp might coexist with .net, without
> having to compile to the IL? Can "unmanaged" code still easily use
> an interface to managed code?
While not Common Lisp, I've been porting Goo [1] to run on .NET
[2]. Goo is a Scheme like language mixing features of CLOS, Scheme and
Dylan. The implementation compiles to C which I compiled using Managed
C++ to generate IL. From there I created an FFI for Goo to call the
.NET framework. I don't see any reason why a similar approach wouldn't
work for CLisp or the like.
The port is still rough and performance is about 75% of the original C
compiled Goo code.
One problem at the moment is the fact that Goo uses the Boehm
collector and I can't retrofit the .NET collector as collectable
memory has a different type to that of normal memory. I didn't want to
make wholesale changes to the Goo code so I went for keeping Boehm for
Goo allocated memory, and using the .NET collector for calls to
managed code and holding managed objects.
A better approach would probably be to write a new backend for the Goo
compiler to generate completely managed code or use C# but I wanted
something working relatively quickly. And it's definitely nice to be
able to use Soap, Winforms, and other things from a Lisp language.
[1] http://www.googoogaga.org
[2] http://radio.weblogs.com/0102385
Chris.
--
http://www.double.co.nz