Greetings,
First of all, I am posting this message to both the Scheme and Lisp
newsgroups because the topic, EuLisp, is pretty much a cross between
Common Lisp and Scheme. I've recently discovered EuLisp and found
many aspects of it very interesting. It also has a rich political
history which I won't discuss except to say that EuLisp was supposed
to be Europe's answer to America's Common Lisp. Not being bound to as
much history, EuLisp was freer in terms of technical options than
Common Lisp. EuLisp actually seems closer to Oaklisp
(http://www-bcl.cs.nuim.ie/~bap/oaklisp/) than anything else.
EuLisp offers the following benefits over Common Lisp (IMO):
1. EuLisp is a Lisp1 dialect offering a single namespace for variables
and functions, or first-class functions, like Scheme. The benefits of
this are too numerous to list and have been discussed ad neausium
elsewhere.
2. EuLisp offers largely similar functionality in a much simpler,
cleaner language with fewer required functions (largely due to its
Lisp1 design).
EuLisp offers the following benefits over Scheme (IMO):
1. EuLisp is object oriented from the ground up (everything is an
object) offering a full meta object protocol (MOP) and reflection
(all like Oaklisp).
2. EuLisp has a defined module system and threading system.
Now my purpose in sending this post is not to start a language debate,
flame, or war. Given some of the nice features of EuLisp, I am
wondering why it appears to be a dead language. The EuLisp standard
document is at version 0.99 and has been so since the late 90s. Also,
there appears to be only one real implementation (Youtoo - open
source) which also appears to be dead now. Nobody appears to be
working with the standard, implementing, using, or even talking about
EuLisp. I can't even seem to contact anyone related to the project.
So the question is is anyone else out there using, implementing, or
even thinking about EuLisp anymore?
Links:
http://www.cs.bath.ac.uk/~jap/ak1/youtoo/
Blake McBride
Am 11.11.2006 20:27 Uhr schrieb "Blake mcBride" unter <·····@mcbride.name>
in ···············@news.supernews.com:
>
> Greetings,
>
> First of all, I am posting this message to both the Scheme and Lisp
> newsgroups because the topic, EuLisp, is pretty much a cross between
> Common Lisp and Scheme. I've recently discovered EuLisp and found
> many aspects of it very interesting. It also has a rich political
> history which I won't discuss except to say that EuLisp was supposed
> to be Europe's answer to America's Common Lisp. Not being bound to as
> much history, EuLisp was freer in terms of technical options than
> Common Lisp. EuLisp actually seems closer to Oaklisp
> (http://www-bcl.cs.nuim.ie/~bap/oaklisp/) than anything else.
>
> EuLisp offers the following benefits over Common Lisp (IMO):
>
> 1. EuLisp is a Lisp1 dialect offering a single namespace for variables
> and functions, or first-class functions, like Scheme. The benefits of
> this are too numerous to list and have been discussed ad neausium
> elsewhere.
>
> 2. EuLisp offers largely similar functionality in a much simpler,
> cleaner language with fewer required functions (largely due to its
> Lisp1 design).
It is cleaner because the library functions have been designed without
that much backwards compatibility (like in Common Lisp). It is
simply a newer approach. The Lisp1 does not give it much advantage.
>
>
> EuLisp offers the following benefits over Scheme (IMO):
>
> 1. EuLisp is object oriented from the ground up (everything is an
> object) offering a full meta object protocol (MOP) and reflection
> (all like Oaklisp).
>
> 2. EuLisp has a defined module system and threading system.
>
>
> Now my purpose in sending this post is not to start a language debate,
> flame, or war. Given some of the nice features of EuLisp, I am
> wondering why it appears to be a dead language.
I can tell you why it is dead: funding in the EU had stopped and it
hasn't got any users with deep pockets and/or useful applications that
would pay for further development.
Lisp in the commercial world in Europe is mostly dead. Same
for Universities. There was once quite a lot interest, but it
died. A big reason was the "AI winter". With only few exceptions.
Academics moved on (Oz, ...) and in the commercial world
many are using Java now.
Most commercial Lisp applications that could have been implemented
in EuLisp were developed in Common Lisp. No prominent vendor
invested in a EuLisp development system. If there was some Lisp
activity left in Europe, it stayed with Common Lisp.
Developing and implementing a new clean Lisp is a large task and
EuLisp was not able to demonstrate any real practical advantage
over Common Lisp. In theory EuLisp could have been cleaner,
but it never materialized.
Even Apple looked at it, they copied some stuff for Dylan. Apple
had with Dylan almost the same goals. And failed, too.
EuLisp was thought to be a Lisp for application development and delivery.
Some experienced problems to deliver Lisp software (efficiency, cost
effectiveness, speed, size, ...). So EuLisp was developed but
did not create enough interest.
You will find a few very interesting documents here:
http://www-berlin.isst.fhg.de/~apply/
The Apply project was a government funded project here in Germany to
contribute to the European EuLisp development.
Some of the more interesting documents were written in German. ;-) :-)
> The EuLisp standard
> document is at version 0.99 and has been so since the late 90s. Also,
> there appears to be only one real implementation (Youtoo - open
> source) which also appears to be dead now. Nobody appears to be
> working with the standard, implementing, using, or even talking about
> EuLisp. I can't even seem to contact anyone related to the project.
> So the question is is anyone else out there using, implementing, or
> even thinking about EuLisp anymore?
>
> Links:
>
> http://www.cs.bath.ac.uk/~jap/ak1/youtoo/
>
>
> Blake McBride
> I can tell you why it is dead: funding in the EU had stopped and it
> hasn't got any users with deep pockets and/or useful applications that
> would pay for further development.
>
> Lisp in the commercial world in Europe is mostly dead. Same
> for Universities. There was once quite a lot interest, but it
> died. A big reason was the "AI winter". With only few exceptions.
> Academics moved on (Oz, ...) and in the commercial world
> many are using Java now.
NOT US - We only use Lisp (and a bit of other stuff supporting old
systems). We are in Europe
>
> Most commercial Lisp applications that could have been implemented
> in EuLisp were developed in Common Lisp. No prominent vendor
> invested in a EuLisp development system. If there was some Lisp
> activity left in Europe, it stayed with Common Lisp.
Agreed - we use SBCL
>
> Developing and implementing a new clean Lisp is a large task and
> EuLisp was not able to demonstrate any real practical advantage
> over Common Lisp. In theory EuLisp could have been cleaner,
> but it never materialized.
>
> Even Apple looked at it, they copied some stuff for Dylan. Apple
> had with Dylan almost the same goals. And failed, too.
>
> EuLisp was thought to be a Lisp for application development and delivery.
> Some experienced problems to deliver Lisp software (efficiency, cost
> effectiveness, speed, size, ...). So EuLisp was developed but
> did not create enough interest.
>
> You will find a few very interesting documents here:
>
> http://www-berlin.isst.fhg.de/~apply/
>
> The Apply project was a government funded project here in Germany to
> contribute to the European EuLisp development.
>
> Some of the more interesting documents were written in German. ;-) :-)
>
>
> > The EuLisp standard
> > document is at version 0.99 and has been so since the late 90s. Also,
> > there appears to be only one real implementation (Youtoo - open
> > source) which also appears to be dead now. Nobody appears to be
> > working with the standard, implementing, using, or even talking about
> > EuLisp. I can't even seem to contact anyone related to the project.
> > So the question is is anyone else out there using, implementing, or
> > even thinking about EuLisp anymore?
> >
> > Links:
> >
> > http://www.cs.bath.ac.uk/~jap/ak1/youtoo/
> >
> >
> > Blake McBride
You know I think part of the problem is that bringing out a new
language you stand against the dark side languages that receive so
much money from the big companies.
For us as a start up using just Lisp what surprised me was that instead
of clients running a mile from "different" although not new, technology
we have people queuing at the door to have their application/site
built. Ok, they wouldn't know if it was a chicken or other small bird
running around inside the computer - but the advantages we can offer
over standard products really impress them.
Our biggest problems?
1. Staff - can't find any - may need about 50 programmers in the next
year
2. Excitement - The two programmers we have keep getting excited about
the code and forgetting we have a job to do - including putting their
arms in the air and shouting "YES" when something works
3. Things being too quick to write - Do you know what it's like when
you say to yourself, right, goal today, do x y and z. You complete this
before 9am and spend the rest of the day looking out of the window
4. Other programmers in dark side languages not understanding us when
we say "lets make one of those kinda things there somewhere and then
we'll patch it together later"... I was in the USA with a C programmer
and a perl programmer, it took 3 days to turn their thinking upside
down before we could really hack some lisp.
5. I feel guilty sometimes that I'm being paid to do something
beatiful.
Paul
http://www.hyperstring.net
boating12345 wrote:
> Our biggest problems?
>
> 1. Staff - can't find any - may need about 50 programmers in the next
> year
Cannot find programmers or cannot find Lisp programmers?
If the latter, is it better to get non-Lisp programmers and
allow/invest time
to develop them into Lisp programmers vs. not having any programmers
at all?
On 11-Nov-2006, Rainer Joswig <······@lisp.de> wrote:
>
> Am 11.11.2006 20:27 Uhr schrieb "Blake mcBride" unter <·····@mcbride.name>
> in ···············@news.supernews.com:
> ...
> > EuLisp offers the following benefits over Common Lisp (IMO):
> >
> > 1. EuLisp is a Lisp1 dialect offering a single namespace for variables
> > and functions, or first-class functions, like Scheme. The benefits of
> > this are too numerous to list and have been discussed ad neausium
> > elsewhere.
> >
> > 2. EuLisp offers largely similar functionality in a much simpler,
> > cleaner language with fewer required functions (largely due to its
> > Lisp1 design).
>
> It is cleaner because the library functions have been designed without
> that much backwards compatibility (like in Common Lisp). It is
> simply a newer approach. The Lisp1 does not give it much advantage.
Lisp1 requires fewer functions to express the same functionality and
in a simpler format. For example:
Lisp2 requires let & flet, Lisp1 can express the same thing with just let.
Lisp2 requires "function" and "funcall", Lisp1 requires neither and
expresses
it in a much simpler way. i.e.
(fun1 (function fun2)) vs. (fun1 fun2)
(funcall fun2 arg1 arg2) vs. (fun2 arg1 arg2)
on, and on, and on...
Blake McBride
"Blake McBride" <·····@mcbride.name> writes:
> On 11-Nov-2006, Rainer Joswig <······@lisp.de> wrote:
>>
>> Am 11.11.2006 20:27 Uhr schrieb "Blake mcBride" unter <·····@mcbride.name>
>> in ···············@news.supernews.com:
>> ...
>> > EuLisp offers the following benefits over Common Lisp (IMO):
>> >
>> > 1. EuLisp is a Lisp1 dialect offering a single namespace for variables
>> > and functions, or first-class functions, like Scheme. The benefits of
>> > this are too numerous to list and have been discussed ad neausium
>> > elsewhere.
You're right about this having been discussed ad nauseam. There have
to be thousands of posts on that topic in comp.lang.scheme and
comp.lang.lisp. Yet there is no widespread consensus about the
"numerous benefits" of a Lisp-1 over a Lisp-2, as you claim. AFAICT,
it seems to be a matter of taste. Some people like Lisp-1, some
prefer Lisp-2. Apparently you're a Lisp-1 person. Good for you!
[...]
>> The Lisp1 does not give it much advantage.
>
> Lisp1 requires fewer functions to express the same functionality and
> in a simpler format. For example:
>
> Lisp2 requires let & flet, Lisp1 can express the same thing with just let.
> Lisp2 requires "function" and "funcall", Lisp1 requires neither and
> expresses it in a much simpler way.
[...]
You wrote in an earlier posting that you didn't want to start another
language war. But what you're doing right now, whether you know it or
not, is starting another Lisp-1 vs. Lisp-2 war. If you want to know
more about these issues, read
<http://www.nhplace.com/kent/Papers/Technical-Issues.html> or search
the net for "Lisp-1 vs. Lisp-2". But let's not have this discussion
all over again.
--
Wolfram Fenske
A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?
On 11-Nov-2006, "Wolfram Fenske" <·····@gmx.net> wrote:
> You wrote in an earlier posting that you didn't want to start another
> language war. But what you're doing right now, whether you know it or
> not, is starting another Lisp-1 vs. Lisp-2 war.
You are right. I did not want to start a flame war. I wanted to discuss
EuLisp. I was prompted by the poster saying "The Lisp1 does not give it
much advantage". I now state that all the posts defending Lisp2 are
correct and I stand corrected.
Are there any more thought about EuLisp?
I tried getting Youtoo to work but it wouldn't compile under Linux or Cygwin
out-of-the-box.
I thought about getting it to build but didn't want to spend the time if it
had already been done.
Does anyone know the status of Youtoo? (Was it a complete implementation of
EuLisp
as defined?)
Are others interested in EuLisp if an implementation were available?
Is Eu2C better?
These are the types of questions I am interested in.
Thanks.
Blake McBride
"Blake McBride" <·····@mcbride.name> writes:
> On 11-Nov-2006, "Wolfram Fenske" <·····@gmx.net> wrote:
>
>> You wrote in an earlier posting that you didn't want to start another
>> language war. But what you're doing right now, whether you know it or
>> not, is starting another Lisp-1 vs. Lisp-2 war.
>
> You are right. I did not want to start a flame war. I wanted to discuss
> EuLisp. I was prompted by the poster saying "The Lisp1 does not give it
> much advantage". I now state that all the posts defending Lisp2 are
> correct and I stand corrected.
>
> Are there any more thought about EuLisp?
>
> I tried getting Youtoo to work but it wouldn't compile under Linux or Cygwin
> out-of-the-box.
> I thought about getting it to build but didn't want to spend the time if it
> had already been done.
>
> Does anyone know the status of Youtoo? (Was it a complete implementation of
> EuLisp
> as defined?)
>
> Are others interested in EuLisp if an implementation were available?
Is there any (free) EuLisp program available that would be worth running?
Indeed, the reason why nobody use EuLisp might be first that there are
no free implementation of EuLisp available on the Internet, and second
that there are no worthwhile application using it.
You might contrast the situation with Haskell and Ocaml. I don't
write Haskell or Ocaml programs, but I still use both of these
programming languages because there are two applications written in
each of them that I use, and I could download them from the Internet
(darcs and MLDonkey). Well, now I've got these compilers on my
computer, I might even try to write a couple of programs in them...
If you plan to provide a new EuLisp implementation, perhaps a good
idea would be to implement it in Common Lisp, like PseudoScheme. This
would allow to use CL libraries in your EuLisp programs, and
vice-versa. We could even run EuLisp program in emacs using emacs-cl!
--
__Pascal Bourguignon__ http://www.informatimago.com/
You never feed me.
Perhaps I'll sleep on your face.
That will sure show you.
Quoth Pascal Bourguignon <···@informatimago.com>:
> You might contrast the situation with Haskell and Ocaml. I don't
> write Haskell or Ocaml programs, but I still use both of these
> programming languages because there are two applications written in
> each of them that I use, and I could download them from the Internet
> (darcs and MLDonkey). Well, now I've got these compilers on my
> computer, I might even try to write a couple of programs in them...
There are a few other particularly interesting applications:
- Unison, which is more or less a "better rsync," is written in Ocaml
- Pugs, an important Perl6 prototype, is written in Haskell
- The curious Haskell example is that some of the people at Linspire
are building replacements for Debian packaging components in Haskell
Unison and Darcs are both interesting applications in that they use
their respective languages without directly "inflicting" a lot of
language knowledge on users. I use Darcs even though I really don't
know Haskell. It doesn't much matter that I don't; Darcs is still
plenty useful.
If there were a few more apps akin to Unison or Darcs written in CL
that *didn't* require a lot of extra packaging, but which could simply
execute as more or less standalone CLISP/CMUCL programs that could run
simply via the #! 'protocol,' that would strike me as a mighty good
thing. Maxima tends to be that easy to deploy, but other stuff often
isn't...
--
(reverse (concatenate 'string "moc.liamg" ·@" "enworbbc"))
http://linuxfinances.info/info/lisp.html
"That which does not kill me, can only make me stronger"
-- Friedrich Nietzsche, "Also Spraech Zarathustra"
In article <···············@news.supernews.com>,
"Blake McBride" <·····@mcbride.name> wrote:
> On 11-Nov-2006, Rainer Joswig <······@lisp.de> wrote:
> >
> > Am 11.11.2006 20:27 Uhr schrieb "Blake mcBride" unter <·····@mcbride.name>
> > in ···············@news.supernews.com:
> > ...
> > > EuLisp offers the following benefits over Common Lisp (IMO):
> > >
> > > 1. EuLisp is a Lisp1 dialect offering a single namespace for variables
> > > and functions, or first-class functions, like Scheme. The benefits of
> > > this are too numerous to list and have been discussed ad neausium
> > > elsewhere.
> > >
> > > 2. EuLisp offers largely similar functionality in a much simpler,
> > > cleaner language with fewer required functions (largely due to its
> > > Lisp1 design).
> >
> > It is cleaner because the library functions have been designed without
> > that much backwards compatibility (like in Common Lisp). It is
> > simply a newer approach. The Lisp1 does not give it much advantage.
>
>
> Lisp1 requires fewer functions to express the same functionality and
> in a simpler format. For example:
>
> Lisp2 requires let & flet, Lisp1 can express the same thing with just let.
> Lisp2 requires "function" and "funcall", Lisp1 requires neither and
> expresses
> it in a much simpler way. i.e.
>
> (fun1 (function fun2)) vs. (fun1 fun2)
>
> (funcall fun2 arg1 arg2) vs. (fun2 arg1 arg2)
>
> on, and on, and on...
Actually there is not much 'on and on'.
There are only a few constructs (LET is not a function) in the core language
that are needed for a Lisp2. It also has almost zero effects
on the size of the library.
Plus the Lisp2 has a few advantages. Surprisingly the biggest advantage
is readability. I'm not a big fan of 'guess what it means' notations.
I'm much in favor for
(funcall (foo bar) baz)
over
((foo bar) baz)
I'm also in favor for
(funcall (funcall (foo bar))
baz)
over
(((foo bar))
baz)
Especially in larger code I like to see that there are returned
functional values involved and called. A FUNCALL lets me see that.
You said:
EuLisp offers largely similar functionality in a much simpler,
cleaner language with fewer required functions (largely due to its
Lisp1 design.
I say: there are only very few added constructs (not functions) needed
in a Lisp2. Lisp1 is not THE big reason why EuLisp is 'cleaner'.
It is one reason.
But if you look at the higher-level language parts, EuLisp has the same
complexity as Common Lisp. Its object system is much like CLOS.
Plus EuLisp has the added disadvantage
of being designed to be less flexible. There is lots of focus
on static compilation. That's a bit against the Lisp spirit.
For development Common Lisp environments are really good. So there
is always a tendency to use Common Lisp for the development.
Anyway, EuLisp is unfinished work... it looks like a beautiful
painting where the artist died before finishing it... it is
like a big city without people.
>
> Blake McBride
On Sun, 12 Nov 2006 03:49:19 +0100, Rainer Joswig wrote:
> There is lots of focus on static compilation.
Please pardon my abject ignorance: I'm interested in, but have not coded
in both lisp and scheme.
Stylistic issues asside (if that is possible), the thing that interested
me most about the description of EuLisp was that one of the stated goals
was to apply the sort of type inference found in other functional
languages like ML and Hascall to lisp. Is there any other/current work in
this direction? It's been this outsider's impression that the focus of
lisp and scheme implementations has been to make dynamic dispatch
efficient, using various machine hacks (like unaligned access traps) and
fall-backs, rather than attempt to pin types down at compile time. That
coupled with manual type annotation/constraint where necessary, as an
optimization step.
Is this impression incorrect? Or is it just that in practice, there isn't
much performance to be gained? Or that lisp isn't actually suitable
for that sort of approach (for whatever reason)?
I'm a big fan of the notion that computers should be made to do as much
heavy-lifting as possible, and type inference seems to me to be one of the
better uses of that sort of effort to have been developed in recent years.
--
Andrew
Am 14.11.2006 5:07 Uhr schrieb "Andrew Reilly" unter
<···············@areilly.bpc-users.org> in
·····························@areilly.bpc-users.org:
> On Sun, 12 Nov 2006 03:49:19 +0100, Rainer Joswig wrote:
>
>> There is lots of focus on static compilation.
>
> Please pardon my abject ignorance: I'm interested in, but have not coded
> in both lisp and scheme.
>
> Stylistic issues asside (if that is possible), the thing that interested
> me most about the description of EuLisp was that one of the stated goals
> was to apply the sort of type inference found in other functional
> languages like ML and Hascall to lisp.
Type inference for what? Sometimes Lisp compilers are doing type inference
to generate faster code. Some also give hints to the user
about typing problems.
> Is there any other/current work in
> this direction? It's been this outsider's impression that the focus of
> lisp and scheme implementations has been to make dynamic dispatch
> efficient, using various machine hacks (like unaligned access traps) and
> fall-backs, rather than attempt to pin types down at compile time. That
> coupled with manual type annotation/constraint where necessary, as an
> optimization step.
>
> Is this impression incorrect? Or is it just that in practice, there isn't
> much performance to be gained? Or that lisp isn't actually suitable
> for that sort of approach (for whatever reason)?
Lisp dialects usually favor runtime flexibility.
If I said 'static compilation' that does not necessarily means 'static
types' just because the word static appears in both.
It is mostly about getting rid of the (maybe costly) runtime
flexibility of Lisp during compilation.
Two examples for compilation that reduce the flexibility of the running
code:
- often if you use Lisp you think that calling a function will use the
latest definition of that function. If you change a function then calling
the function will use the new definition. For top-level functions
you need to look at the symbol's function cell and call that function
object.
With static compilation you may assume that no changes to functions are
allowed and that you can inline the function or use some other mechanism.
- in Lisp-based object-oriented languages you can often redefine
the class hierarchy at runtime. This gives you a lot of flexibility.
For CLOS it means that the layout of objects can change at runtime
(if you think as slots implemented as a vector). For a slot
access one would access the vector at a known index. Not in CLOS.
In CLOS you have to see somehow if the class has changed and
if that is the case you need to get the (possibly) new place where the
slot is located. In static compilation you may assume that
class hierarchies do not change. A weaker assumption could be
that you allow class hierarchies to change, but that the change
is not allowed to have an impact on the layout of the slots.
Static compilation for Lisp means that you can't use all kinds
of dynamic features that Lisp developers are used to.
EuLisp was designed so that it supports these kinds of static
compilation features. EuLisp would then be used in a controlled
dynamic, flexible way during programming. The assumption was that at
runtime of delivered programs these features are not needed.
So you assume a static software at runtime (where functions don't change,
classes don't change, ...) and a compiler can generate
faster, smaller code if you compile for delivery.
Note that ANSI Common Lisp also allows some optimizations
for compiled code and that several Common Lisp systems
have many features for static compilation.
>
> I'm a big fan of the notion that computers should be made to do as much
> heavy-lifting as possible, and type inference seems to me to be one of the
> better uses of that sort of effort to have been developed in recent years.
Andrew Reilly <···············@areilly.bpc-users.org> writes:
> On Sun, 12 Nov 2006 03:49:19 +0100, Rainer Joswig wrote:
>
> > There is lots of focus on static compilation.
>
> Stylistic issues asside (if that is possible), the thing that interested
> me most about the description of EuLisp was that one of the stated goals
> was to apply the sort of type inference found in other functional
> languages like ML and Hascall to lisp. Is there any other/current work in
> this direction?
CMUCL and its offshoot SBCL tend to have a lot more type inference and
propagation than most other Lisp systems, particular in regard to
numeric code, where the type information gives the biggest improvement
in performance.
So, this is possible to do in Common Lisp, but it is at the
implementation level rather than at the language standard level.
--
Thomas A. Russ, USC/Information Sciences Institute
"Blake McBride" <·····@mcbride.name> writes:
> Lisp2 requires let & flet
No: that's just how CL does it, but not a requirement. An alternative
design could, for example
(a) allow #'f in place of a name in binding constructs
(b) have convenient reader syntax for funcall, eg [f args...]
Here, (a) eliminates the "requirement" for flet and (b) renders
FUNCALLs almost invisible. An imaginary example showing all
combinations:
(let ((1+ (lambda (x) (+ x 1)))
(#'map (lambda (#'f list)
(and list (cons (f (car list)) (map #'f (cdr list)))))))
(map 1+ (list [1+ 0] 2 3)))
--
Marcus Breiing
(Cologne, Germany)
Rainer Joswig wrote:
> Am 11.11.2006 20:27 Uhr schrieb "Blake mcBride" unter <·····@mcbride.name>
> in ···············@news.supernews.com:
>
> >
> > Greetings,
> >
> > First of all, I am posting this message to both the Scheme and Lisp
> > newsgroups because the topic, EuLisp, is pretty much a cross between
> > Common Lisp and Scheme. I've recently discovered EuLisp and found
> > many aspects of it very interesting. It also has a rich political
> > history which I won't discuss except to say that EuLisp was supposed
> > to be Europe's answer to America's Common Lisp. Not being bound to as
> > much history, EuLisp was freer in terms of technical options than
> > Common Lisp. EuLisp actually seems closer to Oaklisp
> > (http://www-bcl.cs.nuim.ie/~bap/oaklisp/) than anything else.
> >
> > EuLisp offers the following benefits over Common Lisp (IMO):
> >
> > 1. EuLisp is a Lisp1 dialect offering a single namespace for variables
> > and functions, or first-class functions, like Scheme. The benefits of
> > this are too numerous to list and have been discussed ad neausium
> > elsewhere.
> >
> > 2. EuLisp offers largely similar functionality in a much simpler,
> > cleaner language with fewer required functions (largely due to its
> > Lisp1 design).
>
> It is cleaner because the library functions have been designed without
> that much backwards compatibility (like in Common Lisp). It is
> simply a newer approach. The Lisp1 does not give it much advantage.
Lisp2 means that all kinds of language primitives have to exist in two
versions, or be parameterizable as to whether they are talking about
the value cell or function cell. It makes the language bigger, and
that's bad in and of itself. --- Daniel Weinreb, 28 Feb 2003
Having separate "value cells" and "function cells" (to use the "street
language" way of saying it) was one of the most unfortuanate issues.
We did not want to break pre-existing programs that had a global
variable named "foo" and a global function named "foo" that were
distinct. We at Symbolics were forced to insist on this, in the face
of everyone's knowing that it was not what we would have done absent
compatibility constraints. It's hard for me to remember all the
specific things like this, but if we had had fewer compatibility
issues, I think it would have come out looking more like Scheme in
general. --- Daniel Weinreb, 24 Feb 2003
Do you really think people in 1000 years want to be
constrained by hacks that got put into the foundations of
Common Lisp because a lot of code at Symbolics depended on
it in 1988? --- Paul Graham
Common Lisp is a significantly ugly language. If Guy and I had been
locked in a room, you can bet it wouldn't have turned out like that.
--- Dick Gabriel
A hacker's language is terse and hackable. Common Lisp is not.
The good news is, it's not Lisp that sucks, but Common Lisp.
--- Paul Graham, May 2001
William James wrote:
> Rainer Joswig wrote:
> > Am 11.11.2006 20:27 Uhr schrieb "Blake mcBride" unter <·····@mcbride.name>
> > in ···············@news.supernews.com:
> >
> > >
> > > Greetings,
> > >
> > > First of all, I am posting this message to both the Scheme and Lisp
> > > newsgroups because the topic, EuLisp, is pretty much a cross between
> > > Common Lisp and Scheme. I've recently discovered EuLisp and found
> > > many aspects of it very interesting. It also has a rich political
> > > history which I won't discuss except to say that EuLisp was supposed
> > > to be Europe's answer to America's Common Lisp. Not being bound to as
> > > much history, EuLisp was freer in terms of technical options than
> > > Common Lisp. EuLisp actually seems closer to Oaklisp
> > > (http://www-bcl.cs.nuim.ie/~bap/oaklisp/) than anything else.
> > >
> > > EuLisp offers the following benefits over Common Lisp (IMO):
> > >
> > > 1. EuLisp is a Lisp1 dialect offering a single namespace for variables
> > > and functions, or first-class functions, like Scheme. The benefits of
> > > this are too numerous to list and have been discussed ad neausium
> > > elsewhere.
> > >
> > > 2. EuLisp offers largely similar functionality in a much simpler,
> > > cleaner language with fewer required functions (largely due to its
> > > Lisp1 design).
> >
> > It is cleaner because the library functions have been designed without
> > that much backwards compatibility (like in Common Lisp). It is
> > simply a newer approach. The Lisp1 does not give it much advantage.
>
> Lisp2 means that all kinds of language primitives have to exist in two
> versions, or be parameterizable as to whether they are talking about
> the value cell or function cell. It makes the language bigger, and
> that's bad in and of itself. --- Daniel Weinreb, 28 Feb 2003
'all kinds' is a bit fuzzy. What are these primitives? What do you
think?
Up to now you fail to give a more exact picture. Random
citations don't help much, as we can see from the quote above.
It is not clear if you know what language primitives
need to exist in two versions, what primitives
are needed additionally and what the consequences are for
user-level code and library design? Do you have an idea?
> Having separate "value cells" and "function cells" (to use the "street
> language" way of saying it) was one of the most unfortuanate issues.
> We did not want to break pre-existing programs that had a global
> variable named "foo" and a global function named "foo" that were
> distinct. We at Symbolics were forced to insist on this, in the face
> of everyone's knowing that it was not what we would have done absent
> compatibility constraints. It's hard for me to remember all the
> specific things like this, but if we had had fewer compatibility
> issues, I think it would have come out looking more like Scheme in
> general. --- Daniel Weinreb, 24 Feb 2003
Common Lisp has all kinds of backwards compatibility issues.
In other places it was even dumbed down.
The other quotes are more about Common Lisp in general
and don't say much about Lisp1 vs. Lisp2.
> Do you really think people in 1000 years want to be
> constrained by hacks that got put into the foundations of
> Common Lisp because a lot of code at Symbolics depended on
> it in 1988? --- Paul Graham
If Common Lisp survives 1000 years, that will be an achievement.
If Common Lisp had more from Symbolics, that wouldn't be that bad.
Then we would have CLOS based pathnames, streams, and a
few other primitive datatypes in CLOS. We would have an
extensible LOOP. More flexible hashtables. And tons of
other features. Lisp Machine Lisp (= ZetaLisp) had some useful
features that didn't make it into Common Lisp.
> Common Lisp is a significantly ugly language. If Guy and I had been
> locked in a room, you can bet it wouldn't have turned out like that.
> --- Dick Gabriel
'ugly' is another fuzzy term. All kinds of people have said that Common
Lisp
is ugly (including me). But I also find C, Java, even Scheme, ... ugly.
The lack of keyword arguments in Scheme alone makes Scheme ugly
(memq, memv, member vs. MEMBER in Common Lisp.
assq, assv, assoc vs. ASSOC in Common Lisp. and so on.).
> A hacker's language is terse and hackable. Common Lisp is not.
> The good news is, it's not Lisp that sucks, but Common Lisp.
> --- Paul Graham, May 2001
Another rather fuzzy quote. Actually I'm not a fan of Paul Graham's
coding style and I'm definitely not a fan of his design principles for
ARC.
If he would like Common Lisp, that would make me nervous.
·······@corporate-world.lisp.de" <······@corporate-world.lisp.de> writes:
> 'all kinds' is a bit fuzzy. What are these primitives? What do you
> think?
> Up to now you fail to give a more exact picture. Random
> citations don't help much, as we can see from the quote above.
> It is not clear if you know what language primitives
> need to exist in two versions, what primitives
> are needed additionally and what the consequences are for
> user-level code and library design? Do you have an idea?
Well we can list them up for him:
quote function
let flet
let* labels (not exactly)
symbol-value symbol-function
funcall
boundp fboundp
round fround (just joking)
defvar, defparameter defun,defgeneric,defmethod
(but this is not really true for defgeneric
and defmethod)
define-symbol-macro defmacro (but this is not really true)
define-compiler-macro
symbol-macrolet macrolet (but this is not really true)
define-setf-expander, defsetf
What about: define-condition, defstruct, deftype, defpackage,
You would have to write
(define c (condition ...))
(define s (structure ...))
(define t (type ...))
(define p (package ...))
?
CL is not lisp-2, it's lisp-N with N>2...
> If Common Lisp survives 1000 years, that will be an achievement.
Well, 40 years running, 960 years to go... It's more than any other
programming language (but FORTRAN) can say.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we. -- Georges W. Bush
Am 20.11.2006 16:11 Uhr schrieb "Pascal Bourguignon" unter
<···@informatimago.com> in ··············@thalassa.informatimago.com:
> ·······@corporate-world.lisp.de" <······@corporate-world.lisp.de> writes:
>
>> 'all kinds' is a bit fuzzy. What are these primitives? What do you
>> think?
>> Up to now you fail to give a more exact picture. Random
>> citations don't help much, as we can see from the quote above.
>> It is not clear if you know what language primitives
>> need to exist in two versions, what primitives
>> are needed additionally and what the consequences are for
>> user-level code and library design? Do you have an idea?
>
> Well we can list them up for him:
>
> quote function
QUOTE? What is the role of QUOTE in a Lisp1 vs. FUNCTION in a Lisp2?
> let flet
> let* labels (not exactly)
> symbol-value symbol-function
> funcall
> boundp fboundp
#' notation
LAMBDA as a macro for (FUNCTION (LAMBDA ...
> defvar, defparameter defun,defgeneric,defmethod
> (but this is not really true for
defgeneric
So that's more like:
DEFVAR, DEFPARAMETER vs. DEFUN
> and defmethod)
> define-symbol-macro defmacro (but this is not really true)
> define-compiler-macro
Yeah those above I would not count in the light of a Lisp1 vs. Lisp2
discussion.
> symbol-macrolet macrolet (but this is not really true)
again, above does not really count...
> define-setf-expander, defsetf
>
> What about: define-condition, defstruct, deftype, defpackage,
> You would have to write
> (define c (condition ...))
> (define s (structure ...))
> (define t (type ...))
> (define p (package ...))
Again above is not interesting in a Lisp1 vs. Lisp2 discussion.
It would be interesting in a Lisp1 vs LispN discussion. ;-)
> ?
>
> CL is not lisp-2, it's lisp-N with N>2...
Yep. But it think the question was, which effects has the special treatment
of functions (calling convention, symbols and functions, ...) in Common Lisp
on the various language constructs. I think the effect is not 'all kinds
of', but more like 'a few'.
>
>
>> If Common Lisp survives 1000 years, that will be an achievement.
>
> Well, 40 years running, 960 years to go... It's more than any other
> programming language (but FORTRAN) can say.
>
Rainer Joswig wrote:
> Am 20.11.2006 16:11 Uhr schrieb "Pascal Bourguignon" unter
> <···@informatimago.com> in ··············@thalassa.informatimago.com:
>
> > ·······@corporate-world.lisp.de" <······@corporate-world.lisp.de> writes:
> >
> >> 'all kinds' is a bit fuzzy. What are these primitives? What do you
> >> think?
> >> Up to now you fail to give a more exact picture. Random
> >> citations don't help much, as we can see from the quote above.
> >> It is not clear if you know what language primitives
> >> need to exist in two versions, what primitives
> >> are needed additionally and what the consequences are for
> >> user-level code and library design? Do you have an idea?
> >
> > Well we can list them up for him:
> >
> > quote function
>
> QUOTE? What is the role of QUOTE in a Lisp1 vs. FUNCTION in a Lisp2?
They are sort-of analogous, both tell the interpreter to stop
evaluating and use what follows as data. Later that data may be
evaluated by funcall or eval if code, or list operations if data. In
simple interpreters it makes some sense. In Emacs Lisp "function" is a
synonym for quote, the bytecompiler considers it separately though.
Consider how lambda is defined in Emacs Lisp:-
(defmacro lambda (&rest cdr) (list 'function (cons 'lambda cdr)))
This becomes a bit nuttier once a compiler is involved.
Am 20.11.2006 17:32 Uhr schrieb "Rob Thorpe" unter
<·······@realworldtech.com> in
························@k70g2000cwa.googlegroups.com:
> Rainer Joswig wrote:
>> Am 20.11.2006 16:11 Uhr schrieb "Pascal Bourguignon" unter
>> <···@informatimago.com> in ··············@thalassa.informatimago.com:
>>
>>> ·······@corporate-world.lisp.de" <······@corporate-world.lisp.de> writes:
>>>
>>>> 'all kinds' is a bit fuzzy. What are these primitives? What do you
>>>> think?
>>>> Up to now you fail to give a more exact picture. Random
>>>> citations don't help much, as we can see from the quote above.
>>>> It is not clear if you know what language primitives
>>>> need to exist in two versions, what primitives
>>>> are needed additionally and what the consequences are for
>>>> user-level code and library design? Do you have an idea?
>>>
>>> Well we can list them up for him:
>>>
>>> quote function
>>
>> QUOTE? What is the role of QUOTE in a Lisp1 vs. FUNCTION in a Lisp2?
>
> They are sort-of analogous, both tell the interpreter to stop
> evaluating and use what follows as data.
No, see below. FUNCTION in CL (a Lisp with lexical scope)
is very DIFFERENT from QUOTE.
> Later that data may be
> evaluated by funcall or eval if code, or list operations if data. In
> simple interpreters it makes some sense. In Emacs Lisp "function" is a
> synonym for quote, the bytecompiler considers it separately though.
But in Common Lisp things are a bit different. Common Lisp has lexical
scope for functions.
FUNCTION in CL is a special operator and returns the functional
value of a function name or a of a lambda expression
in the current lexical environment.
QUOTE just returns the object unevaluated.
In Scheme (as a Lisp1 with lexical scope) you would not use QUOTE
in places where you would use FUNCTION in Common Lisp.
In Lisp1 FUNCTION is not necessary and NOT replaced by QUOTE.
Example1
--------
Lisp2:
(flet ((foo (bar) bar))
(function foo))
Lisp1:
(let ((foo (lambda (bar) bar)))
foo)
Example2
--------
Lisp2:
(let ((foo (function (lambda (bar) bar))))
foo)
In CL you can also write:
(let ((foo (function (lambda (bar) bar))))
foo)
Which then gets macro expanded to the earlier form above.
Lisp1:
(let ((foo (lambda (bar) bar)))
foo)
>
> Consider how lambda is defined in Emacs Lisp:-
> (defmacro lambda (&rest cdr) (list 'function (cons 'lambda cdr)))
What do you think LAMBDA is in Common Lisp?
try: (macroexpand '(lambda (foo) foo))
>
> This becomes a bit nuttier once a compiler is involved.
>
Am 20.11.2006 18:20 Uhr schrieb "Rainer Joswig" unter <······@lisp.de> in
·····················@lisp.de:
> Am 20.11.2006 17:32 Uhr schrieb "Rob Thorpe" unter
> <·······@realworldtech.com> in
> ························@k70g2000cwa.googlegroups.com:
>
>> Rainer Joswig wrote:
>>> Am 20.11.2006 16:11 Uhr schrieb "Pascal Bourguignon" unter
>>> <···@informatimago.com> in ··············@thalassa.informatimago.com:
>>>
>>>> ·······@corporate-world.lisp.de" <······@corporate-world.lisp.de> writes:
>>>>
>>>>> 'all kinds' is a bit fuzzy. What are these primitives? What do you
>>>>> think?
>>>>> Up to now you fail to give a more exact picture. Random
>>>>> citations don't help much, as we can see from the quote above.
>>>>> It is not clear if you know what language primitives
>>>>> need to exist in two versions, what primitives
>>>>> are needed additionally and what the consequences are for
>>>>> user-level code and library design? Do you have an idea?
>>>>
>>>> Well we can list them up for him:
>>>>
>>>> quote function
>>>
>>> QUOTE? What is the role of QUOTE in a Lisp1 vs. FUNCTION in a Lisp2?
>>
>> They are sort-of analogous, both tell the interpreter to stop
>> evaluating and use what follows as data.
>
> No, see below. FUNCTION in CL (a Lisp with lexical scope)
> is very DIFFERENT from QUOTE.
>
>> Later that data may be
>> evaluated by funcall or eval if code, or list operations if data. In
>> simple interpreters it makes some sense. In Emacs Lisp "function" is a
>> synonym for quote, the bytecompiler considers it separately though.
>
> But in Common Lisp things are a bit different. Common Lisp has lexical
> scope for functions.
>
> FUNCTION in CL is a special operator and returns the functional
> value of a function name or a of a lambda expression
> in the current lexical environment.
>
> QUOTE just returns the object unevaluated.
>
> In Scheme (as a Lisp1 with lexical scope) you would not use QUOTE
> in places where you would use FUNCTION in Common Lisp.
> In Lisp1 FUNCTION is not necessary and NOT replaced by QUOTE.
>
> Example1
> --------
>
> Lisp2:
>
> (flet ((foo (bar) bar))
> (function foo))
>
> Lisp1:
>
> (let ((foo (lambda (bar) bar)))
> foo)
>
> Example2
> --------
>
> Lisp2:
>
> (let ((foo (function (lambda (bar) bar))))
> foo)
>
> In CL you can also write:
>
> (let ((foo (function (lambda (bar) bar))))
> foo)
Oops, I meant:
(let ((foo (lambda (bar) bar)))
foo)
>
> Which then gets macro expanded to the earlier form above.
>
> Lisp1:
>
> (let ((foo (lambda (bar) bar)))
> foo)
>
>
>
>
>
>>
>> Consider how lambda is defined in Emacs Lisp:-
>> (defmacro lambda (&rest cdr) (list 'function (cons 'lambda cdr)))
>
> What do you think LAMBDA is in Common Lisp?
>
> try: (macroexpand '(lambda (foo) foo))
>
>>
>> This becomes a bit nuttier once a compiler is involved.
>>
>
Rainer Joswig wrote:
> Am 20.11.2006 17:32 Uhr schrieb "Rob Thorpe" unter
> <·······@realworldtech.com> in
> ························@k70g2000cwa.googlegroups.com:
>
> > Rainer Joswig wrote:
> >> Am 20.11.2006 16:11 Uhr schrieb "Pascal Bourguignon" unter
> >> <···@informatimago.com> in ··············@thalassa.informatimago.com:
> >>
> >>> ·······@corporate-world.lisp.de" <······@corporate-world.lisp.de> writes:
> >>>
> >>>> 'all kinds' is a bit fuzzy. What are these primitives? What do you
> >>>> think?
> >>>> Up to now you fail to give a more exact picture. Random
> >>>> citations don't help much, as we can see from the quote above.
> >>>> It is not clear if you know what language primitives
> >>>> need to exist in two versions, what primitives
> >>>> are needed additionally and what the consequences are for
> >>>> user-level code and library design? Do you have an idea?
> >>>
> >>> Well we can list them up for him:
> >>>
> >>> quote function
> >>
> >> QUOTE? What is the role of QUOTE in a Lisp1 vs. FUNCTION in a Lisp2?
> >
> > They are sort-of analogous, both tell the interpreter to stop
> > evaluating and use what follows as data.
>
> No, see below. FUNCTION in CL (a Lisp with lexical scope)
> is very DIFFERENT from QUOTE.
>
> > Later that data may be
> > evaluated by funcall or eval if code, or list operations if data. In
> > simple interpreters it makes some sense. In Emacs Lisp "function" is a
> > synonym for quote, the bytecompiler considers it separately though.
>
> But in Common Lisp things are a bit different. Common Lisp has lexical
> scope for functions.
>
> FUNCTION in CL is a special operator and returns the functional
> value of a function name or a of a lambda expression
> in the current lexical environment.
>
> QUOTE just returns the object unevaluated.
>
> In Scheme (as a Lisp1 with lexical scope) you would not use QUOTE
> in places where you would use FUNCTION in Common Lisp.
> In Lisp1 FUNCTION is not necessary and NOT replaced by QUOTE.
>
> Example1
> --------
>
> Lisp2:
>
> (flet ((foo (bar) bar))
> (function foo))
>
> Lisp1:
>
> (let ((foo (lambda (bar) bar)))
> foo)
>
> Example2
> --------
>
> Lisp2:
>
> (let ((foo (function (lambda (bar) bar))))
> foo)
>
> In CL you can also write:
>
> (let ((foo (function (lambda (bar) bar))))
> foo)
>
> Which then gets macro expanded to the earlier form above.
>
> Lisp1:
>
> (let ((foo (lambda (bar) bar)))
> foo)
You're right. Since in Scheme and CL functions form a separate type,
dissimilar from lists and trees. Function in CL is simply unnecessary
in Scheme.
The situation is complex and can't be summarised in a table comparing
lisp1 to lisp2, other things must be taken into account, like scope and
type of functions.
> > Consider how lambda is defined in Emacs Lisp:-
> > (defmacro lambda (&rest cdr) (list 'function (cons 'lambda cdr)))
>
> What do you think LAMBDA is in Common Lisp?
>
> try: (macroexpand '(lambda (foo) foo))
Interesting.
William James wrote:
> Rainer Joswig wrote:
>> Am 11.11.2006 20:27 Uhr schrieb "Blake mcBride" unter <·····@mcbride.name>
>> in ···············@news.supernews.com:
>>
>>> Greetings,
>>>
>>> First of all, I am posting this message to both the Scheme and Lisp
>>> newsgroups because the topic, EuLisp, is pretty much a cross between
>>> Common Lisp and Scheme. I've recently discovered EuLisp and found
>>> many aspects of it very interesting. It also has a rich political
>>> history which I won't discuss except to say that EuLisp was supposed
>>> to be Europe's answer to America's Common Lisp. Not being bound to as
>>> much history, EuLisp was freer in terms of technical options than
>>> Common Lisp. EuLisp actually seems closer to Oaklisp
>>> (http://www-bcl.cs.nuim.ie/~bap/oaklisp/) than anything else.
>>>
>>> EuLisp offers the following benefits over Common Lisp (IMO):
>>>
>>> 1. EuLisp is a Lisp1 dialect offering a single namespace for variables
>>> and functions, or first-class functions, like Scheme. The benefits of
>>> this are too numerous to list and have been discussed ad neausium
>>> elsewhere.
>>>
>>> 2. EuLisp offers largely similar functionality in a much simpler,
>>> cleaner language with fewer required functions (largely due to its
>>> Lisp1 design).
>> It is cleaner because the library functions have been designed without
>> that much backwards compatibility (like in Common Lisp). It is
>> simply a newer approach. The Lisp1 does not give it much advantage.
>
> Lisp2 means that all kinds of language primitives have to exist in two
> versions, or be parameterizable as to whether they are talking about
> the value cell or function cell. It makes the language bigger, and
> that's bad in and of itself. --- Daniel Weinreb, 28 Feb 2003
>
> Having separate "value cells" and "function cells" (to use the "street
> language" way of saying it) was one of the most unfortuanate issues.
> We did not want to break pre-existing programs that had a global
> variable named "foo" and a global function named "foo" that were
> distinct. We at Symbolics were forced to insist on this, in the face
> of everyone's knowing that it was not what we would have done absent
> compatibility constraints. It's hard for me to remember all the
> specific things like this, but if we had had fewer compatibility
> issues, I think it would have come out looking more like Scheme in
> general. --- Daniel Weinreb, 24 Feb 2003
>
> Do you really think people in 1000 years want to be
> constrained by hacks that got put into the foundations of
> Common Lisp because a lot of code at Symbolics depended on
> it in 1988? --- Paul Graham
>
> Common Lisp is a significantly ugly language. If Guy and I had been
> locked in a room, you can bet it wouldn't have turned out like that.
> --- Dick Gabriel
>
> A hacker's language is terse and hackable. Common Lisp is not.
> The good news is, it's not Lisp that sucks, but Common Lisp.
> --- Paul Graham, May 2001
Separation into function and value namespaces is an extremely good idea.
--- Pascal Costanza, 20 Nov 2006
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Blake mcBride wrote:
> Now my purpose in sending this post is not to start a language debate,
> flame, or war. Given some of the nice features of EuLisp, I am
> wondering why it appears to be a dead language.
Probably the main essential feature of Lisp is that once you have a
sufficiently complete implementation (be it a Lisp-1 like Scheme or a
Lisp-2 like Common Lisp), you can build both language extensions and
language subsets in relatively straightforward ways. Even in hard cases
where a language extension counters some of the basic design decisions
in the Lisp dialect of choice, it is typically possible to take a
layered design approach where you can choose to switch between two
different language worlds (and still provide some level of
interoperability).
Because of this, it's actually not necessary to have a large number of
competing Lisp dialects. If you have a decent Scheme implementation, you
can implement most or all of, say, EuLisp and Dylan as libraries on top.
If you have a decent Common Lisp implementation, you can implement most
of, say, ISLISP on top. In Common Lisp, it's even relatively
straightforward to implement most of Scheme on top (see Pseudoscheme).
Everyone has a different idea of what the perfect ideal Lisp dialect
should look like, and unfortunately many of these ideas are
incompatible. Instead, you can choose to be pragmatic, pick one of the
existing Lisp dialects that's closest to your "perfect Lisp", and
assemble your own combination of extensions and subset that work well
for your needs.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
After takin a swig o' Arrakan spice grog, "Blake mcBride" <·····@mcbride.name> belched out:
> Greetings,
>
> First of all, I am posting this message to both the Scheme and Lisp
> newsgroups because the topic, EuLisp, is pretty much a cross between
> Common Lisp and Scheme. I've recently discovered EuLisp and found
> many aspects of it very interesting. It also has a rich political
> history which I won't discuss except to say that EuLisp was supposed
> to be Europe's answer to America's Common Lisp. Not being bound to as
> much history, EuLisp was freer in terms of technical options than
> Common Lisp. EuLisp actually seems closer to Oaklisp
> (http://www-bcl.cs.nuim.ie/~bap/oaklisp/) than anything else.
>
> EuLisp offers the following benefits over Common Lisp (IMO):
>
> 1. EuLisp is a Lisp1 dialect offering a single namespace for variables
> and functions, or first-class functions, like Scheme. The benefits of
> this are too numerous to list and have been discussed ad neausium
> elsewhere.
You may get agreement on comp.lang.scheme; not so on comp.lang.lisp.
Better to assume that this benefit is a mirage.
> 2. EuLisp offers largely similar functionality in a much simpler,
> cleaner language with fewer required functions (largely due to its
> Lisp1 design).
Possible, but that isn't necessarily relevant.
> EuLisp offers the following benefits over Scheme (IMO):
>
> 1. EuLisp is object oriented from the ground up (everything is an
> object) offering a full meta object protocol (MOP) and reflection
> (all like Oaklisp).
>
> 2. EuLisp has a defined module system and threading system.
Having a well-defined threading system strikes me as the first
unambiguously relevant benefit that you've mentioned.
> Now my purpose in sending this post is not to start a language
> debate, flame, or war. Given some of the nice features of EuLisp, I
> am wondering why it appears to be a dead language. The EuLisp
> standard document is at version 0.99 and has been so since the late
> 90s. Also, there appears to be only one real implementation (Youtoo
> - open source) which also appears to be dead now. Nobody appears to
> be working with the standard, implementing, using, or even talking
> about EuLisp. I can't even seem to contact anyone related to the
> project. So the question is is anyone else out there using,
> implementing, or even thinking about EuLisp anymore?
CL had applications ported to it because parts of its design were
specifically done so that MacLisp code could be ported.
EuLisp didn't stabilize until the AI "winter" had arrived, which was a
"frozen Russia" to freeze up any European 'invaders'/(implementors
:-)).
If there had been significant EuLisp applications, people might care.
But the AI "winter" prevented that development from taking place, so
there's no reason anymore to care about EuLisp, however attractive it
might be.
--
wm(X,Y):-write(X),write(·@'),write(Y). wm('cbbrowne','gmail.com').
http://linuxdatabases.info/info/x.html
Rules of the Evil Overlord #129. "Despite the delicious irony, I will
not force two heroes to fight each other in the arena."
<http://www.eviloverlord.com/>
Christopher Browne wrote:
> If there had been significant EuLisp applications, people might care.
> But the AI "winter" prevented that development from taking place, so
> there's no reason anymore to care about EuLisp, however attractive it
> might be.
See, I don't agree. It's been 20 years or so: There's been some
new technology developed. Some kinds of traditional technology
can now be seen as redundant or clumsy. I think that it's
reasonable that new lisp dialects can and should arise, and not
just in the sense of defining a bunch of macros.
Bear
On Fri, 17 Nov 2006 10:36:18 +0100, Ray Dillinger <····@sonic.net> wrote:
> Christopher Browne wrote:
>
>> If there had been significant EuLisp applications, people might care.
>> But the AI "winter" prevented that development from taking place, so
>> there's no reason anymore to care about EuLisp, however attractive it
>> might be.
>
> See, I don't agree. It's been 20 years or so: There's been some
> new technology developed. Some kinds of traditional technology
> can now be seen as redundant or clumsy. I think that it's
> reasonable that new lisp dialects can and should arise, and not
> just in the sense of defining a bunch of macros.
>
> Bear
>
ARC?
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad wrote:
> On Fri, 17 Nov 2006 10:36:18 +0100, Ray Dillinger <····@sonic.net> wrote:
<clip>
>> I think that it's
>> reasonable that new lisp dialects can and should arise, and not
>> just in the sense of defining a bunch of macros.
> ARC?
Yah, Paul Graham obviously feels the same way.
Bear