can someone explain this quote by Tim Daly?
gavino
Lisp has two fundamental features.
1) Programs and data are the same.
2) nil eq () eq false
Almost all other programming
languages miss the first features.
Scheme screwed up when the broke
the second feature.
Without these features, it is
not lisp.
Python is just one of thousands
of languages that pretend to be
lisp "without the parens". Python
is a lost cause, its just too young
to bother dying but it will.
Dimiter "malkia" Stanev
forth.
Ken Tilton
http://www.infoq.com/interviews/mccarthy-elephant-2000
When searching for examples of programming languages that might be
extended to support the functionality he has in mind for e2k, McCarthy
came up with Fortran, COBOL, and Java.
rather cororrarily, when asked if something as awesome as e2k called for
any special features in a programming (John! Say closures! Code as data,
John!) he said, nope. C would be fine.
And Mr. Graham might be in trouble with his hundred-year baby:
"One stimulus for writing this article was a talk entitled ``Programming
languages of the year 2000'' that I considered insufficiently
ambitious." -- from
http://www-formal.stanford.edu/jmc/elephant/node1.html#SECTION00010000000000000000
Gotta tell ya, I don't think abbreviating funcall to fn rises to the
level of sufficiently ambitious.
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Johannes Weiner
Ken Tilton <kenny...@optonline.net> writes:
> Gotta tell ya, I don't think abbreviating funcall to fn rises to the
> level of sufficiently ambitious.
I though FN is a lambda?
Hannes
Jeff
I think it is. Nevertheless, the argument remains valid.
Ken Tilton
Jeff wrote:
>>I though FN is a lambda?
>
>
> I think it is.
Yeah, I thought I posted a Doh! confirmation but I do not see it so...
Doh!
Esp. funny since it is a Lisp-1, pg actually saved eight characters
shortening funcall.
gavino
> My takeaways from:
>
> http://www.infoq.com/interviews/mccarthy-elephant-2000
>
> When searching for examples of programming languages that might be
> extended to support the functionality he has in mind for e2k, McCarthy
> came up with Fortran, COBOL, and Java.
>
> rather cororrarily, when asked if something as awesome as e2k called for
> any special features in a programming (John! Say closures! Code as data,
> John!) he said, nope. C would be fine.
>
> And Mr. Graham might be in trouble with his hundred-year baby:
>
> "One stimulus for writing this article was a talk entitled ``Programming
> languages of the year 2000'' that I considered insufficiently
>
> Gotta tell ya, I don't think abbreviating funcall to fn rises to the
> level of sufficiently ambitious.
>
> kenny
>
>
> "In the morning, hear the Way;
> in the evening, die content!"
> -- Confucius
Mccarthy is freakin hilarious.
I want him to make a lisp DNS server.
and a functional database that obsoletes relational db.
A lisp based distributed filesystem be awesome too.
gavino
wrote:
forth seems awesome
especally forth-linda
gavino
what does section 2 mean?
Pascal Bourguignon
Don't bother, there's no way you could understand.
If you cannot go by yourself from
>> 2) nil eq () eq false
to (and (eq nil '()) (eq '() false))
then you won't be able to understand the later either.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"This statement is false." In Lisp: (defun Q () (eq nil (Q)))
Stanisław Halik
>>> Lisp has two fundamental features.
[...]
>>> 2) nil eq () eq false
>> what does section 2 mean?
>>> 2) nil eq () eq false
> to (and (eq nil '()) (eq '() false))
What's so special about nil and () in the context of being a Lisp? Seems
like a contrived example made specifically to exclude Scheme from the
Lisp family.
--
Nawet świnka wejdzie na drzewo kiedy ją chwalą.
Pascal Bourguignon
> thus spoke Pascal Bourguignon <p...@informatimago.com>:
>
>>>> Lisp has two fundamental features.
> [...]
>>>> 2) nil eq () eq false
>>> what does section 2 mean?
>>>> 2) nil eq () eq false
>> to (and (eq nil '()) (eq '() false))
>
> What's so special about nil and () in the context of being a Lisp? Seems
> like a contrived example made specifically to exclude Scheme from the
> Lisp family.
Rather, the problem with scheme is that (not (eql? (= 1 0) '()))
You can always (define nil '()) ; even if it's not as practical
as (defconstant nil 'nil).
What is so special about false and '() is that mathematically, there
is an isomorphism between sets and booleans:
false <---> empty set
true <---> whole set
and <---> intersection
or <---> union
not <---> complement in the whole set. (or set difference from the whole).
Scheme breaks this isomorphims.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Pour moi, la grande question n'a jamais été: «Qui suis-je? Où vais-je?»
comme l'a formulé si adroitement notre ami Pascal, mais plutôt:
«Comment vais-je m'en tirer?» -- Jean Yanne
Kent M Pitman
> thus spoke Pascal Bourguignon <p...@informatimago.com>:
>
> >>> Lisp has two fundamental features.
> [...]
> >>> 2) nil eq () eq false
> >> what does section 2 mean?
> >>> 2) nil eq () eq false
> > to (and (eq nil '()) (eq '() false))
>
> What's so special about nil and () in the context of being a Lisp? Seems
> like a contrived example made specifically to exclude Scheme from the
> Lisp family.
Actually, the difference is not accidental. The Scheme community used
to be like Lisp and certain Scheme designers mounted a deliberate
effort to distance themselves from Lisp, so it's reasonable to say
that the line is unimportant to you but it's really not a contrived line.
I actually think the effort was misplaced. It's the false vs symbol
NIL and empty list vs symbol NIL relations that are messy. Having a
randomly chosen symbol be false when all other symbols are true is
occasionally annoying... but even then, not often enough to be a burden.
The problem was never, IMO, between empty list and false.
Certainly the ability to pun on NIL being both false and empty is very
useful. It's been rare in my experience to want to return NIL and
have it taken as true. And anyway, the chief place it comes up is
where you might want to return an empty list and have it not be
confused with an absence of value. But then, the change to separate
the empty list and false doesn't help things because even then you
want to not confuse false and the absence of value. So there's no
substitute in the general case for either returning two values (as
GETHASH does) or taking an optional default value (again, as GETHASH
does).
Also, as for falseness, many languages have more than one value that
is permissible to use as a false value and it works quite well. So
the notion of canonical falsity is contrived from the outset. There
is no notion of canonical truth in Lisp.
I think the people who pushed this change to Scheme did so as part of
a religious mission to get people not to confuse NOT and NULL? in a
way they didn't approve of. But in the real world the pun is often
quite useful and leads to very few problems. Language design based on
trying to preemptively keep people from using certain programming
styles might be said to be pushing a contrived notion, but there is
nothing contrived about saying that language designers do, in fact,
engage in the practice. And if languages are designed to attract
people, they are then implicitly designed to repel others. So if
someone says this is what attracts or repels them, that seems
legitimate.
As a footnote, if I were to pick a symbol that was not going to feel
"randomly chosen" as the designated false value and empty list, but
rather would feel somewhat uniquely determined in an objective sense,
it would be ||. But then, it would raise the whole question of how
symbols are notated, and that's probably a lurking religious war in
its own right.
Andrew Reilly
> Stanisław Halik <sthalik...@tehran.lain.pl> writes:
>
>> thus spoke Pascal Bourguignon <p...@informatimago.com>:
>>
>>>>> Lisp has two fundamental features.
>> [...]
>>>>> 2) nil eq () eq false
>>>> what does section 2 mean?
>>>>> 2) nil eq () eq false
>>> to (and (eq nil '()) (eq '() false))
>>
>> What's so special about nil and () in the context of being a Lisp?
>> Seems like a contrived example made specifically to exclude Scheme from
>> the Lisp family.
>
> Rather, the problem with scheme is that (not (eql? (= 1 0) '())) You can
> always (define nil '()) ; even if it's not as practical as (defconstant
> nil 'nil).
>
> What is so special about false and '() is that mathematically, there is
> an isomorphism between sets and booleans:
>
> false <---> empty set
> true <---> whole set
> and <---> intersection
> or <---> union
> not <---> complement in the whole set. (or set difference from the
> whole).
>
> Scheme breaks this isomorphims.
Yeah, but so does lisp, because (just like scheme), anything that isn't
'() is true, not just lists that have some members, as your set analogy
would seem to imply. Examples of strings, integers, every other sort of
object are just as "true" as '(()). Even 0 is true, in both lisp and
scheme, which takes a bit of un-learning...
How cute is it that (listp (< 4 3)) -> T? In scheme, it's #f, whichever
way around those two numbers are.
Cheers,
--
Andrew
John Thingstad
<andrew-...@areilly.bpc-users.org>:
>
> Yeah, but so does lisp, because (just like scheme), anything that isn't
> '() is true, not just lists that have some members, as your set analogy
> would seem to imply. Examples of strings, integers, every other sort of
> object are just as "true" as '(()). Even 0 is true, in both lisp and
> scheme, which takes a bit of un-learning...
>
Unlearning? The only language where 0 sometimes means false is C and that
is definitely a mistake.
Does file-length 0 mean that the length is zero or that it failed to find
the length?
This sort of thing leads a plethora of inconsistencies in the C library.
Genaralized boolean is at least logically consistent.
--------------
John Thingstad
Andrew Reilly
> På Sat, 15 Mar 2008 21:23:49 +0100, skrev Andrew Reilly
> <andrew-...@areilly.bpc-users.org>:
>
>
>> Yeah, but so does lisp, because (just like scheme), anything that isn't
>> '() is true, not just lists that have some members, as your set analogy
>> would seem to imply. Examples of strings, integers, every other sort
>> of object are just as "true" as '(()). Even 0 is true, in both lisp
>> and scheme, which takes a bit of un-learning...
>>
>>
> Unlearning? The only language where 0 sometimes means false is C and
> that is definitely a mistake.
I did mean to imply that I found it a change, myself.
I think that singling out C is a mistake, though. Besides the C family,
Python, Perl and Awk all accept 0 as false. I think Fortran and Forth
are the same, but it's been too long. At least the Bourne shell doesn't:
0 is true, there :-) (sort of.) From memory, the Wirth languages
require explicit FALSE, but they also require explicit TRUE, so you wind
up explicitly testing everything.
> Does file-length 0 mean that the length is zero or that it failed to
> find the length?
> This sort of thing leads a plethora of inconsistencies in the C library.
There are manual pages for that sort of information, and there are, as
you say, plenty of inconsistencies that result.
Cheers,
--
Andrew
Kent M Pitman
> På Sat, 15 Mar 2008 21:23:49 +0100, skrev Andrew Reilly
> <andrew-...@areilly.bpc-users.org>:
>
> >
> > Yeah, but so does lisp, because (just like scheme), anything that isn't
> > '() is true, not just lists that have some members, as your set analogy
> > would seem to imply. Examples of strings, integers, every other sort of
> > object are just as "true" as '(()). Even 0 is true, in both lisp and
> > scheme, which takes a bit of un-learning...
>
> Unlearning? The only language where 0 sometimes means false is C and
> that is definitely a mistake.
0 is false in MOO (design by Pavel Curtis, who contributed to the CL
condition system and certainly knew Lisp) and it works very well. MOO
also has 0.0, "", the empty list {}, and error types true, which also
work fine. It makes object types (the vague equivalent of our
standard class instances) false, and that's a design mistake that is
annoying. But I actually came to think a lot of types having a null
representative was a cool and useful idea.
> Does file-length 0 mean that the length is zero or that it failed to
> find the length?
Well, in fairness, does false being returned from something mean false
or the absence of an answer? Separating false and the empty list still
doesn't get you all the way home in this game.
If there is a possible value you can return, then there is a possible
situation where it can be the "real answer" and where a non-value will
need to be distinguished from it. Failures have to be communicated
some other way if there is an overlap of meaning. For example, in
file I/O in MACLISP, one used -1 as the eof result of TYI because 0
was taken by ASCII NULL. But in general either the third arg to GETHASH
or the second return value from GETHASH are the examples of answers.
This issue is not really black&white. The ultimate answer is
necessarily arbitrary, so parting company with traditional lisp in
order to be less than arbitrary seems pointlessly arbitrary.
> This sort of thing leads a plethora of inconsistencies in the C library.
That doesn't imply that it would in Lisp, of course. C has other
differences. Languages are ecologies, and the totality of the
situations has to be taken into account.
> Genaralized boolean is at least logically consistent.
Well, there is, in principle, no reason that there can't both be a
canonical false value and other false values, as there is now a
canonical true value and other true values.
John Thingstad
<pit...@nhplace.com>:
> "John Thingstad" <jpt...@online.no> writes:
>
>> På Sat, 15 Mar 2008 21:23:49 +0100, skrev Andrew Reilly
>> <andrew-...@areilly.bpc-users.org>:
>>
>> >
>> > Yeah, but so does lisp, because (just like scheme), anything that
>> isn't
>> > '() is true, not just lists that have some members, as your set
>> analogy
>> > would seem to imply. Examples of strings, integers, every other sort
>> of
>> > object are just as "true" as '(()). Even 0 is true, in both lisp and
>> > scheme, which takes a bit of un-learning...
>>
>> Unlearning? The only language where 0 sometimes means false is C and
>> that is definitely a mistake.
>
OK, not just C.. But since C doesn't have exceptions it is a bigger
problem here.
>
>> Does file-length 0 mean that the length is zero or that it failed to
>> find the length?
>
> Well, in fairness, does false being returned from something mean false
> or the absence of an answer? Separating false and the empty list still
> doesn't get you all the way home in this game.
>
Clearly a exception if the file didn't exist would be better. You could
use the equivalent of probe-file first if you didn't want to trigger a
exception. (The judge is out on whether exceptions should only signal
errors or whether they are a acceptable standard dispatch mechanism. I
leave this to taste.)
> If there is a possible value you can return, then there is a possible
> situation where it can be the "real answer" and where a non-value will
> need to be distinguished from it. Failures have to be communicated
> some other way if there is an overlap of meaning. For example, in
> file I/O in MACLISP, one used -1 as the eof result of TYI because 0
> was taken by ASCII NULL. But in general either the third arg to GETHASH
> or the second return value from GETHASH are the examples of answers.
This EOF issue lookes like it comes from it's Unix C interface which would
illustrates my point..
You can then get global value errno for a more spesific error.
(C used to define null as '#define NULL (void *) 0' The cast makes it work
for both char and int types. UGH!)
>
> This issue is not really black&white. The ultimate answer is
> necessarily arbitrary, so parting company with traditional lisp in
> order to be less than arbitrary seems pointlessly arbitrary.
>
>> This sort of thing leads a plethora of inconsistencies in the C library.
>
> That doesn't imply that it would in Lisp, of course. C has other
> differences. Languages are ecologies, and the totality of the
> situations has to be taken into account.
>
My point is that 0 is a acceptable value for a integer. Should "" also
mean false?
nil is only a object of type null. It reduces the problems. As scheme
illustrates forcing you to return false complicates the code.
personally I prefer the terser
(when (search ..) ..) to (when (not (null (search ..)) ..)
Of cource some people find this bad style..
>> Genaralized boolean is at least logically consistent.
>
> Well, there is, in principle, no reason that there can't both be a
> canonical false value and other false values, as there is now a
> canonical true value and other true values.
--------------
John Thingstad
George Neuner
>På Sat, 15 Mar 2008 21:23:49 +0100, skrev Andrew Reilly
><andrew-...@areilly.bpc-users.org>:
>
>>
>> Yeah, but so does lisp, because (just like scheme), anything that isn't
>> '() is true, not just lists that have some members, as your set analogy
>> would seem to imply. Examples of strings, integers, every other sort of
>> object are just as "true" as '(()). Even 0 is true, in both lisp and
>> scheme, which takes a bit of un-learning...
>>
>
>Unlearning? The only language where 0 sometimes means false is C and that
>is definitely a mistake.
>Does file-length 0 mean that the length is zero or that it failed to find
>the length?
First, there is no "file-length" function in the C standard library.
To portably get the length of a file, you have to do something morally
equivalent to
old:
long pos, len;
int ret;
// get start position
pos = ftell( fp );
if ( len < 0L ) fail();
// seek to end and get position
ret = fseek( fp, 0L, SEEK_END );
if ( ret != 0 ) fail();
len = ftell( fp );
if ( len < 0L ) fail();
// restore start position
ret = fseek( fp, pos, SEEK_SET );
if ( ret != 0 ) fail();
new:
fpos_t pos, len;
int ret;
// get start position
ret = fgetpos( fp, &pos );
if ( ret != 0 ) fail();
// seek to end and get position
ret = fseek( fp, 0L, SEEK_END );
if ( ret != 0 ) fail();
ret = fgetpos( fp, &len );
if ( ret != 0 ) fail();
// restore start position
ret = fsetpos( fp, &pos );
if ( ret != 0 ) fail();
// get length from fpos_t
...
fseek/fgetpos/fsetpos all use zero to indicate success (as do many
other library functions). ftell uses a negative number to indicate
failure because zero and positive numbers are legal return values.
Obviously the seek/get/set version is more regular and to be preferred
over the seek/tell version.
>This sort of thing leads a plethora of inconsistencies in the C library.
>Genaralized boolean is at least logically consistent.
I'll happily agree that C's library is inconsistent, but IMO it is no
more inconsistent than CL's library (related functions taking
parameters in opposite order, etc.).
Like all programming languages, C's problems are mostly between its
users and their keyboards.
George
--
for email reply remove "/" from address
gavino
wrote:
So what it means is that nil equals the empty list? = true? in common
lisp?
and this is more true for majority of mathematical examples?
George Neuner
wrote:
>"John Thingstad" <jpt...@online.no> writes:
>
>> På Sat, 15 Mar 2008 21:23:49 +0100, skrev Andrew Reilly
>> <andrew-...@areilly.bpc-users.org>:
>>
>> >
>> > Yeah, but so does lisp, because (just like scheme), anything that isn't
>> > '() is true, not just lists that have some members, as your set analogy
>> > would seem to imply. Examples of strings, integers, every other sort of
>> > object are just as "true" as '(()). Even 0 is true, in both lisp and
>> > scheme, which takes a bit of un-learning...
>>
>> Unlearning? The only language where 0 sometimes means false is C and
>> that is definitely a mistake.
>
>0 is false in MOO (design by Pavel Curtis, who contributed to the CL
>condition system and certainly knew Lisp) and it works very well. MOO
>also has 0.0, "", the empty list {}, and error types true, which also
>work fine. It makes object types (the vague equivalent of our
>standard class instances) false, and that's a design mistake that is
>annoying. But I actually came to think a lot of types having a null
>representative was a cool and useful idea.
But those type-specific nulls should not be conflated with boolean
false.
>> Does file-length 0 mean that the length is zero or that it failed to
>> find the length?
>
>Well, in fairness, does false being returned from something mean false
>or the absence of an answer? Separating false and the empty list still
>doesn't get you all the way home in this game.
>
>If there is a possible value you can return, then there is a possible
>situation where it can be the "real answer" and where a non-value will
>need to be distinguished from it. Failures have to be communicated
>some other way if there is an overlap of meaning.
You beat me to this point. I agree that conflating return values with
the success/failure status of the function is wrong. If a function
can somehow fail to produce a meaningful answer, it should return a
separate status indication.
One good thing about Lisp is that multiple return values are a very
convenient way to accomplish this.
>For example, in
>file I/O in MACLISP, one used -1 as the eof result of TYI because 0
>was taken by ASCII NULL. But in general either the third arg to GETHASH
>or the second return value from GETHASH are the examples of answers.
>
>This issue is not really black&white. The ultimate answer is
>necessarily arbitrary, so parting company with traditional lisp in
>order to be less than arbitrary seems pointlessly arbitrary.
>
>> This sort of thing leads a plethora of inconsistencies in the C library.
>
>That doesn't imply that it would in Lisp, of course. C has other
>differences. Languages are ecologies, and the totality of the
>situations has to be taken into account.
>
>> Genaralized boolean is at least logically consistent.
>
>Well, there is, in principle, no reason that there can't both be a
>canonical false value and other false values, as there is now a
>canonical true value and other true values.
IMO, there should be canonical true and false boolean values to which
comparators evaluate and upon which conditionals are switched. Scheme
got it wrong ... comparators evaluate to #t/#f, but for conditionals
anything not #f is considered true - copying C's (and Lisp's!) broken
boolean model. It's perfectly fine to have type-specific nulls, but
you should have to explicitly test for them. Only #t should be true.
YMMV. I don't expect much agreement from people who like the way Lisp
handles boolean expressions - I just had to say my piece.
Pertti Kellomäki
> What is so special about false and '() is that mathematically, there
> is an isomorphism between sets and booleans:
>
> false <---> empty set
> true <---> whole set
> and <---> intersection
> or <---> union
> not <---> complement in the whole set. (or set difference from the whole).
But '() is the empty *list*, not the empty *set*. Sets can be implemente
using lists, but lists are not sets.
--
Pertti
Pascal Bourguignon
For the CL package, '() is the empty set too.
nil <--> ()
generalized true <--> (())
and <--> cl:intersection
or <--> cl:union
not <--> (lambda (x) (set-difference '(()) x))
--
__Pascal Bourguignon__ http://www.informatimago.com/
"You question the worthiness of my code? I should kill you where you
stand!"