Why not a setf-able NIL ?

kodifik@eurogaran.com schrieb:
> smallpond wrote:
>> This is a tremendous idea. Let's extend it. I occasionally write
>> a program using a specific number, say 16. How much better would it
>> be if I could change my code to use 32, say, by just doing:
>>
>> (setf 16 32)
>>
>> That way I wouldn't have to go through my code changing each instance
>> of 16 to 32. After all "16" is just two bytes of ASCII interpreted
>> by the reader, we should be able to assign it any meaning we wish.
> You can use a free variable, call it A :
> (setf A 16)
> Then you could change things just by doing
> (setf A 32)
> The question (yes, it was a question, not a proposal) was about why
> not tampering with NIL as easily.

This would work, as both have the same type.
But writing code where you call several functions with the argument A
will in most cases assume a number.
(setf A "Haha") could cause problems in code like:
(< A PI)


André
--

kodifik@eurogaran.com wrote:
> smallpond wrote:
> > This is a tremendous idea. Let's extend it. I occasionally write
> > a program using a specific number, say 16. How much better would it
> > be if I could change my code to use 32, say, by just doing:
> >
> > (setf 16 32)
> >
> > That way I wouldn't have to go through my code changing each instance
> > of 16 to 32. After all "16" is just two bytes of ASCII interpreted
> > by the reader, we should be able to assign it any meaning we wish.
> You can use a free variable, call it A :
> (setf A 16)
> Then you could change things just by doing
> (setf A 32)
> The question (yes, it was a question, not a proposal) was about why
> not tampering with NIL as easily.

Note that there is no fundamental difference between

(setf 16 32)

and

(setf () '(0))

or

(setf () 0)

(in the second case we are also changing type, but that is little
detail compared to changing value of a literal).

If you are satisfies with using variables you can do

(setf empty ())

Common Lisp decided that empty list is used as boolean falsity
and that _symbol_ NIL is _identical_ to empty list. This second
decision really is a historical artifact, there are no strong reasons
for this (it is nice to have name for empty list, but it would be
enough if nil _evaluated_ to empty list).

Assuming that in modified Lisp nil is just a variable (which is
initialized to empty list) and boolean falsity is the same as
empty list, assigning value to nil will give "expected" result
on code using nil, but loops and coditionals will still expect
empty list.

You also asked if having constants is fundamental. Yes and no:
one can imagine programming language where everything directly
available to programmer is a variable. However, when you acces
variable you want to get a value. Most programming language
designers decided that language which does not allow you to
use values directly (and forces you to access them via variables)
is too limiting.

--
Waldek Hebisch
hebisch@math.uni.wroc.pl

On Oct 2, 2:37 am, kodi...@eurogaran.com wrote:
> smallpond wrote:
> > This is a tremendous idea. Let's extend it. I occasionally write
> > a program using a specific number, say 16. How much better would it
> > be if I could change my code to use 32, say, by just doing:
>
> > (setf 16 32)
>
> > That way I wouldn't have to go through my code changing each instance
> > of 16 to 32. After all "16" is just two bytes of ASCII interpreted
> > by the reader, we should be able to assign it any meaning we wish.
>
> You can use a free variable, call it A :
> (setf A 16)
> Then you could change things just by doing
> (setf A 32)
> The question (yes, it was a question, not a proposal) was about why
> not tampering with NIL as easily.

because NIL is not a variable

Barry Margolin <barmar@alum.mit.edu> writes:

> In article <87k5csnpp1.fsf@hubble.informatimago.com>,
> pjb@informatimago.com (Pascal J. Bourguignon) wrote:
>
> > You must be very very sad. I know of no programming language
> > allowing you to redefined/reassing 42.
>
> Fortran used to allow this. Parameters were passed by reference, and
> when you passed a literal it passed a reference to its location in the
> literal pool. If the procedure assigned that parameter, it would change
> the literal.
>
> This was probably implementation-dependent, but I've heard that it
> occurred with many popular implementations.

Hah, I had thought of this as well.

You got really amusing effects when you managed to change the constant
zero (0) to something else.

--
Thomas A. Russ, USC/Information Sciences Institute

On Oct 2, 2:07*am, kodi...@eurogaran.com wrote:
> Matthias Buelow wrote:
> > The primary purpose of the DATA statement is to give names to constants;
> > instead of referring to PI as 3.141592653589797, at every appearance,
> > the variable PI can be given that value with a DATA statement, and
> > used instead of the longer form of the constant. This also simplifies
> > modifying the program, should the value of PI change."
>
> > Granted, it's only bad wording but still funny.
>
> It is not bad wording and it is not funny. The value of PI can change.
> Just suppose you want to repeat calculations for a non-euclidean space.

You seem to have the same confusion about pi that you had about NIL.

Pi is the name for a particular number. It is independent of geometry,
physics, coordinate system, or anything but the most basic assumptions
about logic.

What can change is, for instance, the ratio of circumference to
diameter of a "circle" or the sum of angles inside a "triangle." In
Euclidian space, 2*pi*r and pi/2 are the norm, and by changing the
coordinate system, this is no longer true.

You can't change pi, you change the formulas for the geometric
quantities, for instance that the angles of a triangle sum to pi + A/
a^2, instead of simply pi.

Otherwise, your probability and integration and all sorts of other
libraries will start to give wrong answers, because you have changed
the formula for a bell-curve and the residue of integrating around a
pole, and all the other things that pi connects to.

In article <ymiskre3deu.fsf@blackcat.isi.edu>,
tar@sevak.isi.edu (Thomas A. Russ) wrote:

> Barry Margolin <barmar@alum.mit.edu> writes:
>
> > In article <87k5csnpp1.fsf@hubble.informatimago.com>,
> > pjb@informatimago.com (Pascal J. Bourguignon) wrote:
> >
> > > You must be very very sad. I know of no programming language
> > > allowing you to redefined/reassing 42.
> >
> > Fortran used to allow this. Parameters were passed by reference, and
> > when you passed a literal it passed a reference to its location in the
> > literal pool. If the procedure assigned that parameter, it would change
> > the literal.
> >
> > This was probably implementation-dependent, but I've heard that it
> > occurred with many popular implementations.
>
> Hah, I had thought of this as well.
>
> You got really amusing effects when you managed to change the constant
> zero (0) to something else.

And just for the record, back in my Lisp Machine days one of my users
managed to set NIL to non-NIL. SETQ had a check to make sure it wasn't
setting NIL or T, but SET didn't (I may be misremembering the exact
detail -- perhaps a locative was involved as well). Needless to say,
the system was not very happy after this, and it quickly crashed the OS.

