Why not a setf-able NIL ?

kodifik@eurogaran.com wrote:

> Why not devote instead a couple of minutes to think how it would be
> done in C and see if it offers some benefit (say execution time) over
> standard CL?

Give a (complete) example. Both gcc and sbcl (for example) have good
optimizers and can produce assembler listings of the generated object
code. Then show how testing against 0 instead of of (zerop foo) in that
example would give better (faster, shorter) output. Why should we
"devote a couple minutes" trying to prove your point?

Matthias Buelow wrote:
> > Why not devote instead a couple of minutes to think how it would be
> > done in C and see if it offers some benefit (say execution time) over
> > standard CL?
>
> Give a (complete) example. Both gcc and sbcl (for example) have good
> optimizers and can produce assembler listings of the generated object
> code. Then show how testing against 0 instead of of (zerop foo) in that
> example would give better (faster, shorter) output. Why should we
> "devote a couple minutes" trying to prove your point?

Lets not convert this thread on another one about Lisp speed. In C
falsehood is 0, and that cannot be changed. This is hardly surprising
given C spirit.
What I wonder is why Lisp has to be similar to C in that respect, why
falsehood can not be modified, as one should expect from a symbolic
language. By the way: it happens to be the same in every other
programming language I know.
Again: Is there a FUNDAMENTAL reason? or purely practical
considerations?

På Wed, 01 Oct 2008 17:37:27 +0200, skrev <kodifik@eurogaran.com>:

> Beware it is not properly ambiguity, since NIL would always have one
> value at any given time.

But you would never know what that value was! Consider

(let ((nil 0))
(declare (special nil))
(format t "Hello")) ; oops format sees the new nil as well.. probably
not good

Note that that doesn't actually work in common lisp as a local nil would
be different from cl:nil. But you seem to think that if they were the same
that would be good.. (Is this guy crazy?)

--------------
John Thingstad

kodifik@eurogaran.com wrote:

> Again: Is there a FUNDAMENTAL reason? or purely practical
> considerations?

It's because of practical considerations. Satisfied?

John Thingstad wrote:
> P� Wed, 01 Oct 2008 17:37:27 +0200, skrev <kodifik@eurogaran.com>:
>
> > Beware it is not properly ambiguity, since NIL would always have one
> > value at any given time.
>
> But you would never know what that value was!
Yes I would. In case of doubt, (print nil) would tell me.

> Consider
> (let ((nil 0))
> (declare (special nil))
> (format t "Hello"))
t is not nil, so no problem.
Moreover, (format nil "Hello") should still print to a string, since
nil would always be false.
What if (setf nil some-stream) ?
Nil would still compute as false, so (format nil "... would still
print to a string.

> Note that that doesn't actually work in common lisp as a local nil would
> be different from cl:nil.
Of course. I think everybody understands that.

> But you seem to think that if they were the same
> that would be good.. (Is this guy crazy?)
What I think would be good is the freedom to do it (or not, it if I
consider it bad).

On Wed, 01 Oct 2008 08:09:51 -0700, kodifik wrote:

>> I don't see the merit of what you propose.
> The merit is freedom.

You miss the point of programming languages. They exist to program
computers, not to satisfy some vague aesthetic ideal.

> Absolutely yes. My profession is student, and it will always be. That's

You have a long way to go.

>> You should not propose a fundamental modification in the design of a
>> language just because you have some vague idea on how it would be
>> "useful" or because you are confused about some general and vague
>> design principle.
> Neither should a fundamental restriction be imposed on me because of
> some vague reason.

As others have said, it was imposed for practical reasons.

>> (hint: having constants in a language is not "hard-coding")
> Yes it is.

You are confused on a very fundamental level. Constants are a feature,
they are constants exactly because you want them to have the same value
and not have to worry about checking what it is all the time.
Hardcoding, in contrast, is a programming style issue.

If you are a student, I seriously hope that you are not a CS major,
because programming language concepts do not appear to be your forte.

> Why not devote instead a couple of minutes to think how it would be done
> in C and see if it offers some benefit (say execution time) over
> standard CL?

Your point, you have to prove it. It is unreasonable to expect others to
devote time to arguing _your_ case (which was pretty weak to start with).

Best,

Tamas

PÃ¥ Wed, 01 Oct 2008 18:50:09 +0200, skrev <kodifik@eurogaran.com>:

> John Thingstad wrote:
>> P� Wed, 01 Oct 2008 17:37:27 +0200, skrev <kodifik@eurogaran.com>:
>>
>> > Beware it is not properly ambiguity, since NIL would always have one
>> > value at any given time.
>>
>> But you would never know what that value was!
> Yes I would. In case of doubt, (print nil) would tell me.
>
>> Consider
>> (let ((nil 0))
>> (declare (special nil))
>> (format t "Hello"))
> t is not nil, so no problem.
> Moreover, (format nil "Hello") should still print to a string, since
> nil would always be false.

You are so not getting it. A special variable is dynamic. What that means
is that every funtion called until nil goes out of scope sees it. That
means format and everything format calls also. Everytime you compare to
nil it sees 0. What does (eql val nil) mean anyhow? Is it (eq val nil) or
is it (= val 0)?

--------------
John Thingstad

kodifik@eurogaran.com wrote:

> Moreover, (format nil "Hello") should still print to a string, since
> nil would always be false.
> What if (setf nil some-stream) ?
> Nil would still compute as false, so (format nil "... would still
> print to a string.

No, it won't. You're confusing the symbol with its value. If you want to
change the concept of falsehood, you have to make the language aware
that the symbol NIL no longer represents falsehood. In Lisp, the symbol
NIL itself, not its value, represents falsehood. Falsehood is checked
(at least, conceptually) by checking if a value is the symbol NIL, not
if a value is the same as the value of the symbol NIL. NIL is set to
have itself as value just for convenience so that you don't have to
quote it everywhere.

Tamas K Papp wrote:
> You miss the point of programming languages. They exist to program
> computers, not to satisfy some vague aesthetic ideal.
One thing does not exclude the other.

> > Absolutely yes. My profession is student, and it will always be.
>
> You have a long way to go.
Thanks. Let's hope the journey will be long.

> As others have said, it was imposed for practical reasons.
Now you finally give your answer. Thanks for it.

> >> (hint: having constants in a language is not "hard-coding")
> > Yes it is.
>
> You are confused on a very fundamental level. Constants are a feature,
> they are constants exactly because you want them to have the same value
> and not have to worry about checking what it is all the time.
> Hardcoding, in contrast, is a programming style issue.
Sounds like "If I do it, it is right; but if you do it, then it is
wrong".

> If you are a student, I seriously hope that you are not a CS major,
> because programming language concepts do not appear to be your forte.
Luckily, there is people like you who find always pleasure to shed
light.

Matthias Buelow wrote:
> You're confusing the symbol with its value. If you want to
> change the concept of falsehood, you have to make the language aware
> that the symbol NIL no longer represents falsehood. In Lisp, the symbol
> NIL itself, not its value, represents falsehood. Falsehood is checked
> (at least, conceptually) by checking if a value is the symbol NIL, not
> if a value is the same as the value of the symbol NIL. NIL is set to
> have itself as value just for convenience so that you don't have to
> quote it everywhere.
Very illuminating explanation. I understand.