As we all know, in Common Lisp logical falsehood is represented by the
non-symbolic atom NIL, which in turn happens to be also the empty list
'().
Everything not nil is true, so in lisp 0 is true.
If -however- NIL were a symbol, one could program things like (let
((nil 0)(number iterations)) (loop while number..) which would
simplify code very often, as the C dudes quickly noticed.
1- I wonder whether there is some really important (theoretical)
reason for not making NIL setf-able, aside implementation simplicity
or speed considerations (practical reasons).
Of course, the programmer would have then to keep in mind that (cons a
nil) could no longer yield (a), and things like that. In other words:
the language would be much more powerful with a redefinable falsehood,
but with greater power comes greater responsibility.
2- Actually, the very fact that the reserved word NIL exists seems to
suggest that this possibility was once regarded.
On Oct 1, 5:35 am, ·······@eurogaran.com wrote:
> As we all know, in Common Lisp logical falsehood is represented by the
> non-symbolic atom NIL, which in turn happens to be also the empty list
> '().
> Everything not nil is true, so in lisp 0 is true.
> If -however- NIL were a symbol, one could program things like (let
> ((nil 0)(number iterations)) (loop while number..) which would
> simplify code very often, as the C dudes quickly noticed.
> 1- I wonder whether there is some really important (theoretical)
> reason for not making NIL setf-able, aside implementation simplicity
> or speed considerations (practical reasons).
> Of course, the programmer would have then to keep in mind that (cons a
> nil) could no longer yield (a), and things like that. In other words:
> the language would be much more powerful with a redefinable falsehood,
> but with greater power comes greater responsibility.
> 2- Actually, the very fact that the reserved word NIL exists seems to
> suggest that this possibility was once regarded.
This is code that I hope no one finds particularly useful or
interesting, but if you want behavior like this, you can get it in
Common Lisp.
;;==================================================
(defpackage #:uncommon-lisp
(:use "COMMON-LISP")
(:shadow "NIL")
(:documentation "A package that is like Common
Lisp, but which does define the symbol nil as a
constant. It can be rebound lexically, or could
be defined (by a user) as a special variable. None
of the library functions have been redefined, though,
so it is not know whether, e.g., NULL, ENDP, among
others, work as expected (as expected?)."))
(in-package #:uncommon-lisp)
(let ((nil 0)
(number 10))
(loop until (eql nil number)
do (print (decf number))))
(let ((nil '()))
(cons 'a nil))
(let ((nil 'b))
(cons 'a nil))
;;==================================================
(defpackage #:uncommon-lisp2
(:use "COMMON-LISP")
;; The symbol itself
(:shadow
#:nil)
;; Functions that depend on NIL in some way
(:shadow
;; many entries here, including...
#:null)
(:documentation "A package that is like Common
Lisp, but which defines NIL as a special variable
using defvar. NIL can then be dynamically rebound.
Functions like NULL, and anything which depends on
NIL and T being truth values would need to be
redefined to use UNCOMMON-LISP2:NIL. Stricter
definitions would be needed for some functions. E.g.,
does MAPCAR end a list with '() or with the dynamic
value of NIL. (I'd go for '(), but both are options.)
Are proper lists those that have a terminating '()
or a terminating NIL? This could cause lists to be
proper in one context, and improper in another, so again
I'd go with '()."))
(in-package #:uncommon-lisp2)
(defvar nil cl:nil)
(defun null (object)
;; should this be eq, eql, equal, equalp?
;; Now nil could be anything...
(eql object nil))
;; But, presumably endp would still compare objects
;; againt '(), mapcar would still terminate lists
;; with '(), and so on...
(cons 'a nil)
;; => (a)
(let ((nil 0)
(iterations 10))
;; of course, really LOOP would be redefined
;; so that until and while check against the
;; uncommon-lisp2:nil...
(loop until (null iterations)
do (print (decf iterations))))
;; => CL:NIL
(setf nil 'b)
;; => b
(cons 'a nil)
;; => (a . b)
(list (null 'a)
(let ((nil 'a))
(null 'a)))
;; => (CL:NIL T)
Joshua Taylor wrote:
> (:documentation "A package that is like Common
> Lisp, but which defines NIL as a special variable
> using defvar. NIL can then be dynamically rebound.
> Functions like NULL, and anything which depends on
> NIL and T being truth values would need to be
> redefined to use UNCOMMON-LISP2:NIL. Stricter
> definitions would be needed for some functions. E.g.,
> does MAPCAR end a list with '() or with the dynamic
> value of NIL. (I'd go for '(), but both are options.)
> Are proper lists those that have a terminating '()
> or a terminating NIL? This could cause lists to be
> proper in one context, and improper in another, so again
> I'd go with '()."))
Indeed. What I discussed implies a previous separation of the concepts
list termination / empty list from the concept of logical falsehood
(prior to being able to redefine falsehood).
·······@eurogaran.com wrote:
> Indeed. What I discussed implies a previous separation of the concepts
> list termination / empty list from the concept of logical falsehood
> (prior to being able to redefine falsehood).
In Common Lisp (and many other dialects), the empty list represents
"false". The empty list is represented by the symbol NIL. If you don't
like these, you could use Scheme, which uses the special values #t and
#f for truth and falsehood, and where the list end () is different from
#f. Some people think this is cleaner (I don't).
Matthias Buelow wrote:
> In Common Lisp (and many other dialects), the empty list represents
> "false". The empty list is represented by the symbol NIL. If you don't
> like these, you could use Scheme, which uses the special values #t and
> #f for truth and falsehood, and where the list end () is different from
> #f. Some people think this is cleaner (I don't).
Neither Scheme has the freedom to redefine/reassign #f.
In other words, suppose I would like to (let ((#f '()))...
P� Wed, 01 Oct 2008 16:20:31 +0200, skrev <·······@eurogaran.com>:
> Matthias Buelow wrote:
>> In Common Lisp (and many other dialects), the empty list represents
>> "false". The empty list is represented by the symbol NIL. If you don't
>> like these, you could use Scheme, which uses the special values #t and
>> #f for truth and falsehood, and where the list end () is different from
>> #f. Some people think this is cleaner (I don't).
> Neither Scheme has the freedom to redefine/reassign #f.
> In other words, suppose I would like to (let ((#f '()))...
Don't do that!
Redefining constants defeats the purpose of making them constant in the
first place. Things are presumably declared that way because the designer
wants the term to mean one and only one thing. Why would you want to
redefine a empty set to mean a set containing the integer 0 in some
contexts? Or in the Sceeme case the boolean value false. Ambiguity is just
a source of obscurity.
--------------
John Thingstad
John Thingstad wrote:
> > In other words, suppose I would like to (let ((#f '()))...
>
> Don't do that!
Don't make Scheme closer to Common Lisp! ;)
> Redefining constants defeats the purpose of making them constant in the
> first place. Things are presumably declared that way because the designer
> wants the term to mean one and only one thing. Why would you want to
> redefine a empty set to mean a set containing the integer 0 in some
> contexts?
Because it could simplify code, it can allow changing program behavior
on the fly, and more flexibility overall.
> Ambiguity is just a source of obscurity.
Beware it is not properly ambiguity, since NIL would always have one
value at any given time.
P� Wed, 01 Oct 2008 17:37:27 +0200, skrev <·······@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
John Thingstad wrote:
> P� Wed, 01 Oct 2008 17:37:27 +0200, skrev <·······@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).
På Wed, 01 Oct 2008 18:50:09 +0200, skrev <·······@eurogaran.com>:
> John Thingstad wrote:
>> P� Wed, 01 Oct 2008 17:37:27 +0200, skrev <·······@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
John Thingstad wrote:
> 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)?
eql is a function, so it evaluates its arguments first.
It would then be the same as (eql [value of val] 0).
·······@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.
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.
·······@eurogaran.com writes:
> Matthias Buelow wrote:
>> In Common Lisp (and many other dialects), the empty list represents
>> "false". The empty list is represented by the symbol NIL. If you don't
>> like these, you could use Scheme, which uses the special values #t and
>> #f for truth and falsehood, and where the list end () is different from
>> #f. Some people think this is cleaner (I don't).
> Neither Scheme has the freedom to redefine/reassign #f.
> In other words, suppose I would like to (let ((#f '()))...
You must be very very sad. I know of no programming language
allowing you to redefined/reassing 42. I suppose you would like to do
(let ((42 101010)) (* 42 2)) too...
--
__Pascal Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he does not
want merely because you think it would be good for him. -- Robert Heinlein
Pascal J. Bourguignon wrote:
> You must be very very sad. I know of no programming language
> allowing you to redefined/reassing 42. I suppose you would like to do
> (let ((42 101010)) (* 42 2)) too...
Looks like you don't know Forth :-)
: 42 77 ;
42 1 + -> 78
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Pascal J. Bourguignon writes:
> ·······@eurogaran.com writes:
>
> > Matthias Buelow wrote:
> >> In Common Lisp (and many other dialects), the empty list represents
> >> "false". The empty list is represented by the symbol NIL. If you don't
> >> like these, you could use Scheme, which uses the special values #t and
> >> #f for truth and falsehood, and where the list end () is different from
> >> #f. Some people think this is cleaner (I don't).
> > Neither Scheme has the freedom to redefine/reassign #f.
> > In other words, suppose I would like to (let ((#f '()))...
>
> You must be very very sad. I know of no programming language
> allowing you to redefined/reassing 42. I suppose you would like to do
> (let ((42 101010)) (* 42 2)) too...
>
In forth maybe:
: 42 101010 ; ok
42 2 * . 202020 ok
I don't know if this is really useful...
Barry Margolin <······@alum.mit.edu> writes:
> In article <··············@hubble.informatimago.com>,
> ···@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
In article <···············@blackcat.isi.edu>,
···@sevak.isi.edu (Thomas A. Russ) wrote:
> Barry Margolin <······@alum.mit.edu> writes:
>
> > In article <··············@hubble.informatimago.com>,
> > ···@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, ······@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 ***
Joshua Taylor wrote:
> ;; But, presumably endp would still compare objects
> ;; againt '(), mapcar would still terminate lists
> ;; with '(), and so on...
That's because these functions use common-lisp:nil, not uncommon-lisp:nil.
If you could redefine common-lisp:nil, all hell would break loose.
I would think that about all uses of NIL rely on the fact that (eq
common-lisp:nil 'common-lisp:nil), both in the Lisp implementation
aswell as user code. Or who writes (cons 1 (cons 2 'nil))?
P� Wed, 01 Oct 2008 11:35:15 +0200, skrev <·······@eurogaran.com>:
> As we all know, in Common Lisp logical falsehood is represented by the
> non-symbolic atom NIL, which in turn happens to be also the empty list
> '().
> Everything not nil is true, so in lisp 0 is true.
> If -however- NIL were a symbol, one could program things like (let
> ((nil 0)(number iterations)) (loop while number..) which would
> simplify code very often, as the C dudes quickly noticed.
> 1- I wonder whether there is some really important (theoretical)
> reason for not making NIL setf-able, aside implementation simplicity
> or speed considerations (practical reasons).
> Of course, the programmer would have then to keep in mind that (cons a
> nil) could no longer yield (a), and things like that. In other words:
> the language would be much more powerful with a redefinable falsehood,
> but with greater power comes greater responsibility.
> 2- Actually, the very fact that the reserved word NIL exists seems to
> suggest that this possibility was once regarded.
I thing your (loop while number ...) illustrates nicely.
Remember in Lisp variables don't have type object's do. 0 is of number
(subtypep). Unlike in C you don't need special numbers to specify a
termination condition.
Instead you just return a nil object. Nil is defined as a type that is the
subtype of all types, but only a member of null.
Having nil take on other values violates the second part.
--------------
John Thingstad
John Thingstad wrote:
> I thing your (loop while number ...) illustrates nicely.
> Remember in Lisp variables don't have type object's do. 0 is of number
> (subtypep). Unlike in C you don't need special numbers to specify a
> termination condition.
> Instead you just return a nil object. Nil is defined as a type that is the
> subtype of all types, but only a member of null.
>Having nil take on other values violates the second part.
I don't understand. NIL seems to be an object of type list:
(listp nil)
T
(numberp nil)
NIL
P� Wed, 01 Oct 2008 16:33:26 +0200, skrev <·······@eurogaran.com>:
> John Thingstad wrote:
>> I thing your (loop while number ...) illustrates nicely.
>> Remember in Lisp variables don't have type object's do. 0 is of number
>> (subtypep). Unlike in C you don't need special numbers to specify a
>> termination condition.
>> Instead you just return a nil object. Nil is defined as a type that is
>> the
>> subtype of all types, but only a member of null.
>> Having nil take on other values violates the second part.
> I don't understand. NIL seems to be an object of type list:
> (listp nil)
> T
> (numberp nil)
> NIL
In CL listp is defined as (define listp (candidate) (or (consp candidate)
(null candidate))
Ie cons elements are considered a list and an empty list denoted by nil or
'() is a list.
Lists are thus a composite type. Merly a convenience. The atomic one is
cons.
--------------
John Thingstad
In article
<····································@x35g2000hsb.googlegroups.com>,
·······@eurogaran.com wrote:
> As we all know, in Common Lisp logical falsehood is represented by the
> non-symbolic atom NIL, which in turn happens to be also the empty list
> '().
> Everything not nil is true, so in lisp 0 is true.
> If -however- NIL were a symbol, one could program things like (let
> ((nil 0)(number iterations)) (loop while number..) which would
> simplify code very often, as the C dudes quickly noticed.
> 1- I wonder whether there is some really important (theoretical)
> reason for not making NIL setf-able, aside implementation simplicity
> or speed considerations (practical reasons).
> Of course, the programmer would have then to keep in mind that (cons a
> nil) could no longer yield (a), and things like that. In other words:
> the language would be much more powerful with a redefinable falsehood,
> but with greater power comes greater responsibility.
> 2- Actually, the very fact that the reserved word NIL exists seems to
> suggest that this possibility was once regarded.
NIL is a symbol. It is a constant that evaluates to itself.
It is similar to this:
[1]> (defconstant bar 'bar)
BAR
[2]> (let ((bar 3)) bar)
*** - LET: BAR is a constant, may not be used as a variable
You can't bind or set constants.
--
http://lispm.dyndns.org/
k> As we all know, in Common Lisp logical falsehood is represented by the
k> non-symbolic atom NIL,
what is non-symbolic in NIL?
* (symbolp nil)
T
* (symbol-name nil)
"NIL"
looks like a symbol for me.
k> If -however- NIL were a symbol, one could program things like (let
k> ((nil 0)(number iterations)) (loop while number..)
it seems you're confusing symbols with variables.
it's just not all symbols can be used as variables. besides NIL and T,
all keyword symbols can not.
couldn't you actually try this in some Common Lisp implementation instead
of writing bullshit here?
[1]> (let ((nil 0)) nil)
*** - LET: NIL is a constant, may not be used as a variable
[3]> (let ((:boo 0)) :boo)
*** - LET: :BOO is a constant, may not be used as a variable
k> which would simplify code very often,
k> as the C dudes quickly noticed.
LOOP has arithmetic clauses that make using numbers as boolean less
important.
e.g. you can just write (loop repeat iterations ...). try this in C.
even if you have to use number in condition, i doubt that
(let ((NIL 0)) (loop while number ...
is better than
(loop while (plusp number) ...
k> 1- I wonder whether there is some really important (theoretical) reason
k> for not making NIL setf-able, aside implementation simplicity or speed
k> considerations (practical reasons).
sanity is such reason. setfable NIL simply does not make sense, it will
make programming more cryptic.
k> the language would be much more powerful with a redefinable falsehood,
k> but with greater power comes greater responsibility.
if you really think that random bullshit makes language more powerful,
you should use Perl.
> what is non-symbolic in NIL?
Nothing. I was really wrong in that. Sorry.
> [1]> (let ((nil 0)) nil)
>
> *** - LET: NIL is a constant, may not be used as a variable
>
Thank you all folks for pointing out that NIL is in fact a symbol
(only a constant, not a variable).
That rewrites my question completely, but it does not answer it.
> LOOP has arithmetic clauses that make using numbers as boolean less
> important.
> e.g. you can just write (loop repeat iterations ...). try this in C.
> ...bullshit...bullshit...
> (loop while (plusp number) ...
>
Look like workarounds, however elegant they are.
> k> 1- I wonder whether there is some really important (theoretical) reason
> k> for not making NIL setf-able, aside implementation simplicity or speed
> k> considerations (practical reasons).
>
> sanity is such reason. setfable NIL simply does not make sense, it will
> make programming more cryptic.
That can be said about setfable variables in general.
By forbidding assignment one does functional style programming,
admittedly clearer and cleaner. None can dispute that.
>
> k> the language would be much more powerful with a redefinable falsehood,
> k> but with greater power comes greater responsibility.
>
> if you really think that random bullshit makes language more powerful,
> you should use Perl.
If you think that pre-established, pre-assigned bullshit makes a
language more powerful, you should use C.
On Oct 1, 11:35 am, ·······@eurogaran.com wrote:
> As we all know, in Common Lisp logical falsehood is represented by the
> non-symbolic atom NIL, which in turn happens to be also the empty list
> '().
> Everything not nil is true, so in lisp 0 is true.
> If -however- NIL were a symbol, one could program things like (let
> ((nil 0)(number iterations)) (loop while number..) which would
> simplify code very often, as the C dudes quickly noticed.
You can setf a symbol named nil. In a modular way.
(in-package :cl-user)
(defpackage :odd
(:use :cl)
(:shadow :nil))
(in-package :odd)
;; Now the fun begins.
(defparameter nil 10)
(loop repeat nil
collect nil)
;; => (10 10 10 10 10 10 10 10 10 10)
Tayssir
·······@eurogaran.com wrote:
> 1- I wonder whether there is some really important (theoretical)
> reason for not making NIL setf-able, aside implementation simplicity
> or speed considerations (practical reasons).
Yeah, so that people don't fuck with it the way you intend to.
Besides:
> (make-package "NOREPINEPHRINE-REUPTAKE-INHIBITOR")
#<PACKAGE NOREPINEPHRINE-REUPTAKE-INHIBITOR>
> (in-package "NOREPINEPHRINE-REUPTAKE-INHIBITOR")
#<PACKAGE NOREPINEPHRINE-REUPTAKE-INHIBITOR>
> (unuse-package "COMMON-LISP")
COMMON-LISP:T
> (common-lisp:defvar nil 0)
NIL
> nil
0
·······@eurogaran.com wrote:
> As we all know, in Common Lisp logical falsehood is represented by the
> non-symbolic atom NIL, which in turn happens to be also the empty list
> '().
> Everything not nil is true, so in lisp 0 is true.
> If -however- NIL were a symbol, one could program things like (let
> ((nil 0)(number iterations)) (loop while number..) which would
> simplify code very often, as the C dudes quickly noticed.
> 1- I wonder whether there is some really important (theoretical)
> reason for not making NIL setf-able, aside implementation simplicity
> or speed considerations (practical reasons).
> Of course, the programmer would have then to keep in mind that (cons a
> nil) could no longer yield (a), and things like that. In other words:
> the language would be much more powerful with a redefinable falsehood,
> but with greater power comes greater responsibility.
> 2- Actually, the very fact that the reserved word NIL exists seems to
> suggest that this possibility was once regarded.
(loop until (zerop number) ...)
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> (loop until (zerop number) ...)
Quite right, doctor. I am not sure the example (loop while number...)
was very fortunate.
What I talked about is something more far-reaching: it would allow for
instance to change the behavior of a running program on the fly
without rewriting it, just by reassigning the symbol nil.
In your solution, the finalization condition is hard-coded.
I am asking why is nil hard-coded in Common Lisp, when it has always
been said that hard-coding things is a mark of bad program design.
Talking about the possibility of being free to redefine nil, does not
mean I would want to do it.
On Wed, 01 Oct 2008 07:09:43 -0700, kodifik wrote:
> Pascal Costanza wrote:
>> (loop until (zerop number) ...)
> Quite right, doctor. I am not sure the example (loop while number...)
> was very fortunate.
> What I talked about is something more far-reaching: it would allow for
> instance to change the behavior of a running program on the fly without
> rewriting it, just by reassigning the symbol nil. In your solution, the
Nope. What you talked about is how to force some way of thinking (that
you possibly acquired elsewhere, but I have no idea where) on Lisp.
> finalization condition is hard-coded. I am asking why is nil hard-coded
> in Common Lisp, when it has always been said that hard-coding things is
> a mark of bad program design. Talking about the possibility of being
> free to redefine nil, does not mean I would want to do it.
I don't see the merit of what you propose. My guess would be that you
are new to CL and don't really understand the language, but that is OK,
in time you will learn.
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 (hint: having constants in a language is not "hard-coding").
I suggest that you
1. try to come up with an example where your proposal would really help,
2. devote at least a couple of minutes of your time to thinking about how
it would be done in standard CL,
3. if 1. offers some benefit over 2. (which I doubt, but let's keep an
open mind), then post it here. Your loop example of course does not
satisfy this test.
HTH,
Tamas
Tamas K Papp wrote:
> What you talked about is how to force some way of thinking (that
> you possibly acquired elsewhere, but I have no idea where) on Lisp.
Maybe I had the (wrong?) impression that Lisp could harbour any
approach to programming.
> I don't see the merit of what you propose.
The merit is freedom.
> My guess would be that you
> are new to CL and don't really understand the language, but that is OK,
> in time you will learn.
Absolutely yes. My profession is student, and it will always be.
That's why I am asking the reasons/rationale/motivations to hard-code
NIL
in the language. Oh great savvy!
> 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.
> (hint: having constants in a language is not "hard-coding")
Yes it is.
> I suggest that you
>
> 1. try to come up with an example where your proposal would really help,
>
> 2. devote at least a couple of minutes of your time to thinking about how
> it would be done in standard CL,
>
> 3. if 1. offers some benefit over 2. (which I doubt, but let's keep an
> open mind), then post it here. Your loop example of course does not
> satisfy this test.
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?
In article
<····································@l76g2000hse.googlegroups.com>,
·······@eurogaran.com wrote:
> Tamas K Papp wrote:
> > What you talked about is how to force some way of thinking (that
> > you possibly acquired elsewhere, but I have no idea where) on Lisp.
> Maybe I had the (wrong?) impression that Lisp could harbour any
> approach to programming.
It can. You can do what you say you want like this:
? (make-package :foo)
#<Package "FOO">
? (in-package :foo)
#<Package "FOO">
? (shadow '(nil))
T
? (intern "NIL")
NIL
:INTERNAL
? (setf nil 123)
123
? nil
123
?
But I suspect this is not quite what you really want ;-)
I suspect that what you "really" want is something more like this:
? (shadow '(if))
T
? (defmacro if (cond then else) `(cl:if (->boolean ,cond) ,then ,else))
IF
? (defmethod ->boolean ((x number)) (not (zerop x)))
#<STANDARD-METHOD ->BOOLEAN (NUMBER)>
? (if 1 2 3)
2
? (if 0 2 3)
3
Of course, you'll need to do something similar for all the built-in
special forms and macros that contain implicit booleans. But you only
have to do that once, and then you will have achieved nirvana forever.
Careful what you wish for.
rg
·······@eurogaran.com wrote:
> Tamas K Papp wrote:
>
>> I don't see the merit of what you propose.
> The merit is freedom.
>
>> My guess would be that you
>> are new to CL and don't really understand the language, but that is OK,
>> in time you will learn.
> Absolutely yes. My profession is student, and it will always be.
> That's why I am asking the reasons/rationale/motivations to hard-code
> NIL
> in the language. Oh great savvy!
Decades of experience has led language designers to see the usefulness
of constants, not only for faster compiled code, but to reduce hard to
fix errors in code. You're free to find or resurrect these older
languages if the trade-off of freedom for easier programming and
debugging is not to your liking.
I and another programmer spent a day trying to figure out why a function
A worked on its own but not when called by function B. A had a COND. It
turned out B had (LET ((T NIL)) ... (A ...) ..) -- T seemed like a
reasonable name in context -- so the (COND ... (T ...)) in A never
executed the else branch. I'd like that day back, please.
Early implementations of Fortran let you change the value of 2, albeit
it would normally happen accidentally.
http://everything2.com/e2node/Changing%2520the%2520value%2520of%25205%2520in%2520FORTRAN
Imagine the debugging time that would involve.
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
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.
·······@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?
On Oct 1, 12:07 pm, ·······@eurogaran.com wrote:
> 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?
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.
--S
In article
<····································@v28g2000hsv.googlegroups.com>,
smallpond <·········@juno.com> wrote:
> On Oct 1, 12:07 pm, ·······@eurogaran.com wrote:
> > 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?
>
> 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.
>
> --S
Common Lisp already has a mechanism for this:
(let ((*read-base* 26))
(read-from-string "16"))
-> 32
;-)
--
http://lispm.dyndns.org/
·······@eurogaran.com wrote:
> Again: Is there a FUNDAMENTAL reason? or purely practical
> considerations?
It's because of practical considerations. Satisfied?
From: Joost Diepenmaat
Subject: Re: Why not a setf-able NIL ?
Date:
Message-ID: <87od24kvu9.fsf@zeekat.nl>
·······@eurogaran.com writes:
> 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?
I would imagine setting nil to t would break just about every function you'd
call. Is that good enough?
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
·······@eurogaran.com wrote:
> 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?
You want nonstandard interpretation. As you can see from
ftp://ftp.ecn.purdue.edu/qobi/popl2007b.pdf this is not so easy to achieve.
It's one thing to want a 'cool' language feature, it's another to make
it actually work.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
·······@eurogaran.com wrote:
> I am asking why is nil hard-coded in Common Lisp, when it has always
> been said that hard-coding things is a mark of bad program design.
Well, obviously you have to agree on _some_ value to mark the end of a
list with, and for some reason, it has been decided to make the symbol
NIL this marker. It could also have been 0 or the string "this is the
end, my friend". How would you do it differently?
·······@eurogaran.com writes:
> Pascal Costanza wrote:
>> (loop until (zerop number) ...)
> Quite right, doctor. I am not sure the example (loop while number...)
> was very fortunate.
> What I talked about is something more far-reaching: it would allow for
> instance to change the behavior of a running program on the fly
> without rewriting it, just by reassigning the symbol nil.
> In your solution, the finalization condition is hard-coded.
> I am asking why is nil hard-coded in Common Lisp, when it has always
> been said that hard-coding things is a mark of bad program design.
> 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.
--
__Pascal Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he does not
want merely because you think it would be good for him. -- Robert Heinlein
Pascal J. Bourguignon wrote:
> 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.
I also like the following quote:
" -----Direct Quote from the Fortran manual for Xerox computers
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. :)
On 2 Okt., 23:39, ················@gmail.com" <············@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
·······@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