From: Hannah Schroeter
Subject: Redefining CAR/CDR/other standard symbols (was Re: [Q] Dylan to Java/JVM compiler?)
Date: 
Message-ID: <9de8ff$mca$1@c3po.schlund.de>
Hello!

In article <·················@no.spam.mindspring.com.no.spam>,
Lyman Taylor  <············@no.spam.mindspring.com.no.spam> wrote:
>Lieven Marchand wrote:
>....
>> <off-topic>
>> BTW, why does LispWorks complain about the equivalent CL code? The
>> Hyperspec specifically allows users to augment the MAKE-INSTANCE
>> generic function.

>  The Hyperspec allows users to define CAR and CDR. 
>  That doesn't mean a prudent implementation might not warn
>  you or ask for confirmation before carrying that out. ;-) 

Huh?

In section 11.1.2.1.2 of the Hyperspec, you find:

11.1.2.1.2 Constraints on the COMMON-LISP Package for Conforming Programs
   
   Except where explicitly allowed, the consequences are undefined if any
   of the following actions are performed on an [12]external symbol of
   the COMMON-LISP package:
   
   1. [13]Binding or altering its value (lexically or dynamically). (Some
          exceptions are noted below.)
       
   2. Defining, undefining, or [14]binding it as a [15]function. (Some
          exceptions are noted below.)
     
   3. Defining, undefining, or [16]binding it as a [17]macro or
          [18]compiler macro. (Some exceptions are noted below.)

[...]

So I'd guess a (defun car ...) has undefined consequences.

>[...]

Kind regards,

Hannah.