I had lots of fun using DDT to figure out what had happened and unwedge
it. In the next OS release, Symbolics aliased the value cells of T and
NIL to a read-only memory page so the hardware would prevent this.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

On 2 Okt., 23:39, "josephoswald...@gmail.com" <josephosw...@gmail.com>
wrote:
> You can't change pi, you change the formulas for the geometric
> quantities, for instance that the angles of a triangle sum to pi + A/
> a^2, instead of simply pi.
>
> Otherwise, your probability and integration and all sorts of other
> libraries will start to give wrong answers, because you have changed
> the formula for a bell-curve and the residue of integrating around a
> pole, and all the other things that pi connects to.

Exactly. Not to mention that in case your system defines -1 as

(defconstant -1 (exp (* pi #(0 1))))

you will suddenly get strange results when evaluating (- 1 1), which
may well be implemented as (+ 1 -1).

Constants are constants for a reason. They provide you with the
fundamentals which you can build your system on. Because of this,
they HAVE TO BE invariant! You need to be able to rely on them never
changing.

Computer science may be considered a branch of mathematics. In
mathematics, it just doesn't make sense to dynamically “redefine” the
fundamentals that you have built your whole system of reasoning on top
of! Especially in logics. Redefine falsity? Umm... no, thanks.

Matthias

kodifik@eurogaran.com writes:

> Pascal J. Bourguignon wrote:
> > > Talking about the possibility of being free to redefine nil, does not
> > > mean I would want to do it.
> > Indeed. Personnaly, I'm quite worried by the hardcoding of neutral
> > charge into neutron. Why are we not able to rebind all the neutrons
> > in the universe to some charge? Try to imagine what would happen if
> > suddenly all the neutrons were -2e.
> In contrast to the enforcement of NIL's value, it is not forbidden to
> make computer simulations of what you say. That's the difference.

Nor it is forbidden to make computer simulations of interpreters that
can rebind nil. In fact, the simplest way to do that is to create your
own package and then build an interpreter for this new lisp language.
As a bonus, you get to leverage all of the existing lisp machinery.

So, why not write such an interpreter and see how well it works?

--
Thomas A. Russ, USC/Information Sciences Institute