Beyond CL?
Jamie Border
thinking[2]..
Couldn't we have a CL++ (sorry) with some nice modern features (libraries as
good as Python, good profiling (yes, I've seen Allegro), blah blah blah, and
still keep the S-expression syntax (or lack thereof)?
Aside: I can't see how moving away from s-exp works - won't macros be
pathetically crippled?
Ramble ramble ramble, but my real point is: why aren't there more Paul
Grahams doing the same thing? Is the problem so intrinsically hard? Does
nobody care?
Jamie
[1] http://www.paulgraham.com/arc.html
[2] bad idea
Joe Marshall
> I've been reading about Arc[1], Paul Graham's Lisp-plus-to-be, and I've been
> thinking[2]..
>
> Couldn't we have a CL++ (sorry) with some nice modern features (libraries as
> good as Python, good profiling (yes, I've seen Allegro), blah blah blah, and
> still keep the S-expression syntax (or lack thereof)?
>
> Aside: I can't see how moving away from s-exp works - won't macros be
> pathetically crippled?
Yes.
> Ramble ramble ramble, but my real point is: why aren't there more Paul
> Grahams doing the same thing?
We're not independently wealthy.
> Is the problem so intrinsically hard?
No, but it is time consuming. A nice full featured CL++ would be a
few man-years in the making.
> Does nobody care?
Food and shelter are always nice, and there is little funding for
language design.
Pascal Costanza
> I've been reading about Arc[1], Paul Graham's Lisp-plus-to-be, and I've been
> thinking[2]..
>
> Couldn't we have a CL++ (sorry) with some nice modern features (libraries as
> good as Python, good profiling (yes, I've seen Allegro), blah blah blah, and
> still keep the S-expression syntax (or lack thereof)?
People are already working on this. It's called programming. ;)
> Aside: I can't see how moving away from s-exp works - won't macros be
> pathetically crippled?
Not necessarily. As long as you have a regular syntax, adding a macro
system should remain relatively straightforward. The more irregularities
you add, the harder it gets.
Macros are not the only reason for keeping the syntax simple.
> Ramble ramble ramble, but my real point is: why aren't there more Paul
> Grahams doing the same thing? Is the problem so intrinsically hard? Does
> nobody care?
There are a number of alternative Lisp dialects being worked on, if
that's what you mean. An important question is whether such attempted
fragmentation of the community really buys you anything. It's really
hard to beat the feature set of Common Lisp.
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Eric Lavigne
>features (libraries as good as Python, good profiling (yes,
>I've seen Allegro), blah blah blah, and still keep the
>S-expression syntax (or lack thereof)?
Yes, there are people who are trying to make CL better. Here is a list
of such projects: http://common-lisp.net/projects.shtml
It basically comes down to time, though. Each of these projects takes a
lot of time. Libraries as good as Python? Well, if you have a favorite
Python library, then you can start translating now ^^ If you want all
of Python's libraries, then time becomes a big problem. Python has more
programmers than we do, so it's hard to keep up. An alternative
solution would be to write a python2lisp translator, but this is no
small task.
>I can't see how moving away from s-exp works - won't macros
>be pathetically crippled?
Paul Graham answered this at http://www.paulgraham.com/arcll1.html
which is linked by the reference page you gave:
http://www.paulgraham.com/arc.html
The basic idea is that macros still operate on s-expressions. Arc
syntax is translated into s-expressions before macros get a chance to
see them.
So the answer (or an answer), I think, to the long pondered question of
syntax for Lisp is: yes, have syntax, but only as abbreviation. Arc
will have syntax, but it will translate in a clearly defined (and in
fact, redefinable) way into underlying s-expressions. Nearly all the
syntax will be optional, and moreover optional at the level of
individual operators.
>why aren't there more Paul Grahams doing the same thing?
>Is the problem so intrinsically hard? Does
>nobody care?
There are quite a lot of languages out there, so many that it would
probably take a long time just to read all their names. There are a few
unique things about the particular case of Arc, though:
1) It's inventor is famous, especially in this newsgroup.
2) It is promised to be the best language ever. Who wouldn't get
excited about that ^^
Writing a new language is fairly easy. Making it good enough to be
worth learning is hard. Convincing others that it is good enough to be
worth learning (so that they will give it a try) is also hard. Adding a
new library to an existing language is far easier on both counts.
R. Mattes
> I've been reading about Arc[1], Paul Graham's Lisp-plus-to-be, and I've been
> thinking[2]..
>
> Couldn't we have a CL++ (sorry)
Wouldn't that be (incf CL) - or short INCL ?-)
> with some nice modern features (libraries as
> good as Python,
Funny, the python libs i had to work with were of rather mediocre quality.
There is _lots_ of python code, agreed, but quantity isn't quality (and
the same is true for CL libs as well ..).
> good profiling (yes, I've seen
Allegro), blah blah blah, and still keep
> the S-expression syntax (or lack thereof)?
>
> Aside: I can't see how moving away from s-exp works - won't macros be
> pathetically crippled?
>
> Ramble ramble ramble, but my real point is: why aren't there more Paul
> Grahams doing the same thing? Is the problem so intrinsically hard?
> Does nobody care?
I think people do care - see common-lisp.net and the loads of Debian CL
packages. But it does take time -- and we all need to earn money, don't we?
Cheers RalfD
Pascal Bourguignon
Nobody care. If you want more library, just write then in Common Lisp.
--
__Pascal Bourguignon__ http://www.informatimago.com/
This is a signature virus. Add me to your signature and help me to live
Tayssir John Gabbour
It's an economics problem. So let's think of what Lisp already
required.
* Teams of people who could lavish time on it. Lisp did not have a
single hand, as we can see from examining documents; and I think any
serious advance generally requires groups of people collaborating in
some fashion, despite what mediocre history books like to claim.
* Resources without expectation of profit. Lisp tore through both
government and investor cash.
Tayssir
rsher...@gmail.com
you suggest could be built as libraries on top of CL, eliminating the
need for a new Lisp dialect. But there have been and are people
implementing new Lisp dialects, most of which seem to generate little
interest. If you waste enough time visiting Lisp-related websites,
you'll find them.
Paul Graham is something of a celebrity, so everybody knows about his
vaporware, but he's not the only one. Goo, for example, is quite
similar to Arc, but it's not very well known at all (yet it may be the
most well known recent new Lisp dialect except for Arc).
Kenny Tilton
Jamie Border wrote:
> I've been reading about Arc[1], Paul Graham's Lisp-plus-to-be, and I've been
> thinking[2]..
>
> Couldn't we have a CL++
Congratulations, you have earned a membership in the Complete Fucking
Morons of Programming Club. These are people who look at the best
programming language available and worry about why it is not better. A
necessary requirement is not being smart enough to understand how much
better the better language is, such that in their wildest dreams they
could not be held back by said language.
The good news is that the denizens of comp.lang.lisp will leap frothing
at this pavlovian bell and discuss the profundities of your post for
weeks to come.
--
Kenny
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"I've wrestled with reality for 35 years, Doctor, and I'm happy to state
I finally won out over it."
Elwood P. Dowd, "Harvey", 1950
Raffael Cavallaro
> Goo, for example, is quite
> similar to Arc, but it's not very well known at all (yet it may be the
> most well known recent new Lisp dialect except for Arc).
Speaking of which, Jonathan Bachrach recently wrote that he'll be
getting back to goo soon after working on other projects, and noted that
"Any specific requests would be appreciated."
the list is at:
<mailto://googo...@lists.csail.mit.edu>
rsher...@gmail.com
to get you into the Complete Fucking Morons of Programming Club, is it
Henry Baker or John McCarthy that teaches you the secret handshake?
Kenny Tilton
That gets you into the Bullshit Debating Tactics Club.
Jamie Border
"Pascal Costanza" <p...@p-cos.net> wrote:
>> Ramble ramble ramble, but my real point is: why aren't there more Paul
>> Grahams doing the same thing? Is the problem so intrinsically hard?
>> Does nobody care?
>
> There are a number of alternative Lisp dialects being worked on, if that's
> what you mean. An important question is whether such attempted
> fragmentation of the community really buys you anything. It's really hard
> to beat the feature set of Common Lisp.
Ah. I failed to express myself properly. What I meant was this:
The CL standardisation process took disparate Lisps and made them easy to
modify to make them standard-compliant.
Couldn't we (well, probably not me, I'm still green) do a similar thing;
taking the best features from Allegro, CMUCL etc, and standardise them?
That way we could have portable networking code etc. with no loss of CL
wonderfuness. Surely we (you guys) could shut the anti-Lisp crowd up a bit
by giving them optional shorter names (mvb not multiple-value-bind, etc.).
You don't have to want it yourself - make it a package (use-package
incomprehensibly-short-names).
Surely if Torvalds can manage a whole bunch of hackers and build something
as big as the Linux kernel, there could be a collaborative effort that might
succeed.
My thought is that this _would_ buy something: less fragmentation. Giving
people standard libraries and (maybe) optionally shadowing some of the
"COMMON-LISP" package wouldn't break a single line of existing code and
would help portable code.
This would surely not remove the commerical advantage of people like Franz -
if they don't have to do stupid stuff like maintain their own standards for
thing like networking and FFI, surely they could be doing more exciting
stuff.
Oh, and it would stop the "Lisp is dead" rants. Perhaps.
Jamie
Jamie Border
"Eric Lavigne" <lavign...@gmail.com> wrote
Me>>I can't see how moving away from s-exp works - won't macros
Me>>be pathetically crippled?
>
> Paul Graham answered this at http://www.paulgraham.com/arcll1.html
> which is linked by the reference page you gave:
> http://www.paulgraham.com/arc.html
> The basic idea is that macros still operate on s-expressions. Arc
> syntax is translated into s-expressions before macros get a chance to
> see them.
Yes. I read this. But right now lisp code is s-exp based, so I can read
the result of the macro expansion. If the macro is written carefully, I can
see the code I would have had to type manually. If you introduce syntax and
macros don't produce output that uses it this break, and I see this as
lossage. Yes, I know that his idea is for syntax to be mostly optional.
>
> So the answer (or an answer), I think, to the long pondered question of
> syntax for Lisp is: yes, have syntax, but only as abbreviation. Arc
> will have syntax, but it will translate in a clearly defined (and in
> fact, redefinable) way into underlying s-expressions. Nearly all the
> syntax will be optional, and moreover optional at the level of
> individual operators.
Hmm.
>
Me>>why aren't there more Paul Grahams doing the same thing?
Me>>Is the problem so intrinsically hard? Does
Me>>nobody care?
>
> There are quite a lot of languages out there, so many that it would
> probably take a long time just to read all their names. There are a few
> unique things about the particular case of Arc, though:
> 1) It's inventor is famous, especially in this newsgroup.
I can see this. But is there not also room for something that runs CL code
but has less weirdness?
> 2) It is promised to be the best language ever. Who wouldn't get
> excited about that ^^
*dribble*
>
> Writing a new language is fairly easy. Making it good enough to be
> worth learning is hard. Convincing others that it is good enough to be
> worth learning (so that they will give it a try) is also hard. Adding a
> new library to an existing language is far easier on both counts.
Kind of what I was thinking. If you can still use _all_ of CL, but pile on
some nice stuff to attract new users, then surely this could be good?
Jamie
Jamie Border
"R. Mattes" <r...@mh-freiburg.de> wrote:
Me>> with some nice modern features (libraries as
Me>> good as Python,
>
> Funny, the python libs i had to work with were of rather mediocre quality.
OK, read good as extensive.
Jamie Border
"Pascal Bourguignon" <p...@informatimago.com> wrote:
Me>> Ramble ramble ramble, but my real point is: why aren't there more Paul
Me>> Grahams doing the same thing? Is the problem so intrinsically hard?
Does
Me>> nobody care?
>
> Nobody care. If you want more library, just write then in Common Lisp.
Yes. That way we will all reinvent similar wheels. And mine will be crap
because I'm so new to Lisp :-(
Jamie Border
a few?
Jamie
>
> Tayssir
>
Jamie Border
Me>> Couldn't we have a CL++
>
> Congratulations, you have earned a membership in the Complete Fucking
> Morons of Programming Club. These are people who look at the best
a) Tell Paul Graham he's a Fucking Moron.
b) So we should have stopped at bronze tools, because they were great, and
anybody who said "these are the best tools, can they be better?" belonged to
the Complete Fucking Morons of Hand Tools Club?
> programming language available and worry about why it is not better. A
> necessary requirement is not being smart enough to understand how much
> better the better language is, such that in their wildest dreams they
> could not be held back by said language.
No. My employer is now trying to find a good way to use cells-gtk. I was
trying to convey my frustration at convincing my colleagues to use CL.
>
> The good news is that the denizens of comp.lang.lisp will leap frothing at
> this pavlovian bell and discuss the profundities of your post for weeks to
> come.
Or perhaps they will tell me that I am a moron.
Jamie
Jamie Border
> If speculating about the possibility of Lisps superior to CL is enough
> to get you into the Complete Fucking Morons of Programming Club, is it
> Henry Baker or John McCarthy that teaches you the secret handshake?
>
I've had a change of heart. I want in.
Jamie
Ulrich Hobelmann
> Couldn't we (well, probably not me, I'm still green) do a similar thing;
> taking the best features from Allegro, CMUCL etc, and standardise them?
Obviously, standardizing stuff like threads, pathnames, and other
features would be great. I guess the CLRFIs' point is just that.
> That way we could have portable networking code etc. with no loss of CL
> wonderfuness. Surely we (you guys) could shut the anti-Lisp crowd up a bit
> by giving them optional shorter names (mvb not multiple-value-bind, etc.).
> You don't have to want it yourself - make it a package (use-package
> incomprehensibly-short-names).
defmacro
No, seriously, I used to think that mvb (and call/cc in Scheme)
are horrid names, but when you have something like slime (i.e. a
decent IDE) the length of names doesn't matter at all. What
matters is that names are different enough so typing three or four
characters lets you expand the thing into the long symbol.
> Surely if Torvalds can manage a whole bunch of hackers and build something
> as big as the Linux kernel, there could be a collaborative effort that might
> succeed.
Well, one is a hacked-together system that continually adds
features, like a Lisp implementation. The other is a standard,
which takes a lot more work and especially coordination, as LOTS
of people have to be asked to make it good.
> My thought is that this _would_ buy something: less fragmentation. Giving
> people standard libraries and (maybe) optionally shadowing some of the
> "COMMON-LISP" package wouldn't break a single line of existing code and
> would help portable code.
Why not? There could be a new package that users can use instead
of COMMON-LISP -- if they want. OTOH the new package would
probably just include CL, not really shadow anything.
--
XML is a prime example of retarded innovation.
-- Erik Meijer and Peter Drayton, Microsoft Corporation
Ulrich Hobelmann
> Wouldn't that be (incf CL) - or short INCL ?-)
It's not about adding, it's about consing.
'(LISP)
(ok, maybe consing nil isn't too much of an improvement ;) )
antoan...@hotmail.com
Stop losing time with languages to be
and continue mastering CL.
Once you'll become a Jedi you may
start writing language you feel it should
look a like.
And BTW s-expressions stays or don't
count on my help .
se...@lycos.com
What's the term for the green programmer
who instead of exercising and practicing his coding
skills is trying to draw attention to himself
by posting in forums and newsgroups various "hot" threads ?
If there's none give your suggestions 'couse
the above are really floating .
Jamie Border
"Ulrich Hobelmann" <u.hob...@web.de> wrote in message
news:3jpd3rF...@individual.net...
> Jamie Border wrote:
>> Couldn't we (well, probably not me, I'm still green) do a similar thing;
>> taking the best features from Allegro, CMUCL etc, and standardise them?
>
> Obviously, standardizing stuff like threads, pathnames, and other features
> would be great. I guess the CLRFIs' point is just that.
>
>> That way we could have portable networking code etc. with no loss of CL
>> wonderfuness. Surely we (you guys) could shut the anti-Lisp crowd up a
>> bit by giving them optional shorter names (mvb not multiple-value-bind,
>> etc.). You don't have to want it yourself - make it a package
>> (use-package incomprehensibly-short-names).
>
> defmacro
>
> No, seriously, I used to think that mvb (and call/cc in Scheme) are horrid
> names, but when you have something like slime (i.e. a decent IDE) the
> length of names doesn't matter at all. What
Yes, but screen space is as valuable to me as clarity, so it would be nice
to shorten a few things in a way that wouldn't make my code "unique" (read
"too hard to read").
> matters is that names are different enough so typing three or four
> characters lets you expand the thing into the long symbol.
>
>> Surely if Torvalds can manage a whole bunch of hackers and build
>> something as big as the Linux kernel, there could be a collaborative
>> effort that might succeed.
>
> Well, one is a hacked-together system that continually adds features, like
> a Lisp implementation. The other is a standard, which takes a lot more
> work and especially coordination, as LOTS of people have to be asked to
> make it good.
But nobody seems to tell CLRFI.
>
>> My thought is that this _would_ buy something: less fragmentation.
>> Giving people standard libraries and (maybe) optionally shadowing some of
>> the "COMMON-LISP" package wouldn't break a single line of existing code
>> and would help portable code.
>
> Why not? There could be a new package that users can use instead of
> COMMON-LISP -- if they want. OTOH the new package would probably just
> include CL, not really shadow anything.
Hmm. I still look green, don't I? Actually, I like the verbosity, my
co-workers don't, and I'm changing jobs anyway, so maybe the problem goes
away for me.
I don't think it's a bad idea, though, to ask people new to Lisp about
things they'd change if they knew how (portable networking, fast, portable
string-handling).
Jamie
Jamie Border
<antoan...@hotmail.com> wrote:
> Jamie i would give you an free advise .
> Stop losing time with languages to be
> and continue mastering CL.
I am doing this.
> Once you'll become a Jedi you may
> start writing language you feel it should
> look a like.
When nine hundred years old I reach, care I will not.
> And BTW s-expressions stays or don't
> count on my help .
I don't want help. I am possibly the least qualified person here to try to
_do_ something, I was just asking the question.
Jamie Border
> Question :
> What's the term for the green programmer
> who instead of exercising and practicing his coding
> skills is trying to draw attention to himself
> by posting in forums and newsgroups various "hot" threads ?
Green? No. New to Lisp, yes.
I am writing as much CL as I can. I've replaced some dumass utilities that
I use at work with cells-gtk based stuff, and I'm trying to understand the
CPS code-walker in UnCommon Web.
I'm trying, but I'm also so new that I don't care if i'm asking old
questions.
If I wanted to draw attention to myself I would start talking about game
development in Lisp.
Jamie
Tim X
> "Pascal Bourguignon" <p...@informatimago.com> wrote:
>
> Me>> Ramble ramble ramble, but my real point is: why aren't there more Paul
> Me>> Grahams doing the same thing? Is the problem so intrinsically hard?
> Does
> Me>> nobody care?
> >
> > Nobody care. If you want more library, just write then in Common Lisp.
>
> Yes. That way we will all reinvent similar wheels. And mine will be crap
> because I'm so new to Lisp :-(
Ah yes, but it will be much better quality and more flexible crap than
a wheel re-invented in C or Java!
--
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you
really need to send mail, you should be able to work it out!
Jamie Border
"Tim X" <ti...@spamto.devnul.com> wrote:
> "Jamie Border" <ja...@jborder.com> writes:
>
>> "Pascal Bourguignon" <p...@informatimago.com> wrote:
>>
>> Me>> Ramble ramble ramble, but my real point is: why aren't there more
>> Paul
>> Me>> Grahams doing the same thing? Is the problem so intrinsically hard?
>> Does
>> Me>> nobody care?
>> >
>> > Nobody care. If you want more library, just write then in Common Lisp.
>>
>> Yes. That way we will all reinvent similar wheels. And mine will be
>> crap
>> because I'm so new to Lisp :-(
>
> Ah yes, but it will be much better quality and more flexible crap than
> a wheel re-invented in C or Java!
>
better, and I'm enjoying it more.
Tim X
>
> If I wanted to draw attention to myself I would start talking about game
> development in Lisp.
>
Surely you mean you would start talking about how lisp is no good for
game programming because it doesn't have the right GL library in a
compact easy to use format that doesn't depend on some other library
and is portable to every platform, even those which haven't been
invented yet.
se...@lycos.com
to post it. If it's usefull there won't be problem to find
somebody to eager to help to make it better .
Everytime we need something nontrivial we Google first
than we write it by ourselves .
Jamie Border
> "Jamie Border" <ja...@jborder.com> writes:
>
>>
>> If I wanted to draw attention to myself I would start talking about game
>> development in Lisp.
>>
>
> Surely you mean you would start talking about how lisp is no good for
> game programming because it doesn't have the right GL library in a
> compact easy to use format that doesn't depend on some other library
> and is portable to every platform, even those which haven't been
> invented yet.
Tim, you've made my day.
Pascal Costanza
> "Pascal Costanza" <p...@p-cos.net> wrote:
>
>>>Ramble ramble ramble, but my real point is: why aren't there more Paul
>>>Grahams doing the same thing? Is the problem so intrinsically hard?
>>>Does nobody care?
>>
>>There are a number of alternative Lisp dialects being worked on, if that's
>>what you mean. An important question is whether such attempted
>>fragmentation of the community really buys you anything. It's really hard
>>to beat the feature set of Common Lisp.
>
> Ah. I failed to express myself properly. What I meant was this:
>
> The CL standardisation process took disparate Lisps and made them easy to
> modify to make them standard-compliant.
>
> Couldn't we (well, probably not me, I'm still green) do a similar thing;
> taking the best features from Allegro, CMUCL etc, and standardise them?
These things already happen. See for example
http://www.cliki.net/ACL-COMPAT or http://uffi.b9.com/
It's important to understand the following: In many other languages, you
need some kind of standardization efforts because integrating stuff
often requires changes to the respective languages. This is not always
obvious, but there is a reason why most languages continually grow, and
often in incompatible ways. If there is a strong gap between
language-level and library-level features, and as soon as you add
sophisticated APIs to languages that started out too simplistic people
start to feel a need to make the language as such more flexible. I think
this is inevitable.
In Lisp, this kind of pressure to make the language more flexible
doesn't exist. The boundary between language and libraries is so blurred
that you can very easily add features that pretend to be new language
constructs. This effectively means that you can go quite a long way by
just implementing libraries before the need for "standardization" ever
arises.
People are just doing that, and this works quite well.
Pascal Costanza
>
> Jamie Border wrote:
>
>> I've been reading about Arc[1], Paul Graham's Lisp-plus-to-be, and
>> I've been thinking[2]..
>>
>> Couldn't we have a CL++
>
> Congratulations, you have earned a membership in the Complete Fucking
> Morons of Programming Club. These are people who look at the best
> programming language available and worry about why it is not better. A
> necessary requirement is not being smart enough to understand how much
> better the better language is, such that in their wildest dreams they
> could not be held back by said language.
Don't be so negative. It seems to me that it happens quite often that
newbies understand that Lisp is such a malleable language that they
start to imagine in what ways it could be "much better". It's an
expression of the fact that they have probably already dreamt of what
their preferred "perfect" language should look like and that they have
just gotten close to being able to actually realizing that dream. It's
an effect of the distinguishing characteristic of Lisp that they don't
completely grasp immediately.
The next step is to understand that they can just do it by taking Lisp
and just simply programming in it. This seems to be a separate step in
the learning process. At least it was like that in my case, and I am not
surprised that it's like that for other people.
> The good news is that the denizens of comp.lang.lisp will leap frothing
> at this pavlovian bell and discuss the profundities of your post for
> weeks to come.
Cool, eh? ;)
Pascal Bourguignon
> R. Mattes wrote:
>> Wouldn't that be (incf CL) - or short INCL ?-)
>
> It's not about adding, it's about consing.
>
> '(LISP)
>
> (ok, maybe consing nil isn't too much of an improvement ;) )
(cons 'common (cons 'lisp (cons '++ nil)))
--
__Pascal_Bourguignon__ _ Software patents are endangering
() ASCII ribbon against html email (o_ the computer industry all around
/\ 1962:DO20I=1.100 //\ the world http://lpf.ai.mit.edu/
2001:my($f)=`fortune`; V_/ http://petition.eurolinux.org/
Jamie Border
Yes. I suppose any particular feature/package/whatever that is well-written
and does the job becomes the "standard" until it gets bettered by something
new.
Not having much exposure to Lisp _culture_ I am just starting to see how
this would make most people run screaming. But there is a difference
between forciing ANSI-style standards on people and offering consistent
(which is what I think I should have said) way of doing things they find
interesting.
Maybe all it needs is for somebody to assemble a reasonably large collection
of good stuff (I'm thinking UFFI, Iterate, a lot of CLOCC) and position it
as "a bunch of stuff aimed at Lisp Newbies to help them do useful stuff
faster".
That way, people like me wouldn't be pissing off half the guys in c.l.l by
asking (to them) stupid questions.
Maybe less people would be turned off if they saw that they can write their
(my) pathetic little programs without such a steep learning curve.
Maybe it wouldn't make a blind bit of difference. I don't know any more.
But at least I'm not afraid to say "I don't know".
Jamie
Ulrich Hobelmann
> Hmm. I still look green, don't I? Actually, I like the verbosity, my
> co-workers don't, and I'm changing jobs anyway, so maybe the problem goes
> away for me.
I think it's mostly self-development and education. I used to
like terse languages, because I used vi and refused to use any
tools. Now I started using Lisp and Objective C, and though my
code is much more verbose, it's actually *more* readable, and I
type *less* than before, because most names are completed quickly
by SLIME or XCode.
And looking into the Java world (or even open-source C, like gtk)
most people use verbose method names anyway. The difference is
that in Lisp you have verbosity, but you avoid code duplication by
use of macros. So the code that's there is both very readable and
very concise, while C code may be terse, but still cluttered.
> I don't think it's a bad idea, though, to ask people new to Lisp about
> things they'd change if they knew how (portable networking, fast, portable
> string-handling).
Not at all.
Pascal Costanza
> Yes. I suppose any particular feature/package/whatever that is well-written
> and does the job becomes the "standard" until it gets bettered by something
> new.
Note that this is what happens anyway in almost any language, no matter
how "strong" their standardization mechanisms are.
> Not having much exposure to Lisp _culture_ I am just starting to see how
> this would make most people run screaming. But there is a difference
> between forciing ANSI-style standards on people and offering consistent
> (which is what I think I should have said) way of doing things they find
> interesting.
>
> Maybe all it needs is for somebody to assemble a reasonably large collection
> of good stuff (I'm thinking UFFI, Iterate, a lot of CLOCC) and position it
> as "a bunch of stuff aimed at Lisp Newbies to help them do useful stuff
> faster".
CL implementations typically come packaged with a number of useful
extensions, so this already happens. Just pick the implementation that
you think suits you most (i.e., has the additional libraries / features
that you want to use). The danger of vendor lock-in is very low.
It would surely be great if there were some more coherence across
several CL implementations wrt such extensions. But this is really,
really hard to achieve. Note that, for example, ANSI Common Lisp itself
wasn't achieved in a day. It actually took some 15 years, or so, to be
finalized, although almost all of the features were already available in
some form or the other. It's important to realize that this is what
you're asking for.
Standards should reflect practice that a considerable large amount of
people agree is good. Standardization itself is not a goal, just a means
to an end. What happens in a lot of other places is that things get
standardized without any, or with very little evidence that they
actually work in practice. Taking into account that the Lisp community
is relatively small and has relatively little money, I think it's much
preferable to actually get important things done now and worry about
streamlining them later when there is enough impetus.
Note that there are already some efforts to do something along the lines
that you propose, like the CLRFI process. But again, these things are
not as simple as they seem and they definitely take their time.
Brian
whatsoever. Sadly, I see a lot of inflamatory posts with no
constructive value at all in this group...
Jamie Border
No, they have amusement value. I don't think that it does any harm to get
called a fool by somebody as obviously talented as Kenny.
Jamie
Russell McManus
lispnubi
...These are people who look at the best
> programming language available and worry about why it is not better. A
> necessary requirement is not being smart enough to understand how much
> better the better language is, such that in their wildest dreams they
> could not be held back by said language.
>
oh yes, programming in cobol is great!
Kenny Tilton
Jamie Border wrote:
> "Kenny Tilton" <kti...@nyc.rr.com> wrote:
>
> Me>> Couldn't we have a CL++
>
>>Congratulations, you have earned a membership in the Complete Fucking
>>Morons of Programming Club. These are people who look at the best
>
>
> a) Tell Paul Graham he's a Fucking Moron.
Try to keep up, will you? Graham was drummed out of the CFMPC when he
stopped active development of Arc.
Besides, Graham, unlike certain geniuses who pop up around here from
time to time fully mastered Lisp and wrote a lot of Actual Code before
attempting improvements. I should have mentioned that both those things
disqualify someone for CFMPC. Not to worry: you are still nicely eligible.
>
> b) So we should have stopped at bronze tools, because they were great, and
> anybody who said "these are the best tools, can they be better?" belonged to
> the Complete Fucking Morons of Hand Tools Club?
I'll put you down for the "Argument By Analogy Is Like Driving Backwards
When You Get Lost" SIG.
>
>
>>programming language available and worry about why it is not better. A
>>necessary requirement is not being smart enough to understand how much
>>better the better language is, such that in their wildest dreams they
>>could not be held back by said language.
>
>
> No. My employer is now trying to find a good way to use cells-gtk. I was
> trying to convey my frustration at convincing my colleagues to use CL.
You are using Cells? You should have mentioned up front that you are a
far-sighted genius. All is forgiven.
>
>
>>The good news is that the denizens of comp.lang.lisp will leap frothing at
>>this pavlovian bell and discuss the profundities of your post for weeks to
>>come.
>
>
> Or perhaps they will tell me that I am a moron.
Actually, I see a few have told you to get off c.l.l and go do some
programming. Word.
Robert Uhl
>
> The boundary between language and libraries is so blurred that you can
> very easily add features that pretend to be new language
> constructs. This effectively means that you can go quite a long way by
> just implementing libraries before the need for "standardization" ever
> arises.
But standardisation does offer certain unique advantages, chief among
them the guarantee that a conforming implementation will offer certain
features. E.g. if the standard included split-string, we wouldn't all
need to grab the code and add it to our utility libraries (and possibly
extend it in incompatible ways...). If the standard more fully defined
what the components of a pathname indicate, we wouldn't need to each
play about with portable pathname libraries. If the standard defined
once and for all a canonical MOP, we could just rely on the thing.
--
Robert Uhl <http://public.xdi.org/=ruhl>
I really have to hand it to Fox this time, they've hit an all new low.
And I just love new lows. They remind me that progress is growth, and
growth is a two way street. --Rick Felice
Robert Uhl
>
> Funny, the python libs i had to work with were of rather mediocre
> quality. There is _lots_ of python code, agreed, but quantity isn't
> quality (and the same is true for CL libs as well ..).
The python standard library is, if not perfect, pretty damned useful.
E.g. pickle: the ability to take _any_ data structure, write it to a
file, and read it in later. That's pretty sweet, and as far as I know
there is no CL equivalent. Or string, which offers more features than
CL's strings. Or re, the regexp package. Or unittest. And _all_ of
these are _guaranteed_ to exist on every single Python installation.
Which is pretty nice.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Brought to you by 'Ouchies', the sharp, prickly toy you bathe with...
Pascal Costanza
> Pascal Costanza <p...@p-cos.net> writes:
>
>>The boundary between language and libraries is so blurred that you can
>>very easily add features that pretend to be new language
>>constructs. This effectively means that you can go quite a long way by
>>just implementing libraries before the need for "standardization" ever
>>arises.
>
> But standardisation does offer certain unique advantages, chief among
> them the guarantee that a conforming implementation will offer certain
> features. E.g. if the standard included split-string, we wouldn't all
> need to grab the code and add it to our utility libraries (and possibly
> extend it in incompatible ways...). If the standard more fully defined
> what the components of a pathname indicate, we wouldn't need to each
> play about with portable pathname libraries. If the standard defined
> once and for all a canonical MOP, we could just rely on the thing.
Sure, but this requires that some dedicated groups of people work out
all the details of the respective specifications. That's the hard part.
Edi Weitz
> Sure, but this requires that some dedicated groups of people work
> out all the details of the respective specifications. That's the
> hard part.
And then all existing implementations should better implement these
new specifications. That's the expensive part.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq "spam...@agharta.de" 5) "edi")
Pascal Costanza
> "R. Mattes" <r...@mh-freiburg.de> writes:
>
>>Funny, the python libs i had to work with were of rather mediocre
>>quality. There is _lots_ of python code, agreed, but quantity isn't
>>quality (and the same is true for CL libs as well ..).
>
> The python standard library is, if not perfect, pretty damned useful.
> E.g. pickle: the ability to take _any_ data structure, write it to a
> file, and read it in later. That's pretty sweet, and as far as I know
> there is no CL equivalent.
print and read, see http://www.pentaside.org/paper/persistence-lemmens.txt
> Or string, which offers more features than
> CL's strings. Or re, the regexp package.
Don't know what you mean wrt strings.
> Or unittest.
http://www.cliki.net/Test%20Framework
> And _all_ of
> these are _guaranteed_ to exist on every single Python installation.
> Which is pretty nice.
...but not across different versions of Python. And not across different
dialects of Python. Which is pretty bad.
I think portability across implementations and across time is much
better in Common Lisp.
Kenny Tilton
Pascal Costanza wrote:
> Kenny Tilton wrote:
>
>>
>> Jamie Border wrote:
>>
>>> I've been reading about Arc[1], Paul Graham's Lisp-plus-to-be, and
>>> I've been thinking[2]..
>>>
>>> Couldn't we have a CL++
>>
>>
>> Congratulations, you have earned a membership in the Complete Fucking
>> Morons of Programming Club. These are people who look at the best
>> programming language available and worry about why it is not better. A
>> necessary requirement is not being smart enough to understand how much
>> better the better language is, such that in their wildest dreams they
>> could not be held back by said language.
>
>
> Don't be so negative. It seems to me that it happens quite often that
> newbies understand that Lisp is such a malleable language that they
> start to imagine in what ways it could be "much better".
No, that is the dilettante subset that does not have any actual ideas to
code up. Anyone with an app to write discovers Lisp and Just Codes. No
time for comp.lang.lisp, and anyway too astonished by the power of Lisp
even to think of anything to change. They feel downright humbled by the
language, and the last thing they would do is enter this august forum
and start lecturing us on our problems.
Edi Weitz
> No, that is the dilettante subset that does not have any actual
> ideas to code up. Anyone with an app to write discovers Lisp and
> Just Codes. No time for comp.lang.lisp
So, why are you still here? And what about me, BTW?
O-MY-GLIFE
> That way we could have portable networking code etc. with no loss of CL
> wonderfuness.
^^^^^^^^^^^^
Nyce typo. Congrats.
Jamie Border
"Kenny Tilton" <kti...@nyc.rr.com> wrote in message
news:XdQBe.1094$Na6.4...@twister.nyc.rr.com...
>
>
> Jamie Border wrote:
>
>> "Kenny Tilton" <kti...@nyc.rr.com> wrote:
>>
>> Me>> Couldn't we have a CL++
>>
>>>Congratulations, you have earned a membership in the Complete Fucking
>>>Morons of Programming Club. These are people who look at the best
>>
>>
>> a) Tell Paul Graham he's a Fucking Moron.
>
> Try to keep up, will you? Graham was drummed out of the CFMPC when he
> stopped active development of Arc.
>
> Besides, Graham, unlike certain geniuses who pop up around here from time
> to time fully mastered Lisp and wrote a lot of Actual Code before
> attempting improvements. I should have mentioned that both those things
> disqualify someone for CFMPC. Not to worry: you are still nicely eligible.
I wasn't attempting improvements. I was attempting dialogue.
>
>>
>> b) So we should have stopped at bronze tools, because they were great,
>> and anybody who said "these are the best tools, can they be better?"
>> belonged to the Complete Fucking Morons of Hand Tools Club?
>
> I'll put you down for the "Argument By Analogy Is Like Driving Backwards
> When You Get Lost" SIG.
I was trying to understand why you responded so harshly, actually.
>
>>
>>
>>>programming language available and worry about why it is not better. A
>>>necessary requirement is not being smart enough to understand how much
>>>better the better language is, such that in their wildest dreams they
>>>could not be held back by said language.
>>
>>
>> No. My employer is now trying to find a good way to use cells-gtk. I
>> was trying to convey my frustration at convincing my colleagues to use
>> CL.
>
> You are using Cells? You should have mentioned up front that you are a
> far-sighted genius. All is forgiven.
No. I'm using it because it is good. If I was a genius I would be
re-writing your code. If I was far-sighted I would have already written it.
>>
>>>The good news is that the denizens of comp.lang.lisp will leap frothing
>>>at this pavlovian bell and discuss the profundities of your post for
>>>weeks to come.
>>
Yeah, they did that, and I understand a lot more about the culture now.
>>
>> Or perhaps they will tell me that I am a moron.
>
> Actually, I see a few have told you to get off c.l.l and go do some
> programming. Word.
>
Excel.
Jamie
Jamie Border
Sophisticated sense of humour. Congrats.
Jamie
Thomas F. Burdick
> No, that is the dilettante subset that does not have any actual ideas to
> code up. Anyone with an app to write discovers Lisp and Just Codes. No
> time for comp.lang.lisp, and anyway too astonished by the power of Lisp
> even to think of anything to change. They feel downright humbled by the
> language, and the last thing they would do is enter this august forum
> and start lecturing us on our problems.
That's not a bad way of characterizing the post that started this
thread. But there are more than two reactions one can have to
discovering Lisp. Holy shit, if there can be something *this* much
better than what I've seen before ... maybe those unthinkable thoughts
I've had before aren'te unthinkable after all -- maybe I can figure
out how to leverage Lisp to make them possible -- and maybe there are
unthinkable things in here already that I won't be able to figure out
on my own. This *ahem* august forum can be pretty good at providing
help in these directions, between all the lectures and the bullshit.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
henry...@gmail.com
Robert Uhl wrote:
> "R. Mattes" <r...@mh-freiburg.de> writes:
> >
> > Funny, the python libs i had to work with were of rather mediocre
> > quality. There is _lots_ of python code, agreed, but quantity isn't
> > quality (and the same is true for CL libs as well ..).
>
> The python standard library is, if not perfect, pretty damned useful.
> E.g. pickle: the ability to take _any_ data structure, write it to a
> file, and read it in later.
You might want to look at the asdf-installable
cl-store.http://common-lisp.net/project/cl-store/
Cheers.
hy
William D Clinger
> > If speculating about the possibility of Lisps superior to CL is enough
> > to get you into the Complete Fucking Morons of Programming Club, is it
> > Henry Baker or John McCarthy that teaches you the secret handshake?
>
> That gets you into the Bullshit Debating Tactics Club.
Where Kenny is a certified instructor for the secret handshake?
Will
Tron3k
Lisp short-sighted and pathetic.
Paul F. Dietz
> I find the attitude that it is wrong to suggest improvements for Common
> Lisp short-sighted and pathetic.
Improvements are just fine. But they actually have to *be*
improvements, and be worth the cost of adding them.
Paul
Tayssir John Gabbour
> I find the attitude that it is wrong to suggest improvements for Common
> Lisp short-sighted and pathetic.
I've listened to some political people speak about their "leftist"
experience, and they have an interesting problem of detachment from
others.
What happens is, most people don't like to hear the problems of the
status quo if they don't really feel they can change it. Sane people
make the best out of their situations; they adjust to what the market
provides. You might not care for a prison commisary now, but after a
while in prison you'd adjust to it.
Same with bad TV: we adjust to it, and even dislike good TV shows if
that means 6 nights out of the TV week are ruined because we can only
enjoy 1. In fact, people don't even have to "like" bad TV if it at
least gives them something to talk about with others.
This even applies to Common Lispers -- when we criticize other
languages, you'll literally hear people saying, "Well, having that much
power is terrible!" The pushback is frequently emotional, and in
practice the only way I know to take conversations out of that zone is
by being honest and rational about Lisp's faults. And offer them a
hopefully enjoyable learning opportunity like Peter Seibel's book, so
they don't have to crawl through boring BS which overhypes lists and
recursion.
(Unless that's actually interesting to them, in which case there's the
SICP vids.)
As I see from your comments, you perhaps have a greater feeling of
power to create your own dialect than many Common Lispers. This may
explain the curious sense you're getting that we're hypocritical. And
we are. But there are worse hypocracies.
Anyway, that explanation sounds persuasive to me, though I don't know
whether it's entirely true.
http://www.zmag.org/audio/albnll.ram
Tayssir
Pascal Costanza
> I find the attitude that it is wrong to suggest improvements for Common
> Lisp short-sighted and pathetic.
Check out the HyperSpec. There are a number of issues listed that were
discussed during the standardization of Common Lisp - see
http://www.lispworks.com/documentation/HyperSpec/Front/X3J13Iss.htm
Apparently, each issue had to follow a certain structure, containing
details about things like: problem description, rationale, current
practice, cost to implementors, cost to users, cost of non-adoption.
A _good_ suggestion for improvement should cover such aspects in order
to have some convincing power. Stuff like "switch from Lisp-n to Lisp-1"
would have to objectively mention all the drawbacks of such a change.
See for example the excellent discussion at
http://www.nhplace.com/kent/Papers/Technical-Issues.html
Another example is the switch from converting identifiers to all upper
case by default (as in ANSI Common Lisp) vs. keeping case (as in Allegro
Common Lisp "modern" mode and as proposed for R6RS Scheme). There was
recently a discussion at comp.lang.scheme about this issue, and in a
chat at ILC'05, Steve Haflich explained Franz's reasons for the modern
mode. Essentially, keeping case avoids all kinds of problems with
characters that don't have unambiguous mappings between lower case and
upper case, and since the whole world has decided to adopt Unicode, a
switch to case sensitivity would solve a whole bunch of problems at
once. I think that could be an actual improvement, but the more
important point here is that the reasons are stronger than just "I would
prefer it like that".
So essentially, if your arguments for or against a change are not
convincing enough, it all just boils down to a matter of taste. And
then, under those circumstances, it is really important to realize that
there is no need at all to force others to agree to your personal
aesthetical preferences. Contrary to other language, Lisp is flexible
enough such that you can just build your own world in which things are
just exactly like you want them to be. So why bother trying to inflict
costs upon others that they don't want to bear?
For example, some time ago I have implemented a with-funcalls macro that
allows you to embed a Lisp-1 programming style within Common Lisp. See
http://groups-beta.google.com/group/comp.lang.lisp/msg/8fce6ead716e6501
So if you prefer that programming style, there's noone stopping you from
just using it.
It seems to me that people have just been trained too much in not being
able to change the language and therefore expecting features to be added
by vendors (because they're the only ones that can actually do it).
These restrictions simply don't exist in Lisp. So go ahead, just do what
you want! ;)
Tron3k
I think you made a really excellent analysis of this phenomenon! It
helped me to understand what you guys are feeling.
I guess I can understand how annoying it is for some upstart like me
(or Paul Graham, for that matter) to come in here and start telling you
guys you should do things my way.
It's just that I'm working on my own Lisp which is like Arc except it
has a special, awesome improvement I made. ;-) It's top secret so far.
But programming in it is soooo wicked! So I can't help but keep trying
to come up with new improvements on Common Lisp.
Tron3k
Tron3k
> Tron3k wrote:
> > I find the attitude that it is wrong to suggest improvements for Common
> > Lisp short-sighted and pathetic.
>
> Check out the HyperSpec. There are a number of issues listed that were
> discussed during the standardization of Common Lisp - see
> http://www.lispworks.com/documentation/HyperSpec/Front/X3J13Iss.htm
>
> Apparently, each issue had to follow a certain structure, containing
> details about things like: problem description, rationale, current
> practice, cost to implementors, cost to users, cost of non-adoption.
>
> A _good_ suggestion for improvement should cover such aspects in order
> to have some convincing power. Stuff like "switch from Lisp-n to Lisp-1"
> would have to objectively mention all the drawbacks of such a change.
> See for example the excellent discussion at
> http://www.nhplace.com/kent/Papers/Technical-Issues.html
Ah, I see your point here. In other words, my ideas are pretty
well-known and obvious, but they don't consider the practical problems.
I'll grant you that. Thankfully I am free of worrying about backwards
compatibility since I'm making my own Lisp. :-)
> Another example is the switch from converting identifiers to all upper
> case by default (as in ANSI Common Lisp) vs. keeping case (as in Allegro
> Common Lisp "modern" mode and as proposed for R6RS Scheme). There was
> recently a discussion at comp.lang.scheme about this issue, and in a
> chat at ILC'05, Steve Haflich explained Franz's reasons for the modern
> mode. Essentially, keeping case avoids all kinds of problems with
> characters that don't have unambiguous mappings between lower case and
> upper case, and since the whole world has decided to adopt Unicode, a
> switch to case sensitivity would solve a whole bunch of problems at
> once. I think that could be an actual improvement, but the more
> important point here is that the reasons are stronger than just "I would
> prefer it like that".
I decided a while ago my Lisp will be case-sensitive. It will be
created with Win32 game development in mind, and I don't want people
calling Win32 or OpenGL functions in all small case, that's just hard
to read.
> So essentially, if your arguments for or against a change are not
> convincing enough, it all just boils down to a matter of taste. And
> then, under those circumstances, it is really important to realize that
> there is no need at all to force others to agree to your personal
> aesthetical preferences. Contrary to other language, Lisp is flexible
> enough such that you can just build your own world in which things are
> just exactly like you want them to be. So why bother trying to inflict
> costs upon others that they don't want to bear?
Let's say I've given up on trying to change the Common Lisp standard,
heh. So I won't be forcing anything on anybody.
I'm wondering about 'taste' ... are some 'tastes' universal? For
example, I think everyone could agree on which one is nicer-looking:
(defun dec-list (lst)
(mapcar #'1- lst))
(def (dec-list lst)
(map 1- lst))
But then again, not being able to use 'list' as a variable name could
certainly leave a bad 'taste' in some people's mouths. (I guess I'm
different in that I purposely try not to give my variable names the
same names as functions even in Common Lisp, because it gets a bit
confusing.)
> For example, some time ago I have implemented a with-funcalls macro that
> allows you to embed a Lisp-1 programming style within Common Lisp. See
> http://groups-beta.google.com/group/comp.lang.lisp/msg/8fce6ead716e6501
>
> So if you prefer that programming style, there's noone stopping you from
> just using it.
That's very cool! I think it's a given that in general, just about
anything in possible in Common Lisp. In the absolute limit, you could
write your own reader and your own code-walker to transform any
language into Common Lisp.
> It seems to me that people have just been trained too much in not being
> able to change the language and therefore expecting features to be added
> by vendors (because they're the only ones that can actually do it).
> These restrictions simply don't exist in Lisp. So go ahead, just do what
> you want! ;)
Heh, one of the features in my new language is complicated to implement
in Common Lisp. I might need to write a whole new reader in order to do
it. Yes, I can do whatever I want, but it's kind of like saying you can
do whatever you want in C if you write a compiler that takes your new
language to C. ;)
Peter Seibel
> I'm wondering about 'taste' ... are some 'tastes' universal? For
> example, I think everyone could agree on which one is nicer-looking:
>
> (defun dec-list (lst)
> (mapcar #'1- lst))
>
> (def (dec-list lst)
> (map 1- lst))
I think everyone will agree that anytime you think everyone could
agree on *anything* you are wrong. (BTW, I prefer the Common Lisp
style version though I'd rename "lst" to "list". But there's no
accounting for taste.)
-Peter
--
Peter Seibel * pe...@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Peter Seibel
> A _good_ suggestion for improvement should cover such aspects in
> order to have some convincing power. Stuff like "switch from Lisp-n
> to Lisp-1" would have to objectively mention all the drawbacks of
> such a change. See for example the excellent discussion at
> http://www.nhplace.com/kent/Papers/Technical-Issues.html
It's been a while since I read that paper but one issue that I don't
recall it discussing which I thought of while pondering Henry Baker's
ILC talk is the issue of renaming. I was imagining a Lisp system
(probably one that used an Interlisp-style structure editor) that
supports renaming things as a simple operation. That is, if I've
defined a function FOO and have used it a bunch of places then I shoud
be able to tell Lisp, (rename 'function 'foo 'bar) (or maybe (rename
#'foo 'bar)). Then I started thinking about macros. The immediate
problem is when you have an expression like (my-macro foo) you don't
know how the symbol FOO will be used (if at all) in the expansion of
MY-MACRO. But that's presumably possible--just macro expand the thing
and then see if FOO is used as the name of a function in the
expansion. (Okay, so there's some hair even then, but probably
solvable.) But then imagine this macro, in a Lisp-2:
(defmacro self-call (name) `(,name ,name))
Now if my program contains the expression (self-call foo) what the
heck is (rename 'function 'foo 'bar) supposed to do. After resisting
it for a while since I'm generally a Lisp-2 fan, I realized that in a
Lisp-1 this problem goes away. Which is not necessarily enough to sway
my to the Lisp-1 camp--maybe were I to implement such a mythical Lisp
system, I'd just signal an error at RENAME time that gives you an
option of replacing the SELF-CALL expression with it's expansion (with
the function calls then appropriately renamed) or something. Anyway,
just something I was thinking about, apropos nothing, really.
Pascal Costanza
>>A _good_ suggestion for improvement should cover such aspects in order
>>to have some convincing power. Stuff like "switch from Lisp-n to Lisp-1"
>>would have to objectively mention all the drawbacks of such a change.
>>See for example the excellent discussion at
>>http://www.nhplace.com/kent/Papers/Technical-Issues.html
>
> Ah, I see your point here. In other words, my ideas are pretty
> well-known and obvious, but they don't consider the practical problems.
> I'll grant you that. Thankfully I am free of worrying about backwards
> compatibility since I'm making my own Lisp. :-)
Just keep in mind that this could create some adoption problems (which
may or may not matter to you).
> Let's say I've given up on trying to change the Common Lisp standard,
> heh. So I won't be forcing anything on anybody.
ok ;)
> I'm wondering about 'taste' ... are some 'tastes' universal?
As someone who listens to music most other people in my social context
find horrible (industrial, experimental, electronic stuff), and enjoys
other forms of art that are equally off, I strongly disbelieve in the
notion of universal taste apart from some very small common denominator.
Just to make the background clear.
> For
> example, I think everyone could agree on which one is nicer-looking:
>
> (defun dec-list (lst)
> (mapcar #'1- lst))
>
> (def (dec-list lst)
> (map 1- lst))
This seems to be a very hypothetical question because the example
doesn't seem to do anything useful that I would want to encapsulate in a
function in the first place. (Yes, I think form and function are related.)
I don't think def instead of defun (or define-function) is a good idea.
There are other kinds of things that you may want to define, and it's
good to be able to tell from the car what you're actually doing. For
example, the first versions of Tiny CLOS (Gregor Kiczales's adoption of
CLOS for Scheme) relied on everything being first class, so that you
could write (define person (make-class ...)) instead of (defclass person
...). However, most derivations of Tiny CLOS have adopted more
distinctive macros, like defclass, defgeneric and defmethod. So
apparently, there is something to be gained from being less generic.
In other words, aesthetical preferences can adopt to practical
considerations. That's why I don't think that #' is in any way ugly.
> But then again, not being able to use 'list' as a variable name could
> certainly leave a bad 'taste' in some people's mouths. (I guess I'm
> different in that I purposely try not to give my variable names the
> same names as functions even in Common Lisp, because it gets a bit
> confusing.)
If it were only about functions and variables, I couldn't care less. The
good thing about Lisp-n is that it encourages you to create new
namespaces for your own concepts (which is quite easy to do by using
hashtables to map from names to concepts). Schemers seem to have a
tendency to create naming conventions instead, like using angle brackets
for class names (i.e., they say (define <person> ...) to indicate that
they want to create a class). I think that overall, working with
multiple namespaces is safer because the danger of accidental name
clashes is considerably reduced (not only in macros, but in general).
For example, I also think that using the same namespace for lexical and
for special variables in Common Lisp is suboptimal exactly for these
reasons. ISLISP has a better design in this regard in that it
effectively provides a separate namespace for special (dynamic)
variables. Again, because two different concepts have to share the same
namespace, this has lead to a naming convention instead (i.e., the use
of asterisks to signal that a name is supposed to refer to a special
binding). This is a workable solution, but not as good as it could be.
>>It seems to me that people have just been trained too much in not being
>>able to change the language and therefore expecting features to be added
>>by vendors (because they're the only ones that can actually do it).
>>These restrictions simply don't exist in Lisp. So go ahead, just do what
>>you want! ;)
>
> Heh, one of the features in my new language is complicated to implement
> in Common Lisp. I might need to write a whole new reader in order to do
> it. Yes, I can do whatever I want, but it's kind of like saying you can
> do whatever you want in C if you write a compiler that takes your new
> language to C. ;)
Of course, there are limits. Still, even writing a compiler for your new
language should be easier to do in Common Lisp than it would be in C.
So I am curious. What's so spectacular about your new Lisp?
Pascal Costanza
> Pascal Costanza <p...@p-cos.net> writes:
>
>>A _good_ suggestion for improvement should cover such aspects in
>>order to have some convincing power. Stuff like "switch from Lisp-n
>>to Lisp-1" would have to objectively mention all the drawbacks of
>>such a change. See for example the excellent discussion at
>>http://www.nhplace.com/kent/Papers/Technical-Issues.html
>
> It's been a while since I read that paper but one issue that I don't
> recall it discussing which I thought of while pondering Henry Baker's
> ILC talk is the issue of renaming. I was imagining a Lisp system
> (probably one that used an Interlisp-style structure editor) that
> supports renaming things as a simple operation. That is, if I've
> defined a function FOO and have used it a bunch of places then I shoud
> be able to tell Lisp, (rename 'function 'foo 'bar) (or maybe (rename
> #'foo 'bar)). Then I started thinking about macros.
I was going to reply that you don't need macros to create examples that
screw you in this regard. Indeed, (apply fun args) already has the
problem because fun could be bound to a symbol whose symbol-function
would be called. So you would need to replace that form by something like
(apply (case fun
(foo 'bar)
(t fun)) args)
so that things wouldn't break at runtime.
However, then I realized that a notion of symbol-function doesn't exist
in Scheme. Even eval is restricted in Scheme such that this problem
cannot be recreated.
Pascal Bourguignon
> Let's say I've given up on trying to change the Common Lisp standard,
> heh. So I won't be forcing anything on anybody.
>
> I'm wondering about 'taste' ... are some 'tastes' universal? For
> example, I think everyone could agree on which one is nicer-looking:
>
> (defun dec-list (lst)
> (mapcar #'1- lst))
>
> (def (dec-list lst)
> (map 1- lst))
I don't know about taste, but why would you want to change Common Lisp
when you can perfectly write:
(defpackage "MY-PGM" (:use "MY-SHORTNAME-LISP"))
(in-package "MY-PGM)
(def (dec-list lst)
(map 1- lst))
instead of:
(DEFPACKAGE "my-pgm" (:USE "common-lisp"))
(IN-PACKAGE "my-pgm)
(defun dec-list (lst)
(mapcar #'1- lst))
and it's not even hard to implement.
> Heh, one of the features in my new language is complicated to implement
> in Common Lisp. I might need to write a whole new reader in order to do
> it. Yes, I can do whatever I want, but it's kind of like saying you can
> do whatever you want in C if you write a compiler that takes your new
> language to C. ;)
Why do you think there's a Greenspun's Tenth Law?
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
M Jared Finder
> Pascal Costanza wrote:
>
> Let's say I've given up on trying to change the Common Lisp standard,
> heh. So I won't be forcing anything on anybody.
>
> I'm wondering about 'taste' ... are some 'tastes' universal? For
> example, I think everyone could agree on which one is nicer-looking:
>
> (defun dec-list (lst)
> (mapcar #'1- lst))
>
> (def (dec-list lst)
> (map 1- lst))
>
> But then again, not being able to use 'list' as a variable name could
> certainly leave a bad 'taste' in some people's mouths. (I guess I'm
> different in that I purposely try not to give my variable names the
> same names as functions even in Common Lisp, because it gets a bit
> confusing.)
I prefer the Common Lisp form to the other form because it also applies
to defining non-value, non-function objects such as structures, classes,
conditions, loop clauses, generic functions. It also allows you to
support different types of variable definitions like with defvar vs
defparameter vs defconstant.
-- MJF
Tron3k
> I don't know about taste, but why would you want to change Common Lisp
> when you can perfectly write:
>
> (defpackage "MY-PGM" (:use "MY-SHORTNAME-LISP"))
> (in-package "MY-PGM)
> (def (dec-list lst)
> (map 1- lst))
>
> instead of:
>
> (DEFPACKAGE "my-pgm" (:USE "common-lisp"))
> (IN-PACKAGE "my-pgm)
> (defun dec-list (lst)
> (mapcar #'1- lst))
>
> and it's not even hard to implement.
>
Ok, so I'll try to implement my new Lisp on top of Common Lisp if this
is possible. I have one problem though: in my Lisp, if x is (a b c d)
and you eval (x 2), you get c. How can I do this on Common Lisp short
of writing a full-fledged code-walker? If I end up having to write a
code-walker I'd prefer to just make a Lisp from ground-up anyway.
Tron3k
Hmm, I don't understand why the DEF form couldn't just apply to
defining everything. This is a Lisp-1 remember, not a Lisp-n. If you
made a class called 'bagel', you could just type bagel at the command
line and get something like:
#<STANDARD CLASS bagel>
Ok, defvar vs. defparameter vs. defconstant. I think defconstant would
be kind of an "optimization" sort of thing; you make some sort of
DECLAIM that this variable will never change and the compiler will
inline it. Interestingly, you could apply this to optimizing functions
as well: when you're shipping your program, you tell the compiler that
all function definitions are constant, and nobody's going to change
them. Then it can compile it as a direct jump or inline it.
defvar vs defparameter? I guess my DEF is really equivalent to
assignment. If you want something like DEFVAR that doesn't modify it if
it is already bound, you could implement it fairly easily.
Pascal Costanza
> If you want something like DEFVAR that doesn't modify it if
> it is already bound, you could implement it fairly easily.
See? Now you're reacting in the same way. ;)
There are always tradeoffs...
Pascal Bourguignon
Nothing from the other world:
(defpackage "MY-STRANGE-LISP"
(:use "COMMON-LISP")
(:shadow "EVAL")
(:export "EVAL" #|...|#))
(in-package "MY-STRANGE-LISP"
(defun eval (&rest args)
#|...|#)
Indeed, you need to implement your own eval, since it is not
COMMON-LISP:EVAL, but since you're posting on comp.lang.lisp, we'll
assume you want to implement it in Common Lisp.
--
__Pascal_Bourguignon__ _ Software patents are endangering
() ASCII ribbon against html email (o_ the computer industry all around
/\ 1962:DO20I=1.100 //\ the world http://lpf.ai.mit.edu/
2001:my($f)=`fortune`; V_/ http://petition.eurolinux.org/
Pascal Costanza
> Ok, so I'll try to implement my new Lisp on top of Common Lisp if this
> is possible. I have one problem though: in my Lisp, if x is (a b c d)
> and you eval (x 2), you get c. How can I do this on Common Lisp short
> of writing a full-fledged code-walker? If I end up having to write a
> code-walker I'd prefer to just make a Lisp from ground-up anyway.
(defmacro glet1 ((name value) &body body)
(let ((index (gensym "INDEX")))
`(let ((,name ,value))
(flet ((,name (,index) (elt ,name ,index)))
,@body))))
(defmacro glet ((&rest bindings) &body body)
(reduce (lambda (binding sofar)
`(glet1 ,binding ,sofar))
bindings
:from-end t
:initial-value `(progn ,@body)))
? (glet ((x '(a b c d)))
(x 2))
C
Optimizations and better names are left as an exercise to the reader. ;)
Don Geddis
> I find the attitude that it is wrong to suggest improvements for Common
> Lisp short-sighted and pathetic.
You misunderstand the reaction you've seen, as well as the quality of your
own suggestions.
Plenty of CL improvements have been discussed here with great interest.
SPLIT-SEQUENCE was a recent one. Grey streams. Franz's first-class
environments. Regular expressions. FFI.
All the people in those discussions knew the historical context, knew why
certain issues had been decided before, and actually worked to design real
improvement.
You, on the other hand, appear to know very little of the huge amount of
language design work that has already gone into Common Lisp, and you express
your naive preferences as though they are the Word of God on programming
language design. When in reality, the bulk of your ideas had already been
considered by smarter people than you long ago, and rejected for very good
reasons that you're not even aware of.
Try asking more questions, and asserting fewer statements about what is
"broken" in CL and needs to be "fixed". Perhaps you think EQUALP ought to
be generic and extensible, so you could customize it for your own data
structures. Instead of staying "EQUALP is CL is broken, and a better CL++
would make it generic and extensible", try asking "why isn't EQUALP extensible
in CL? What were the designers thinking in making its definition fixed?"
You may be surprised about what you learn about programming language design.
Common Lisp is very, very, very well designed. The few things that you might
get widespread agreement on being theoretically improvable in some new Lisp
dialect tend to be conscious choices made for backwards compatibility, an
argument which holds even stronger today.
There are a few topics out there which, in hindsight, the designers might have
done slightly differently now that they have 20 years of experience to examine.
But those topics are few and far between, and you haven't come close to finding
any of them. Lisp-1 vs. Lisp-n is not one.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ d...@geddis.org
They all laughed at Albert Einstein. They all laughed at Columbus.
Unfortunately, they also all laughed at Bozo the Clown.
-- William H. Jefferys
M Jared Finder
> M Jared Finder wrote:
>
>>Tron3k wrote:
>>
>>>Pascal Costanza wrote:
>>>
>>>Let's say I've given up on trying to change the Common Lisp standard,
>>>heh. So I won't be forcing anything on anybody.
>>>
>>>I'm wondering about 'taste' ... are some 'tastes' universal? For
>>>example, I think everyone could agree on which one is nicer-looking:
>>>
>>>(defun dec-list (lst)
>>> (mapcar #'1- lst))
>>>
>>>(def (dec-list lst)
>>> (map 1- lst))
>>>
>>>But then again, not being able to use 'list' as a variable name could
>>>certainly leave a bad 'taste' in some people's mouths. (I guess I'm
>>>different in that I purposely try not to give my variable names the
>>>same names as functions even in Common Lisp, because it gets a bit
>>>confusing.)
>>
>>I prefer the Common Lisp form to the other form because it also applies
>>to defining non-value, non-function objects such as structures, classes,
>>conditions, loop clauses, generic functions. It also allows you to
>>support different types of variable definitions like with defvar vs
>>defparameter vs defconstant.
>
> defining everything. This is a Lisp-1 remember, not a Lisp-n. If you
> made a class called 'bagel', you could just type bagel at the command
> line and get something like:
> #<STANDARD CLASS bagel>
You kinda missed my point. In CL, you define a class by evaluating the
defclass form (defclass bagel (bread hole-mixin) ...))
What form would you evaluate to define a class in your lisp? I assume
it will use def, because to create a special shortcut only for functions
seems pretty useless. But how are you exposing this functionality to
the programmer, so they can add their own types of def clauses? I
expect that eventually you'll either have a whole bunch of weird syntax
for defining different variables vs defining classes vs defining
functions, or you'll end up with something like:
(def class bagel (bread hole-mixin) ...)
(def package my-package ...)
(def loop-clause (FOR var IN-REVERSE seq) ...)
and you'd have some define-def-form take the place of defmacro, but only
for def forms.
Using a special syntax will end up ugly, and making such a specialized
defmacro seems silly.
> Ok, defvar vs. defparameter vs. defconstant. I think defconstant would
> be kind of an "optimization" sort of thing; you make some sort of
> DECLAIM that this variable will never change and the compiler will
> inline it. Interestingly, you could apply this to optimizing functions
> as well: when you're shipping your program, you tell the compiler that
> all function definitions are constant, and nobody's going to change
> them. Then it can compile it as a direct jump or inline it.
I like this idea. Telling the compiler that you can inline a function
does seem very similar to telling the compiler that a value will not
change. They both can have a significant speed increase, with the
disadvantage that if you do end up wanting to change the value/function,
you will most likely have to recompile the world.
-- MJF
Tron3k
> Tron3k wrote:
>
> > If you want something like DEFVAR that doesn't modify it if
> > it is already bound, you could implement it fairly easily.
>
> See? Now you're reacting in the same way. ;)
>
> There are always tradeoffs...
Hehehe. :-)
Well I'll probably provide this defvar-like thing standard anyway. I
just need a good name ...
Why not make DEF take keyword parameters?
(def x 3
$new nil) ; signifying that you don't want to put in a 'new'
; value if there is already one there
(The dollar sign is the keyword marker ... I appropriated the colon for
my own nefarious purposes.)
I love language design, it's really so fun! :-)
Tron3k
> You may be surprised about what you learn about programming language design.
> Common Lisp is very, very, very well designed.
I wonder about this. By unabashedly stealing from Paul Graham and
adding some of my new ideas, I've been able to create a better (even if
only slightly) variant of Lisp in the space of 2 days.
Note also: Common Lisp LOOP and FORMAT each have much better
replacements floating around the web.
If I personally consider my Lisp better than Common Lisp, then what do
I care what others say about it? I still win.
Tron3k
Tron3k
Hmm, I don't think I'm going to do it that way. (I like your bagel
'hole-mixin'. Hehe.)
I might do it like this:
(def bagel
(class (bread hole-mixin)
...))
With regards to defining a package, I'll just auto-create a package
when it is first referred to.
Things like defining a loop clause or whatever can certainly have their
own def-loop-clause forms or whatever? What's wrong with that? Def is
something of a special case of defining by assignment.
> > Ok, defvar vs. defparameter vs. defconstant. I think defconstant would
> > be kind of an "optimization" sort of thing; you make some sort of
> > DECLAIM that this variable will never change and the compiler will
> > inline it. Interestingly, you could apply this to optimizing functions
> > as well: when you're shipping your program, you tell the compiler that
> > all function definitions are constant, and nobody's going to change
> > them. Then it can compile it as a direct jump or inline it.
>
> I like this idea.
Thanks!
> Telling the compiler that you can inline a function
> does seem very similar to telling the compiler that a value will not
> change. They both can have a significant speed increase, with the
> disadvantage that if you do end up wanting to change the value/function,
> you will most likely have to recompile the world.
Right, or maybe I'll just assume the user means it when he says he
won't modify something. ;)
But yes the compiler might auto-inline something. Then we have to
recompile the world when the user changes it.
Tron3k
Clever. Unfortunately it doesn't work. For example:
('(1 2 3) 2) must evaluate to 3.
Tron3k
As it turns out I need to write my own READer too, so the reading of
forms will be done by my program, the evaluation of forms will be done
by my program, the printing also will be done by my program. But now
I'm not building my language on *top* of Common Lisp anymore, I'm using
Common Lisp as my preferential language to program my interpreter in -
but I could use C++ too (but I won't, hehe).
So yes, that was my original plan from the start.
M Jared Finder
I'm talking about extendibility, because that is one of *the* strengths
I see in CL. Here you are creating a special case shortcut in def that
only works for functions and is not exposed to the programmer in any
way. It doesn't make code significantly faster to not expose this
functionality, so I don't see what the advantage is.
Much of the code I write is defining functions and variables, but
another similarly sized chunk of that code is defining non-function,
non-variable objects, like classes, methods, or loop clauses.
-- MJF
Tron3k
I'm a bit confused as to what "special-case shortcut" you're talking
about.
Is it that I'm allowing the user to specify a function as:
(def (plus-one x) (1+ x))
instead of:
(def plus-one
[x|(1+ x)])
???
[Side note: You could of course do (def plus-one 1+). Hehe.]
I don't see what the problem with that is; it's just like Scheme.
Kenny Tilton
Tron3k wrote:
> I decided a while ago my Lisp will be case-sensitive. It will be
> created with Win32 game development in mind, and I don't want people
> calling Win32 or OpenGL functions in all small case,..
OK, you get one chance to explain the, um, ignorance of that remark. I
would give you zero, but you are such a genius that you have in two days
created a language better than Lisp. (URL, plz.)
Now for the bad news: the only folks sucked into your thread are the
same ones who fall for every troll, so we have you down for a C- at this
point. Keep them in the air for another week and we'll make it a B.
--
Kenny
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"I've wrestled with reality for 35 years, Doctor, and I'm happy to state
I finally won out over it."
Elwood P. Dowd, "Harvey", 1950
M Jared Finder
> M Jared Finder wrote:
>
>>I'm talking about extendibility, because that is one of *the* strengths
>>I see in CL. Here you are creating a special case shortcut in def that
>>only works for functions and is not exposed to the programmer in any
>>way. It doesn't make code significantly faster to not expose this
>>functionality, so I don't see what the advantage is.
>>
>>Much of the code I write is defining functions and variables, but
>>another similarly sized chunk of that code is defining non-function,
>>non-variable objects, like classes, methods, or loop clauses.
>
> about.
> Is it that I'm allowing the user to specify a function as:
> (def (plus-one x) (1+ x))
> instead of:
> (def plus-one
> [x|(1+ x)])
> ???
> [Side note: You could of course do (def plus-one 1+). Hehe.]
>
> I don't see what the problem with that is; it's just like Scheme.
In my first draft of that post, I had the comment "I didn't like it in
Scheme, and I don't like it now." The problem I have with such a short
cut is it makes the assumption that most of what I define is either
functions or variables. That is not the case -- an equally huge chunk
are the other things I keep mentioning.
-- MJF
rsher...@gmail.com
so that you can do something like:
gosh> (define-method object-apply ((s <list>) (i <integer>))
(list-ref s i))
#<generic object-apply (7)>
gosh> (let ((x '(a b c d)))
(x 2))
c
Or, of course, you could make it return the ith cdr, i concatenations
of the list, etc.
This is kind of neat, but I think that most of the time when you
evaluate (a-list 2) it's a mistake, and I'd rather have it raise an
error than fail silently. But I've never used it in practice.
William D Clinger
> Another example is the switch from converting identifiers to all upper
> case by default (as in ANSI Common Lisp) vs. keeping case (as in Allegro
> Common Lisp "modern" mode and as proposed for R6RS Scheme). There was
> recently a discussion at comp.lang.scheme about this issue, and in a
> chat at ILC'05, Steve Haflich explained Franz's reasons for the modern
> mode. Essentially, keeping case avoids all kinds of problems with
> characters that don't have unambiguous mappings between lower case and
> upper case, and since the whole world has decided to adopt Unicode, a
> switch to case sensitivity would solve a whole bunch of problems at
Just a point of information: I am told, by people who should know,
that the Unicode standard defines unambiguous mappings between lower
and upper case that cover all code points. These mappings are probably
not satisfactory to all users, and they are not as easy to implement
as implementors would like, but they are unambiguously defined.
Before someone asks about Eszett, I understand it to be a fixed point
of both mappings, making it both lower case and upper case. That may
be one of the things that a lot of people don't like.
Will
Kent M Pitman
This is the property I keep calling "sparseness" in language design.
In assembly language, it's common to make 0 be an invalid opcode because
0's happen a lot and if you execute non-code by accident, you'll hopefully
quickly find a 0 and the program will stop.
The analogy in higher level languages is to assure that you don't make
everything be "defined".
People with only a superficial familiarity with TECO used to fear that it
would just run forever if given a wrong program, since every single
character was an operator. But in practice it would quickly get arity
or other bounds errors. I'd bet the same is so of APL.
In C++, you often run with NULLs well past where you wish because they
match up typewise with pointers to objects even though NULL really has
a different "shape" than other pointer data of the same "type". When you
finally get in the debugger, finding the source of the NULL is sometimes
tricky.
In Common Lisp, changes to do things like make everything generic would be
a step in the direction of running longer after an error had happened, only
finding yourself in the debugger when the good debugging context was gone.
- - -
The other problem with this is that the BIG temptation is to want to do
just as you say--to define LIST. But CL's basic theory of design says
that you should never define things that are in public/shared packages since
other modules might be tempted to make incompatible definitions of the
same public/shared symbols. For user data, of course, it's a different
matter. But then, it's not hard to do
(defmethod ref ((v vector) (key fixnum)) (aref v key))
(defmethod ref ((h hash-table) (key t)) (gethash key h))
and then to define your own REF extensions in your own package.
CL doesn't have any way at all to define new things that can go in the
car of a list, so the issue you actually cite in your example doesn't
come up. You'd have to write (funcall a-list 2) in order for the example
to work in CL, so at that point doing (ref a-list 2) is just as easy
and requires no special language support.
My weird (and properly-named) http://www.nhplace.com/kent/Half-Baked/
addresses the issue of finding syntactic common ground between CL and
Scheme. I didn't make much success of it, but I think it's tractable.
Maybe some day some bored soul will complete it...
Arthur Lemmens
> I've been able to create a better (even if only slightly) variant
> of Lisp in the space of 2 days.
Haha.
Pascal Costanza
> Clever. Unfortunately it doesn't work. For example:
>
> ('(1 2 3) 2) must evaluate to 3.
What does this buy you? Why don't you just write 3?
At least one of the two elements should be a variable if this should
make sense. If the list a , my macro does the job. If the index is a
variable, why don't you just use nth or elt?
Pascal Costanza
> What form would you evaluate to define a class in your lisp? I assume
> it will use def, because to create a special shortcut only for functions
> seems pretty useless. But how are you exposing this functionality to
> the programmer, so they can add their own types of def clauses? I
> expect that eventually you'll either have a whole bunch of weird syntax
> for defining different variables vs defining classes vs defining
> functions, or you'll end up with something like:
>
> (def class bagel (bread hole-mixin) ...)
> (def package my-package ...)
> (def loop-clause (FOR var IN-REVERSE seq) ...)
>
> and you'd have some define-def-form take the place of defmacro, but only
> for def forms.
This reminds me of Marco Antoniotti's definer library. See
http://common-lisp.net/project/definer/
Pascal Costanza
> Just a point of information: I am told, by people who should know,
> that the Unicode standard defines unambiguous mappings between lower
> and upper case that cover all code points. These mappings are probably
> not satisfactory to all users, and they are not as easy to implement
> as implementors would like, but they are unambiguously defined.
>
> Before someone asks about Eszett, I understand it to be a fixed point
> of both mappings, making it both lower case and upper case. That may
> be one of the things that a lot of people don't like.
...which I think is an acceptable solution.
However, if that's the case, why the plan to switch to case sensitivity
for R6RS?
Pascal Costanza
> Don Geddis wrote:
>
>>You may be surprised about what you learn about programming language design.
>>Common Lisp is very, very, very well designed.
>
> I wonder about this. By unabashedly stealing from Paul Graham and
> adding some of my new ideas, I've been able to create a better (even if
> only slightly) variant of Lisp in the space of 2 days.
Did this include writing a number of considerably large programs to see
how things fit together in the larger picture, or have you put this
aside for the next two days?
Pascal
P.S.: Maybe I should listen to Kenny earlier next time... :}
Pascal Costanza
> Tron3k wrote:
>
>> Clever. Unfortunately it doesn't work. For example:
>>
>> ('(1 2 3) 2) must evaluate to 3.
>
>
> What does this buy you? Why don't you just write 3?
>
> At least one of the two elements should be a variable if this should
> make sense. If the list a , my macro does the job. If the index is a
> variable, why don't you just use nth or elt?
"If the list is a variable, my macro..."
Tron3k
> Tron3k wrote:
>
> > Clever. Unfortunately it doesn't work. For example:
> >
> > ('(1 2 3) 2) must evaluate to 3.
>
> What does this buy you? Why don't you just write 3?
>
> At least one of the two elements should be a variable if this should
> make sense. If the list a , my macro does the job. If the index is a
> variable, why don't you just use nth or elt?
>
Obviously the point is that the first element of the list must be
evaluated. What if x were ((a b c) d e) and you wanted to do ((car x)
1) which evals to b. Why shouldn't you be able to do that?
Tron3k
> Tron3k wrote:
> > Don Geddis wrote:
> >
> >>You may be surprised about what you learn about programming language design.
> >>Common Lisp is very, very, very well designed.
> >
> > I wonder about this. By unabashedly stealing from Paul Graham and
> > adding some of my new ideas, I've been able to create a better (even if
> > only slightly) variant of Lisp in the space of 2 days.
>
> Did this include writing a number of considerably large programs to see
> how things fit together in the larger picture, or have you put this
> aside for the next two days?
>
What I've done is translate quite a few of the major functions in my
MMORPG game to this new language, and I have been pleasantly surprised
by the neatness and readability of it.
Tron3k
> Tron3k wrote:
>
> > I decided a while ago my Lisp will be case-sensitive. It will be
> > created with Win32 game development in mind, and I don't want people
> > calling Win32 or OpenGL functions in all small case,..
>
> OK, you get one chance to explain the, um, ignorance of that remark. I
> would give you zero, but you are such a genius that you have in two days
> created a language better than Lisp. (URL, plz.)
>
> Now for the bad news: the only folks sucked into your thread are the
> same ones who fall for every troll, so we have you down for a C- at this
> point. Keep them in the air for another week and we'll make it a B.
I am not a troll! I'm here because I love Lisp and I *actually am*
making a new one! What's the problem with everyone here? This is not
what I expected in comp.lang.lisp. I thought Lispy people *loved*
playing around with new ideas for Lisps. Personally I find it *so* fun,
I do it all the time. On the train I carry around a clipboard to jot
down new Lisp ideas *every single day*. What is going on here?
And you tell me what looks better:
win@createprocessasuser
win@CreateProcessAsUser
And before you ask, I am not going to change it to
create-process-as-user. I have my reasons.
Pascal Costanza
What kinds of problems do you intend to solve with this approach?
Tron3k
> Tron3k wrote:
> > Pascal Costanza wrote:
> >
> >>Tron3k wrote:
> >>
> >>>Clever. Unfortunately it doesn't work. For example:
> >>>
> >>>('(1 2 3) 2) must evaluate to 3.
> >>
> >>What does this buy you? Why don't you just write 3?
> >>
> >>At least one of the two elements should be a variable if this should
> >>make sense. If the list a , my macro does the job. If the index is a
> >>variable, why don't you just use nth or elt?
> >
> > Obviously the point is that the first element of the list must be
> > evaluated. What if x were ((a b c) d e) and you wanted to do ((car x)
> > 1) which evals to b. Why shouldn't you be able to do that?
>
> What kinds of problems do you intend to solve with this approach?
- This feature interacts very nicely with the new syntax. It looks much
better than AREF or NTH (I really dislike AREF, it's friggin' huge!).
- This feature is extensible to many different situations. You can
"call" any object like it is a function, and get different features for
different objects.
- Now I don't need make-instance or constructors because you just "call
the class" to create something from it. You can call an object to get
particular slots or to call methods which are particular to the object.
(We still have multimethods though.) One thing I REALLY like about this
is that you can have a slot like X for a 3D vector object and you can
just say (my-vec-obj x) [uses a special evaluation rule more like a
macro] instead of (vec3-x my-vec-obj).
- All this makes me very happy. :-)
Matthias Buelow
>win@createprocessasuser
>win@CreateProcessAsUser
I prefer unix:unix-fork...
scnr ;-)
mkb.
Kent M Pitman
> Tron3k wrote:
>
> > Clever. Unfortunately it doesn't work. For example:
> > ('(1 2 3) 2) must evaluate to 3.
>
> What does this buy you? Why don't you just write 3?
>
> At least one of the two elements should be a variable if this should
> make sense. If the list a , my macro does the job. If the index is a
> variable, why don't you just use nth or elt?
I agree with Pascal here but would put the question a different way:
"Why don't you want to be able to choose NTH or ELT or any of various
other things explicitly?" In general, there may be multiple ways to
access or traverse a structure, including not only algorithms for
getting the answer but error-reporting behavior both in terms of
restricting domain and enforcing range. e.g.,
(NTH 3 '(A B C))
yields NIL while
(ELT '(A B C) 3)
signals an error. I find these clearer than
('(A B C) 3)
which appears to give linguistic preference to something that by rights
should be a user/program choice.
But there's a more subtle issue as well:
NOTE WELL: This discussion presumes a Lisp1, which CL is not. CL does not
evaluate VARIABLES nor EXPRESSIONS (other than lambda expressions)
in the car of a list. Discussion below is necessarily hypothetical
about a world that did do these things.
If you could do (setq my-structure '(a b c)) and then
do (my-structure 2) => C, the problems are several. Note only does it
appear to give linguistic preference to one of many operators, as
mentioned above, but it also means that you get "other things" falling
through because many things that ought to be caught as errors will fall
through. This includes not only (setq my-structure "abc") which maybe
some PEOPLE would be happy about but some APPLICATIONS would not be,
but also, more insidiously, people who do (setq id '(lambda (x) x))
and then (numberp (id 2)) => NIL
Pascal Bourguignon
> One thing I REALLY like about this
> is that you can have a slot like X for a 3D vector object and you can
> just say (my-vec-obj x) [uses a special evaluation rule more like a
> macro] instead of (vec3-x my-vec-obj).
What do we earn in writting (my-vec x) instead of (x my-vec) ?
> - All this makes me very happy. :-)
Then enjoy!
--
__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