[XP+F'up c.l.lisp]

From: Lyman Taylor
Subject: Re: Redefining CAR/CDR/other standard symbols (was Re: [Q] Dylan to  Java/JVM compiler?)
Date: 
Message-ID: <3AFAC88F.72F68F5C@NO.SPAM.mindspring.com.no.spam>
Hannah Schroeter wrote:
...
> >> Hyperspec specifically allows users to augment the MAKE-INSTANCE
> >> generic function.
...
> >  The Hyperspec allows users to define CAR and CDR.
...
> Huh?

   I didn't use "specifically allows" in my response on purpose. :-) 
   Sorry, I should have stated I was drawing an analogy. 
   It was an analogous context I was trying to illustrate. 
   They probably are not completely equivalent in the light of the 
   standard's legalese language. 

   Pragmatically it "allows" users to do this.   "Undefine consequences"
   means 
          1.  It is not portable across implementations. 
          2.  The behaviour taken is left to the implementors discretion.   
              The implementor has 4 broad choices. 

                  i.  "do what I mean"
                  ii.  warn and "do what I mean" 
                  iii.  (cerror ...)  and the first restart is 
                              "do what I mean".
                  iv.  disallow;  issue an (error ... ) 
              
              In three out of these four cases this is "allowed"; in a
              colloquial sense of the word.   

   Analogous point 1. was that implementations may do something different.
   Analogous point 2  ii. was that Lispworks seemed to "allow" this,
   but was really issuing an "are you sure?" dialog. 

   The Hyperspec lists a portion of MAKE-INSTANCE's defintion as "...".
   What if in a implementation that is a really import part of maintaining
   system integrity?  Wouldn't it be prudent to do an "are you sure?" 
   dialog before the system defined version was replaced?  Perhaps not 
   for an abstract class, but for a concrete it seems like it would. 


Lyman
From: Barry Margolin
Subject: Re: Redefining CAR/CDR/other standard symbols (was Re: [Q] Dylan to  Java/JVM compiler?)
Date: 
Message-ID: <GLAK6.13$oj7.508@burlma1-snr2>
In article <·················@NO.SPAM.mindspring.com.no.spam>,
Lyman Taylor  <············@NO.SPAM.mindspring.com.no.spam> wrote:
>   Pragmatically it "allows" users to do this.   "Undefine consequences"
>   means 
>          1.  It is not portable across implementations. 
>          2.  The behaviour taken is left to the implementors discretion.   
>              The implementor has 4 broad choices. 
>
>                  i.  "do what I mean"
>                  ii.  warn and "do what I mean" 
>                  iii.  (cerror ...)  and the first restart is 
>                              "do what I mean".
>                  iv.  disallow;  issue an (error ... ) 
>              
>              In three out of these four cases this is "allowed"; in a
>              colloquial sense of the word.   

No.  "Undefined consequences" means that *anything* can happen; to quote
from the standard, "the consequences may range from harmless to fatal."
For instance (car <number>) in unsafe code is likely to cause a
segmentation violation in Unix implementations.

Your list of potential actions is closer to the intent of "unspecified
consequences", which is defined as "unpredictable but harmless."

-- 
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Erik Naggum
Subject: Re: Redefining CAR/CDR/other standard symbols (was Re: [Q] Dylan to  Java/JVM compiler?)
Date: 
Message-ID: <3198510607976083@naggum.net>
* Lyman Taylor <NO.SPAM.no.spam>
> Pragmatically it "allows" users to do this.

  You cannot redefine common-lisp:car and common-lisp:cdr as functions, but
  you may certainly define a foobar:car and foobar:cdr and shadow-import
  them into a package that otherwise uses the common-lisp package.

  The section you quote from is concerned with symbols in the common-lisp
  package, not symbols with the same name as those in the common-lisp
  package.  This confuses a lot of people from one-namespace, no-packages
  languages.

  If you really want a different make-instance, perform the same trick.

#:Erik
-- 
  Travel is a meat thing.
From: Kent M Pitman
Subject: Re: Redefining CAR/CDR/other standard symbols (was Re: [Q] Dylan to   Java/JVM compiler?)
Date: 
Message-ID: <sfwheys8zn3.fsf@world.std.com>
Lyman Taylor <············@NO.SPAM.mindspring.com.no.spam> writes:

> Hannah Schroeter wrote:
> ...
> > >> Hyperspec specifically allows users to augment the MAKE-INSTANCE
> > >> generic function.
> ...
> > >  The Hyperspec allows users to define CAR and CDR.
> ...
> > Huh?
> 
>    I didn't use "specifically allows" in my response on purpose. :-) 
>    Sorry, I should have stated I was drawing an analogy. 
>    It was an analogous context I was trying to illustrate. 
>    They probably are not completely equivalent in the light of the 
>    standard's legalese language. 
> 
>    Pragmatically it "allows" users to do this.   "Undefine consequences"
>    means 
>           1.  It is not portable across implementations. 
>           2.  The behaviour taken is left to the implementors discretion.   
>               The implementor has 4 broad choices. 
> 
>                   i.  "do what I mean"
>                   ii.  warn and "do what I mean" 
>                   iii.  (cerror ...)  and the first restart is 
>                               "do what I mean".
>                   iv.  disallow;  issue an (error ... ) 
>               
>               In three out of these four cases this is "allowed"; in a
>               colloquial sense of the word.   
> 

Please do NOT make up meanings for things, and when you are making up things
please be sure to plainly identify what you have written as "manufactured"
rather than putting it in this kind of neatly displayed form that you have
chosen, which falsely suggests you have taken it from an authoritative source
rather than just making it up out of whole cloth. 

The Common Lisp HyperSpec (which uses wording identical to the ANSI CL 
standard itself), chapter 1.4.2 (Error Terminology) states:

| The consequences are undefined
| 
| This means that the consequences are unpredictable. The consequences
| may range from harmless to fatal. No conforming code may depend on the
| results or effects. Conforming code must treat the consequences as
| unpredictable. In places where the words ``must,'' ``must not,'' or
| ``may not'' are used, then ``the consequences are undefined'' if the
| stated requirement is not met and no specific consequence is explicitly
| stated. An implementation is permitted to signal an error in this case. 
| 
| For example: ``Once a name has been declared by defconstant to be
| constant, any further assignment or binding of that variable has 
| undefined consequences.''
From: Lyman Taylor
Subject: Re: Redefining CAR/CDR/other standard symbols (was Re: [Q] Dylan to    Java/JVM compiler?)
Date: 
Message-ID: <3AFC3CB2.C8F80423@NO.SPAM.mindspring.com.no.spam>
Kent M Pitman wrote:
...
> Lyman Taylor <············@NO.SPAM.mindspring.com.no.spam> writes:
...
> >    Pragmatically it "allows" users to do this.   "Undefine consequences"
> >    means

  I should have said "implies" (or better still just avoided explaining
  in standards terminology ) and I was merging elements of 
  unspecified consequences as Barry pointed out.  I apologize for the
  confusion I may have caused. 

> rather than putting it in this kind of neatly displayed form that you have
> chosen, which falsely suggests you have taken it from an authoritative 

  I was using the format to line up the mapping to the analogy.  If I had
  meant to site a legal authority I would have linked in the Hyperspec.
  The authoritative source I was drawing from was experience with several
  lisp implementations with that example. (which not suprisingly doesn't  
  include "segmentation fault"-like fatal consequences for these specific
  examples). 

  What I should have said was at this threads origin was: 
  Some implementations allow you to do  highly dubious things (like 
  redefine "core" functions ) without even the slightest warning. That's 
  allowed because the standard says that's acceptable. Other implementations
  take varying degrees of proactive measures to warn you that you may 
  have just shot yourself in the foot (or are in the process of doing so). 

  In light the full ramifications of the standard language,
  that should also include not so proactive measures involving the lisp
  environment dying with illdescriptive error messages. ;-)


