Hi all,
According to Paul Graham[www.paulgraham.com/ilc03.html], any language
that contains the seven operators (quote, eq?, cons, car, cdr, pair?,
and cond) is a dialect of Lisp. What if array is used instead of linked
list? That is, use (make-vector vector vector?
vector-empty? vector-ref vector-length (vector-set!)) as primitives and
define the _eval_ correspondingly. Doing so will not lose linked list,
because pair is just vector of length 2.
-----------
The world is ever changing and it's useful to allow programs to change
dynamically with it
From: Kent M Pitman
Subject: Re: what if array instead of linked list
Date:
Message-ID: <uacodk8er.fsf@nhplace.com>
"MrMathematica" <···········@citiz.net> writes:
> According to Paul Graham[www.paulgraham.com/ilc03.html], any language
> that contains the seven operators (quote, eq?, cons, car, cdr, pair?,
> and cond) is a dialect of Lisp. What if array is used instead of linked
> list? That is, use (make-vector vector vector?
> vector-empty? vector-ref vector-length (vector-set!)) as primitives and
> define the _eval_ correspondingly. Doing so will not lose linked list,
> because pair is just vector of length 2.
Suppose someone said "ok, sure, include make-array"... or suppose they said
"never, you mustn't". How will your life change if you find the universe
has congregated around either of these positions?
These are just names.
And though Lisp is quite cool, it's less clear that the _name_ Lisp is
all that cool. People who like it seem to like it. But people who don't
seem not to.
If you have "all" of the so-called good ideas of Lisp and none of the
name baggage, maybe you'll do better...?
But more likely it won't have any effect one way or the other.
Kent M Pitman <······@nhplace.com> writes:
> And though Lisp is quite cool, it's less clear that the _name_ Lisp is
> all that cool. People who like it seem to like it. But people who don't
> seem not to.
Indeed the name Common Lisp is even worse because it just doesn't seem
to roll off the tongue. And the name Lisp itself seems to be
generic. I was speaking with a friend the other day who said Lisp was
used on a project he worked on. I was quite happy with the news and
asked which implementation to which he replied Chicken. But that's a
Scheme. And then he went on to complain about the huge fragmentation
of Scheme implementations and their incompatible libraries for
accessing system APIs as if it was a Lisp-wide problem. Sigh.
I did my best to set the record straight, but I'm not even sure that
the idea that Scheme and Common Lisp are two different languages the
way C and Java are really got across. I thought I had some progress
in that area when I explained how a while back I made a choice between
Scheme and Common Lisp because my brain wasn't ready to take on both
at once and that I choose Common Lisp. Then he said that he thought
Common Lisp was just a teaching language while Scheme was used for
serious industrial applications. Aargh.
I fear that Lisp, Common Lisp in particular, has a lot of
misconceptions to overcome even with those intelligent people who are
not taught a lite version of an interpreted Scheme in school.
Another "problem" is that the free CL implementations lack a sexy GUI
IDE. Yes, Emacs + SLIME rocks. But cosmetics are important as well.
I expect that, in time, McClim will help fix that. Perhaps OpenMCL's
Cocoa IDE will also get better (I haven't actually seen it yet). Many
people are going to judge Lisp from the free software offerings no
matter how good the trial edition of Lispworks is. Those same people
are a worthwhile target audiance to convince that Lisp is not just a
cool language but a useful one as well.
On a different note, has anyone written a decent Lisp-Advocacy-HOWTO?
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
David Steuber wrote:
> Indeed the name Common Lisp is even worse because it just doesn't seem
> to roll off the tongue. And the name Lisp itself seems to be
> generic. I was speaking with a friend the other day who said Lisp was
> used on a project he worked on. I was quite happy with the news and
> asked which implementation to which he replied Chicken. But that's a
> Scheme. And then he went on to complain about the huge fragmentation
> of Scheme implementations and their incompatible libraries for
> accessing system APIs as if it was a Lisp-wide problem. Sigh.
I would say that Scheme and Common Lisp are both Lisps, as are
Arc, LibRep (the Lisp behind the SawFish X11 window manager) and
others. Yes, CL people always refer to CL as Lisp, and from
context that's clear, but at least to me "Lisp" refers to the
family of languages with lots of ()s.
You might say that the Lisp world is fragmented as regards
libraries and system APIs.
> I did my best to set the record straight, but I'm not even sure that
> the idea that Scheme and Common Lisp are two different languages the
> way C and Java are really got across. I thought I had some progress
> in that area when I explained how a while back I made a choice between
> Scheme and Common Lisp because my brain wasn't ready to take on both
> at once and that I choose Common Lisp. Then he said that he thought
> Common Lisp was just a teaching language while Scheme was used for
> serious industrial applications. Aargh.
When I was new to Lisp (I learned Scheme in my 1st semester using
SICP) I thought CL was merely an old version of Lisp, like Emacs
Lisp (which I still refuse to learn because of its non-lexical
binding and other things I heard of :D), while Scheme was new and
cleaned up. Only after reading Paul Grahams stuff and finally
reading the beginning of On Lisp did I become aware that CL is in
fact a more powerful and more practical language than the still
mainly academic Scheme.
> I fear that Lisp, Common Lisp in particular, has a lot of
> misconceptions to overcome even with those intelligent people who are
> not taught a lite version of an interpreted Scheme in school.
Well, from my class I suspect I was the only one who really read
SICP cover to cover and actually appreciates Lisp now. We were
roughly 150 students.
Everyone else probably hates ()s because they never really got it
(because they didn't really try). Most of them might use XML by now.
One reason for this dislike of Scheme might be that SICP doesn't
mention macros at all, that most classes using Scheme don't,
either, and that Scheme macros are somewhat tricky, IMHO (and my
main reason for being here now). I myself dropped Scheme for a
while and used SML instead (less car/cdr). Lisp macros, OTOH, are
much more intuitive, and the language with stuff like dolist is
much nicer for imperative programs as well.
Maybe universities should drop Scheme+Java for CL, or introduce CL
after a beginning Scheme or SML class. *dream*
Ulrich Hobelmann <···········@web.de> schrieb:
> You might say that the Lisp world is fragmented as regards
> libraries and system APIs.
That's like saying the "C-family world" is fragmented as regards
libraries and system APIs, referring to C, C++, Objective C, C#, BCPL,
who knows what else.
Adrian Kubala wrote:
> Ulrich Hobelmann <···········@web.de> schrieb:
>
>>You might say that the Lisp world is fragmented as regards
>>libraries and system APIs.
>
> That's like saying the "C-family world" is fragmented as regards
> libraries and system APIs, referring to C, C++, Objective C, C#, BCPL,
> who knows what else.
Hey, that's a good idea! ;)
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
On Wed, 06 Apr 2005 10:54:33 +0200, Pascal Costanza wrote:
> Adrian Kubala wrote:
>> Ulrich Hobelmann <···········@web.de> schrieb:
>>
>>>You might say that the Lisp world is fragmented as regards
>>>libraries and system APIs.
>>
>> That's like saying the "C-family world" is fragmented as regards
>> libraries and system APIs, referring to C, C++, Objective C, C#, BCPL,
>> who knows what else.
>
> Hey, that's a good idea! ;)
That's a _cute_ idea, but to be fair: i think Ulrich was talking about
the API fragmentation _within_ the CL family. I got fed up with the
fragmentation within the Scheme world (basically: for part of my problems
implemetation A would provide smart and wonderful APIs, bit for the rest
implementation B or C would be much better). A lot of the CL community
claims that CL gives you an implementation independent standard that
covers all common ground. I was rather displeased when i found out (the
painful way) that there's nothing like a standard for networking et al.
(anyone for a _fully standards compliant_ XML parser????).
I love to do as much as i can in CL but i also must say it's the least
interoperable language i've come across so far :-/
Cheers Ralf Mattes
>
>
> Pascal
R. Mattes wrote:
> i think Ulrich was talking about
> the API fragmentation _within_ the CL family. I got fed up with the
> fragmentation within the Scheme world (basically: for part of my problems
> implemetation A would provide smart and wonderful APIs, bit for the rest
> implementation B or C would be much better). A lot of the CL community
> claims that CL gives you an implementation independent standard that
> covers all common ground. I was rather displeased when i found out (the
> painful way) that there's nothing like a standard for networking et al.
> (anyone for a _fully standards compliant_ XML parser????).
> I love to do as much as i can in CL but i also must say it's the least
> interoperable language i've come across so far :-/
This all depends on how you define "common ground". I think it's a good
idea that a language specification covers the stuff that is believed to
be stable on a long term. Unless someone finds revolutionary new ways
for specifying data structures and algorithms, it is pretty safe to
standardize on lists, trees, tables, arrays, numbers, chars, and so on.
It seems that these things won't be fundamentally different in, say, 20,
50 or 100 years from now.
I don't believe that XML will be around by then, or will probably look
very different. I don't know about the stability of networking APIs, so
I cannot judge this. But, for example, I also wouldn't bet on the
longevity of the notion of files. (In that regard, CL maybe covers too
much. ;)
Furthermore, I don't think that this situation is fundamentally
different in other language communities. To the contrary, for many
languages that have existed for a considerable amount of time, you can
find recommendations that you shouldn't do things as they are proposed
by the standard APIs, but instead use something else, etc. I think that
CL is quite stable in this regard.
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
On 2005-04-06, Pascal Costanza <··@p-cos.net> wrote:
>
> This all depends on how you define "common ground". I think it's a good
> idea that a language specification covers the stuff that is believed to
> be stable on a long term. Unless someone finds revolutionary new ways
> for specifying data structures and algorithms, it is pretty safe to
> standardize on lists, trees, tables, arrays, numbers, chars, and so on.
> It seems that these things won't be fundamentally different in, say, 20,
> 50 or 100 years from now.
The Common Lisp standard is 10 years old, and some things where different
back then, but there are some things that are obvious candidates for
standardization. The most obvious is networking and foreign function
interfaces, with multiple threads as a good candidate.
The central networking paradigm has been unchanged for almost 20 years.
It would not not be very radical to assume that there is stream-based or
packet-based, and that networking services can be identified by host name
or address, and port number/service name. I think that is unlikely to
change radically in the near future, and all major CL implementations
has an almost identical networking library feature-wise. They are just
incompatible, so a standardization would be favourable.
The same goes for FFI. Almost all CL implementations have it, but they
are incompatible, but feature-wise quite similar. The implemantation
differs in whether they allow callbacks to lisp, but is otherwise
similar.
For threads there is a little bit more to be desired. Not all implementations
have them, and the semantic differences is significant. Some implemantations
have os-threads others not, and there is no consensus about which features
that should be included. It is also harder for an implementation that has
chosen one approch, to switch to different semantics. It would be very
useful to standardize threading though, since it seems to get more and more
important. The problem is that we can get something like pathnames in the
current standard, where there is obviously some issues that could have been
better thought out during standardization, like the ability to traverse a
directory structure, but the concept was maybe not mature at the time.
>
> I don't believe that XML will be around by then, or will probably look
> very different. I don't know about the stability of networking APIs, so
> I cannot judge this. But, for example, I also wouldn't bet on the
> longevity of the notion of files. (In that regard, CL maybe covers too
> much. ;)
Neither do I, and XML parsing/handling should probably not be a part of
the language standard if it is to be revised in the next few years.
--
Gisle S�lensminde, Phd student, Scientific programmer
Computational biology unit, University of Bergen, Norway
Email: ·····@cbu.uib.no | Complicated is easy, simple is hard.
From: André Thieme
Subject: Re: what if array instead of linked list
Date:
Message-ID: <d30gok$1rq$1@ulric.tng.de>
Ulrich Hobelmann schrieb:
> [...]
> I thought CL was merely an old version of Lisp, like Emacs Lisp (which I
> still refuse to learn because of its non-lexical binding and other
> things I heard of :D)
> [...]
How difficult would it be to write a translator EL2CL?
Andr�
--
From: Joe Marshall
Subject: Re: what if array instead of linked list
Date:
Message-ID: <ekdouhgv.fsf@ccs.neu.edu>
Andr� Thieme <······························@justmail.de> writes:
> Ulrich Hobelmann schrieb:
>
>> [...]
>> I thought CL was merely an old version of Lisp, like Emacs Lisp
>> (which I still refuse to learn because of its non-lexical binding
>> and other things I heard of :D)
> > [...]
>
> How difficult would it be to write a translator EL2CL?
Not *that* hard, but....
A lot of the functionality in Emacs Lisp comes from the parts written
in C and you would have to emulate those.
From: Edi Weitz
Subject: Re: what if array instead of linked list
Date:
Message-ID: <u1x9oatda.fsf@agharta.de>
On Wed, 06 Apr 2005 13:27:07 +0200, Andr� Thieme <······························@justmail.de> wrote:
> How difficult would it be to write a translator EL2CL?
I seem to remember that CLOCC contains something like that. That
doesn't give you the underlying editor primitives, though, so I don't
think it's really useful.
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
In article <··············@david-steuber.com>,
David Steuber <·····@david-steuber.com> wrote:
> Another "problem" is that the free CL implementations lack a sexy GUI
> IDE. Yes, Emacs + SLIME rocks. But cosmetics are important as well.
I think it might be worthwhile to point people one thinks would be
impressed by a slick GUI/IDE to LispWorks personal for the time being.
By no means perfect, but still along the lines of what people expect
from an IDE, and it's available for the major platforms. This way they
can get a free taste of a real lisp implementation without having to
either spend any money up front, or deal with the complexities of
emacs/slime at the same time they are meeting lisp for the first time.
New users are likely to conflate the difficulties and rough edges of
emacs/slime with lisp itself (especially as emacs uses a dialect of lisp
as its extension language). For a world used to GUI/IDEs this extra
mental struggle is a negative for lisp. LispWorks personal avoids this
additional hurdle, and lets them get to know common lisp directly, in a
GUI context in which they are already comfortable.
David Steuber <·····@david-steuber.com> writes:
> Kent M Pitman <······@nhplace.com> writes:
>
> > And though Lisp is quite cool, it's less clear that the _name_ Lisp is
> > all that cool. People who like it seem to like it. But people who don't
> > seem not to.
>
> Indeed the name Common Lisp is even worse because it just doesn't seem
> to roll off the tongue.
Try: L++
> And the name Lisp itself seems to be
> generic. I was speaking with a friend the other day who said Lisp was
> used on a project he worked on. I was quite happy with the news and
> asked which implementation to which he replied Chicken. But that's a
> Scheme. And then he went on to complain about the huge fragmentation
> of Scheme implementations and their incompatible libraries for
> accessing system APIs as if it was a Lisp-wide problem. Sigh.
Yes, that's the problem with insisting to write Lisp or lisp instead of LISP.
> I did my best to set the record straight, but I'm not even sure that
> the idea that Scheme and Common Lisp are two different languages the
> way C and Java are really got across. I thought I had some progress
> in that area when I explained how a while back I made a choice between
> Scheme and Common Lisp because my brain wasn't ready to take on both
> at once and that I choose Common Lisp. Then he said that he thought
> Common Lisp was just a teaching language while Scheme was used for
> serious industrial applications. Aargh.
Aargh indeed.
> I fear that Lisp, Common Lisp in particular, has a lot of
> misconceptions to overcome even with those intelligent people who are
> not taught a lite version of an interpreted Scheme in school.
>
> Another "problem" is that the free CL implementations lack a sexy GUI
> IDE.
VisualCLisp
http://ciapek.uci.agh.edu.pl/~kwlodarc/VisualCLisp/en.htm
> Yes, Emacs + SLIME rocks. But cosmetics are important as well.
> I expect that, in time, McClim will help fix that. Perhaps OpenMCL's
> Cocoa IDE will also get better (I haven't actually seen it yet). Many
> people are going to judge Lisp from the free software offerings no
> matter how good the trial edition of Lispworks is. Those same people
> are a worthwhile target audiance to convince that Lisp is not just a
> cool language but a useful one as well.
>
> On a different note, has anyone written a decent Lisp-Advocacy-HOWTO?
>
> --
> An ideal world is left as an excercise to the reader.
> --- Paul Graham, On Lisp 8.1
--
__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
"Pascal Bourguignon" <····@mouse-potato.com> wrote in message
···················@thalassa.informatimago.com...
>
> Try: L++
>
Back to this again...
S-EXpression Integrated Language Editing Environment :-)
Even have a Swiftie:
"Parentheses? I love those well-rounded curves," Tom said SEXILEE.
--
Geoff
From: André Thieme
Subject: Re: what if array instead of linked list
Date:
Message-ID: <d30ghv$1lk$1@ulric.tng.de>
Pascal Bourguignon schrieb:
> VisualCLisp
> http://ciapek.uci.agh.edu.pl/~kwlodarc/VisualCLisp/en.htm
Oh no, it is full of C++ code. Imagine MS Visual Studio, programmed in
Perl or Mercury... no way.
Andr�
--