I thought that his was interesting.
"Anonymous methods are practical language constructs that will enable
programmers using Visual C# Whidbey to create code blocks that can be
encapsulated in a delegate and executed at a later time. They are based on a
language concept called a lambda function and are similar to those found in
Lisp and Python."
http://www.msdn.microsoft.com/vstudio/productinfo/roadmap.aspx
Harag wrote:
> I thought that his was interesting.
>
> "Anonymous methods are practical language constructs that will enable
> programmers using Visual C# Whidbey to create code blocks that can be
> encapsulated in a delegate and executed at a later time. They are based on a
> language concept called a lambda function and are similar to those found in
> Lisp and Python."
>
Yowza! Nice find. The moths are drawn to the flame.
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Harag wrote:
> I thought that his was interesting.
No, it's not IMHO. There are numerous languages that have this feature.
Why should it be interesting that some badly designed newcomer language
is catching up? ;-P
Let us know when they add macros to C# and a MOP to the .NET runtime.
> "Anonymous methods are practical language constructs that will enable
> programmers using Visual C# Whidbey to create code blocks that can be
> encapsulated in a delegate and executed at a later time. They are based on a
> language concept called a lambda function and are similar to those found in
> Lisp and Python."
>
> http://www.msdn.microsoft.com/vstudio/productinfo/roadmap.aspx
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
"Pascal Costanza" <········@web.de> wrote in message
·················@newsreader2.netcologne.de...
>
...
> No, it's not IMHO. There are numerous languages that have this feature.
> Why should it be interesting that some badly designed newcomer language
> is catching up? ;-P
Well if you enjoy lisp but have to use C# everday then it becomes
interesting and I happened to be wishing that such a thing (lambda) was
possible in C# just a day or to ago ;oP
More seriously I was actually wondering how this would better the chance of
somebody doing a cl implementation for dotnet. (...and NO Pascal , I'm not
up to it (yet), I'm still working on lacsap_db ;oP )
Harag wrote:
> "Pascal Costanza" <········@web.de> wrote in message
> ·················@newsreader2.netcologne.de...
>
> ...
>
>>No, it's not IMHO. There are numerous languages that have this feature.
>>Why should it be interesting that some badly designed newcomer language
>>is catching up? ;-P
>
> Well if you enjoy lisp but have to use C# everday then it becomes
> interesting and I happened to be wishing that such a thing (lambda) was
> possible in C# just a day or to ago ;oP
I see. You have my sympathy. ;)
> More seriously I was actually wondering how this would better the chance of
> somebody doing a cl implementation for dotnet. (...and NO Pascal , I'm not
> up to it (yet), I'm still working on lacsap_db ;oP )
I don't think so. The hardest part is probably to allow CLOS classes
inherit from other .NET classes and vice versa. Especially when you want
to combine this with the MOP, I don't see how you could achieve this.
Maybe ISLISP is a better option here. (But this is only guesswork.)
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
"Pascal Costanza" <········@web.de> wrote in message
··················@f1node01.rhrz.uni-bonn.de...
...
> I don't think so. The hardest part is probably to allow CLOS classes
> inherit from other .NET classes and vice versa. Especially when you want
> to combine this with the MOP, I don't see how you could achieve this.
>
> Maybe ISLISP is a better option here. (But this is only guesswork.)
>
So what is the exact problem(s) with the inheritance, is it static type
conversions or is the consept of a class in lisp incompatable with dotnet's
consept of a class?
If you got some reading to point me to first please point me there first. I
must add thow that what I have found either degenerates into a arithmatic(or
errors in it) war or static typing vs 'whatever' war ;o)
"Harag" <·········@psychedelic.co.za> writes:
> "Pascal Costanza" <········@web.de> wrote in message
> ··················@f1node01.rhrz.uni-bonn.de...
> ...
>> I don't think so. The hardest part is probably to allow CLOS classes
>> inherit from other .NET classes and vice versa. Especially when you want
>> to combine this with the MOP, I don't see how you could achieve this.
>>
>> Maybe ISLISP is a better option here. (But this is only guesswork.)
>>
>
> So what is the exact problem(s) with the inheritance, is it static type
> conversions or is the consept of a class in lisp incompatable with dotnet's
> consept of a class?
Common Lisp is multiple-inheritance, .NET is single inheritance.
Harag wrote:
> "Pascal Costanza" <········@web.de> wrote in message
> ··················@f1node01.rhrz.uni-bonn.de...
> ...
>
>>I don't think so. The hardest part is probably to allow CLOS classes
>>inherit from other .NET classes and vice versa. Especially when you want
>>to combine this with the MOP, I don't see how you could achieve this.
>>
>>Maybe ISLISP is a better option here. (But this is only guesswork.)
>
> So what is the exact problem(s) with the inheritance, is it static type
> conversions or is the consept of a class in lisp incompatable with dotnet's
> consept of a class?
>
> If you got some reading to point me to first please point me there first. I
> must add thow that what I have found either degenerates into a arithmatic(or
> errors in it) war or static typing vs 'whatever' war ;o)
No, this time it's not about static typing - phew! ;)
Joe already mentioned multiple inheritance.
What's even harder is the MOP. Each class is an instance of a metaclass.
The Metaclass influences how the class is constructed.
Now, MOP is not part of ANSI Common Lisp, so one might consider it ok
not to include that. However, you still have the concept of generic
functions with multiple dispatch. That should be relatively easy. What's
harder is that you can change the methods for a generic function at
runtime, and that you can define your own method combinations. I don't
see how you could add that to .NET without destroying the possibility of
cross-language class hierarchies.
See the specification for user-defined method combinations in CLtL2 or
the HyperSpec.
AFAIK, ISLISP is much less flexible in those regards than Common Lisp,
so it should be easier to port this to .NET. Or else you have to define
a proper subset of Common Lisp first. (This is something the ANSI Common
Lisp standard allows for, but you have to make this explicit.)
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Harag writes:
> So what is the exact problem(s) with the inheritance, is it static type
> conversions or is the consept of a class in lisp incompatable with dotnet's
> consept of a class?
Some time ago Duane Rettig posted here a detailed analysis of why
Franz decided not to port their Lisp product to an early version of
.NET.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Went through the posts and this is what I think the 'jist' is:
To have LIPS and DOTNET play nicely both ways will be a nightmare but it
would not be so bad to get LISP to *use* dotnet.
If you could have LISP *use* the hoards of stuff ms is pushing into dotnet
it would be great! Who cares if the favour is not returned, ie if the other
dotnet languages can't use the LISP stuff written using dotnet.
Following is part of a post in that discussion and my conclusions are based
mostly on this bit:
[snip]
>From: Frode Vatvedt Fjeld (······@acm.org)
>Subject: Re: Lisp# in .NET?
View this article only
>Newsgroups: comp.lang.lisp
>Date: 2001-06-07 16:20:48 PST
>From what I've seen of .NET the central technology-oriented aspect of
>it is the Common Type System, which is a "standard" for meta-data
>representation, meaning what objects, functions etc. looks like at
>compile- and run-time. The idea is that CTS enables software
>components written in different languages to be linked together
>seamlessly[1]. Unfortunately, the designers of CTS chose to ignore
>Common Lisp with its rich type system, flexible generic functions
>etc. My impression is that a CL implementor would have to really bend
>over backwards in order to squeeze into the .NET mold. I'm not
>convinced this would even be possible while staying reasonably ANSI
>compliant.
>
>Perhaps a viable approach would be to view CTS/.NET as a subset of
>lisp typing, and implement a .NET (Common Intermediate Language)
>compiler that compiles stuff so that it integrates into the lisp
>run-time environment, rather than the other way around (i.e. C#
>functions becomes compiled native "lisp" functions etc). I haven't
>looked into the details, but I have a feeling this might actually work
>precisely because of the strict requirements imposed by CTS and
>CIL. As a bonus, this would really be true to the "embrace and extend"
>formula :-)
[snip]"embrace and extend" ... hehe theres beauty :o)
PS: Is there a unspoken rule that if it has been discussed or done before
that it should not be touched again?
So much changes in in such a short time in the IT industry that I would be
reluctant to not review thoughts and practices regularly.
Harag wrote:
> Went through the posts and this is what I think the 'jist' is:
>
> To have LIPS and DOTNET play nicely both ways will be a nightmare but it
> would not be so bad to get LISP to *use* dotnet.
>
> If you could have LISP *use* the hoards of stuff ms is pushing into dotnet
> it would be great! Who cares if the favour is not returned, ie if the other
> dotnet languages can't use the LISP stuff written using dotnet.
There are some good arguments why one would want this. However, it is
very hard to do and requires a lot of effort to get this into a shape so
that it becomes really useful. And then the question comes up whether
the outcome justifies that effort.
Take a look at how much time and effort it has taken to get decent open
source Common Lisp implementations off the ground. And they didn't need
to mix and match with some other architecture that doesn't quite fit the
Lisp philosophy.
There are essentially three things to balance:
a) You need to understand all the implications of the Common Lisp standard.
b) You need to know what are good ways to implement Lisp languages.
There's a whole body of literature about this topic alone.
c) You need to understand all the implications of the .NET platform.
Add to this the fact that .NET is still a moving target, and you don't
really know what they will change in near future releases of .NET.
If you are really interested in these things, pick out one of those
three areas. It is very likely that it will take years to fully grasp
just one.
Don't expect that people in this newsgroup will give you all the answers
that can lead to an implementation of Lisp on top of .NET. That's just
heavy stuff. There are books and online documentation that you have to
study in detail to do that. There is simply no away around such work.
Yes, there are some projects that try to implement, say, Scheme on top
of Java and/or .NET. But please take into account that they are usually
undertaken by people who already know at least one of those areas pretty
well. And most of those implementations still have their limitations, so
even the pros don't get it right at first.
If you are really interested in having Lisp and other languages work
together, there are other less demanding approaches to do that. Use one
of the various remote call protocols (RPC, RMI, XML-RPC, and so on).
There are already several Lisp libraries available that support you in
doing that.
Another option is to invest some time in Lisp projects that have already
been started. There is enough work to do without the need to reinvent
wheels. After some time you might notice that the fashions of the week
as pushed by companies like Microsoft, IBM or Sun may not be that
important as they try very hard to make you believe.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
"Pascal Costanza" <········@web.de> wrote in message
·················@newsreader2.netcologne.de...
> There are some good arguments why one would want this. However, it is
> very hard to do and requires a lot of effort to get this into a shape so
> that it becomes really useful. And then the question comes up whether
> the outcome justifies that effort.
After reading for some hours it finally dawned on me that maybe the effort
is not worth it ;o)
> Don't expect that people in this newsgroup will give you all the answers
> that can lead to an implementation of Lisp on top of .NET. That's just
> heavy stuff. There are books and online documentation that you have to
> study in detail to do that. There is simply no away around such work.
I know it will take the rest of my life to get to master all these areas to
do something about it. I was actually more interested in a two or three page
summary of why it is precieved to be so difficult to marry the two without
having to wade through all those type and atritmatic wars ;o}
> If you are really interested in having Lisp and other languages work
> together, there are other less demanding approaches to do that. Use one
> of the various remote call protocols (RPC, RMI, XML-RPC, and so on).
> There are already several Lisp libraries available that support you in
> doing that.
>
Will do so, thanx do the pointers
> Another option is to invest some time in Lisp projects that have already
> been started. There is enough work to do without the need to reinvent
> wheels. After some time you might notice that the fashions of the week
> as pushed by companies like Microsoft, IBM or Sun may not be that
> important as they try very hard to make you believe.
Well, actually I was also thinking about not having to reinvent the wheel
here aswell it just seemed a waste that one could not 'ride' on the effort
that 'they' put into the framework saving everybody the time to do it in
lisp 'natively'. I suppose it was a naive wish... ;o)
Re being of any help on projects, well it will be a couple of years before
my lisp skills where up to scratch for this but maybe I should put some time
into testing.
The question which project? I'm inclined to think anything involving cross
platform UI or a free 'advanced' development environment for lisp. Those are
the things I find missing most for 'trivial' day to day programming. I feel
that those trivial or 'sugar candy' things are what matter if you are not
building apps to send rockets to the moon etc :o)
(Like I've said elsewhere ... I'm spoilt with ease of use or click and go...
and yes I know the top of the range commercial lisp vendors gives you all
the candy but it is for the time being out of my reach (working on it
though)....and the students think that they have money problems ...roflmao
:o) )
Anyway thanks for the input I can truly say that my CURIOSITY on this
subjects has been satisfied.
PS: I must add that all the commercial vendors I had contact with really
tried their best to accommodate my 'situation' and I really appreciate their
efforts.
Harag wrote:
> "Pascal Costanza" <········@web.de> wrote in message
> ·················@newsreader2.netcologne.de...
> > Another option is to invest some time in Lisp projects that have
> > already been started. There is enough work to do without the need
> > to reinvent wheels. After some time you might notice that the
> > fashions of the week as pushed by companies like Microsoft, IBM or
> > Sun may not be that important as they try very hard to make you
> > believe.
>
> Well, actually I was also thinking about not having to reinvent the
> wheel here aswell it just seemed a waste that one could not 'ride' on
> the effort that 'they' put into the framework saving everybody the
> time to do it in lisp 'natively'. I suppose it was a naive wish... ;o)
> The question which project?
If you want something that gives you a Lisp-like syntax with complete access
to the .NET Framework (and Win32 via P/Invoke) have a look at DotLisp:
http://sourceforge.net/projects/dotlisp/
It's /not/ for you if you want a complete CL implementation, with GUI (as you
seem to impy from the stuff I've clipped).
> Anyway thanks for the input I can truly say that my CURIOSITY on this
> subjects has been satisfied.
Oh, OK.
--
Regards,
Mark Hurd, B.Sc.(Ma.) (Hons.)
"Mark Hurd" <········@ozemail.com.au> wrote in message
···············@news.iprimus.com.au...
...
> If you want something that gives you a Lisp-like syntax with complete
access
> to the .NET Framework (and Win32 via P/Invoke) have a look at DotLisp:
> http://sourceforge.net/projects/dotlisp/
>
I'm still learning CL so I am trying to stay away form 'dialects' to limit
possible confusion for the time being.
> > Anyway thanks for the input I can truly say that my CURIOSITY on this
> > subjects has been satisfied.
>
> Oh, OK.
Well I need to do some more work on my 'background material' as Paolo points
out :o) before I continue this conversation and that will mostlikly produce
more questions than awnsers :oP
[SNIP]
...
Search Result 36
From: Duane Rettig (·····@franz.com)
Subject: Re: How I lost my faith (very long)
View: Complete Thread (113 articles)
Original Format
Newsgroups: comp.lang.lisp
Date: 2002-02-22 19:00:11 PST
I just got off the phone with the Franz developer who did the study.
There were three areas where CRL posed problems for us, all of which
we could work around at a loss of efficiency and/or security, and all
of which we asked MS for changes based on our needs. The MS developers
agreed with our needs in principle, but made no promises, and we don't
know if they made any changes to the CRL design. Please bear in mind
that these analyses were made over two years ago, and that the
descriptions may have changed for the better.
1. There was really no way to specify a varying number of arguments
in a call. This had ramifications for almost the entire CL calling
sequence, including &optionals, &rest, and &key arguments. We figured
that the most efficient way to get such operation is to cons up a "list"
of arguments for each call. There may now be ways to call with varying
arguments, but there was not at the time we did our analysis.
2. As you implied above, the type tree was more tree-like than net-like,
and didn't allow for multiple inheritance. We felt we would have to
consider all CL objects as being of the single type "object", which
really defeats the purpose of the object system.
3. Method dispatch was compile-time only. Good for static languages,
bad for Lisp.
On the plus side, it seemed to have a pretty good garbage-collector,
although it had high storage overhead per object, which would be
problematic for systems with huge numbers of cons cells...
...
[SNIP]
Anybody knows if any of these points where addresses by ms in the last 3
years?
Harag writes:
> Went through the posts and this is what I think the 'jist' is:
[...]
> PS: Is there a unspoken rule that if it has been discussed or done before
> that it should not be touched again?
Ever heard about background material?
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
"Paolo Amoroso" <·······@mclink.it> wrote in message
···················@plato.moon.paoloamoroso.it...
> Harag writes:
>
> > Went through the posts and this is what I think the 'jist' is:
> [...]
> > PS: Is there a unspoken rule that if it has been discussed or done
before
> > that it should not be touched again?
>
> Ever heard about background material?
Point taken.
"Harag" <·········@psychedelic.co.za> wrote:
> More seriously I was actually wondering how this would better the chance of
> somebody doing a cl implementation for dotnet.
It's irrelevant. The delegate mechanism has been in the IL all
along. They are making this mechanism available in C#, but Lisp
implementors already had access to it.
Will