Lyman
From: Barry Margolin
Subject: Re: Redefining CAR/CDR/other standard symbols (was Re: [Q] Dylan to    Java/JVM compiler?)
Date: 
Message-ID: <87YK6.56$oj7.1050@burlma1-snr2>
In article <·················@NO.SPAM.mindspring.com.no.spam>,
Lyman Taylor  <············@NO.SPAM.mindspring.com.no.spam> wrote:
>  I was using the format to line up the mapping to the analogy.  If I had
>  meant to site a legal authority I would have linked in the Hyperspec.
>  The authoritative source I was drawing from was experience with several
>  lisp implementations with that example. (which not suprisingly doesn't  
>  include "segmentation fault"-like fatal consequences for these specific
>  examples). 

Given how most implementations work, redefining built-in functions is
probably not going to cause OS-level problems like segfaults, except
perhaps on Lisp Machines where the built-in functions *are* the OS.  Some
very basic functions, like CAR/CDR/CONS, are open-coded in practically all
implementations, so you can get away with quite a bit there.  But I can
easily imagine redefining something like MAKE-ARRAY resulting in infinite
recursions.  Suppose the implementation has an extension to MAKE-ARRAY, but
your redefinition doesn't include that, and the implementation's error
handler calls MAKE-ARRAY with that extended option; as soon as you get an
error, it will call MAKE-ARRAY, which will generate a "bad keyword
argument" error, which will invoke the error handler, and voila! you're in
an error loop.  Eventually you exceed the stack depth limit, which
generates a new error, which recurses infinitely some more (I guess now
we're talking aleph-1 recursion), and soon something has to give and Lisp
dies.

As another example, until about 10 years ago, Symbolics machines didn't put
NIL's value cell on a write-protected page.  (SETQ NIL ...) didn't do
anything bad, because SETQ checked whether the argument was NIL or T, but
SET NIL didn't have any similar checks.  Someone tripped over this, and
within minutes the OS crashed into the FEP.  The cool thing was that I
managed to put NIL's value cell back the way it should be using DDT.

When we were working on the section of the standard with all the
restrictions on what you can do with symbols in the CL package, we
considered giving users carte blanche.  Implementors would just have to
make sure that they're not dependent on the symbols internally, e.g. they
would call SYSTEM-INTERNALS:MAKE-ARRAY rather than MAKE-ARRAY, so
redefining the latter wouldn't affect them.  But IIRC, we decided against
it for a couple of reasons: 1) This would require lots of work in most
implementations to remove all the dependencies, and 2) many of the
restrictions exist to allow multiple applications to coexist in the same
Lisp environment: if two applications both try to redefine MAKE-ARRAY,
there's a conflict, so we prevent this by legislating against such
definitions.

-- 
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.