How do you imagine future Common Lisp standard ?
antoan...@hotmail.com
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.
Pascal Costanza
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/
Paolo Amoroso
> 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
antoan...@hotmail.com
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)
Ulrich Hobelmann
> 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
Pascal Bourguignon
> antoan...@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
Tron3k
- 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
Luigi Panzeri
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 ;-)
antoan...@hotmail.com writes:
--
Luigi Panzeri aka Matley
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Evaluate Lisp: http://lisp.tech.coop/Evaluate%20Lisp
Björn Lindberg
> 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
Pascal Costanza
> 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. ;)
Christophe Rhodes
Joe Marshall
> antoan...@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 <u.hob...@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.
Matthias Buelow
>(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.
Pascal Costanza
I know. I just don't like languages that pretend they know what's best
for me. That's anti-enlightening.
Robert Uhl
> > 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
Joe Marshall
> 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.
Arthur Lemmens
> "Tron3k" <tro...@gmail.com> writes:
>
>> - A function for splitting sequences
>
> Haha.
Hehe.
Tron3k
> 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.
rsher...@gmail.com
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.
Pascal Bourguignon
> 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/
Tron3k
(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.
Tron3k
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
:-)
Edi Weitz
> 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 "spam...@agharta.de" 5) "edi")
Tron3k
Tron3k
Christophe Rhodes
> Arthur Lemmens wrote:
>> Christophe Rhodes <cs...@cam.ac.uk> wrote:
>>
>> > "Tron3k" <tro...@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
Tron3k
Not really, no.
Peter Seibel
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 * pe...@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Joe Marshall
> 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
Tron3k
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
David
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.
David
previous post about getting a decent editor...)
Pascal Costanza
> 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.
Tron3k
> 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.
Don Geddis
>> > I would like to see:
>> > - Predicates changed to end in '?' and destructive functions changed to
>> > end in '!', just like Scheme
This much sure sounds like Scheme. Which already exists. So why don't you
use it?
"Tron3k" <tro...@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/ d...@geddis.org
Zenophobia: the irrational fear of convergent sequences.
Tron3k
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. :-)
André Thieme
> 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é
--
André Thieme
> 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é
--
Pascal Costanza
> 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.
Tayssir John Gabbour
> 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.
>
> ;-)
>
> 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. ;)
antoan...@hotmail.com
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.
Jason Kantz
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.
Tron3k
> > 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.
drewc
> 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
Ulrich Hobelmann
>> 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
drewc
> 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.
Tron3k
> 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.
Matthias Buelow
>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.
drewc
> 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 :).
drewc
> drewc <dr...@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.
Tim X
> 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!
Tim X
> 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.
Robert Uhl
>
> 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
Tron3k
> 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.
Gareth McCaughan
> 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
Pascal Bourguignon
> 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!"
Joe Marshall
> 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
Tron3k
> "Tron3k" <tro...@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.
Edi Weitz
> (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 "spam...@agharta.de" 5) "edi")
M Jared Finder
> 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
drewc
> 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.
rsher...@gmail.com
> 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?
Matthias Buelow
>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.
Edi Weitz
> I have the windows key bound to hyper, and it's great. Can't you do
> that?
Maybe he has a ThinkPad...
drewc
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
drewc
> 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) :)
Tron3k
> ...
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?
Pascal Bourguignon
> 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/
drewc
> 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
Tron3k
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.
Tayssir John Gabbour
> 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
Tim X
> Joe Marshall wrote:
> > "Tron3k" <tro...@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.
Rob Warnock
+---------------
| 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 <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
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.
>
> 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.
Pascal Bourguignon
> 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
Robert Uhl
>
> 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
Robert Uhl
>
> 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
> "Tron3k" <tro...@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
> 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
Joe Marshall
> On Sun, 17 Jul 2005 13:30:18 -0400, Joe Marshall <prunes...@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?
Joe Marshall
Edi Weitz
Hey, originally you said you only wanted one key...
drewc
> 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.
fireblade
try Allegro none Ansi image .
Thomas F. Burdick
> 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! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
facethe...@hotmail.com
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.
Immanuel Litzroth
antoan...@hotmail.com
Juliusz Chroboczek
Pascal Costanza <p...@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
Sam Steingold
>
> 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.
jayessay
> 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
alexand...@lycos.com
http://www.international-lisp-conference.org
and if you don't like Lisp why wasting the time in c.l.l ?
Ulrich Hobelmann
> 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
antoan...@hotmail.com
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.
fireblade
Is that legal ?
antoan...@hotmail.com
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 .
alexand...@lycos.com
What does Eric have to do with this thread ?
lin8080
antoan...@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
antoan...@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
antoan...@hotmail.com
on Erik Naggum.
antoan...@hotmail.com
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 ??