Ok since everybody here have some time to waste i decided to start this
time
killing game :
Rules are simple:
List all thing you want added , removed, modified for the new Common
Lisp standard with brief explanations?
Especially i want to heard things from those seeking for wanna be
languages ?
Maybe they have some brilliant idea ?
Will organize voting at some of the forum who has support for it.
I would like to see:
- Predicates changed to end in '?' and destructive functions changed to
end in '!', just like Scheme
- A standardized foreign function interface
- A function for splitting sequences
- Eventually make it a Lisp-1
Yeah, OK, some of those are never gonna happen. :D
Tron3k
·············@hotmail.com wrote:
> Ok since everybody here have some time to waste i decided to start this
> time
> killing game :
> Rules are simple:
> List all thing you want added , removed, modified for the new Common
> Lisp standard with brief explanations?
> Especially i want to heard things from those seeking for wanna be
> languages ?
> Maybe they have some brilliant idea ?
> Will organize voting at some of the forum who has support for it.
From: Christophe Rhodes
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <sqy888yqvt.fsf@cam.ac.uk>
"Tron3k" <······@gmail.com> writes:
> - A function for splitting sequences
Haha.
Christophe
From: Arthur Lemmens
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <opsty0g9ltk6vmsw@news.xs4all.nl>
Christophe Rhodes <·····@cam.ac.uk> wrote:
> "Tron3k" <······@gmail.com> writes:
>
>> - A function for splitting sequences
>
> Haha.
Hehe.
Arthur Lemmens wrote:
> Christophe Rhodes <·····@cam.ac.uk> wrote:
>
> > "Tron3k" <······@gmail.com> writes:
> >
> >> - A function for splitting sequences
> >
> > Haha.
>
> Hehe.
I didn't realize this was such an outlandish request. I'm a bit
surprised by you guys. Observe:
http://pre.plt-scheme.org/docs/html/srfi/srfi-13.html#string-tokenize
http://diveintopython.org/native_data_types/joining_lists.html
http://www.comp.leeds.ac.uk/Perl/split.html
http://ca.php.net/split
http://www.cplusplus.com/ref/cstring/strtok.html
http://www.rgagnon.com/javadetails/java-0438.html
:-)
From: Peter Seibel
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <m2irzbhcug.fsf@gigamonkeys.com>
"Tron3k" <······@gmail.com> writes:
> Arthur Lemmens wrote:
>> Christophe Rhodes <·····@cam.ac.uk> wrote:
>>
>> > "Tron3k" <······@gmail.com> writes:
>> >
>> >> - A function for splitting sequences
>> >
>> > Haha.
>>
>> Hehe.
>
> I didn't realize this was such an outlandish request. I'm a bit
> surprised by you guys. Observe:
>
> http://pre.plt-scheme.org/docs/html/srfi/srfi-13.html#string-tokenize
> http://diveintopython.org/native_data_types/joining_lists.html
> http://www.comp.leeds.ac.uk/Perl/split.html
> http://ca.php.net/split
> http://www.cplusplus.com/ref/cstring/strtok.html
> http://www.rgagnon.com/javadetails/java-0438.html
And see also:
http://www.cliki.net/SPLIT-SEQUENCE
I think the laughter was of the muted but maniacal variety because of
the pain that was involved in coming up with that spec. I wasn't
involved but based on comments I saw later, a fair (as in ridiculous)
amount of time was spent just agreeing on the name of the
function. Which probably just goes to show how hard it is to
"standardize" stuff. (Or maybe I have that all wrong; as I say, my
understanding of what happened is based on reading the tea-leaves
after the fact.)
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Peter Seibel wrote:
> "Tron3k" <······@gmail.com> writes:
>
> > Arthur Lemmens wrote:
> >> Christophe Rhodes <·····@cam.ac.uk> wrote:
> >>
> >> > "Tron3k" <······@gmail.com> writes:
> >> >
> >> >> - A function for splitting sequences
> >> >
> >> > Haha.
> >>
> >> Hehe.
> >
> > I didn't realize this was such an outlandish request. I'm a bit
> > surprised by you guys. Observe:
> >
> > http://pre.plt-scheme.org/docs/html/srfi/srfi-13.html#string-tokenize
> > http://diveintopython.org/native_data_types/joining_lists.html
> > http://www.comp.leeds.ac.uk/Perl/split.html
> > http://ca.php.net/split
> > http://www.cplusplus.com/ref/cstring/strtok.html
> > http://www.rgagnon.com/javadetails/java-0438.html
>
> And see also:
>
> http://www.cliki.net/SPLIT-SEQUENCE
>
> I think the laughter was of the muted but maniacal variety because of
> the pain that was involved in coming up with that spec. I wasn't
> involved but based on comments I saw later, a fair (as in ridiculous)
> amount of time was spent just agreeing on the name of the
> function. Which probably just goes to show how hard it is to
> "standardize" stuff. (Or maybe I have that all wrong; as I say, my
> understanding of what happened is based on reading the tea-leaves
> after the fact.)
>
> -Peter
>
> --
> Peter Seibel * ·····@gigamonkeys.com
> Gigamonkeys Consulting * http://www.gigamonkeys.com/
> Practical Common Lisp * http://www.gigamonkeys.com/book/
Ohhhhhhhh! People are laughing at me because of THAT? I *know* about
that! Yes, basically my whole idea is that that function should be in
Common Lisp.
Tron3k
From: Robert Uhl
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <m33bqc2jw7.fsf@4dv.net>
Peter Seibel <·····@gigamonkeys.com> writes:
>
> And see also:
>
> http://www.cliki.net/SPLIT-SEQUENCE
>
> I think the laughter was of the muted but maniacal variety because of
> the pain that was involved in coming up with that spec. I wasn't
> involved but based on comments I saw later, a fair (as in ridiculous)
> amount of time was spent just agreeing on the name of the
> function. Which probably just goes to show how hard it is to
> "standardize" stuff.
But now that the hard work has been done, wouldn't it make sense to make
it part of the standard? After some time for testing, user acceptance,
ensuring that there aren't hidden gotchas &c. &c. &c.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Ah well, back to the cutting edge on the coal-face of e-commerce.
--Charlie Stross
Peter Seibel <·····@gigamonkeys.com> writes:
> http://www.cliki.net/SPLIT-SEQUENCE
>
> I think the laughter was of the muted but maniacal variety because of
> the pain that was involved in coming up with that spec. I wasn't
> involved but based on comments I saw later, a fair (as in ridiculous)
> amount of time was spent just agreeing on the name of the
> function. Which probably just goes to show how hard it is to
> "standardize" stuff. (Or maybe I have that all wrong; as I say, my
> understanding of what happened is based on reading the tea-leaves
> after the fact.)
It might be easier to standardize something more substatial, though.
If standardizing something is going to involve a huge amount of
effort, something trivial like sequence splitting is going to be more
tiring than it's worth. Part of the name issue, and I think a lot of
the crummy design were a result of SPLIT-SEQUENCE being far too much
effort for what it is. Also, usenet is probably the worst place to
have such a discussion (I can't think of another medium more prone to
creating heated discussions about tangential details).
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
There ain't gonna be a next CL standard because there's no
standard comittee only a chairman (Steven M. Haflich) of a board that
never met since 2002 (and even that brifly) . No projects no nothing.
God knows where we gonna see standardized sockets and rest
things that other languages take for granted.
From: Immanuel Litzroth
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <ackhagkf.fsf@immanuelinux.site>
··············@hotmail.com writes:
> There ain't gonna be a next CL standard because there's no
> standard comittee only a chairman (Steven M. Haflich) of a board that
> never met since 2002 (and even that brifly) . No projects no nothing.
> God knows where we gonna see standardized sockets and rest
> things that other languages take for granted.
God knows which languages have standardized sockets.
Immanuel
Boss : The CEO complains that newest version lack features.
Me: What features ?
Boss:The one you removed during the process of
reducing the size of the executable.
Me : I didn't removed anything .
Boss: Don't argue with me , the previous version was 20 MB
the current is a floppy size of 1.44 MB and i want it to
be at least 24 MB.I allready told the CEO that this is a
pilot version and they'll have the final in a two weeks
full of new features.
Two weeks afterwards :
Boss: 32 Mb that's excellent . You recoded it very fast .
Me : No i didn't .Ijust included Common Lisp hyperspec in it.
I don't know didn't actually done it .
This is actually about an argue with
one of my clients who "knowed for sure"
that improved version must be a larger
size than a previous . After all my
attempts to persuade him become fruitless
i just "grow up" the app with unnecessary
documentation and useless tutorials
( the staff was allready skilled of using the app).
Anyway let's mention Eric Naggum and close this thread .
Long live Common Lisp .
Any conversation between two or more Lispers will lead to a discussion
on Erik Naggum.
From: Christophe Rhodes
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <sq7jfrzmjp.fsf@cam.ac.uk>
"Tron3k" <······@gmail.com> writes:
> Arthur Lemmens wrote:
>> Christophe Rhodes <·····@cam.ac.uk> wrote:
>>
>> > "Tron3k" <······@gmail.com> writes:
>> >
>> >> - A function for splitting sequences
>> >
>> > Haha.
>>
>> Hehe.
>
> I didn't realize this was such an outlandish request.
Would you like to guess again?
Christophe
Christophe Rhodes wrote:
> "Tron3k" <······@gmail.com> writes:
>
> > Arthur Lemmens wrote:
> >> Christophe Rhodes <·····@cam.ac.uk> wrote:
> >>
> >> > "Tron3k" <······@gmail.com> writes:
> >> >
> >> >> - A function for splitting sequences
> >> >
> >> > Haha.
> >>
> >> Hehe.
> >
> > I didn't realize this was such an outlandish request.
>
> Would you like to guess again?
>
> Christophe
Not really, no.
From: Pascal Costanza
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <3jq49gFqvdv3U1@individual.net>
Tron3k wrote:
> I would like to see:
>
> - Predicates changed to end in '?' and destructive functions changed to
> end in '!', just like Scheme
Doesn't solve a problem, would just make old code unnecessarily
incompatible.
(Furthermore, what's so special about side effects that function names
should end in a bang? Here is another suggestion: Functions that consist
of less than 5 lines of code should end in $. Sounds equally useful to
me... ;)
> - A standardized foreign function interface
Foreign function interface look very different depending on what the
foreign language is. For example, an FFI for Java or C# can be much
simpler than an FFI for C or C++. So it's hard to understand what you
actually mean by "standardized" here without further qualification. (Do
you mean "a standardized FFI for C as compiled by gcc on typical Unix
systems"?!? Yuck! ;)
> - A function for splitting sequences
See Bjoern's comment.
> - Eventually make it a Lisp-1
Doesn't solve a problem. In fact, only creates a few new ones, and
additionally would just make old code unnecessarily incompatible.
If you want Scheme, you know where to get it. ;)
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Pascal Costanza wrote:
> Tron3k wrote:
> > I would like to see:
> >
> > - Predicates changed to end in '?' and destructive functions changed to
> > end in '!', just like Scheme
>
> Doesn't solve a problem, would just make old code unnecessarily
> incompatible.
I'm really talking about what I want in my ideal Lisp.
> (Furthermore, what's so special about side effects that function names
> should end in a bang? Here is another suggestion: Functions that consist
> of less than 5 lines of code should end in $. Sounds equally useful to
> me... ;)
Well, we need REVERSE and NREVERSE, granted? So we need some kind of
idiom anyway. But I don't like the prefixed 'N', because it doesn't
look nice when I write my *own* destructive functions. I end up putting
the exclamation mark, which is inconsistent with the rest of Common
Lisp and thus ugly.
> > - A standardized foreign function interface
>
> Foreign function interface look very different depending on what the
> foreign language is. For example, an FFI for Java or C# can be much
> simpler than an FFI for C or C++. So it's hard to understand what you
> actually mean by "standardized" here without further qualification. (Do
> you mean "a standardized FFI for C as compiled by gcc on typical Unix
> systems"?!? Yuck! ;)
Hmm, what's UFFI then?
> > - A function for splitting sequences
>
> See Bjoern's comment.
Yes, I can write it easily. Don't you think I know that? The point is
that it *feels* wrong to not have it there. It feels like something
that should be there.
> > - Eventually make it a Lisp-1
>
> Doesn't solve a problem. In fact, only creates a few new ones, and
> additionally would just make old code unnecessarily incompatible.
Once again, I'm talking about my ideal Lisp, really. Arc is a Lisp-1,
for example.
> If you want Scheme, you know where to get it. ;)
Look, I don't use Scheme because it *sucks*! I use Common Lisp for
everything. I just would like some things to be fixed in it to make it
perfect. I'm aware that most of them will never happen though.
>> Tron3k wrote:
>> > I would like to see:
>> > - Predicates changed to end in '?' and destructive functions changed to
>> > end in '!', just like Scheme
>> > - Eventually make it a Lisp-1
This much sure sounds like Scheme. Which already exists. So why don't you
use it?
"Tron3k" <······@gmail.com> wrote on 15 Jul 2005 13:2:
> I'm really talking about what I want in my ideal Lisp.
> Once again, I'm talking about my ideal Lisp, really. Arc is a Lisp-1,
> for example.
> Look, I don't use Scheme because it *sucks*! I use Common Lisp for
> everything. I just would like some things to be fixed in it to make it
> perfect. I'm aware that most of them will never happen though.
Bad choice of language. These two suggestions are not "broken" in Common
Lisp, so they don't need to be "fixed". They are choices, and supported by
many CL programmers.
You prefer different choices, which is fine. But there exists a community
that supports your choices (the Scheme community). Why do you object to
using Scheme instead of Common Lisp? Why are you trying to convert the CL
community, which has clearly made (and prefers) different choices than you?
Perhaps you think that CL comes with much more "built-in", but modern Schemes
generally have a lot of libraries includes. It seems that you want to
emphasize functional programming over destructive; and you want a Lisp-1;
those two choices comes close to _defining_ the difference between the Scheme
and CL communities.
CL people don't want to be Scheme. It seems that you do. I wonder why you
don't consider it more seriously.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
Zenophobia: the irrational fear of convergent sequences.
Don Geddis wrote:
> >> Tron3k wrote:
> >> > I would like to see:
> >> > - Predicates changed to end in '?' and destructive functions changed to
> >> > end in '!', just like Scheme
> >> > - Eventually make it a Lisp-1
>
> This much sure sounds like Scheme. Which already exists. So why don't you
> use it?
>
> "Tron3k" <······@gmail.com> wrote on 15 Jul 2005 13:2:
> > I'm really talking about what I want in my ideal Lisp.
> > Once again, I'm talking about my ideal Lisp, really. Arc is a Lisp-1,
> > for example.
> > Look, I don't use Scheme because it *sucks*! I use Common Lisp for
> > everything. I just would like some things to be fixed in it to make it
> > perfect. I'm aware that most of them will never happen though.
>
> Bad choice of language. These two suggestions are not "broken" in Common
> Lisp, so they don't need to be "fixed". They are choices, and supported by
> many CL programmers.
>
> You prefer different choices, which is fine. But there exists a community
> that supports your choices (the Scheme community). Why do you object to
> using Scheme instead of Common Lisp? Why are you trying to convert the CL
> community, which has clearly made (and prefers) different choices than you?
>
> Perhaps you think that CL comes with much more "built-in", but modern Schemes
> generally have a lot of libraries includes. It seems that you want to
> emphasize functional programming over destructive; and you want a Lisp-1;
> those two choices comes close to _defining_ the difference between the Scheme
> and CL communities.
>
> CL people don't want to be Scheme. It seems that you do. I wonder why you
> don't consider it more seriously.
>
> -- Don
> _______________________________________________________________________________
> Don Geddis http://don.geddis.org/ ···@geddis.org
> Zenophobia: the irrational fear of convergent sequences.
My first day of serious posting and I'm already accused of treachery?
;-)
No, seriously, here's why I'm using Common Lisp:
1. I've already mastered it.
2. I like CL macros a lot.
3. Scheme is missing features like keyword arguments.
4. Like Paul Graham says, Scheme is nice, but Common Lisp is better for
- you know - actually *writing programs*. ;-)
Now what's all this about CL people not wanting to 'be Scheme'? I want
Common Lisp to be Scheme, and Scheme to be Common Lisp. What I *really*
want is something like Arc, though. :-)
Tron3k wrote:
> Don Geddis wrote:
> > CL people don't want to be Scheme. It seems that you do. I wonder why you
> > don't consider it more seriously.
>
> My first day of serious posting and I'm already accused of treachery?
> ;-)
>
> No, seriously, here's why I'm using Common Lisp:
>
> 1. I've already mastered it.
> 2. I like CL macros a lot.
> 3. Scheme is missing features like keyword arguments.
> 4. Like Paul Graham says, Scheme is nice, but Common Lisp is better for
> - you know - actually *writing programs*. ;-)
>
> Now what's all this about CL people not wanting to 'be Scheme'? I want
> Common Lisp to be Scheme, and Scheme to be Common Lisp. What I *really*
> want is something like Arc, though. :-)
It appears that many are trained to believe that Lisp can absolutely
conform to what they want in a tool, and find it really unfortunate
when Lisp isn't quite there.
As for Arc.. it's easy to want something you've only heard good vapor
about. ;)
From: André Thieme
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <dba4dg$fse$1@ulric.tng.de>
Tron3k schrieb:
> My first day of serious posting and I'm already accused of treachery?
> ;-)
Welcome.
But really, this idea with ! does not get us anywhere.
> No, seriously, here's why I'm using Common Lisp:
>
> 1. I've already mastered it.
Wow. How did you do that?
> 2. I like CL macros a lot.
> 3. Scheme is missing features like keyword arguments.
> 4. Like Paul Graham says, Scheme is nice, but Common Lisp is better for
> - you know - actually *writing programs*. ;-)
Paul Graham also says "[...]it's not Lisp that sucks, but Common Lisp."
( http://www.paulgraham.com/popular.html )
> Now what's all this about CL people not wanting to 'be Scheme'? I want
> Common Lisp to be Scheme, and Scheme to be Common Lisp. What I *really*
> want is something like Arc, though. :-)
Noone stops you to create something like that. If Lisp would really be
so good then it should not be a problem for you as a master to do it
within a few weeks/months.
Andr�
--
André Thieme wrote:
> > No, seriously, here's why I'm using Common Lisp:
> >
> > 1. I've already mastered it.
>
> Wow. How did you do that?
What I mean is: I know it well enough to make programs that I want to
make in it.
> > 2. I like CL macros a lot.
> > 3. Scheme is missing features like keyword arguments.
> > 4. Like Paul Graham says, Scheme is nice, but Common Lisp is better for
> > - you know - actually *writing programs*. ;-)
>
> Paul Graham also says "[...]it's not Lisp that sucks, but Common Lisp."
> ( http://www.paulgraham.com/popular.html )
It's kind of like how democracy is a terrible system for running things
- but it's the best we have. ;-)
> > Now what's all this about CL people not wanting to 'be Scheme'? I want
> > Common Lisp to be Scheme, and Scheme to be Common Lisp. What I *really*
> > want is something like Arc, though. :-)
>
> Noone stops you to create something like that. If Lisp would really be
> so good then it should not be a problem for you as a master to do it
> within a few weeks/months.
I'm actually creating my own version of Arc. The short function names
really are a big win, just like Paul Graham says.
Tron3k wrote:
> I'm actually creating my own version of Arc. The short function names
> really are a big win, just like Paul Graham says.
A big win how? I like long descriptive names, it makes code much more
readable IMO.
I think its worth noting that PG allegedly uses vi[1], which may explain
why he values terse function names. In Emacs+SLIME with
slime-fuzzy-complete-symbol, the long function names are not that many
key strokes at all ( mvb[C-c M-i] => multiple-value-bind ).
I value read-ability over write-ability, and descriptive function names
are a really big win when reading, and hardly a loss (using the right
tools) when writing.
[1] I can't find a reference for this beyond a slashdot post, but i'm
sure i've read it somewhere else.
--
Drew Crampsie
drewc at tech dot coop
"Never mind the bollocks -- here's the sexp's tools."
-- Karl A. Krueger on comp.lang.lisp
drewc wrote:
> Tron3k wrote:
>
> > I'm actually creating my own version of Arc. The short function names
> > really are a big win, just like Paul Graham says.
>
> A big win how? I like long descriptive names, it makes code much more
> readable IMO.
>
> I think its worth noting that PG allegedly uses vi[1], which may explain
> why he values terse function names. In Emacs+SLIME with
> slime-fuzzy-complete-symbol, the long function names are not that many
> key strokes at all ( mvb[C-c M-i] => multiple-value-bind ).
>
> I value read-ability over write-ability, and descriptive function names
> are a really big win when reading, and hardly a loss (using the right
> tools) when writing.
>
> [1] I can't find a reference for this beyond a slashdot post, but i'm
> sure i've read it somewhere else.
>
Long descriptive names should be used for things that are not central
language features. I'm OK with that. The things in the core should be
short.
1. It is easier to type short names. (I don't like hitting Ctrl or Alt
in the middle of editing to do some completion shortcut.)
2. It makes the code more compressed horizontally.
PG says coding in Arc feels a lot better because of the short names,
and I tend to agree.
Torn3k wrote:
> Long descriptive names should be used for things that are not central
> language features. I'm OK with that. The things in the core should be
> short.
I disagree. When learning a language, or designing a library, one looks
to the standard library functions for common idioms. In common lisp,
because we are able to change the language with ease, it is especially
important to design your extensions so that they feel like part of the
language.
The perfect example of this is the WITH-* pattern. If WITH-OPEN-FILE
were named WOF (or whatever, this is just an example), the designer of
clsql might have thought it a good idea to name WITH-DEFAULT-DATABASE as
WDD, which is completely meaningless, and unreadable.
> 1. It is easier to type short names. (I don't like hitting Ctrl or Alt
> in the middle of editing to do some completion shortcut.)
On my desktop machine i have slime-fuzzy-complete-symbol bound to HYPER,
which is bound to my windows key. This is like the argument that [] is
better than () because one must shift for the second. Switch the
bindings and be done... this is a tools issue, not a language issue.
> 2. It makes the code more compressed horizontally.
This is not a 'big win', but a minor personal aesthetic preference.
Although i will admit to using slime-pretty-lambdas when i have nested
MAPCARs with LAMBDAs or something (and of course LAMBDA is typed as
"lam[HYPER]") , i don't see this as a reason to change the language to
use what i consider as inferior identifiers.
> PG says coding in Arc feels a lot better because of the short names,
> and I tend to agree.
Common Lisp and the ANSI standard were designed by hackers who i hold in
higher esteem than Graham. The consistent readability of CL, which for
the most part has *great* names for things, is a much bigger win than
ease of data entry, IMHO. With a proper environment, any perceived
problems with long identifiers can all but disapear, where if the core
were cryptic, not only would we be stuck with poor names (CL is a
standard after all), but they would surely multiply throughout the
libraries and DSLs people create as they look to the standard for
patterns and idioms.
Its worth noting that PG made his fortune programming in Common Lisp,
not some fictional dialect of his own invention :).
--
Drew Crampsie
drewc at tech dot coop
"Never mind the bollocks -- here's the sexp's tools."
-- Karl A. Krueger on comp.lang.lisp
drewc wrote:
> Tron3k wrote:
>
> > Long descriptive names should be used for things that are not central
> > language features. I'm OK with that. The things in the core should be
> > short.
>
> I disagree. When learning a language, or designing a library, one looks
> to the standard library functions for common idioms. In common lisp,
> because we are able to change the language with ease, it is especially
> important to design your extensions so that they feel like part of the
> language.
>
> The perfect example of this is the WITH-* pattern. If WITH-OPEN-FILE
> were named WOF (or whatever, this is just an example), the designer of
> clsql might have thought it a good idea to name WITH-DEFAULT-DATABASE as
> WDD, which is completely meaningless, and unreadable.
Ah, I see. You don't know what I'm talking about when I say shorter
names. WITH-OPEN-FILE is a *good* name. If you thought I wanted it to
be WOF, you must have assumed for some reason that I am an idiot - but
I'm not. Here are examples of better names:
MULTIPLE-VALUE-BIND should be MV-BIND
CALL-WITH-CURRENT-CONTINUATION (when we get it) should be CALL/CC
MAPCAR should be MAP (and then MAP should be something else - it is
used less often than MAPCAR)
Get the picture?
Moreover, you worry about people learning the language. Remember, a
language should be designed for the skilled and intelligent people
using it: "Language for Smart People."
> > 1. It is easier to type short names. (I don't like hitting Ctrl or Alt
> > in the middle of editing to do some completion shortcut.)
>
> On my desktop machine i have slime-fuzzy-complete-symbol bound to HYPER,
> which is bound to my windows key. This is like the argument that [] is
> better than () because one must shift for the second. Switch the
> bindings and be done... this is a tools issue, not a language issue.
I personally have a dislike for all sorts of completion. For example,
when you are logging on to a website in Firefox, it's always trying to
complete things for you. I *hate* that. I want to minimize use of
completion in programming. Don't forget this is also for reading code:
long names are hard to read, because they're so big. Your brain finds
it harder to gestalt them. And not to mention friggin'
MULTIPLE-VALUE-BIND forcing me to add extra lines to my code so that it
doesn't fall off the side of the page.
> > 2. It makes the code more compressed horizontally.
>
> This is not a 'big win', but a minor personal aesthetic preference.
> Although i will admit to using slime-pretty-lambdas when i have nested
> MAPCARs with LAMBDAs or something (and of course LAMBDA is typed as
> "lam[HYPER]") , i don't see this as a reason to change the language to
> use what i consider as inferior identifiers.
It's a big win, man. It lets you see more. It's like the difference
between planning a raid from the ground and planning it from the air.
Also, I can't believe you use completion for LAMBDA. The mere prospect
of doing that makes me feel pain. For a while I've been using
SmallTalk-style lambda constructs: [x y|(+ x y)]
Now that is sweet.
> > PG says coding in Arc feels a lot better because of the short names,
> > and I tend to agree.
>
> Common Lisp and the ANSI standard were designed by hackers who i hold in
> higher esteem than Graham. The consistent readability of CL, which for
> the most part has *great* names for things, is a much bigger win than
> ease of data entry, IMHO. With a proper environment, any perceived
> problems with long identifiers can all but disapear, where if the core
> were cryptic, not only would we be stuck with poor names (CL is a
> standard after all), but they would surely multiply throughout the
> libraries and DSLs people create as they look to the standard for
> patterns and idioms.
You're still stuck on the idea that short names have to be cryptic. Not
so. And don't forget the manifold importance of being able to gestalt
more of the code at once.
> It's worth noting that PG made his fortune programming in Common Lisp,
> not some fictional dialect of his own invention :).
Is it worth noting that I use Common Lisp extensively too (for game
development)? I don't really think so.
From: Joe Marshall
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <ll45uyqd.fsf@comcast.net>
"Tron3k" <······@gmail.com> writes:
> I personally have a dislike for all sorts of completion.
I'll bet there's some sort of completion you'd like.
> For example, when you are logging on to a website in Firefox, it's
> always trying to complete things for you. I *hate* that.
Agreed. Completion shouldn't happen unless you *ask* it to.
Personally, I like the dynamic completion in Emacs. It isn't eagerly
trying to complete things, it's reasonably easy to M-/ to get the
completion started, and repeated M-/ cycles through the possibilities.
(None of this having to use the mouse to select the right completion
from a dropdown box!)
> Also, I can't believe you use completion for LAMBDA.
I do, too. (But man, I wish I had a [HYPER] key.)
--
~jrm
Joe Marshall wrote:
> "Tron3k" <······@gmail.com> writes:
>
> > I personally have a dislike for all sorts of completion.
>
> I'll bet there's some sort of completion you'd like.
Hmm, I think I might like a completion system where I personally tell
it what abbreviations I want, and no more.
So I tell it MVB is really MULTIPLE-VALUE-BIND and it will
automatically expand it immediately when I press the space after MVB.
That requires no extra effort from me while typing!
> > For example, when you are logging on to a website in Firefox, it's
> > always trying to complete things for you. I *hate* that.
>
> Agreed. Completion shouldn't happen unless you *ask* it to.
>
> Personally, I like the dynamic completion in Emacs. It isn't eagerly
> trying to complete things, it's reasonably easy to M-/ to get the
> completion started, and repeated M-/ cycles through the possibilities.
> (None of this having to use the mouse to select the right completion
> from a dropdown box!)
I guess I could get used to it ... heh.
> > Also, I can't believe you use completion for LAMBDA.
>
> I do, too. (But man, I wish I had a [HYPER] key.)
In my Lisp you can either do [x|(+ x 3)] or (fn (x) (+ x 3)). There's a
third top-secret syntax, but I can't tell you guys what it is yet. ;-)
Rest assured that it is 'super-phat', as the kids say.
Tron3k wrote:
> In my Lisp you can either do [x|(+ x 3)] or (fn (x) (+ x 3)). There's a
> third top-secret syntax, but I can't tell you guys what it is yet. ;-)
> Rest assured that it is 'super-phat', as the kids say.
I can't say I'd like the look of (super-phat (x) (+ x 3)). It's just
not readable. ;)
-- MJF
"Tron3k" <······@gmail.com> writes:
> In my Lisp you can either do [x|(+ x 3)] or (fn (x) (+ x 3)). There's a
> third top-secret syntax, but I can't tell you guys what it is yet. ;-)
> Rest assured that it is 'super-phat', as the kids say.
This is ludicrous.
[42]> (defmacro fn (args &body body) `(lambda ,args ,@body))
FN
[43]> (fn (x y) (+ x y))
#<FUNCTION :LAMBDA (X Y) (+ X Y)>
[44]> (set-macro-character
#\[
(lambda (stream char)
(let ((pipe (gensym)))
(multiple-value-bind (pipe-fun pipe-non-term)
(get-macro-character #\|)
(set-macro-character #\| (lambda (ch stream) pipe) nil)
;; We disable | as an escape character so we'll have
;; to write: [ \C\o\u\n\t\e\r | (+ 1 \C\o\u\n\t\e\r ) ]
;; instead of: (lambda (|Counter|) (+ 1 |Counter|))
(unwind-protect
(let ((lambda-expression
(loop with eof = (gensym)
for var = (read stream nil eof t)
do (cond
((eq var eof) (error "eof in [|]"))
((eq var pipe) (loop-finish))
((eq var ']) (error "] in [|] before |")))
collect var)))
`(lambda ,lambda-expression ,@(read-delimited-list #\] stream t)))
(set-macro-character #\| pipe-fun pipe-non-term))))))
T
[45]> [x y|(+ x y)]
#<FUNCTION :LAMBDA (X Y) (+ X Y)>
How can you justify developing your own programming language when you
can achieve the same results in five minutes of Common Lisp?
The whole point of LISP, discovered in 1959, is that the syntax
doesn't matter at all, be it super-phat or hyper-meta-super-phat.
Now, given that such syntactical extensions are so easy to implement
and use in Common Lisp, ask yourself the following questions:
- Why nobody use them?
- What Common Lisp programmer would be interested in your language if
they don't even have a use for such stuff in their Common Lisp programming?
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
__Pascal Bourguignon__ http://www.informatimago.com/
Pascal Bourguignon wrote:
> "Tron3k" <······@gmail.com> writes:
> > In my Lisp you can either do [x|(+ x 3)] or (fn (x) (+ x 3)). There's a
> > third top-secret syntax, but I can't tell you guys what it is yet. ;-)
> > Rest assured that it is 'super-phat', as the kids say.
>
> This is ludicrous.
>
>
> [42]> (defmacro fn (args &body body) `(lambda ,args ,@body))
> FN
> [43]> (fn (x y) (+ x y))
> #<FUNCTION :LAMBDA (X Y) (+ X Y)>
>
> [44]> (set-macro-character
> #\[
> (lambda (stream char)
> (let ((pipe (gensym)))
> (multiple-value-bind (pipe-fun pipe-non-term)
> (get-macro-character #\|)
> (set-macro-character #\| (lambda (ch stream) pipe) nil)
> ;; We disable | as an escape character so we'll have
> ;; to write: [ \C\o\u\n\t\e\r | (+ 1 \C\o\u\n\t\e\r ) ]
> ;; instead of: (lambda (|Counter|) (+ 1 |Counter|))
> (unwind-protect
> (let ((lambda-expression
> (loop with eof = (gensym)
> for var = (read stream nil eof t)
> do (cond
> ((eq var eof) (error "eof in [|]"))
> ((eq var pipe) (loop-finish))
> ((eq var ']) (error "] in [|] before |")))
> collect var)))
> `(lambda ,lambda-expression ,@(read-delimited-list #\] stream t)))
> (set-macro-character #\| pipe-fun pipe-non-term))))))
> T
> [45]> [x y|(+ x y)]
> #<FUNCTION :LAMBDA (X Y) (+ X Y)>
I have obviously already done these things in Common Lisp. ;)
> How can you justify developing your own programming language when you
> can achieve the same results in five minutes of Common Lisp?
I justify it with my 8 pages of new features I've been figuring out
over the last few days, many of which are *impossible* to implement in
Common Lisp using readtable modification or macros.
> The whole point of LISP, discovered in 1959, is that the syntax
> doesn't matter at all, be it super-phat or hyper-meta-super-phat.
It matters if you can type less characters to achieve the same thing.
That means my hands will get tired later than they normally would. ;)
> Now, given that such syntactical extensions are so easy to implement
> and use in Common Lisp, ask yourself the following questions:
>
> - Why nobody use them?
Because it is the culture to abhor syntax. In my new world of Lisp, it
will not be.
> - What Common Lisp programmer would be interested in your language if
> they don't even have a use for such stuff in their Common Lisp programming?
Don't judge my language by the tidbits I've handed out here. The sum of
the changes I've made is far greater than the individual parts:
together, they combine in the most delightful ways. I've already
surprised myself a couple of times with the new interactions of these
features.
From: Robert Uhl
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <m3y884156e.fsf@4dv.net>
"Tron3k" <······@gmail.com> writes:
>
> Hmm, I think I might like a completion system where I personally tell
> it what abbreviations I want, and no more.
>
> So I tell it MVB is really MULTIPLE-VALUE-BIND and it will
> automatically expand it immediately when I press the space after MVB.
> That requires no extra effort from me while typing!
C-h i m emacs RET C-s abbrev RET RET
--
Robert Uhl <http://public.xdi.org/=ruhl>
After all, how do you give Microsoft the benefit of the doubt when you
know that if you throw it into a room with truth, you'd risk a
matter/anti-matter explosion. --N. Petreley
"Tron3k" <······@gmail.com> writes:
> Joe Marshall wrote:
> > "Tron3k" <······@gmail.com> writes:
> >
> > > I personally have a dislike for all sorts of completion.
> >
> > I'll bet there's some sort of completion you'd like.
>
> Hmm, I think I might like a completion system where I personally tell
> it what abbreviations I want, and no more.
>
Well, that sounds exactly like emacs' abbrev mode. You define some
abbreviation and when you type it, its replaced by a longer
form. Actually, you can go further an bind an emacs elisp function to
the abbrev, so when you type it, it can do all kinds of things, not
just expand to a static abbrev.
Tim
--
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!
>> Also, I can't believe you use completion for LAMBDA.
> I do, too. (But man, I wish I had a [HYPER] key.)
I have the windows key bound to hyper, and it's great. Can't you do
that?
From: Edi Weitz
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <u4qatvtb2.fsf@agharta.de>
On 17 Jul 2005 17:32:38 -0700, ··········@gmail.com wrote:
> I have the windows key bound to hyper, and it's great. Can't you do
> that?
Maybe he has a ThinkPad...
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Joe Marshall
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <br50m2p0.fsf@ccs.neu.edu>
··········@gmail.com writes:
>>> Also, I can't believe you use completion for LAMBDA.
>
>> I do, too. (But man, I wish I had a [HYPER] key.)
>
> I have the windows key bound to hyper, and it's great. Can't you do
> that?
No clue. I'll look into it. Thanks.
From: Edi Weitz
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <uhdetvyky.fsf@agharta.de>
On Sun, 17 Jul 2005 13:30:18 -0400, Joe Marshall <·············@comcast.net> wrote:
> (But man, I wish I had a [HYPER] key.)
I can send you one, I have an old Symbolics keyboard lying around.
What are you willing to pay?
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Joe Marshall
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <fyucm2ps.fsf@ccs.neu.edu>
Edi Weitz <········@agharta.de> writes:
> On Sun, 17 Jul 2005 13:30:18 -0400, Joe Marshall <·············@comcast.net> wrote:
>
>> (But man, I wish I had a [HYPER] key.)
>
> I can send you one, I have an old Symbolics keyboard lying around.
> What are you willing to pay?
How much of the rest of the hardware is attached?
From: Edi Weitz
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <u8y04j80k.fsf@agharta.de>
On Mon, 18 Jul 2005 13:41:19 -0400, Joe Marshall <···@ccs.neu.edu> wrote:
> Edi Weitz <········@agharta.de> writes:
>
>> On Sun, 17 Jul 2005 13:30:18 -0400, Joe Marshall <·············@comcast.net> wrote:
>>
>>> (But man, I wish I had a [HYPER] key.)
>>
>> I can send you one, I have an old Symbolics keyboard lying around.
>> What are you willing to pay?
>
> How much of the rest of the hardware is attached?
Hey, originally you said you only wanted one key...
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Tron3k wrote:
> drewc wrote:
>>The perfect example of this is the WITH-* pattern. If WITH-OPEN-FILE
>>were named WOF (or whatever, this is just an example), the designer of
>>clsql might have thought it a good idea to name WITH-DEFAULT-DATABASE as
>>WDD, which is completely meaningless, and unreadable.
>
>
> Ah, I see. You don't know what I'm talking about when I say shorter
> names. WITH-OPEN-FILE is a *good* name. If you thought I wanted it to
> be WOF, you must have assumed for some reason that I am an idiot - but
> I'm not. Here are examples of better names:
Like i said, it was just an example... whether i think you're an idiot
or not is beside the point.
> MULTIPLE-VALUE-BIND should be MV-BIND
This is the example that everybody uses, because it is such a long name.
Personally i use m-v-b so rarely that it doesn't bug me. If it really
bugs you, and for the reasons you mentioned, there is nothing stopping
you from writing a wrapper function.. but to expect everybody else to
want to go along with your 'improvements' is nothing short of arrogance.
> CALL-WITH-CURRENT-CONTINUATION (when we get it) should be CALL/CC
What makes you think CL will be getting CALL/CC anytime soon? (and, FWIW
i've already mentioned my preference for the second elsewhere in this
thread.)
> MAPCAR should be MAP (and then MAP should be something else - it is
> used less often than MAPCAR)
And then what? you expect me to rewrite all my software to use your
'new' names? is the saving of three keystrokes worth breaking millions
of lines of running code?
Besides the fact the i personally prefer the name MAPCAR over MAP for
the function that MAPs over successive CARs, changing the names of
identifiers in a standardised langauge is not something to be undertaken
simply because a few people would like to save 3 keystrokes.
>
> Get the picture?
Not really, it still just sounds arrogant to me. You have a preference
for short names, and you want to inflict that preference on the entire
community, compatability be damned. While i *may* agree that MV-BIND is
a good name (and that's not to say i do), i can't make the leap to "we
have to change common lisp to suit your preferences"
>
> Moreover, you worry about people learning the language. Remember, a
> language should be designed for the skilled and intelligent people
> using it: "Language for Smart People."
I've read Graham's papers and understood his arguments, there is no need
to keep parroting them here. Just because Paul Graham said it does not
make it gospel. FWIW i think PG is arrogant as well, although he has a
right to be. PG is a smart man with some good ideas, and i'm interested
in his writings about ARC, but i expect to be using common lisp for
quite a while. There is no compelling reason to switch to the other
dialects that exist, and WRT ARC, i can't compile code with vapour.
I'm not saying your proposals are a bad idea for another LISP dialect,
like, say, ARC... but CL is an established langauge with 20 years of
momentum behind it, and some of the 'improvements' you suggest are
nothing short of drastic changes, for no (IMHO) good reason besides your
wanting CL to be more like Scheme or ARC. The Lisp-1 thing for example
would be a huge loss.
> I personally have a dislike for all sorts of completion. For example,
> when you are logging on to a website in Firefox, it's always trying to
> complete things for you.
That's a personal preference, not a technical or language issue. Besides
that, emacs never tries to 'complete things for you', you have to
specifically invoke the completion mechanism.
> I *hate* that. I want to minimize use of
> completion in programming.
You do.. i don't. I'm not asking you to use completion if you don't want
to, but you've expected me to take, as fact, that your ideas for a LISP
are 'better' than established practice. I'm simply pointing out that
perhaps Common Lisp is not the langauge you are looking for, and if you
are looking for a language with the features you describe, perhaps you
should look elsewhere.
> Don't forget this is also for reading code:
> long names are hard to read, because they're so big. Your brain finds
> it harder to gestalt them.
Your brain perhaps. To assume you know how _my_ brain works is arrogance
again. It's not that i take offense to your ideas, some of which are
'interesting', but the way you present them.
Personally, i am a rapid reader. Not only do i not read individual
letters in a word, but i hardly read individual words within the
sentance, and often barely skim a sentance within a paragraph. I rely
more on structure, and my knowledge of the language, rather than the
invidual letters and the length of words.
This is consistent with how the psycholinguists say 'skilled' readers
proccess text. YMMV, but don't assume that my brain works like yours.
> And not to mention friggin'
> MULTIPLE-VALUE-BIND forcing me to add extra lines to my code so that it
> doesn't fall off the side of the page.
M-V-B is not 'forcing' you to do anything, there is nothing stopping you
from creating an alias for it. This is one of the big wins in CL, that
you are not forced to rely on the whims of the language designers.
>>>2. It makes the code more compressed horizontally.
>>
>>This is not a 'big win', but a minor personal aesthetic preference.
>>Although i will admit to using slime-pretty-lambdas when i have nested
>>MAPCARs with LAMBDAs or something (and of course LAMBDA is typed as
>>"lam[HYPER]") , i don't see this as a reason to change the language to
>>use what i consider as inferior identifiers.
> It's a big win, man. It lets you see more. It's like the difference
> between planning a raid from the ground and planning it from the air.
How is planning a raid similar to reading source code? I don't mind
argument by analogy, as it's often helped me to see things from another
POV, but this analogy is shaky at best.
Its not that i disagree with you, its just that i don't see any of your
arguments as compelling enough to change the Common Lisp ANSI standard.
>
> Also, I can't believe you use completion for LAMBDA. The mere prospect
> of doing that makes me feel pain. For a while I've been using
> SmallTalk-style lambda constructs: [x y|(+ x y)]
> Now that is sweet.
I find that absolutely hideous and unreadable (which was my problem with
smalltalk actually). I'll admit that this simple personal preference,
but i've got the lisp community behind me on this one. We, in general,
are not big fans of syntax. Esp. syntax which looks like line noise.
It's fine to have these little utilities around for quick jaunts at the
REPL, but if any of my programmers ever tried to check in code that
looked like that, they'd get a stern warning :).
> You're still stuck on the idea that short names have to be cryptic. Not
> so. And don't forget the manifold importance of being able to gestalt
> more of the code at once.
Short names are, by their very nature, cryptic. A programmer must
decrypt the name before understanding what the function does.
Lets take MULTIPLE-VALUE-BIND as an example. Great name, tells me
exactly what it does with no ambiguity.
Your suggestion is MV-BIND, and it is cryptic. You are expecting the
programmer to know that MV means 'multiple value'. Coming from a unix
background, i'd probably read this as "MOVE-BIND" which would confuse
me. While not _very_ cryptic, to claim that it is not so is simply false.
The most popular definition of 'cryptic' is something along the lines of
"Having hidden meaning". MV-BIND definately has this property.
>>It's worth noting that PG made his fortune programming in Common Lisp,
>>not some fictional dialect of his own invention :).
> Is it worth noting that I use Common Lisp extensively too (for game
> development)? I don't really think so.
Me neither. but i don't see what that has to do with my point. I simply
wanted to mention that, since you keep using PG as your authority on the
subject, he has never suggested that we change CL to look be more like
ARC. ARC is intended to be a dialect that stands alone, not an 'update'
to common lisp, or a future Common Lisp standard.
--
Drew Crampsie
drewc at tech dot coop
"Never mind the bollocks -- here's the sexp's tools."
-- Karl A. Krueger on comp.lang.lisp
drewc wrote:
> ...
Hi drewc. Sorry, I think my main mistake was in saying (or implying)
that I wanted Common Lisp to change for me. I don't. I was idly
speculating about the future Lisp, the ultimate Lisp, the Omega Lisp.
It seems that you agree with some of my ideas but don't want to destroy
previous programs in order to implement them, and I agree with that.
Oh yes! I have eliminated the MV-BIND which you correctly denounced as
cryptic. I now simply do multiple value binding by replacing the
variable to be bound in a LET with a list of variables! It's brilliant!
[Note: In my Lisp WITH is LET1.]
So, for example:
(with (a b c) (values 1 2 3)
(list a b c))
=>
(1 2 3)
Excellent, is it not?
Tron3k wrote:
> Hi drewc. Sorry, I think my main mistake was in saying (or implying)
> that I wanted Common Lisp to change for me. I don't. I was idly
> speculating about the future Lisp, the ultimate Lisp, the Omega Lisp.
> It seems that you agree with some of my ideas but don't want to destroy
> previous programs in order to implement them, and I agree with that.
I find some of your ideas 'interesting' (or at least i did the first
time i heard them, which was not from you), but i hardly agree with most
of them. My problem is that your are calling it 'the ultimate lisp'
while throwing away a lot of the things I really like about Common Lisp,
and adding syntax, which i personally abhor.
I'll probably stop responding if you start calling it 'my ultimate
lisp', because, for the most part, i don't like what i've seen of your
lisp and probably wouldn't use it. I find the CL is pretty darn close to
being _my_ perfect lisp, and i probably wouldn't use ARC over CL either.
That's not to say there isn't room for other LISPs, but to claim
anything as the 'ultimate' lisp, especially over CL, you'd have to come
up with much better evidence than what you've shown here, and one hell
of a good spec/standard.
> Oh yes! I have eliminated the MV-BIND which you correctly denounced as
> cryptic. I now simply do multiple value binding by replacing the
> variable to be bound in a LET with a list of variables! It's brilliant!
> [Note: In my Lisp WITH is LET1.]
>
> So, for example:
> (with (a b c) (values 1 2 3)
> (list a b c))
>
> =>
>
> (1 2 3)
>
> Excellent, is it not?
I'm not a fan of overloading operators in this manner. I find it
somewhat cryptic, more so than MV-BIND which is at least obviously
performing a different task from WITH. Same thing with your use of
DEFINE as a generic definition operation.. i prefer DEFUN, DEFVAR,
DEFMACRO etc.. That being said, if part of your design goal was to
eliminate the name 'MULTIPLE-VALUE-BIND', this is a neat solution. If
you feel that it is 'brilliant' and 'excellent', i wont begrudge you
that, no matter how strongly i disagree ;)
drewc
--
Drew Crampsie
drewc at tech dot coop
"Never mind the bollocks -- here's the sexp's tools."
-- Karl A. Krueger on comp.lang.lisp
drewc wrote:
> Tron3k wrote:
> > Hi drewc. Sorry, I think my main mistake was in saying (or implying)
> > that I wanted Common Lisp to change for me. I don't. I was idly
> > speculating about the future Lisp, the ultimate Lisp, the Omega Lisp.
> > It seems that you agree with some of my ideas but don't want to destroy
> > previous programs in order to implement them, and I agree with that.
>
> I find some of your ideas 'interesting' (or at least i did the first
> time i heard them, which was not from you), but i hardly agree with most
> of them. My problem is that your are calling it 'the ultimate lisp'
> while throwing away a lot of the things I really like about Common Lisp,
> and adding syntax, which i personally abhor.
>
> I'll probably stop responding if you start calling it 'my ultimate
> lisp', because, for the most part, i don't like what i've seen of your
> lisp and probably wouldn't use it. I find the CL is pretty darn close to
> being _my_ perfect lisp, and i probably wouldn't use ARC over CL either.
The Lisp-1 vs. Lisp-N thing is probably tricker than it seems at first
sight. I currently suspect that Lisp-N is the sounder choice, and its
ugliness is due to insufficiently advanced programmer UIs.
In particular, the 2-D plaintext UI seems at fault, not Lisp-N. Perhaps
I'll think this through later. Interlisp may have led to advances in
this direction; too bad it was intentionally killed by Common Lisp's
standardization, and now Intentional Programming may take up the
slack...
(So for example, one alternative might be where you could "rotate" code
in a 3rd dimension within some UI. Perhaps to see macroexpansion
histories, or annotations like type information. Similar cues such as
colors may also be used for these purposes.)
(This does not need to trade off with lists, as lists remain a nice
serialization form when you want to print stuff out, use over dumb
terminals, or save the code to storage. As Dave Moon suggested for Arc,
OOP objects may alternately be used for this.)
> That's not to say there isn't room for other LISPs, but to claim
> anything as the 'ultimate' lisp, especially over CL, you'd have to come
> up with much better evidence than what you've shown here, and one hell
> of a good spec/standard.
On one hand, I agree we haven't yet seen good enough evidence. Where's
this "secret feature" that Tron3k mentions? Why's it secret?
On the other hand, it seems that whenever people bring this topic up,
others call them dumb and whatnot. (I don't mean you do this.) The
discourse doesn't evolve since it becomes a matter of Lisp
fundamentalism; it remains dumb. It brings to mind this quote:
"Those who have put out the people's eyes, reproach them for their
blindness." -- John Milton
Tayssir
Tayssir John Gabbour wrote:
> > That's not to say there isn't room for other LISPs, but to claim
> > anything as the 'ultimate' lisp, especially over CL, you'd have to come
> > up with much better evidence than what you've shown here, and one hell
> > of a good spec/standard.
>
> On one hand, I agree we haven't yet seen good enough evidence. Where's
> this "secret feature" that Tron3k mentions? Why's it secret?
Har har. Ok, the truth is that I have too many new things in my
notebook and I don't have the time to write them all out now. Also I
like a little subterfuge ... if I actually provided an example of one
of my features I would be instantly attacked by unimaginable hordes.
(Look what happened with my short form for LAMBDA! And yet this form
looks SO nice when you use it in mapping functions and the like. People
respond viscerally to anything new.) The features need to be seen as a
gestalt, I believe. And as Paul Graham says, I don't want to get into
arguments with anti-Yellowists. ;-)
> On the other hand, it seems that whenever people bring this topic up,
> others call them dumb and whatnot. (I don't mean you do this.) The
> discourse doesn't evolve since it becomes a matter of Lisp
> fundamentalism; it remains dumb. It brings to mind this quote:
>
> "Those who have put out the people's eyes, reproach them for their
> blindness." -- John Milton
I also think it would be a better Lisp world if we weren't in this
situation of one person desperately trying to defend himself against
the hordes of comp.lang.lisp. :-) It should be more of a free exchange
of new ideas. I imagine many people reading these threads are afraid of
throwing out new ideas now - it's just a bad kind of culture to create.
Tron3k wrote:
> I also think it would be a better Lisp world if we weren't in this
> situation of one person desperately trying to defend himself against
> the hordes of comp.lang.lisp. :-) It should be more of a free exchange
> of new ideas. I imagine many people reading these threads are afraid of
> throwing out new ideas now - it's just a bad kind of culture to create.
I strongly suggest visiting one of those in-person Lisp meetings.
There's such a wild lack of bandwidth on the net -- like running
through waist-deep water. Also, the heavy posters here aren't really
representative of Lisp users, most of whom never/occasionally write on
these forums. Meetings are generally warmer and quite constructive.
I learned far more discussing my thoughts face-to-face with people, and
got a better sense of what arguments were more technically convincing.
These aspects of forums have been long observed in the Lisp world.
"Knee-jerk Anti-LOOPism and other E-mail Phenomena" and
Gabriel/Steele's HOPL-uncut paper both mention a bit on this topic...
My best use of usenet is to go back in time and find targetted posts.
http://disciplinedminds.tripod.com/
Tayssir
"Tron3k" <······@gmail.com> writes:
> I also think it would be a better Lisp world if we weren't in this
> situation of one person desperately trying to defend himself against
> the hordes of comp.lang.lisp. :-) It should be more of a free exchange
> of new ideas. I imagine many people reading these threads are afraid of
> throwing out new ideas now - it's just a bad kind of culture to create.
Perhaps if you started a thread "Tron3k new kind of lisp" listing the
features of your lisp and showing how well they interact and what
emerges.
But you're "trolling" in threads named "Beyond CL" and "How do you
imagine future Common Lisp standard ?". The answer has been clear:
the future of Common Lisp is more Common Lisp, not a lisp-1 with a lot
of syntactic suggar.
Start again on good bases.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we. -- Georges W. Bush
Pascal Bourguignon wrote:
> "Tron3k" <······@gmail.com> writes:
> > I also think it would be a better Lisp world if we weren't in this
> > situation of one person desperately trying to defend himself against
> > the hordes of comp.lang.lisp. :-) It should be more of a free exchange
> > of new ideas. I imagine many people reading these threads are afraid of
> > throwing out new ideas now - it's just a bad kind of culture to create.
>
> Perhaps if you started a thread "Tron3k new kind of lisp" listing the
> features of your lisp and showing how well they interact and what
> emerges.
I'll do that when I'm finished designing it.
> But you're "trolling" in threads named "Beyond CL" and "How do you
> imagine future Common Lisp standard ?". The answer has been clear:
> the future of Common Lisp is more Common Lisp, not a lisp-1 with a lot
> of syntactic sugar.
Funny, I thought "Beyond CL" would be exactly what I'm talking about.
The other one, I agree, I accidentally got into that one somehow.
Tayssir John Gabbour wrote:
> The Lisp-1 vs. Lisp-N thing is probably tricker than it seems at first
> sight. I currently suspect that Lisp-N is the sounder choice, and its
> ugliness is due to insufficiently advanced programmer UIs.
One of my early lisp epiphanies (we should have a word for this,
lispiphany?) was that, after all this reading about Lisp-1 vs. Lisp-2,
CL was infact a Lisp-N, and i was free to add my own N+1 :)
> In particular, the 2-D plaintext UI seems at fault, not Lisp-N. Perhaps
> I'll think this through later. Interlisp may have led to advances in
> this direction; too bad it was intentionally killed by Common Lisp's
> standardization, and now Intentional Programming may take up the
> slack...
It could well be the plaintext UI. I'm glad you pointed this out. I love
reading, and have always thought that programs are meant to be read. I
find CL a joy to read, but someone who doesn't feel the same way would
be well served by an advanced UI, and once you finally got me to try it
i'm sure i'd be impressed as well :)
Although i've never used Interlisp, i've read as much about it as i
could get my hands (or mouse) on. There is a lot of room in Lisp for
DWIM and environments that interact with the running image in ways that
CL doesn't neccesarily provide for, or doesn't make easy.
> (So for example, one alternative might be where you could "rotate" code
> in a 3rd dimension within some UI. Perhaps to see macroexpansion
> histories, or annotations like type information. Similar cues such as
> colors may also be used for these purposes.)
Something along those lines would be a boon to productivity, no doubt
about it, and i don't think you could build an enviroment like that on
top of CL without writing half a CL as well.
I'd like to see an implementation that provided hooks into the compiler
for the development environment, or perhaps a development environment
that contains a CL interpreter and can reason about your code.
> (This does not need to trade off with lists, as lists remain a nice
> serialization form when you want to print stuff out, use over dumb
> terminals, or save the code to storage. As Dave Moon suggested for Arc,
> OOP objects may alternately be used for this.)
Exactly. CL is a fine serialisation format IMO. If all the incredible
features of interlisp, and lisps yet to be created, can be compiled by a
CL compiler, and output to CL sexps, i think that would be an ideal
situation.
I think that what i'm trying to get at is that i view Common Lisp as a
passable universal language. If we create incredible UI's for
development, and yet still output CL, we could make advancements of this
sort with the strength of the CL standard as the foundation. Obviously
it's far from perfect, but it's damn good. Lets give it a few more years
and see how it goes :)
I said to Tron3k:
>>That's not to say there isn't room for other LISPs, but to claim
>>anything as the 'ultimate' lisp, especially over CL, you'd have to come
>>up with much better evidence than what you've shown here, and one hell
>>of a good spec/standard.
you replied:
> On one hand, I agree we haven't yet seen good enough evidence. Where's
> this "secret feature" that Tron3k mentions? Why's it secret?
From what i saw, it seemed like a nice little toy lisp. I'm sure most
of us have various lisp interpreters lying around that we play with from
time to time. I know that when i read SICP and the LtU papers i created
quite a few scheme type languages :). It's a great exercise, and a lot
of fun. I'm sure we'll see Tron3k again when he is humbled by the task
and has learned a lot more about LISP.
Similarly, i hope to hear from Paul Graham on Arc. I think his type/tag
system looks really cool, and i'd love to see how the first-class macros
are working out. There are lots of interesting things to explore, and he
is a great hacker. I just can't see his language replacing CL for my
uses. I sincerely hope that he, or someone else, can prove me wrong.
> On the other hand, it seems that whenever people bring this topic up,
> others call them dumb and whatnot. (I don't mean you do this.) The
> discourse doesn't evolve since it becomes a matter of Lisp
> fundamentalism; it remains dumb. It brings to mind this quote:
>
> "Those who have put out the people's eyes, reproach them for their
> blindness." -- John Milton
This is an excellent point. One of the things we praise about lisp is
the ability to 'make your own language', and i guess this topic is a
logical outcome of that. I hope i didn't come off as trying to make the
OP feel dumb, as rather i was going for humble. It's great that he's
excited about Lisp, but there are better ways to spend your energy than
giving language design advice to Kent Pitman ;)
I suppose we should be more open to this sort of thing, as i personally
am looking for a nice lispy scripting language for doing unix system
tasks, and somebody like Tron3k just might be the one to create things
like that. Unfortunately i can't help but have an aversion to his method
of communicating his ideas. It reminds me of the newLisp homepage, where
the author argues for reference counting and dynamic scope.... it's just
too painful to read.
--
Drew Crampsie
drewc at tech dot coop
"Never mind the bollocks -- here's the sexp's tools."
-- Karl A. Krueger on comp.lang.lisp
"Tron3k" <······@gmail.com> writes:
> Oh yes! I have eliminated the MV-BIND which you correctly denounced as
> cryptic. I now simply do multiple value binding by replacing the
> variable to be bound in a LET with a list of variables! It's brilliant!
> [Note: In my Lisp WITH is LET1.]
>
> So, for example:
> (with (a b c) (values 1 2 3)
> (list a b c))
>
> =>
>
> (1 2 3)
>
> Excellent, is it not?
Actually it is boring. It's been done a zillion times by pretty much
everyone at one time or another. What's better (but still boring and
also been done before) is to seamlessly and clearly be able to mix all
such binding techniques in a general form.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
drewc <·····@rift.com> writes:
>Lets take MULTIPLE-VALUE-BIND as an example. Great name, tells me
>exactly what it does with no ambiguity.
Well, I personally would have chosen BIND-VALUES but it's not that
much shorter.
mkb.
Matthias Buelow wrote:
> drewc <·····@rift.com> writes:
>
>
>>Lets take MULTIPLE-VALUE-BIND as an example. Great name, tells me
>>exactly what it does with no ambiguity.
>
>
> Well, I personally would have chosen BIND-VALUES but it's not that
> much shorter.
That is a good name as well, although i like the similarity between MVB
and DESTRUCTURING-BIND and BIND-DESTRUCTURING just doesn't feel right :)
drewc
--
Drew Crampsie
drewc at tech dot coop
"Never mind the bollocks -- here's the sexp's tools."
-- Karl A. Krueger on comp.lang.lisp
drewc <·····@rift.com> writes:
> Torn3k wrote:
>
> > Long descriptive names should be used for things that are not central
> > language features. I'm OK with that. The things in the core should be
> > short.
>
> I disagree. When learning a language, or designing a library, one
> looks to the standard library functions for common idioms. In common
> lisp, because we are able to change the language with ease, it is
> especially important to design your extensions so that they feel like
> part of the language.
>
As someone new to CL, I'm very very thankful that the functions which
make up the core of the language have long descriptive names. There is
quite a lot there and finding what you need would be difficult if the
functions had short abbreviated names - for example, you would need to
know what abbreviation to put into apropos etc. Its much easier to
see/guess what a function does with the long names. If you use
abbreviated names, you have two problems. New users need to know the
scheme used to derive abbreviations and you need to make sure all
abbreviations are consistent.
Tim
--
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!
From: Robert Uhl
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <m3slyegm85.fsf@4dv.net>
drewc <·····@rift.com> writes:
>
> I think its worth noting that PG allegedly uses vi[1], which may explain
> why he values terse function names. In Emacs+SLIME with
> slime-fuzzy-complete-symbol, the long function names are not that many
> key strokes at all ( mvb[C-c M-i] => multiple-value-bind ).
Actually it generates:
Click <mouse-2> on a completion to select it.
In this buffer, type n and p to navigate between completions.
Type RET to select the completion near point. Type q to abort.
Flags: boundp fboundp generic-function class macro special-operator
Completion: Flags: Score:
------------------------------- ------ --------
multiple-value-bind -f--m- 26.59
most-positive-double-float b----- 12.42
most-negative-double-float b----- 12.42
*compile-verbose* b----- 10.67
*compiler-print-variable-alist* b----- 10.34
--
Robert Uhl <http://public.xdi.org/=ruhl>
A lot of plants have taken a rather seriously defencive stance against
being eaten. --Bruce Johnson
drewc <·····@rift.com> writes:
>A big win how? I like long descriptive names, it makes code much more
>readable IMO.
So you'd, for example in Scheme, prefer call-with-current-continuation
over call/cc? [1]
I don't think the first makes the code more readable. Quite the
contrary, actually.
mkb.
[1] Forgive me for not constructing a Common Lisp example, but that
one's immediately popped into my mind.
Matthias Buelow wrote:
> drewc <·····@rift.com> writes:
> So you'd, for example in Scheme, prefer call-with-current-continuation
> over call/cc? [1]
> I don't think the first makes the code more readable. Quite the
> contrary, actually.
I'm not talking about scheme, i don't use scheme, and your footnote does
not save you from being offtopic :). If a CL-like language[1] were to
add continuations, i would not mind seeing call/cc at all, as call/cc
has been around a long time and it's usage is well known. I prefer CADR
to (FIRST (REST ...)) most of the time as well, depending on how it's used.
I enjoy the fact that you are looking for a specific example with which
to prove my generalisation wrong, so how about i phrase it this way :
"with few exceptions, i prefer the longer identifier as i find it more
readable. For the most part, the designers of Common Lisp agree with me.
Regardless, long identifiers are not a problem that needs to be
'fixed', and i don't think re-visiting the ANSI Standardisation process
with the intention of making such a trivial change (which breaks
compatability) is a good idea".
Good enough for you?
drewc
--
Drew Crampsie
drewc at tech dot coop
"Never mind the bollocks -- here's the sexp's tools."
-- Karl A. Krueger on comp.lang.lisp
[1] Like, say, UncommonWeb actions.
Drew Crampsie wrote:
> I prefer CADR to (FIRST (REST ...)) most of the time as well,
> depending on how it's used.
I'd have thought that in most contexts SECOND is preferable
to either of those.
--
Gareth McCaughan
.sig under construc
Gareth McCaughan <················@pobox.com> writes:
> Drew Crampsie wrote:
>
>> I prefer CADR to (FIRST (REST ...)) most of the time as well,
>> depending on how it's used.
>
> I'd have thought that in most contexts SECOND is preferable
> to either of those.
Depends. If the recursion is on (cddr x), then I prefer to process
(car x) and (cadr x).
On the other hand, if the recursion is on (third x), of course, I
process (first x) and (second x).
--
__Pascal Bourguignon__ http://www.informatimago.com/
Cats meow out of angst
"Thumbs! If only we had thumbs!
We could break so much!"
Gareth McCaughan wrote:
> Drew Crampsie wrote:
>
>
>>I prefer CADR to (FIRST (REST ...)) most of the time as well,
>>depending on how it's used.
>
>
> I'd have thought that in most contexts SECOND is preferable
> to either of those.
>
LOL, i probably meant (rest (first ...)) and CADR, but it doesn't really
obscure my point (i hope) :)
--
Drew Crampsie
drewc at tech dot coop
"Never mind the bollocks -- here's the sexp's tools."
-- Karl A. Krueger on comp.lang.lisp
drewc <·····@rift.com> writes:
> Tron3k wrote:
>
> > I'm actually creating my own version of Arc. The short function names
> > really are a big win, just like Paul Graham says.
>
> A big win how? I like long descriptive names, it makes code much more
> readable IMO.
>
> I think its worth noting that PG allegedly uses vi[1], which may
> explain why he values terse function names. In Emacs+SLIME with
> slime-fuzzy-complete-symbol, the long function names are not that many
> key strokes at all ( mvb[C-c M-i] => multiple-value-bind ).
>
> I value read-ability over write-ability, and descriptive function
> names are a really big win when reading, and hardly a loss (using the
> right tools) when writing.
>
> [1] I can't find a reference for this beyond a slashdot post, but i'm
> sure i've read it somewhere else.
>
I'm with Drew on the length of names - descriptive names are much
better for understanding code, which I also think is more important
than less keystrokes when typing code.
I do have to admit to having a 'hidden agenda' for supporting long
descriptive identifiers. I'm a blind programmer. For the past 7 years,
I've been using the fantastic emacspeak package written by
T. V. Raman. This elisp package uses features like elisps defadvice to
add commands that send text to a text-to-speech synthesizer. It was
through using this system, adding to it, customizing it etc, that made
me interested in Lisp generally and eventually brought me to CL.
One of the first things I noticed was how much easier it was to follow
what was going on in code because of the long names used by most
users. Not really an argument which is very convincing for most users
- for that I'll have to wait until we are all using an interface based
on speech recognition and text-to-speech output.
Tim
--
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!
From: Ulrich Hobelmann
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <3jte4jFrobh5U1@individual.net>
Tron3k wrote:
>> Paul Graham also says "[...]it's not Lisp that sucks, but Common Lisp."
>> ( http://www.paulgraham.com/popular.html )
>
> It's kind of like how democracy is a terrible system for running things
> - but it's the best we have. ;-)
And that's just a matter of taste... ;)
>>> Now what's all this about CL people not wanting to 'be Scheme'? I want
>>> Common Lisp to be Scheme, and Scheme to be Common Lisp. What I *really*
>>> want is something like Arc, though. :-)
>> Noone stops you to create something like that. If Lisp would really be
>> so good then it should not be a problem for you as a master to do it
>> within a few weeks/months.
>
> I'm actually creating my own version of Arc. The short function names
> really are a big win, just like Paul Graham says.
Not sure about that, but I like other Arc features.
It's a funny world, where everybody has different opinions :)
The thing that keeps us here is CL.
--
XML is a prime example of retarded innovation.
-- Erik Meijer and Peter Drayton, Microsoft Corporation
From: Pascal Costanza
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <3jru3oFkl6ngU1@individual.net>
Tron3k wrote:
> Now what's all this about CL people not wanting to 'be Scheme'?
Some people think that CL is much better wrt fundamental design
decisions, like Lisp-n instead of Lisp-1.
If you want those design decisions to be different, but also want
CL-style macros, keywords, etc, there are a number of Scheme systems
that provide them as extensions, like PLT Scheme and Bigloo and probably
others.
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Pascal Costanza wrote:
> Tron3k wrote:
>
>> Now what's all this about CL people not wanting to 'be Scheme'?
>
>
> Some people think that CL is much better wrt fundamental design
> decisions, like Lisp-n instead of Lisp-1.
The Lisp-n bit has got to be my favourite feature in CL. I've always had
trouble naming things that i feel should have the same name in languages
that use the same namespace for functions/variables/classes.
(defvar list (list 1 2)) ;;a poor example.
In a lisp-1 i'd use "lst", which, to me, reads as "first" in some fonts
and "lust" in others :) I find there are many cases where i want to use
the same name for things in different contexts , and my language should
allow me to do that. Functions, variables and classes are different things!
(defclass pun ()
((pun :accessor pun :initarg :pun :initform t)))
(defparameter pun (make-instance 'pun))
(setf (pun pun) (make-instance 'pun :pun 'pun))
(pun (pun pun))
=> PUN
ahhh ... feels right.
drewc
>
> If you want those design decisions to be different, but also want
> CL-style macros, keywords, etc, there are a number of Scheme systems
> that provide them as extensions, like PLT Scheme and Bigloo and probably
> others.
>
>
> Pascal
>
--
Drew Crampsie
drewc at tech dot coop
"Never mind the bollocks -- here's the sexp's tools."
-- Karl A. Krueger on comp.lang.lisp
drewc wrote:
> Pascal Costanza wrote:
>
>> Some people think that CL is much better wrt fundamental design
>> decisions, like Lisp-n instead of Lisp-1.
>
> The Lisp-n bit has got to be my favourite feature in CL. I've always had
> trouble naming things that i feel should have the same name in languages
> that use the same namespace for functions/variables/classes.
>
> (defvar list (list 1 2)) ;;a poor example.
>
> In a lisp-1 i'd use "lst", which, to me, reads as "first" in some fonts
> and "lust" in others :) I find there are many cases where i want to use
> the same name for things in different contexts , and my language should
> allow me to do that. Functions, variables and classes are different things!
Except when they're all first-class and mutable, they're
not. A function is just another value that a variable
can be bound to as far as I'm concerned; I find the
sharp-quote thing really annoying, because when I type
the name of a function, dammnit, I mean the function!
Likewise, when I put an expression that evaluates to a
function in the function position of a call, or the name
of a variable that's been provided as an argument, what
the hell else does the system think I could possibly
mean?
Maybe it's because I started writing lispy code in
Lisp-1's, but it has seemed forever bizarre to me that
CL evaluates expressions differently depending on where
in the expression it finds them, requires different forms
for binding different values to them, different syntax
for referring to their values depending on the type of
the value, etc. It gives me the same icky feeling as
type declarations in statically typed languages or
the way ancient BASIC's required prefix characters on
variables to tell you what type the variable was
supposed to be.
FWIW, in Lisp-1's I prefer to use 'list' for a list of
things, and 'make-list' for a function that makes a
list.
Bear
Ray Dillinger wrote:
> drewc wrote:
>
>> Pascal Costanza wrote:
>>
>>> Some people think that CL is much better wrt fundamental design
>>> decisions, like Lisp-n instead of Lisp-1.
>>
>>
>> The Lisp-n bit has got to be my favourite feature in CL. I've always
>> had trouble naming things that i feel should have the same name in
>> languages that use the same namespace for functions/variables/classes.
>>
>> (defvar list (list 1 2)) ;;a poor example.
>>
>> In a lisp-1 i'd use "lst", which, to me, reads as "first" in some
>> fonts and "lust" in others :) I find there are many cases where i want
>> to use the same name for things in different contexts , and my
>> language should allow me to do that. Functions, variables and classes
>> are different things!
> Except when they're all first-class and mutable, they're
> not. A function is just another value that a variable
> can be bound to as far as I'm concerned; I find the
> sharp-quote thing really annoying, because when I type
> the name of a function, dammnit, I mean the function!
To me, the name of the function and the function itself are different
things. Maybe, because i learned CL before any Lisp-1, this seems
natural to me... that a symbol may name different things, in different
packages, in different contexts etc. Regardless, i don't see it as a
major issue... the Lisp-n approach seems more flexible, but i can see
why someone may prefer a lisp-1.
Just like my first name, "Drew", refers to both a person named "Drew",
or the past tense of the verb "draw". This seems perfectly natural to
me, but it might be only because i'm aware i'm not a verb. :)
> Likewise, when I put an expression that evaluates to a
> function in the function position of a call, or the name
> of a variable that's been provided as an argument, what
> the hell else does the system think I could possibly
> mean?
I'm not sure it's the job of the system to figure out what you 'could
possibly mean'. I think its the job of the programmer to explain,
unambiguously, his intent to the system. A similar line of reasoning may
be "when i setf a variable i have not declared, it should be declared
and set to that value, what else could i have possibly meant?" It could
be just be a typo! I used to get bit by this sort of thing in Perl all
the time.
I'm not saying that, objectively, one is better then the other. There
are good arguments for both. Personally, i see the CL approach as more
powerful and flexible, which naturally requires more discipline on the
part of the user.
> Maybe it's because I started writing lispy code in
> Lisp-1's, but it has seemed forever bizarre to me that
> CL evaluates expressions differently depending on where
> in the expression it finds them, requires different forms
> for binding different values to them, different syntax
> for referring to their values depending on the type of
> the value, etc.
I don't have a problem with that personally. I think the difference
might be in how one views programming and programming languages. Those
with a mathematics backround may prefer something 'elegant', whereas
those (such as myself) that view source as 'Prose' rather than 'formula'
might prefer something that allows the expressiveness (and flexibility)
that a lisp-n gives us.
I think the parallel is natural language (or at least english/french
which are the only languages i have a great exposure to) where the same
'name' can refer to different 'values', depending on the context.
Usually, the distinction is between 'verb' and 'noun' (or function and
variable).
An example here might be 'google', which started out as a noun, but has
been 'verbed' (which is a verbed noun in itself :) ).
"Visit google and try to search for that X"
"Google that X".
The same name. But in the first position of the statement, 'google' is
a verb (just like CL). Obviously this is a very contrived example, but i
think it gets my point across. I imagine the symbol GOOGLE to have two
namespaces, the symbol-value is "http://google.ca", and the
symbol-function is '(lambda (x) (search-internet x :search-engine-url
google))' or whatever (and completly ignoring the fact that google has a
different value in the 'mathematics' package).
I use a similar reasoning for prefix maths.. when talking about a
calculation i usually say "Multiply 4 by 3" ((* 4 3)) rather than "4
multiplied by 3" (#I(4 * 3)).
> It gives me the same icky feeling as
> type declarations in statically typed languages or
> the way ancient BASIC's required prefix characters on
> variables to tell you what type the variable was
> supposed to be.
Ewww... it's not that bad :)
> FWIW, in Lisp-1's I prefer to use 'list' for a list of
> things, and 'make-list' for a function that makes a
> list.
FWIW I prefer that as well, even in a lisp-n.
--
Drew Crampsie
drewc at tech dot coop
"Never mind the bollocks -- here's the sexp's tools."
-- Karl A. Krueger on comp.lang.lisp
From: Peter Seibel
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <m2wtm5qwxs.fsf@gigamonkeys.com>
drewc <·····@rift.com> writes:
> Ray Dillinger wrote:
>> drewc wrote:
>>
>>> Pascal Costanza wrote:
>>>
>>>> Some people think that CL is much better wrt fundamental design
>>>> decisions, like Lisp-n instead of Lisp-1.
>>>
>>>
>>> The Lisp-n bit has got to be my favourite feature in CL. I've
>>> always had trouble naming things that i feel should have the same
>>> name in languages that use the same namespace for
>>> functions/variables/classes.
>>>
>>> (defvar list (list 1 2)) ;;a poor example.
>>>
>>> In a lisp-1 i'd use "lst", which, to me, reads as "first" in some
>>> fonts and "lust" in others :) I find there are many cases where i
>>> want to use the same name for things in different contexts , and my
>>> language should allow me to do that. Functions, variables and
>>> classes are different things!
>
>> Except when they're all first-class and mutable, they're
>> not. A function is just another value that a variable
>> can be bound to as far as I'm concerned; I find the
>> sharp-quote thing really annoying, because when I type
>> the name of a function, dammnit, I mean the function!
>
> To me, the name of the function and the function itself are different
> things. Maybe, because i learned CL before any Lisp-1, this seems
> natural to me... that a symbol may name different things, in different
> packages, in different contexts etc. Regardless, i don't see it as a
> major issue... the Lisp-n approach seems more flexible, but i can see
> why someone may prefer a lisp-1.
>
> Just like my first name, "Drew", refers to both a person named "Drew",
> or the past tense of the verb "draw". This seems perfectly natural to
> me, but it might be only because i'm aware i'm not a verb. :)
>
>
>> Likewise, when I put an expression that evaluates to a
>> function in the function position of a call, or the name
>> of a variable that's been provided as an argument, what
>> the hell else does the system think I could possibly
>> mean?
>
> I'm not sure it's the job of the system to figure out what you 'could
> possibly mean'. I think its the job of the programmer to explain,
> unambiguously, his intent to the system. A similar line of reasoning
> may be "when i setf a variable i have not declared, it should be
> declared and set to that value, what else could i have possibly
> meant?" It could be just be a typo! I used to get bit by this sort of
> thing in Perl all the time.
>
> I'm not saying that, objectively, one is better then the other. There
> are good arguments for both. Personally, i see the CL approach as more
> powerful and flexible, which naturally requires more discipline on the
> part of the user.
>
>> Maybe it's because I started writing lispy code in
>> Lisp-1's, but it has seemed forever bizarre to me that
>> CL evaluates expressions differently depending on where
>> in the expression it finds them, requires different forms
>> for binding different values to them, different syntax
>> for referring to their values depending on the type of
>> the value, etc.
>
> I don't have a problem with that personally. I think the difference
> might be in how one views programming and programming languages. Those
> with a mathematics backround may prefer something 'elegant', whereas
> those (such as myself) that view source as 'Prose' rather than
> formula' might prefer something that allows the expressiveness (and
> flexibility) that a lisp-n gives us.
>
> I think the parallel is natural language (or at least english/french
> which are the only languages i have a great exposure to) where the
> same 'name' can refer to different 'values', depending on the
> context. Usually, the distinction is between 'verb' and 'noun' (or
> function and variable).
>
> An example here might be 'google', which started out as a noun, but
> has been 'verbed' (which is a verbed noun in itself :) ).
>
> "Visit google and try to search for that X"
>
> "Google that X".
>
> The same name. But in the first position of the statement, 'google'
> is a verb (just like CL). Obviously this is a very contrived example,
> but i think it gets my point across. I imagine the symbol GOOGLE to
> have two namespaces, the symbol-value is "http://google.ca", and the
> symbol-function is '(lambda (x) (search-internet x :search-engine-url
> google))' or whatever (and completly ignoring the fact that google has
> a different value in the 'mathematics' package).
Actually not. The mathematical constant to which you presumably are
referring is a Googol. The Google guys are good at search, but bad at
spelling.
-Peeter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Peter Seibel <·····@gigamonkeys.com> wrote:
+---------------
| drewc <·····@rift.com> writes:
| > ... i think it gets my point across. I imagine the symbol GOOGLE to
| > have two namespaces, the symbol-value is "http://google.ca", and the
| > symbol-function is '(lambda (x) (search-internet x :search-engine-url
| > google))' or whatever (and completly ignoring the fact that google has
| > a different value in the 'mathematics' package).
|
| Actually not. The mathematical constant to which you presumably are
| referring is a Googol.
+---------------
FWIW, 1 googol == (expt 10 100)
+---------------
| The Google guys are good at search, but bad at spelling.
+---------------
According to <http://www.google.com/intl/en/corporate/history.html>,
"Google "a play on the word googol". It's obviously a deliberate
misspelling, since "googol" could not be trademarked, but "Google"
could be... and was! [C.f. "Orbitz", "Infiniti", "Netflix", etc.]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> +---------------
> | The Google guys are good at search, but bad at spelling.
> +---------------
>
> According to <http://www.google.com/intl/en/corporate/history.html>,
> "Google "a play on the word googol". It's obviously a deliberate
> misspelling, since "googol" could not be trademarked, but "Google"
> could be... and was! [C.f. "Orbitz", "Infiniti", "Netflix", etc.]
Gah. We've developed a corporate culture that encourages misspelling.
Still, I'm startled that they were able to claim "google" for themselves
after how many years of "barney google and snuffy smith" comics?
Anybody remember Barney Google? With the goo-goo-googley eyes? He
was a fireman(?) IIRC, always looking for this and that and the
other thing, and the running gag was that he was always finding
bizarre stuff that wasn't what he was looking for. I figured
Google the search engine had named themselves after him.
Bear
From: Kent M Pitman
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <ufyssrao5.fsf@nhplace.com>
Ray Dillinger <····@sonic.net> writes:
> Rob Warnock wrote:
>
> > +---------------
> > | The Google guys are good at search, but bad at spelling.
> > +---------------
> > According to <http://www.google.com/intl/en/corporate/history.html>,
> > "Google "a play on the word googol". It's obviously a deliberate
> > misspelling, since "googol" could not be trademarked, but "Google"
> > could be... and was! [C.f. "Orbitz", "Infiniti", "Netflix", etc.]
>
> Gah. We've developed a corporate culture that encourages misspelling.
Well, historically, there was never anything that was "correct spelling".
As I recall (someone correct me if I'm spreading mistruths here),
the obvious need for standardized spelling was recognized by Webster,
who just made a lot of arbitrary decisions.
Now maybe the public has an urge to just recanonicalize the spelling, but
I think they're just lazy and the trademarkers are just being dumb by
picking lazy spellings that get in the way of the rush to change "for"
into "4". If they picked LONGER and HARDER names like "Googoll",
"Infinnnitee", "Netphlicks", etc. this would probably never have been an
issue since the gradient went the other way.
I don't think the legal culture caused this. Laziness caused it.
The legal culture is just diving into rapidly moving traffic without looking.
Peter Seibel wrote:
> drewc <·····@rift.com> writes:
>
>
>>Ray Dillinger wrote:
>>
>>>drewc wrote:
>>>
>>>
>>>>Pascal Costanza wrote:
>>>>
>>>>
>>>>>Some people think that CL is much better wrt fundamental design
>>>>>decisions, like Lisp-n instead of Lisp-1.
>>>>
>>>>
>>>>The Lisp-n bit has got to be my favourite feature in CL. I've
>>>>always had trouble naming things that i feel should have the same
>>>>name in languages that use the same namespace for
>>>>functions/variables/classes.
>>>>
>>>>(defvar list (list 1 2)) ;;a poor example.
>>>>
>>>>In a lisp-1 i'd use "lst", which, to me, reads as "first" in some
>>>>fonts and "lust" in others :) I find there are many cases where i
>>>>want to use the same name for things in different contexts , and my
>>>>language should allow me to do that. Functions, variables and
>>>>classes are different things!
>>
>>>Except when they're all first-class and mutable, they're
>>>not. A function is just another value that a variable
>>>can be bound to as far as I'm concerned; I find the
>>>sharp-quote thing really annoying, because when I type
>>>the name of a function, dammnit, I mean the function!
>>
>>To me, the name of the function and the function itself are different
>>things. Maybe, because i learned CL before any Lisp-1, this seems
>>natural to me... that a symbol may name different things, in different
>>packages, in different contexts etc. Regardless, i don't see it as a
>>major issue... the Lisp-n approach seems more flexible, but i can see
>>why someone may prefer a lisp-1.
>>
>>Just like my first name, "Drew", refers to both a person named "Drew",
>>or the past tense of the verb "draw". This seems perfectly natural to
>>me, but it might be only because i'm aware i'm not a verb. :)
>>
>>
>>
>>>Likewise, when I put an expression that evaluates to a
>>>function in the function position of a call, or the name
>>>of a variable that's been provided as an argument, what
>>>the hell else does the system think I could possibly
>>>mean?
>>
>>I'm not sure it's the job of the system to figure out what you 'could
>>possibly mean'. I think its the job of the programmer to explain,
>>unambiguously, his intent to the system. A similar line of reasoning
>>may be "when i setf a variable i have not declared, it should be
>>declared and set to that value, what else could i have possibly
>>meant?" It could be just be a typo! I used to get bit by this sort of
>>thing in Perl all the time.
>>
>>I'm not saying that, objectively, one is better then the other. There
>>are good arguments for both. Personally, i see the CL approach as more
>>powerful and flexible, which naturally requires more discipline on the
>>part of the user.
>>
>>
>>>Maybe it's because I started writing lispy code in
>>>Lisp-1's, but it has seemed forever bizarre to me that
>>>CL evaluates expressions differently depending on where
>>>in the expression it finds them, requires different forms
>>>for binding different values to them, different syntax
>>>for referring to their values depending on the type of
>>>the value, etc.
>>
>>I don't have a problem with that personally. I think the difference
>>might be in how one views programming and programming languages. Those
>>with a mathematics backround may prefer something 'elegant', whereas
>>those (such as myself) that view source as 'Prose' rather than
>>formula' might prefer something that allows the expressiveness (and
>>flexibility) that a lisp-n gives us.
>>
>>I think the parallel is natural language (or at least english/french
>>which are the only languages i have a great exposure to) where the
>>same 'name' can refer to different 'values', depending on the
>>context. Usually, the distinction is between 'verb' and 'noun' (or
>>function and variable).
>>
>>An example here might be 'google', which started out as a noun, but
>>has been 'verbed' (which is a verbed noun in itself :) ).
>>
>>"Visit google and try to search for that X"
>>
>>"Google that X".
>>
>>The same name. But in the first position of the statement, 'google'
>>is a verb (just like CL). Obviously this is a very contrived example,
>>but i think it gets my point across. I imagine the symbol GOOGLE to
>>have two namespaces, the symbol-value is "http://google.ca", and the
>>symbol-function is '(lambda (x) (search-internet x :search-engine-url
>>google))' or whatever (and completly ignoring the fact that google has
>>a different value in the 'mathematics' package).
>
>
> Actually not. The mathematical constant to which you presumably are
> referring is a Googol. The Google guys are good at search, but bad at
> spelling.
Damn it, and i thought i was being clever :)
drewc
>
> -Peeter
>
--
Drew Crampsie
drewc at tech dot coop
"Never mind the bollocks -- here's the sexp's tools."
-- Karl A. Krueger on comp.lang.lisp
> Well, we need REVERSE and NREVERSE, granted? So we need some kind of
> idiom anyway. But I don't like the prefixed 'N', because it doesn't
> look nice when I write my *own* destructive functions. I end up putting
> the exclamation mark, which is inconsistent with the rest of Common
> Lisp and thus ugly.
Please, stop complaining!
Nothing prevents you to use another package than "COMMON-LISP"!
(defpackage "COMMON-LISP-WITH-MY-NAMING-CONVENTIONS"
(:nickname "MY-CL")
(:use-package "COMMON-LISP"))
(in-package "COMMON-LISP-WITH-MY-NAMING-CONVENTIONS")
(defun list-external-symbols (package &key (sorted t))
(let ((pack (find-package package)))
(if pack
(let ((sl '())) (do-external-symbols (s pack) (push s sl))
(if sorted (sort sl (function string<)) sl))
(error "No package ~S" package))))
(export (set-difference (list-external-symbols "COMMON-LISP" :sorted nil)
'(nreverse #|...|#)))
(export '(reverse! #|...|#))
(setf (symbol-function 'reverse!) (symbol-function nreverse))
(setf (documentation 'reverse! 'function) (documentation 'nreverse 'function))
;; ...
(defpackage "MY-PROGRAM"
(USE "MY-CL"))
(in-package "MY-PROGRAM")
(defparameter *exemple* (reverse! (list 1 2 3)))
By the way, DEFUN changes the state too. Mind renaming it: DEFUN! !
--
__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/
Um, why go to all that effort when I can just:
(defun reverse! (seq)
(nreverse seq))
Anyway, never mind that. You're right, of course. I should change Lisp,
not expect it to change for me. All I'm saying is that if I were given
a choice between two equivalent Common Lisps, except one used the
exclamation mark, I know which one I would choose. This is not as
strong an opinion as "using N to indicate destructive functions really
sucks and I hate it!" It's just a small grievance.
Pascal Bourguignon wrote:
> > Well, we need REVERSE and NREVERSE, granted? So we need some kind of
> > idiom anyway. But I don't like the prefixed 'N', because it doesn't
> > look nice when I write my *own* destructive functions. I end up putting
> > the exclamation mark, which is inconsistent with the rest of Common
> > Lisp and thus ugly.
>
> Please, stop complaining!
>
> Nothing prevents you to use another package than "COMMON-LISP"!
>
>
> (defpackage "COMMON-LISP-WITH-MY-NAMING-CONVENTIONS"
> (:nickname "MY-CL")
> (:use-package "COMMON-LISP"))
> (in-package "COMMON-LISP-WITH-MY-NAMING-CONVENTIONS")
>
> (defun list-external-symbols (package &key (sorted t))
> (let ((pack (find-package package)))
> (if pack
> (let ((sl '())) (do-external-symbols (s pack) (push s sl))
> (if sorted (sort sl (function string<)) sl))
> (error "No package ~S" package))))
>
> (export (set-difference (list-external-symbols "COMMON-LISP" :sorted nil)
> '(nreverse #|...|#)))
> (export '(reverse! #|...|#))
> (setf (symbol-function 'reverse!) (symbol-function nreverse))
> (setf (documentation 'reverse! 'function) (documentation 'nreverse 'function))
> ;; ...
>
> (defpackage "MY-PROGRAM"
> (USE "MY-CL"))
> (in-package "MY-PROGRAM")
> (defparameter *exemple* (reverse! (list 1 2 3)))
>
>
> By the way, DEFUN changes the state too. Mind renaming it: DEFUN! !
>
>
> --
> __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/
From: Edi Weitz
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <ur7dzfzwd.fsf@agharta.de>
On 15 Jul 2005 15:35:42 -0700, "Tron3k" <······@gmail.com> wrote:
> Um, why go to all that effort when I can just:
>
> (defun reverse! (seq)
> (nreverse seq))
Because then you'd still have the ugly NREVERSE hanging around. Plus,
you don't want to export new symbols from the COMMON-LISP package.
Plus, your definition of REVERSE! adds another function call while
Pascal's doesn't.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Anyway this is all academic. I'm not actually going to do it. ;)
Tron3k
Edi Weitz wrote:
> On 15 Jul 2005 15:35:42 -0700, "Tron3k" <······@gmail.com> wrote:
>
> > Um, why go to all that effort when I can just:
> >
> > (defun reverse! (seq)
> > (nreverse seq))
>
> Because then you'd still have the ugly NREVERSE hanging around. Plus,
> you don't want to export new symbols from the COMMON-LISP package.
> Plus, your definition of REVERSE! adds another function call while
> Pascal's doesn't.
>
> Cheers,
> Edi.
>
> --
>
> Lisp is not dead, it just smells funny.
>
> Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: André Thieme
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <dba3vc$fc6$1@ulric.tng.de>
Pascal Bourguignon schrieb:
> By the way, DEFUN changes the state too. Mind renaming it: DEFUN! !
Tron3k wanted functions to end with a !.
However, I doubt that all Lispers would follow this route and also use
the !-convention in their own programs which would make them harder to
read and reuse when other people expect the !.
Andr�
--
From: Pascal Costanza
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <3jr16fFrgjmgU1@individual.net>
Tron3k wrote:
> Pascal Costanza wrote:
>
>>Tron3k wrote:
>>
>>>I would like to see:
>>>
>>>- Predicates changed to end in '?' and destructive functions changed to
>>>end in '!', just like Scheme
>>
>>Doesn't solve a problem, would just make old code unnecessarily
>>incompatible.
>
> I'm really talking about what I want in my ideal Lisp.
Incompatibility? ;-)
The OP asked for proposed changes to the Common Lisp standard. Common
Lisp has set some rules in its beginning, one of the important being
that incompatible changes should be avoided unless they actually improve
the language. That's why I have objected to your suggestion.
> Well, we need REVERSE and NREVERSE, granted? So we need some kind of
> idiom anyway. But I don't like the prefixed 'N', because it doesn't
> look nice when I write my *own* destructive functions. I end up putting
> the exclamation mark, which is inconsistent with the rest of Common
> Lisp and thus ugly.
NREVERSE exists because REVERSE is already taken. REMOVE and DELETE
don't follow that naming convention.
I really think that side-effect free functions are not special enough
that everything else should be marked in some way. There are lots of
other characteristics of programs that are sometimes more important. If
we added nameing conventions for each and every aspect, we would end up
with a pretty horrible mess. (Reminds me of Hungarian notation.)
What if in the development process I change my mind about whether a
function is free of side effects or not? Do cache updates qualify as
side effects? Functions that merely memoize results are still
composable, right? Why worry about these things when they may not be
important?
>>>- A standardized foreign function interface
>>
>>Foreign function interface look very different depending on what the
>>foreign language is. For example, an FFI for Java or C# can be much
>>simpler than an FFI for C or C++. So it's hard to understand what you
>>actually mean by "standardized" here without further qualification. (Do
>>you mean "a standardized FFI for C as compiled by gcc on typical Unix
>>systems"?!? Yuck! ;)
>
> Hmm, what's UFFI then?
...something that people care enough about so that it has apparently
become a defacto standard. Doesn't mean that it's good enough to be
added to the Common Lisp specification.
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Pascal Costanza wrote:
> Tron3k wrote:
> > Pascal Costanza wrote:
> >
> >>Tron3k wrote:
> >>
> >>>I would like to see:
> >>>
> >>>- Predicates changed to end in '?' and destructive functions changed to
> >>>end in '!', just like Scheme
> >>
> >>Doesn't solve a problem, would just make old code unnecessarily
> >>incompatible.
> >
> > I'm really talking about what I want in my ideal Lisp.
>
> Incompatibility? ;-)
>
> The OP asked for proposed changes to the Common Lisp standard. Common
> Lisp has set some rules in its beginning, one of the important being
> that incompatible changes should be avoided unless they actually improve
> the language. That's why I have objected to your suggestion.
I see. :-) I was thinking too far in the future, like what Lisp will be
like in 20 years, maybe. I didn't realize we were limiting our scope.
> > Well, we need REVERSE and NREVERSE, granted? So we need some kind of
> > idiom anyway. But I don't like the prefixed 'N', because it doesn't
> > look nice when I write my *own* destructive functions. I end up putting
> > the exclamation mark, which is inconsistent with the rest of Common
> > Lisp and thus ugly.
>
> NREVERSE exists because REVERSE is already taken. REMOVE and DELETE
> don't follow that naming convention.
>
> I really think that side-effect free functions are not special enough
> that everything else should be marked in some way. There are lots of
> other characteristics of programs that are sometimes more important. If
> we added nameing conventions for each and every aspect, we would end up
> with a pretty horrible mess. (Reminds me of Hungarian notation.)
>
> What if in the development process I change my mind about whether a
> function is free of side effects or not? Do cache updates qualify as
> side effects? Functions that merely memoize results are still
> composable, right? Why worry about these things when they may not be
> important?
Well, here's what I think. You're pretty much right. I just think that
sometimes, not THAT often, you have a pair of functions, one with
side-effects and one without, but both do the same thing. That's the
only time we would use any side-effects idiom. We wouldn't use it for
DEFUN, for example. :-)
> >>>- A standardized foreign function interface
> >>
> >>Foreign function interface look very different depending on what the
> >>foreign language is. For example, an FFI for Java or C# can be much
> >>simpler than an FFI for C or C++. So it's hard to understand what you
> >>actually mean by "standardized" here without further qualification. (Do
> >>you mean "a standardized FFI for C as compiled by gcc on typical Unix
> >>systems"?!? Yuck! ;)
> >
> > Hmm, what's UFFI then?
>
> ...something that people care enough about so that it has apparently
> become a defacto standard. Doesn't mean that it's good enough to be
> added to the Common Lisp specification.
>
You're right.
Tron3k <······@gmail.com> wrote:
+---------------
| I see. :-) I was thinking too far in the future, like what Lisp will be
| like in 20 years, maybe. I didn't realize we were limiting our scope.
+---------------
Another mere 20 years is *much* too soon to be throwing away the
lessons of a language that is already more than 45 years old.
"Progress, far from consisting in change, depends on retentiveness.
Those who cannot remember the past are condemned to repeat it."
-- George Santayana, "The Life of Reason" (1905)
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Joe Marshall
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <hdevon8l.fsf@ccs.neu.edu>
Pascal Costanza <··@p-cos.net> writes:
> Furthermore, what's so special about side effects that function names
> should end in a bang?
They don't commute over sequencing. Pure functions do.
From: Matthias Buelow
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <3jq804Fr0oifU1@news.dfncis.de>
Pascal Costanza <··@p-cos.net> wrote:
>(Furthermore, what's so special about side effects that function names
>should end in a bang? Here is another suggestion: Functions that consist
Well.. I assume that Scheme goes with the general functional language
dictum that side effects are generally Evil and hence the programmer
should be warned when he uses mutating procedures (hence the !).
mkb.
From: Pascal Costanza
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <3jqchgFr6b3qU1@individual.net>
Matthias Buelow wrote:
> Pascal Costanza <··@p-cos.net> wrote:
>
>>(Furthermore, what's so special about side effects that function names
>>should end in a bang? Here is another suggestion: Functions that consist
>
> Well.. I assume that Scheme goes with the general functional language
> dictum that side effects are generally Evil and hence the programmer
> should be warned when he uses mutating procedures (hence the !).
I know. I just don't like languages that pretend they know what's best
for me. That's anti-enlightening.
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
>> - A standardized foreign function interface
Pascal Costanza <··@p-cos.net>:
> Foreign function interface look very different depending on what the
> foreign language is. For example, an FFI for Java or C# can be much
> simpler than an FFI for C or C++. So it's hard to understand what
> you actually mean by "standardized" here without further qualification.
Communicating with the outer world is obviously dependent on what the
outer world is like, and any language standard that allows portable
communication with outside makes assumptions on the nature of outside.
(Think about how Common Lisp streams, for example, are general enough
for manipulating both Unix and Windows files, but not VMS files.)
A portable Common Lisp FFI needs to be general enough to deal with the
FFI needs of a large majority of Common Lisp users, but no more
general than that. I haven't thought about it seriously, but this
probably means:
- being able to interact with C on implementations where this is needed;
- being able to interact with Java/C# on implementations where this
is needed;
- being able to interact with foreign threads and blocking foreign
functions on implementations where Lisp threads are not OS threads;
- being able to efficiently interface with foreign functions on
implementations where this makes sense.
In particular, this probably means that such an FFI will require the
programmer to provide information that is ignored by most imple-
mentations. For example, it will probably be necessary to mark
foreign functions as blocking, although non-threaded implementations
will ignore such decorations.
Juliusz
From: Sam Steingold
Subject: Re: Portable FFI [was: How do you imagine future Common Lisp standard ?]
Date:
Message-ID: <uoe8xsbw0.fsf@gnu.org>
> * Juliusz Chroboczek <···@ccf.whffvrh.se> [2005-07-20 17:00:29 +0200]:
>
> In particular, this probably means that such an FFI will require the
> programmer to provide information that is ignored by most imple-
> mentations. For example, it will probably be necessary to mark
> foreign functions as blocking, although non-threaded implementations
> will ignore such decorations.
a nice thing is that such a "Common CL FFI" would allow C programmers to
use a standard formal language to document their functions in a deeper
way than what C allows.
E.g., instead of
/* returns the value in the location pointed to by the argument */
void foo (int*);
one could write
(def-call-out foo
(:arguments (val (c-ptr int) :out))
(:return-type nil))
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.openvotingconsortium.org/> <http://www.jihadwatch.org/>
<http://www.honestreporting.com> <http://www.dhimmi.com/>
Ph.D. stands for "Phony Doctor" - Isaak Asimov, Ph.D.
From: Joerg Hoehle
Subject: Re: Portable FFI [was: How do you imagine future Common Lisp standard ?]
Date:
Message-ID: <uk6jihk18.fsf@users.sourceforge.net>
Sam Steingold <···@gnu.org> writes:
> use a standard formal language to document their functions in a deeper
> way than what C allows.
> void foo (int*);
> one could write
> (def-call-out foo
> (:arguments (val (c-ptr int) :out))
> (:return-type nil))
True, but that catches only one scenario (likely the most used
one). It does not cover the case where one *wants* to pass a pointer
(obtained elsewhere) for that int*.
A hypothetical CL-POSIX API will face similar problems: it's likely to
provide interfaces that e.g. use Lisp strings, but doing so will
disallow passing foreign pointers to the foreign functions.
There's a difference between
(:arguments (val c-string)) and
(:arguments (val c-pointer))
Many Lisp implementations will not allow passing one for the other.
C has the distinguishing advantage that it's sort of polymorphic. Cast
and pointers everywhere.
And I did not even mention the difficulty that some (arguable broken
in their semantics) C APIs allow NULL to be passed as val pointer.
(val (c-ptr int) :out) will invariably pass a non-NULL pointer.
Regards,
Jorg Hohle
Telekom/T-Systems Technology Center
From: Sam Steingold
Subject: Re: Portable FFI [was: How do you imagine future Common Lisp standard ?]
Date:
Message-ID: <uhdemk73e.fsf@gnu.org>
> * Joerg Hoehle <······@hfref.fbheprsbetr.arg> [2005-07-22 18:39:47 +0200]:
>
> Sam Steingold <···@gnu.org> writes:
>> use a standard formal language to document their functions in a deeper
>> way than what C allows.
>> void foo (int*);
>> one could write
>> (def-call-out foo
>> (:arguments (val (c-ptr int) :out))
>> (:return-type nil))
>
> True, but that catches only one scenario (likely the most used
> one). It does not cover the case where one *wants* to pass a pointer
> (obtained elsewhere) for that int*.
;; pass the pointed as is:
(def-call-out foo
(:arguments (val (c-ptr int)))
(:return-type nil))
;; pass the pointer and return its value
(def-call-out foo
(:arguments (val (c-ptr int) :io))
(:return-type nil))
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://pmw.org.il/> <http://www.memri.org/> <http://www.camera.org>
<http://www.dhimmi.com/> <http://ffii.org/> <http://www.mideasttruth.com/>
War doesn't determine who's right, just who's left.
From: Sam Steingold
Subject: Re: Portable FFI [was: How do you imagine future Common Lisp standard ?]
Date:
Message-ID: <ubr4uk70d.fsf@gnu.org>
> * Joerg Hoehle <······@hfref.fbheprsbetr.arg> [2005-07-22 18:39:47 +0200]:
>
> And I did not even mention the difficulty that some (arguable broken
> in their semantics) C APIs allow NULL to be passed as val pointer.
> (val (c-ptr int) :out) will invariably pass a non-NULL pointer.
(val (c-ptr int) :out :optional)
val can be either
NIL (pass NULL to C) or
T (just like (val (c-ptr int) :out): pass pointer to a stack var) or
(c-ptr in) (pass this pointer)
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.honestreporting.com> <http://www.jihadwatch.org/>
<http://www.camera.org> <http://ffii.org/> <http://www.memri.org/>
Those who value Life above Freedom are destined to lose both.
From: Björn Lindberg
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <42d7d77d@news.cadence.com>
Tron3k wrote:
> I would like to see:
>
> - Predicates changed to end in '?' and destructive functions changed to
> end in '!', just like Scheme
(defun (setf foo)! (bar baz)
...)
Hm...
> - A function for splitting sequences
It's not _that_ hard to write you know.
Bj�rn
From: Robert Maas, see http://tinyurl.com/uh3t
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <REM-2005jul27-011@Yahoo.Com>
> From: "Tron3k" <······@gmail.com>
> - Predicates changed to end in '?' and destructive functions changed
> to end in '!', just like Scheme
Hmm, that's one idea. Another idea is to make it more English-like, for
example instead of primep or prime? make it is-prime, and instead of
nchange or change! make it change-ip where ip means in-place (as
opposed to copying). Until everyone agrees on the standard, I suggest
you make your own package that inherits all such symbols from LISP
package, and see if the change in notation makes it (1) easier for you
to write your own software, and (2) easier to teach the language to
beginners.
- A standardized foreign function interface
If you can figure out how to parameterize all the various FFIs for each
different language, starting with the C interface but also including
interfaces to many languages that aren't compatible with C interface,
so that with just a change of parameter you can call a C function or a
function using another calling convention while not changing that basic
form of function call, that would be nice.
- A function for splitting sequences
That spec is grossly vague. What exactly do you mean? Please provide a
few examples of what kinds of splits you propose. For example, do you
mean a one-level split per some delimiter, as with Java's string
tokenizer class, or a more smart split that recognizes special syntax
such as the tokenizer in Lisp where "..." is recognzed as a single
token regardless of any delimiters within the string, or do you mean a
full parser such as lexx etc. might provide?
- Eventually make it a Lisp-1
Bad idea! Do I need to explain why?
From: Matthias Buelow
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <3kqdqfFvlt5mU3@news.dfncis.de>
Robert Maas, see http://tinyurl.com/uh3t <·······@yahoo.com> wrote:
>but also including
>interfaces to many languages that aren't compatible with C interface,
Which are?
mkb.
Matthias Buelow wrote:
> Robert Maas, see http://tinyurl.com/uh3t <·······@yahoo.com> wrote:
>
>
>>but also including
>>interfaces to many languages that aren't compatible with C interface,
>
>
> Which are?
Ever tried to pass an array back and forth from Fortran?
Cheers
--
Marco
From: Matthias Buelow
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <3ks6blF100dcsU1@news.dfncis.de>
Marco Antoniotti <·······@cs.nyu.edu> wrote:
>Ever tried to pass an array back and forth from Fortran?
When did you last link Lisp against Fortran?
mkb.
Matthias Buelow wrote:
> Marco Antoniotti <·······@cs.nyu.edu> wrote:
>
>
>>Ever tried to pass an array back and forth from Fortran?
>
>
> When did you last link Lisp against Fortran?
>
Matlisp does all the time. Some time ago I tried to link in the LSODE
solver. I brought the issue up because there is quite an impedance
between Fortran and CL. (Also between C and Fortran for what matters)
Cheers
--
marco
From: Kent M Pitman
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <u1x5jge0d.fsf@nhplace.com>
·······@Yahoo.Com (Robert Maas, see http://tinyurl.com/uh3t) writes:
> > From: "Tron3k" <······@gmail.com>
> > - Predicates changed to end in '?' and destructive functions changed
> > to end in '!', just like Scheme
One subtle reason that ? and ! aren't used in CL is to keep them from
being used up as potential macro characters. The more characters that
everyone has to use all the time, the fewer available for interesting
specialized applications. Scheme doesn't focus on good macro
character support as a basic need of programmers, so ends up making
different decisions. Once again evidence of my oft-made point that
Goodness and Badness must be evaluated in a particular design-space
context, not in isolation.
Also, I personally find the notion of "!" on words the same level of
out-of-control screaming as many others seem to feel about
all-uppercase. People who DON'T use these operators are the ones that
seem to want them marked; the people who do use them often feel they
aren't as dangerous as the people who do. Personally, I find excess
consing a lot more "dangerous" in practice than re-linking a data
structure as part of a thoughtful algorithm.
> - A standardized foreign function interface
I agree this is powerful/useful, and that compatibility would be a
win. It's fortunate that this can be done without change to the standard,
and hence doesn't have to be part of a future _CL_ standard--it can be
added as a layered standard.
> - A function for splitting sequences
The set of useful library functions is unending.
When we designed CL, we referred to the design as the "white pages"
and intended this stuff to appear in the "yellow pages" (by analogy
with phone books, where the "commerce" in useful stuff was to be done
outside of it).
In fact, splitting sequences is enough important that having multiple
ways to do it subject to different constraints is probably also good,
which makes it possibly not such a good candidate for a standard.
(But then, I argued against having a standardized EQUAL function, too,
for similar reasons.)
> - Eventually make it a Lisp-1
There's no point in making Common Lisp a Lisp-1, since that would be such
a big change as to completely change the language, and hence the user base.
Once you've done that, you might as well have just designed something new.
There's no reason to define the old language away, since you can already
do that by consing a new language with such cool new stuff that people leave
voluntarily.
Everyone who's interested in this issue--or even is just studying the
US Supreme Court battle now ongoing--should become familiar with the term
"stare decisis" and its underlying rationale. Here's a pretty good simple
explanation as a starting point, which does a good job of summarizing the
rationale:
http://www.lectlaw.com/def2/s065.htm
Wiki ( http://en.wikipedia.org/wiki/Stare_decisis ) has more detail, but
makes it harder to find the "take home messages".
As for making forward progress on the lisp1/lisp2 debate,
I'm just a bit sad that Tron3K isn't studying my Half-Baked stuff,
which advocates a Lisp-Omega approach that I believe ought to be both
mathematically elegant and potentially encompassing of both dialects.
My stabs at it were limited in scope and may or may not be comprehensible,
but I am available to answer questions about the concepts.
Whether following my work directly or just doing something else in the same
space, it would at least be "new work" of an interesting kind. Trying to
use "power plays" to perturb a community from one core idea to another
isn't really a good idea.
I've played with Python a little bit and i
definately don't like Lisp to be like it .
Parenthesis might not look very cool but they are very practical.
What else to committee obviously done
a better job than i can imagine .
From: Pascal Costanza
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <3jpmn3Fr7b1cU1@individual.net>
·············@hotmail.com wrote:
> Ok since everybody here have some time to waste i decided to start this
> time
> killing game :
> Rules are simple:
> List all thing you want added , removed, modified for the new Common
> Lisp standard with brief explanations?
> Especially i want to heard things from those seeking for wanna be
> languages ?
> Maybe they have some brilliant idea ?
> Will organize voting at some of the forum who has support for it.
See http://www.cliki.net/Proposed%20Extensions%20To%20ANSI and
http://www.cliki.net/Lisp%20-%20Next%20Generation
(In other words, no need to discuss these things here.)
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
·············@hotmail.com writes:
> List all thing you want added , removed, modified for the new Common
> Lisp standard with brief explanations?
http://www.cliki.net/Proposed%20Extensions%20To%20ANSI
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools:
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
I started this thread to see what Lisp newbies
expect from Lisp , not what an seasoned Lisp programmers
want for the next standard.
When i started learning Lisp i was bugged by too many
parenthesis , i wanted someway of omitting them or reducing as much i
could
(Or like Graham wrote at Ansi Common LIsp)
defun our-member (obj lst)
if null lst
nil
if eql (car lst) obj
lst
our-member obj (cdr lst)
Get yourself a decent text editor and learn how to use it, and you
won't want this anymore. If constantly typing Shift [90] is too
strenuous for you hands, remap your keys so that the brackets are
swapped with the parentheses. You never need to count parentheses.
That's the editor's job.
Whitespace sensitive indentation has been done (google for srfi-49,
while noting that it's one of the few srfi's that never made it out of
"draft" status), but it hasn't caught on because it's unnecessary.
Here here. I used to think it might be a good idea to try and remove
the need for some of the parenthesis, but since doing a lot of coding
with emacs I've found the following:-
editing lisp code in an editor which doesn't help you that much is
considerably harder than editing code in most other languages, but...
editing lisp code in emacs [for example] is _much_ easier than editing
code in any other language in any other text editor.
I've swapped my parens and square brackets, since I use square brackets
very rarely. It's a great help, though its a pain to use other people's
keyboards :) I also have emacs put in close parens when I press the
open paren key and skip over close parens and reindent the line when I
press close paren. It makes it really easy editing lisp - I almost
never have to think about indentation or parenthesis. I now find
editing perl code rather cumbersome.
The really great thing, though, is how easy it is to rearrange lisp
code in terms of complete expressions - to do things like empty out the
body of a lisp form; throw a loop around a bunch of statements or swap
the true/false parts of a test. (I have M-t swap sexps rather than
words)
I now find the simple syntax and parenthesis of lisp to be a really big
win.
(hmm, that seems a bit out of context. It was meant to be a reply to a
previous post about getting a decent editor...)
From: Ulrich Hobelmann
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <3jpsqgFrau4mU1@individual.net>
·············@hotmail.com wrote:
> I started this thread to see what Lisp newbies
> expect from Lisp , not what an seasoned Lisp programmers
> want for the next standard.
Well, since Lisp newbies started looking at Lisp, I assume that
they see something in it ;)
Otherwise they'd just hack their own langugage, wouldn't they?
> When i started learning Lisp i was bugged by too many
> parenthesis , i wanted someway of omitting them or reducing as much i
> could
> (Or like Graham wrote at Ansi Common LIsp)
>
> defun our-member (obj lst)
> if null lst
> nil
> if eql (car lst) obj
> lst
> our-member obj (cdr lst)
>
That only works in a language like Rebol where you know how many
arguments a function takes.
I'd rather go along the lines of Paul Graham's Arc, where he
reduces the () usage of common operators, like LET or COND.
Anyway, take Lisp's ()s as a feature. They save you having to
deal with ,s {}s []s and ;s and lots of ML-style or Pascal-style
keywords (whether or not that's a good thing).
And by introducing ' ` and , Lisp allows you to write macros,
unlike other languages (C macros and C++ templates don't count).
--
XML is a prime example of retarded innovation.
-- Erik Meijer and Peter Drayton, Microsoft Corporation
From: Joe Marshall
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <oe94nhf1.fsf@ccs.neu.edu>
> ·············@hotmail.com wrote:
>> When i started learning Lisp i was bugged by too many
>> parenthesis , i wanted someway of omitting them or reducing as much i
>> could
>> (Or like Graham wrote at Ansi Common LIsp)
>> defun our-member (obj lst)
>> if null lst
>> nil
>> if eql (car lst) obj
>> lst
>> our-member obj (cdr lst)
>>
Ulrich Hobelmann <···········@web.de> writes:
> That only works in a language like Rebol where you know how many
> arguments a function takes.
And it turns out to be a bad idea. Not only does it greatly
complicate the interpreter and compiler, it turns out to be rather
*un*readable in practice. As an example, here is a line from the
REBOL BBS tutorial:
update-topic topic-id length? msgs first last msgs
certainly REBOL knows how many arguments each function takes (and
which of those identifiers refer to functions), but if *you* don't
know, you can't parse it.
From: Robert Uhl
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <m38y077u5u.fsf@4dv.net>
Ulrich Hobelmann <···········@web.de> writes:
> > defun our-member (obj lst)
> > if null lst
> > nil
> > if eql (car lst) obj
> > lst
> > our-member obj (cdr lst)
>
> That only works in a language like Rebol where you know how many
> arguments a function takes.
I don't know about that. What about these rules:
o a symbol on a line by itself evaluates to that symbol's value
o a line with multiple symbols indicates a function call (or the start
thereof)
o use parentheses to call a function with no args, and to call functions
within a line
o indentation is significant; it is used to terminate multi-line list
o otherwise syntax is like CL
So the above example would become:
defun our-member (obj list)
if (null list)
nil
if (eql (car list) obj)
list
our-member obj (cdr list)
I _think_ those rules should be unambiguous.
--
Robert Uhl <http://public.xdi.org/=ruhl>
...at the end of the conversation, the guy said `Thanks a lot for
reporting this. If you need more details on our anti-spam policies,
just hit 'refresh' on the URL you reported.'
--Willondon Donovan in nanae
From: Joe Marshall
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <vf3bwsur.fsf@comcast.net>
Robert Uhl <·········@NOSPAMgmail.com> writes:
> What about these rules:
>
> o a symbol on a line by itself evaluates to that symbol's value
> o a line with multiple symbols indicates a function call (or the start
> thereof)
> o use parentheses to call a function with no args, and to call functions
> within a line
> o indentation is significant; it is used to terminate multi-line list
> o otherwise syntax is like CL
Ugh.
> So the above example would become:
>
> defun our-member (obj list)
> if (null list)
> nil
> if (eql (car list) obj)
> list
> our-member obj (cdr list)
>
> I _think_ those rules should be unambiguous.
Yep. Unambiguous.
--
~jrm
Here is a column based list representation --
http://www.kantz.com/jason/programs/ergono/ -- that I was into for a
while, but dropped.
I think there is definitely a gap to be crossed for newbies when it
comes to editing lisp code. When I was a fledgling I didn't really
understand the benefit of parens and the speed in which one can make
extensive changes to lisp code, until I observed someone do it with
emacs.
There is the refrain that experienced lisp programmers no longer see
the parens. With all the editor commands that operate on lists
(explode list, down list, up list, Insert (), etc.) one can also
approach the state of no longer typing parens. So the idea of a
structured editor and a structured list representation has a bit of an
appeal to me.
I've found that the repetitive key combinations for list editing
commands aren't the most ergonomic of things for my hands and wrists
(although my beloved Kinesis which puts ctrl and alt on the thumbs
helps). A recent transient interest is auditing my lisp editing --
http://www.kantz.com/jason/programs/lispworks-key-audit.lisp -- and
writing a program that finds repetitive patterns that should be
abstracted into shortcuts.
Ulrich Hobelmann <···········@web.de> writes:
> ·············@hotmail.com wrote:
>> I started this thread to see what Lisp newbies
>> expect from Lisp , not what an seasoned Lisp programmers
>> want for the next standard.
>
> Well, since Lisp newbies started looking at Lisp, I assume that they
> see something in it ;)
>
> Otherwise they'd just hack their own langugage, wouldn't they?
>
>> When i started learning Lisp i was bugged by too many
>> parenthesis , i wanted someway of omitting them or reducing as much i
>> could
>> (Or like Graham wrote at Ansi Common LIsp)
>> defun our-member (obj lst)
>> if null lst
>> nil
>> if eql (car lst) obj
>> lst
>> our-member obj (cdr lst)
>>
>
> That only works in a language like Rebol where you know how many
> arguments a function takes.
That said, there are 338 functions, macros or special operators in
COMMON-LISP that have a fixed number of arguments, therefore for which
parentheses can be deduced automatically.
One could write a FIXARY-CL package to even increase that number.
And of the remaining variadic operators, most have keywords, so the
end of the argument lists can be defined as the occurence of a non
KEYWORD symbol where a keyword was expected, or even as the occurence
as anything else than one of the expected keywords.
A possibility is to adopt an hybrid approach where the editor will
automagically insert the parentheses for you.
See: pjb-cl-magic.el from:
http://www.informatimago.com/develop/emacs/index.html
--
__Pascal Bourguignon__ http://www.informatimago.com/
This is a signature virus. Add me to your signature and help me to live
Rebol , very nice little scripting language
thugh i didn't done any serious thing with it.
My proposition was from the beginning of
my Lisp coding , i don't mind parens too
much presently.
Also i hated the very-long-and-descriptive-names
than , but nowdays i found them helping
especially in the long problems.
Anyway i didn't see many suggestions except from
Tron3k . It looks like that many want a new lisp
but they don't know what it should look like.
From: Ulrich Hobelmann
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <3jskaeFrl54qU1@individual.net>
·············@hotmail.com wrote:
> Anyway i didn't see many suggestions except from
> Tron3k . It looks like that many want a new lisp
> but they don't know what it should look like.
Maybe not seeing many suggestions means that the rest doesn't
really want a new lisp ;)
I think languagewise CL is really good as it is, except that it's
lacking in terms of modular coding (IMHO), and maybe binary
linking, and FFIs. The tools could be better, too (but that
requires a good module system, IMHO).
Add to that some smaller features, but those can easily written as
macros or functions by those who need them.
--
XML is a prime example of retarded innovation.
-- Erik Meijer and Peter Drayton, Microsoft Corporation
·············@hotmail.com wrote:
> Rebol , very nice little scripting language
> thugh i didn't done any serious thing with it.
>
> My proposition was from the beginning of
> my Lisp coding , i don't mind parens too
> much presently.
>
> Also i hated the very-long-and-descriptive-names
> than , but nowdays i found them helping
> especially in the long problems.
Most languages embed a lot of meaning in
punctuation and syntax that Lispy languages
don't have. I mean, face it: Our punctuation
consists exclusively of parentheses and our
syntax, beyond read/write syntax for data
constants, looks exactly like function calls.
Lisp is so dynamic, that depending on bindings,
it's possible for almost any arbitrary
expression to mean almost anything. Imagine
how horrible debugging lisp would be if all
the functions and syntax and variables had
two-character names that had nothing to do
with their use or purpose. Good programmers
prevent a slide into chaos by assigning
descriptive names and writing descriptive
comments.
I think the longer names reflect the fact
that the syntax of Lisp provides less support
for seeing what's actually going on than the
syntax of other languages.
> Anyway i didn't see many suggestions except from
> Tron3k . It looks like that many want a new lisp
> but they don't know what it should look like.
Heh. I've got a pretty good idea. So does
Paul Graham if you can get him to talk about
it.
Bear
> ·············@hotmail.com wrote:
>> Anyway i didn't see many suggestions except from
>> Tron3k . It looks like that many want a new lisp
>> but they don't know what it should look like.
Whilst I'm sure many want a new Lisp, not many want a _future Common
Lisp standard_ to be a new Lisp.
Common Lisp evolved by standardising upon the behaviour of descendents
of McCarthy's original Lisp. The ANSI standard evolved by standardising
upon the behaviour of implementations of Common Lisp. A future standard
will evolve by standardising upon the behaviour of implementations of
ANSI Common Lisp.
The principle is this: different vendors provide versions of Common Lisp
tailored for specific needs; with vendor-specific extensions to support
those needs. Extensions which turn out to be generally useful are likely
to be picked up by other vendors. Standardisation helps to collate
related widely used extensions and provide a standard interface to those
extensions so that they can be used in a portable manner.
As such, a future Common Lisp standard will likely only contain features
which are already available as extensions in existing implementations of
Common Lisp.
I _imagine_ a future Common Lisp standard will contain ASDF and more of
the MOP.
I'd _like_ it if it contained an FFI, first-class global environments,
more standard functions being generic functions, multiprogramming and
networking support. But I don't think there's enough of a consensus on
those kinds of things for it to be standardised in the near future.
Nathan Baum wrote:
>> ·············@hotmail.com wrote:
>>
>>> Anyway i didn't see many suggestions except from
>>> Tron3k . It looks like that many want a new lisp
>>> but they don't know what it should look like.
>
>
> Whilst I'm sure many want a new Lisp, not many want a _future Common
> Lisp standard_ to be a new Lisp.
>
Exactly; later rounds of standardization refine and
extend, but (generally) do not change and redesign.
That is, a future common lisp standard is NOT going
to revisit such design decisions as having a separate
namespace for functions; that's decided already and
the rest of the language's design "fits" with the
decision.
But, a future version of Common Lisp is not the only
possible interpretation of a future Lisp. Other
lisps will come along sooner or later, and some of
them will be lisp-1's.
And this, I think, is as it should be. A revision in
a standard ought not wipe out every existing program
requiring a rewrite of all software in the language;
it should address problems and inconsistencies that
have shown themselves both to be problematic and to
have good solutions consistent with the rest of the
language. Code that breaks under a standard revision
is (or ought to be) code whose creators knew that it
was badly designed or a workaround or that it relied
on unspecified behavior from the start.
If you want to revisit those fundamental design
decisions, you have to start the process over again
starting by creating a different Lisp dialect. And
if it endures, the process of standardization will
refine and extend the new dialect, probably without
revisiting the fundamental design decisions that
defined it again. The new dialect won't magically
become the new "Common Lisp," nor should it. If
you are right that the fundamentals ought to be
different, then eventually it may displace Common
Lisp as the dominant dialect, but it will forever
be a different set of choices.
Note, if OP is serious about a Lisp-1 analogue to
Common Lisp, he may want to look into/revive the
Eulisp dialect. It sounds like most of the proposals
would fit into Eulisp a lot better than into CL.
Bear
From: lin8080
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <4318920A.D6DA3CBB@freenet.de>
Ray Dillinger schrieb:
found this:
http://lists.tunes.org/archives/tunes/2001-February/003058.html
Modernizing Common Lisp Recommended Extensions
If you want to hide(just a bit) parenthesis you can add to your
.emacs:
(defface paren-face
'((((class color) (background dark))
(:foreground "grey20"))
(((class color) (background light))
(:foreground "grey80")))
"Face used to dim parentheses.")
(defun hide-paren ()
(font-lock-add-keywords nil '(("(\\|)" . 'paren-face))))
(add-hook 'lisp-mode-hook 'hide-paren)
or learn lisp and you will not see them, also without this trick ;-)
·············@hotmail.com writes:
> I started this thread to see what Lisp newbies
> expect from Lisp , not what an seasoned Lisp programmers
> want for the next standard.
>
> When i started learning Lisp i was bugged by too many
> parenthesis , i wanted someway of omitting them or reducing as much i
> could
> (Or like Graham wrote at Ansi Common LIsp)
>
> defun our-member (obj lst)
> if null lst
> nil
> if eql (car lst) obj
> lst
> our-member obj (cdr lst)
>
--
Luigi Panzeri aka Matley
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Evaluate Lisp: http://lisp.tech.coop/Evaluate%20Lisp
From: lin8080
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <42DF77B3.75F1E825@freenet.de>
·············@hotmail.com schrieb:
> defun our-member (obj lst)
> if null lst
> nil
> if eql (car lst) obj
> lst
> our-member obj (cdr lst)
Huch. Oh no. Please. () are so nice typos. I will miss that when you
remove only one. Years of training are for cats.
but...
(make-sound "lala.mp3")
stefan
lin8080 wrote:
> ·············@hotmail.com schrieb:
>
> > defun our-member (obj lst)
> > if null lst
> > nil
> > if eql (car lst) obj
> > lst
> > our-member obj (cdr lst)
>
> Huch. Oh no. Please. () are so nice typos. I will miss that when you
> remove only one. Years of training are for cats.
>
> but...
> (make-sound "lala.mp3")
>
> stefan
Well i ment to have option using the parens or the indentation.
Like new row = (
1 ( setf x (list 1 2 3))
2 setf x
list 1 2 3
Anyway i don't have an idea how to inform the compiler where the
closing parens are ) . Any idea ??
·············@hotmail.com wrote:
>
> lin8080 wrote:
>
>>·············@hotmail.com schrieb:
>>
>>
>>>defun our-member (obj lst)
>>> if null lst
>>> nil
>>> if eql (car lst) obj
>>> lst
>>> our-member obj (cdr lst)
>>
>>Huch. Oh no. Please. () are so nice typos. I will miss that when you
>>remove only one. Years of training are for cats.
>>
>>but...
>>(make-sound "lala.mp3")
>>
>>stefan
>
>
> Well i ment to have option using the parens or the indentation.
> Like new row = (
> 1 ( setf x (list 1 2 3))
> 2 setf x
> list 1 2 3
>
> Anyway i don't have an idea how to inform the compiler where the
> closing parens are ) . Any idea ??
>
This is a questio better asked to comp.lang.python.
Have Python have the option of entering code in S-expression format
instead. Then you would have an almost Common Lisp. :)
Cheers
--
Marco
From: lin8080
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <42E2911C.FE237B5@freenet.de>
·············@hotmail.com schrieb:
> lin8080 wrote:
Hallo
> Well i ment to have option using the parens or the indentation.
> Like new row = (
> 1 ( setf x (list 1 2 3))
> 2 setf x
> list 1 2 3
> Anyway i don't have an idea how to inform the compiler where the
> closing parens are ) . Any idea ??
to 2: when there are more lines you have to scroll up and down (my font
is at size 8 with 1024x768).
As I know from python: this is not very good, means I do not like it
very much.
Also it is up to me, to isolate error-code with new lines and for my use
this works fine.
And last, usualy I code in Lisp from inside out, this is start with a
variable and pack some action around it. In your point 2 this needs some
reformat or a tool to get readable code, in special when there are
longer parts you need to do so with poit one too.
Maybe there are more reasons.
stefan
From: lin8080
Subject: Re: How do you imagine future Common Lisp standard ?
Date:
Message-ID: <42DF7A76.4B402517@freenet.de>
·············@hotmail.com schrieb:
> List all thing you want added , removed, modified for the new Common
> Lisp standard with brief explanations?
(macrop 'setf)
---> T
or:
(setq a 3)
---> 3
(resetq a 3)
---> A
(warning: A has no value)
Explain: many function have no way to redo their actions. (important
when the old status is wanted)
stefan