From: Paul F. Dietz
Subject: Is there any standardized way to obtain an instance of class METHOD-COMBINATION?
Date: 
Message-ID: <vOadnb16NfyeBIyiXTWJkA@dls.net>
The ANSI CL spec specifies that the standardized class METHOD-COMBINATION exists.
However, I don't see any standard way to obtain an instance of this class.
DEFINE-METHOD-COMBINATION may create such an instance, but it returns the name
of the method combination, not the method combination object.

Is there some way of getting these objects that I missed?

	Paul

From: Marco Antoniotti
Subject: Re: Is there any standardized way to obtain an instance of class METHOD-COMBINATION?
Date: 
Message-ID: <3F11A72D.9010001@cs.nyu.edu>
Yep.  I second that.  Looks like something like

	FIND-METHOD-COMBINATION &rest approriate-args

was forgotten from the spec.

Cheers

marco

Paul F. Dietz wrote:
> The ANSI CL spec specifies that the standardized class 
> METHOD-COMBINATION exists.
> However, I don't see any standard way to obtain an instance of this class.
> DEFINE-METHOD-COMBINATION may create such an instance, but it returns 
> the name
> of the method combination, not the method combination object.
> 
> Is there some way of getting these objects that I missed?
> 
>     Paul
> 
From: Rainer Joswig
Subject: Re: Is there any standardized way to obtain an instance of class METHOD-COMBINATION?
Date: 
Message-ID: <c366f098.0307131502.383731ed@posting.google.com>
Marco Antoniotti <·······@cs.nyu.edu> wrote in message news:<················@cs.nyu.edu>...
> Yep.  I second that.  Looks like something like
> 
> 	FIND-METHOD-COMBINATION &rest approriate-args
> 
> was forgotten from the spec.

Yes, and it even is sometimes needed.

ENSURE-GENERIC-FUNCTION has a parameter METHOD-COMBINATION,
where you sometimes would want to pass a method combination object.

> 
> Cheers
> 
> marco
> 
> Paul F. Dietz wrote:
> > The ANSI CL spec specifies that the standardized class 
> > METHOD-COMBINATION exists.
> > However, I don't see any standard way to obtain an instance of this class.
> > DEFINE-METHOD-COMBINATION may create such an instance, but it returns 
> > the name
> > of the method combination, not the method combination object.
> > 
> > Is there some way of getting these objects that I missed?
> > 
> >     Paul
> >
From: Steven M. Haflich
Subject: Re: Is there any standardized way to obtain an instance of class   METHOD-COMBINATION?
Date: 
Message-ID: <3F11B15F.3010601@alum.mit.edu>
Marco Antoniotti wrote:

> Yep.  I second that.  Looks like something like
> 
>     FIND-METHOD-COMBINATION &rest approriate-args
> 
> was forgotten from the spec.

Sorry, Marco, but your implication that FIND-METHOD-COMBINATION should
have been included in the ANS is not supported by history or logic.

The X3J13 action that adopted CLOS into the draft ANS happened in 1989.
At that time there were no mature industrial implementations and relatively
little experience coding with CLOS.  (PCL existed, but did not qualify as
mature, industrial quality code.)  The most-excellent subcommittee that had
drafted the proposed CLOS standard presented it in three parts, the first
two parts of which were the portion currently embodied in the ANS and the
third of which was the MOP.  They recommended (forcefully!) that the first
two sections be accepted exactly as they stood (since the design of CLOS
is subtle, and innocent plenum committee tweaks could easily have broken
the design) but they recommended justas strongly that the MOP portion be
deferred until there was more experience both implementing and exploiting
the MOP.  This is what X3J13 enacted, and I believe it was the wise path.
Objectively ("objectively" is a synonym for my subjective opinion :-) the
CLOS definition has survived with little need for tweaking, while the MOP
would need a few objectively-minor tweaks before being officially
standardized.

The difficulty in this standardization path was that it was difficult to
specify CLOS and the MOP separately, so that CLOS wcould stand alone
without the MOP and there would be no loose ends in the standalone CLOS
definition.  But the current boundary between CLOS/ANS and the MOP
mostly achieves consistency, even if artificial consistency.  There are
only minor exceptions, and offhand I can't remember what they are.

In the case of METHOD-COMBINATION, there is indeed no way within the ANS
to get a reference to one.  But even if there were such a way, such as
FIND-METHOD-COMBINATION or GENERIC-FUNCTION-METHOD-COMBINATION, there
would still be nothing else of interest within the ANS that one could
do with a METHOD-COMBINATION-OBJECT (other than things that can be done
with every object, like printing or passing to TYPE-OF).  There would be
no use to having a handle on a METHOD-COMBINATION without also dragging
in significant portions of the MOP.
From: Kent M Pitman
Subject: Re: Is there any standardized way to obtain an instance of class METHOD-COMBINATION?
Date: 
Message-ID: <sfwr84uyper.fsf@shell01.TheWorld.com>
"Steven M. Haflich" <·················@alum.mit.edu> writes:

> Marco Antoniotti wrote:
> 
> > Yep.  I second that.  Looks like something like
> >     FIND-METHOD-COMBINATION &rest approriate-args
> > was forgotten from the spec.
> 
> Sorry, Marco, but your implication that FIND-METHOD-COMBINATION should
> have been included in the ANS is not supported by history or logic.

FWIW, I basically concur with Steve's remarks on this.  This was not an 
oversight, just a rough edge between the parts of CLOS we included and the
parts we did not and left to AMOP.
From: Marco Antoniotti
Subject: Re: Is there any standardized way to obtain an instance of class METHOD-COMBINATION?
Date: 
Message-ID: <3F12BBFD.7030602@cs.nyu.edu>
Kent M Pitman wrote:
> "Steven M. Haflich" <·················@alum.mit.edu> writes:
> 
> 
>>Marco Antoniotti wrote:
>>
>>
>>>Yep.  I second that.  Looks like something like
>>>    FIND-METHOD-COMBINATION &rest approriate-args
>>>was forgotten from the spec.
>>
>>Sorry, Marco, but your implication that FIND-METHOD-COMBINATION should
>>have been included in the ANS is not supported by history or logic.
> 
> 
> FWIW, I basically concur with Steve's remarks on this.  This was not an 
> oversight, just a rough edge between the parts of CLOS we included and the
> parts we did not and left to AMOP.

I wasn't commenting on how things went.  You guys are definitively 
allowed to have left in some rough edge.  That was the meaning of my 
comment.  It is a just a rough edge.

Cheers

--
Marco
From: Paul Dietz
Subject: Re: Is there any standardized way to obtain an instance of  classMETHOD-COMBINATION?
Date: 
Message-ID: <3F12C450.B51EE136@motorola.com>
"Steven M. Haflich" wrote:

> Sorry, Marco, but your implication that FIND-METHOD-COMBINATION should
> have been included in the ANS is not supported by history or logic.

Its lack (or something similar) renders a part of the specification
untestable by a conforming test suite.  I consider this to be a defect
in the specification.

	Paul
From: Kent M Pitman
Subject: Re: Is there any standardized way to obtain an instance of  classMETHOD-COMBINATION?
Date: 
Message-ID: <sfw7k6lytq3.fsf@shell01.TheWorld.com>
Paul Dietz <············@motorola.com> writes:

> "Steven M. Haflich" wrote:
> 
> > Sorry, Marco, but your implication that FIND-METHOD-COMBINATION should
> > have been included in the ANS is not supported by history or logic.
> 
> Its lack (or something similar) renders a part of the specification
> untestable by a conforming test suite.  I consider this to be a defect
> in the specification.

You mean a defect in "the language design".

While I can see why having it would make implementations more testable,
it's also plain that numerous aspects of the language are inherently
not testable, so I don't know that this makes it hugely worse.  You surely
don't mean to say that given only this one thing, suddenly almost everything
in the language would be testable, do you?
From: Paul Dietz
Subject: Re: Is there any standardized way to obtain an instance of class  METHOD-COMBINATION?
Date: 
Message-ID: <3F12E840.C095E90B@motorola.com>
Kent M Pitman wrote:

> While I can see why having it would make implementations more testable,
> it's also plain that numerous aspects of the language are inherently
> not testable, so I don't know that this makes it hugely worse.  You surely
> don't mean to say that given only this one thing, suddenly almost everything
> in the language would be testable, do you?

No, of course not (to the question).  But it's moderately annoying
to me that features are included in the language (such as,
the :method-combination argument to ensure-generic-function)
that cannot be tested *at all* by conforming tests.  Wouldn't
it have been easier to just leave that out, and let the keyword
argument be part of the extension (MOP, I presume) that would
provide values that would make it useful?

	Paul
From: Kent M Pitman
Subject: Re: Is there any standardized way to obtain an instance of class  METHOD-COMBINATION?
Date: 
Message-ID: <sfw7k6lnep4.fsf@shell01.TheWorld.com>
Paul Dietz <············@motorola.com> writes:

> Wouldn't it have been easier to just leave that out, and let the
> keyword argument be part of the extension (MOP, I presume) that
> would provide values that would make it useful?

Well, as I recall we wasted a _huge_ amount of time fussing about whether
it was permissible for an implementation to extend DEFCLASS, DEFGENERIC,
etc.  Some people (I remember arguing with Dick Gabriel about this, so he
must have been one of them) feared that if they were extensible, people 
would write code-walkers that would not do the right thing (either because
they were permitting non-portable options or not permitting them, depending
on context).  I know there was a definite bias against leaving out an 
argument.  The preference was to include an operator "as a whole" or not to
include it...  I'm pretty sure (but not reliably sure) that this is why we
did not leave out keywords, even at the risk of them being useless.
From: Barry Margolin
Subject: Re: Is there any standardized way to obtain an instance of class  METHOD-COMBINATION?
Date: 
Message-ID: <l4CQa.141$0z4.45@news.level3.com>
In article <·················@motorola.com>,
Paul Dietz  <············@motorola.com> wrote:
>Kent M Pitman wrote:
>
>> While I can see why having it would make implementations more testable,
>> it's also plain that numerous aspects of the language are inherently
>> not testable, so I don't know that this makes it hugely worse.  You surely
>> don't mean to say that given only this one thing, suddenly almost everything
>> in the language would be testable, do you?
>
>No, of course not (to the question).  But it's moderately annoying
>to me that features are included in the language (such as,
>the :method-combination argument to ensure-generic-function)
>that cannot be tested *at all* by conforming tests.  Wouldn't
>it have been easier to just leave that out, and let the keyword
>argument be part of the extension (MOP, I presume) that would
>provide values that would make it useful?

I think that may have been the intent.  When we decided not to included the
MOP in ANSI CL, we got rid of most of the MOP-related features that were in
the CLOS proposal, but missed a few.

But in some cases, I think we intentionally left placeholders like this.
We wanted to ensure that the MOP gets added to implementations in a
consistent way, e.g. that all implementations use the :METHOD-COMBINATION
option to ENSURE-GENERIC-FUNCTION, rather than someone deciding to provide
a function like ENSURE-GENERIC-FUNCTION-WITH-METHOD-COMBINATION.

-- 
Barry Margolin, ··············@level3.com
Level(3), Woburn, 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: Nikodemus Siivola
Subject: Re: Is there any standardized way to obtain an instance of class  METHOD-COMBINATION?
Date: 
Message-ID: <bf0t51$avb$1@nyytiset.pp.htv.fi>
Barry Margolin <··············@level3.com> wrote:

> I think that may have been the intent.  When we decided not to included the
> MOP in ANSI CL, we got rid of most of the MOP-related features that were in
> the CLOS proposal, but missed a few.

Which reminds me: in the last INCITS/J13 Annual Report

  http://www.ncits.org/Archive/2002/it020567/it020567.htm

there is mention of possibility for fast-tracking MOP for
standardization. Was/is this wishfull thinking, or is something
happening once again?

Cheers,

 -- Nikodemus
From: Steven M. Haflich
Subject: Re: Is there any standardized way to obtain an instance of class    METHOD-COMBINATION?
Date: 
Message-ID: <3F14B9BB.9090800@alum.mit.edu>
Paul Dietz wrote:

> No, of course not (to the question).  But it's moderately annoying
> to me that features are included in the language (such as,
> the :method-combination argument to ensure-generic-function)
> that cannot be tested *at all* by conforming tests.  Wouldn't
> it have been easier to just leave that out, and let the keyword
> argument be part of the extension (MOP, I presume) that would
> provide values that would make it useful?

I have read the subsequent discussion on this thread, but I must
admit that I can't understand the premise of the discussion at all.

(First, there is the minor point tha the ANS was _not_ written in
order to proved a well-formed canonical convex exercise for the
writer of a conformance suite.  Somewhere Kent or Barmar or I could
probably dig up the "objectives" document drafted the evening of the
first day of the first X3J13 meeting, but please don't ask.  If you
approach the ANS with that bias, you will surely have difficulty.)

My major point is that there is nothing lacking in the ANS
specifications surrounding method combination.  The
DEFINE-METHOD-COMBINATION macro has well defined semantics:
After executing a DMC form, that named method combination may
be used in the :METHOD-COMBINATION argument to DEFGENERIC.  When
a gf specifying that method combination is called, the combination
specified by the DEFINE-METHOD-COMBINATION form is implemented.

All this can be cleverly tested the same way the result of
(list 1 '2 (/ 22 7)) is tested.

Either I'm missing something important, or you are...
From: Paul F. Dietz
Subject: Re: Is there any standardized way to obtain an instance of class METHOD-COMBINATION?
Date: 
Message-ID: <aOqcndo__KVuIYmiXTWJkQ@dls.net>
Steven M. Haflich wrote:

> My major point is that there is nothing lacking in the ANS
> specifications surrounding method combination.  The
> DEFINE-METHOD-COMBINATION macro has well defined semantics:
> After executing a DMC form, that named method combination may
> be used in the :METHOD-COMBINATION argument to DEFGENERIC.  When
> a gf specifying that method combination is called, the combination
> specified by the DEFINE-METHOD-COMBINATION form is implemented.
> 
> All this can be cleverly tested the same way the result of
> (list 1 '2 (/ 22 7)) is tested.
> 
> Either I'm missing something important, or you are...


I wasn't talking about the :method-combination argument to
defgeneric, I was talking about the :method-combination argument
to ensure-generic-function.  The latter must be a method combination
object, not the name of a method combination.

	Paul
From: Steven M. Haflich
Subject: Re: Is there any standardized way to obtain an instance of class   METHOD-COMBINATION?
Date: 
Message-ID: <3F161F7E.1010609@alum.mit.edu>
Paul F. Dietz wrote:

> I wasn't talking about the :method-combination argument to
> defgeneric, I was talking about the :method-combination argument
> to ensure-generic-function.  The latter must be a method combination
> object, not the name of a method combination.

Sorry, I must have missed that detail in your original post.

After rereviewing the details, it seems to me that the restriction
on the :method-combination argument to ensure-generic-function was
simply an oversight in cleaving ANSI CL from the MOP (elsewhere
described by Kent as leaving a "rough edge").  The specification
should have allowed either a method-combination or the name of a
method-combination.  The first possibility would still be useless
within the portable language, but without the second, it is the
:method-combination argument to ensure-generic-function that is
entirely useless within the portable language.

The counter argument might be that there should be some kind of
separation between the defining macros and the functional interfaces.
The defining macros typically receive names of entities when they refer
to a class, method-combination, etc., while the functional versions
typically receive first-class objects.  However, this is only a
convention of typical use; for instance, defclass accepts names or
class objects in its subclass list, and on the other side,
ensure-class and ensure-class-using-class will similarly accept names
of classes as well as class objects in the direct-superclass argument
list.

I see no reason the :method-combination arguments of both defgeneric
and ensure-generic-function should be any different.  Probably we
(X3J13) would have caught it if there ever had been any significant
use of ensure-generic-function.

I see no reason this couldn't be fixed by amending the definition
of defgeneric and ensure-generic-function to accept method-combination
names as well as method-combination objects.  Perhaps I'll ask
INCITS/J13 to take this up.  There is one member of J13 who has
expressed desire to start standardizing the MOP, but this item is a
simple short-term item that cleans up the status quo just a little.
From: Christophe Rhodes
Subject: Re: Is there any standardized way to obtain an instance of class METHOD-COMBINATION?
Date: 
Message-ID: <squ19lecsc.fsf@lambda.jcn.srcf.net>
"Steven M. Haflich" <·················@alum.mit.edu> writes:

> I see no reason this couldn't be fixed by amending the definition
> of defgeneric and ensure-generic-function to accept method-combination
> names as well as method-combination objects.  Perhaps I'll ask
> INCITS/J13 to take this up.  There is one member of J13 who has
> expressed desire to start standardizing the MOP, but this item is a
> simple short-term item that cleans up the status quo just a little.

I'd like to have a word ("non-trivial") inserted in the description of
the STRING system class; however, I thought there was no way of opening the
standard to amendment in this way.

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)
From: Steven M. Haflich
Subject: Re: Is there any standardized way to obtain an instance of class METHOD-COMBINATION?
Date: 
Message-ID: <3F16C366.8030309@alum.mit.edu>
Christophe Rhodes wrote:

> I'd like to have a word ("non-trivial") inserted in the description of
> the STRING system class;

If you're concerned about the muddle surrounding

  (stringp (make-array ... :element-type 'nil))

uncovered by Paul Dietz's conformance suite, this wouldn't be the best
way to fix it because "non-trivial" is not a term of art and is open
to far too much interpretation.  But I agree it is desirable to repair
this sort of unintended consequence in the ANS because they can have
real efficiency costs and cause implementations to vary over behaviors
that are visible to user code but which have no intrinsic value.

There is a related mess surrounding upgraded-array-element-type.

> however, I thought there was no way of opening the
> standard to amendment in this way.

I don't know why everyone thinks this.  It must be a comp.lang.lisp
urban legend.

Although the 1994 ANS could be openend for revision with the goal of issuing
a revised ANS, I don't imagine anyone has the energy or interest to undertake
this, nor do I see any need.  A much more rational procedure is for INCITS/J13
to create one or more projects to draft Amendment(s) that address well-defined
and limited areas of concern.  After any such amendment were adopted, the 1994
ANS would remain unchanged.  An implementations could still claim to conform to
X3.226-1994, or it could claim to conform to X3.226-1994 as modified by
Amendment INCITS/J13.123-2004 ...  The choice whether an implementation did so
would be left to market pressure, which is where the choice has always lain.

If the MOP were ever to be standardized in whole or in part, this would be the
way to do it.
From: Christophe Rhodes
Subject: Re: Is there any standardized way to obtain an instance of class METHOD-COMBINATION?
Date: 
Message-ID: <sqptk9dtvp.fsf@lambda.jcn.srcf.net>
"Steven M. Haflich" <·················@alum.mit.edu> writes:

> Christophe Rhodes wrote:
>
>> I'd like to have a word ("non-trivial") inserted in the description of
>> the STRING system class;
>
> If you're concerned about the muddle surrounding
>
>   (stringp (make-array ... :element-type 'nil))
>
> uncovered by Paul Dietz's conformance suite, 

Yes, I am; while I've implemented the literal behaviour mandated by
the standard with what I believe to be minimal cost to users, the cost
is non-zero.

> this wouldn't be the best
> way to fix it because "non-trivial" is not a term of art and is open
> to far too much interpretation.  

OK.  I'm sure I can think of a more precise wording.  :-)

> But I agree it is desirable to repair
> this sort of unintended consequence in the ANS because they can have
> real efficiency costs and cause implementations to vary over behaviors
> that are visible to user code but which have no intrinsic value.
>
> There is a related mess surrounding upgraded-array-element-type.

Indeed, though there it's a little less clear how to preserve some of
the nice properties of the type system while not requiring
implementations to support ostensibly useless specializations.

On the other hand, I don't believe the issue in
upgraded-array-element-type affects users in any meaningful way; the
existence of an (UNSIGNED-BYTE 7) specialization in an implementation
that offers both (SIGNED-BYTE 8) and (UNSIGNED-BYTE 8) is perhaps
surprising, but does it lead to a measurable cost?

> Although the 1994 ANS could be openend for revision with the goal of issuing
> a revised ANS, I don't imagine anyone has the energy or interest to undertake
> this, nor do I see any need.  A much more rational procedure is for INCITS/J13
> to create one or more projects to draft Amendment(s) that address well-defined
> and limited areas of concern.  After any such amendment were adopted, the 1994
> ANS would remain unchanged.  An implementations could still claim to conform to
> X3.226-1994, or it could claim to conform to X3.226-1994 as modified by
> Amendment INCITS/J13.123-2004 ...  The choice whether an implementation did so
> would be left to market pressure, which is where the choice has always lain.
> 
> If the MOP were ever to be standardized in whole or in part, this would be the
> way to do it.

Right.  How does one get the ball rolling?  (Probably the ball should
only start rolling once Paul is happy with his magnum opus; but maybe
the ball needs to be pushed for a while before it sets off?)

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)
From: Daniel Barlow
Subject: Amendments to ANS (was Re: Is there any standardized way to obtain an instance of class METHOD-COMBINATION?)
Date: 
Message-ID: <871xwp6lo4.fsf_-_@noetbook.telent.net>
Christophe Rhodes <·····@cam.ac.uk> writes:

> On the other hand, I don't believe the issue in
> upgraded-array-element-type affects users in any meaningful way; the
> existence of an (UNSIGNED-BYTE 7) specialization in an implementation
> that offers both (SIGNED-BYTE 8) and (UNSIGNED-BYTE 8) is perhaps
> surprising, but does it lead to a measurable cost?

In SBCL, it's another widetag that we perhaps might have wanted to
give to something that people might actually use.  Not that we're
running out just now, but we might have been.

There may be other implementation strategies that avoid using widetags
in this way, but then we're having our development driven by these
ultimately pretty stupid requirements.  Even if that's not measurable
at runtime, it costs developer time to implement in the first place.

Steven Haflich wrote:
>> Although the 1994 ANS could be openend for revision with the goal
>> of issuing a revised ANS, I don't imagine anyone has the energy or
>> interest to undertake this, nor do I see any need.  A much more
>> rational procedure is for INCITS/J13 to create one or more projects
>> to draft Amendment(s) that address well-defined and limited areas
>> of concern.

I too was under the impression that the only way to change the
standatd was by opening it up again wholesale, so this is really
welcome news to me too.  


-dan

-- 

   http://www.cliki.net/ - Link farm for free CL-on-Unix resources 
From: Steven M. Haflich
Subject: Re: Amendments to ANS (was Re: Is there any standardized way to obtain   an instance of class METHOD-COMBINATION?)
Date: 
Message-ID: <3F1D6C32.9090501@alum.mit.edu>
Daniel Barlow wrote:

> Christophe Rhodes <·····@cam.ac.uk> writes:
>>On the other hand, I don't believe the issue in
>>upgraded-array-element-type affects users in any meaningful way; the
>>existence of an (UNSIGNED-BYTE 7) specialization in an implementation
>>that offers both (SIGNED-BYTE 8) and (UNSIGNED-BYTE 8) is perhaps
>>surprising, but does it lead to a measurable cost?

Real computers support native datatypes of (SIGNED-BYTE 8) and
(UNSIGNED-BYTE 8), and these are important either for efficiency or
for interfacing to other languages and libraries.  Real programmers
expect to be able to use them, and I believe it was the intention in
ANSI CL that they would be available.  That the ANS either requires a
conforming implementation to upgrade [un]signed-byte 8 array element
types to 16-bit specialized arrays, or else implement unsigned-byte 7,
is more than just a little unfortunate.  It limits what the programmer
can do with these native arrays without tedious and unintuitive type
hacking and declarations.  It works against the ability of CL to support
_real_ applications like web servers that have to deal with real data
with high throughput.

So I would hold that the need for [UN]SIGNED-BYTE 7 is a total
artificiality having no benefit in language power or expressiveness;
its size is unnatural to the underlying hardware and it's only benefit
is in conformance.  Try explaining it to a C programmer.  For that
matter, try explaining it to a Lisp programmer. :-)

 > In SBCL, it's another widetag that we perhaps might have wanted to
 > give to something that people might actually use.  Not that we're
 > running out just now, but we might have been.
 >
 > There may be other implementation strategies that avoid using widetags
 > in this way, but then we're having our development driven by these
 > ultimately pretty stupid requirements.  Even if that's not measurable
 > at runtime, it costs developer time to implement in the first place.

I'm glad that your reaction from the perspective of SBCL is similar to
mine from the perspective of Allegro.  In particular, the need for an
array type specialized for nil, and the requirement for that type to be
stringp, not only consumes a type code, but also makes typechecking code
or inline type dispatch tables longer.  The cost might not be huge, but
the cost is systemic, and carries with it absolutely no useful increase
in the expressiveness or power of the language.

It would be good to have someone from the cmucl or sbcl communities
either as a member of J13, or at least working with it.  Assuming the
committee acts on this tangle of type and array-upgrading issues, the
goal would presumably be to eliminate these silly, unintended requirements
on conformance without prohibiting any desirable extensions or
establishing any new implementation costs.  It is helpful to have members
intimately familiar with all the various implementations.
From: Christophe Rhodes
Subject: Re: Amendments to ANS
Date: 
Message-ID: <sqhe5ea2w4.fsf@lambda.jcn.srcf.net>
"Steven M. Haflich" <·················@alum.mit.edu> writes:

> Daniel Barlow wrote:
>
>> Christophe Rhodes <·····@cam.ac.uk> writes:
>>>On the other hand, I don't believe the issue in
>>>upgraded-array-element-type affects users in any meaningful way; the
>>>existence of an (UNSIGNED-BYTE 7) specialization in an implementation
>>>that offers both (SIGNED-BYTE 8) and (UNSIGNED-BYTE 8) is perhaps
>>>surprising, but does it lead to a measurable cost?
>
> Real computers support native datatypes of (SIGNED-BYTE 8) and
> (UNSIGNED-BYTE 8), and these are important either for efficiency or
> for interfacing to other languages and libraries.  Real programmers
> expect to be able to use them, and I believe it was the intention in
> ANSI CL that they would be available.  That the ANS either requires a
> conforming implementation to upgrade [un]signed-byte 8 array element
> types to 16-bit specialized arrays, or else implement unsigned-byte 7,
> is more than just a little unfortunate.  

To be clear, I agree with this.  But I'm not sure that your
rationalization below is a good example...

> It limits what the programmer
> can do with these native arrays without tedious and unintuitive type
> hacking and declarations.  It works against the ability of CL to support
> _real_ applications like web servers that have to deal with real data
> with high throughput.

Firstly, surely a programmer who knows his platform is going to be
making type declarations of the form 
  (make-array :element-type '(unsigned-byte 8)) 
and 
  (simple-array (unsigned-byte 8) (*)), 
which will have the right memory layout characteristics for
interfacing with buffers or foreign code.  And secondly, I would be
very surprised if for Allegro an putative array of specialized type
(unsigned-byte 7) were not to have exactly the same memory layout as
an array of type (unsigned-byte 8), so that if for some reason a
programmer knew that all his elements would be of type (unsigned-byte 7), 
the interface to the foreign world would continue to work as before.
Certainly, this is how I would implement it for sbcl.

> So I would hold that the need for [UN]SIGNED-BYTE 7 is a total
> artificiality having no benefit in language power or expressiveness;
> its size is unnatural to the underlying hardware and it's only benefit
> is in conformance.  Try explaining it to a C programmer.  For that
> matter, try explaining it to a Lisp programmer. :-)

Heh :-).  I don't think that the cost of these specialized arrays is
enormous -- certainly not as great as the string/vector-nil; I'm
willing to be persuaded by an example, though, and if there is a good
way of cleaning up this one I'd be all for it.

> I'm glad that your reaction from the perspective of SBCL is similar to
> mine from the perspective of Allegro.  In particular, the need for an
> array type specialized for nil, and the requirement for that type to be
> stringp, not only consumes a type code, but also makes typechecking code
> or inline type dispatch tables longer.  The cost might not be huge, but
> the cost is systemic, and carries with it absolutely no useful increase
> in the expressiveness or power of the language.

I'm inclined to agree, but when the (vector nil) issue first came out
(not the string case, but the simple existence of such an array type),
there was a surprising amount of positive commentary, and
demonstrations (from Duane Rettig, among others) of an
implementation.

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)
From: Duane Rettig
Subject: Re: Amendments to ANS
Date: 
Message-ID: <4el0iw5qp.fsf@beta.franz.com>
Christophe Rhodes <·····@cam.ac.uk> writes:

> > I'm glad that your reaction from the perspective of SBCL is similar to
> > mine from the perspective of Allegro.  In particular, the need for an
> > array type specialized for nil, and the requirement for that type to be
> > stringp, not only consumes a type code, but also makes typechecking code
> > or inline type dispatch tables longer.  The cost might not be huge, but
> > the cost is systemic, and carries with it absolutely no useful increase
> > in the expressiveness or power of the language.
> 
> I'm inclined to agree, but when the (vector nil) issue first came out
> (not the string case, but the simple existence of such an array type),
> there was a surprising amount of positive commentary, and
> demonstrations (from Duane Rettig, among others) of an
> implementation.

Yes, I did the implementation of (array nil) on a whim, since it was
clearly specified _and_ because it had no other consequenses at the
time.  However, this little monster has grown into something that I
daresay no CL programmer or implementor could have imagined.  I cooled
off quite a bit to the idea as soon as it became apparent that these
(array nil) types had to be stringp, because the implications _and_ the
assault on the intuitions are much more than just plugging up some
trivial and never-before-visited holes.

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: Kent M Pitman
Subject: Re: Amendments to ANS
Date: 
Message-ID: <sfwoezmqg3s.fsf@shell01.TheWorld.com>
Duane Rettig <·····@franz.com> writes:

> Christophe Rhodes <·····@cam.ac.uk> writes:
> 
> > > I'm glad that your reaction from the perspective of SBCL is similar to
> > > mine from the perspective of Allegro.  In particular, the need for an
> > > array type specialized for nil, and the requirement for that type to be
> > > stringp, not only consumes a type code, but also makes typechecking code
> > > or inline type dispatch tables longer.  The cost might not be huge, but
> > > the cost is systemic, and carries with it absolutely no useful increase
> > > in the expressiveness or power of the language.
> > 
> > I'm inclined to agree, but when the (vector nil) issue first came out
> > (not the string case, but the simple existence of such an array type),
> > there was a surprising amount of positive commentary, and
> > demonstrations (from Duane Rettig, among others) of an
> > implementation.
> 
> Yes, I did the implementation of (array nil) on a whim, since it was
> clearly specified _and_ because it had no other consequenses at the
> time.  However, this little monster has grown into something that I
> daresay no CL programmer or implementor could have imagined.  I cooled
> off quite a bit to the idea as soon as it became apparent that these
> (array nil) types had to be stringp, because the implications _and_ the
> assault on the intuitions are much more than just plugging up some
> trivial and never-before-visited holes.

My position on this is that it would be better for implementations to 
willfully violate any issues related to
     (a) upgraded-array-element-type
 and (b) typep

since 

     (a) i believe this operator was intended to reveal implementation
         decisions, not to constrain them (viz, the sample implementation),
         and consequently i think any overspecificity of this operator is
         the real bug, not the idea of a NIL type.

     (b) this operator exists only so that people don't do
         (defun typep (x)
           (or (let* ((*print-escape* (or *print-readably* *print-escape*))
                      (*print-readably* nil)
                      (x-string (prin1-to-string x))
                      (pos))
                 (when (and (string-equal x "#<" :end1 (max 2 (length x)))
                            (setq pos (position #\Space x :start 2)))
                   (read-from-string x nil nil :start 2 :end pos)))
               ...other gross hacks...))
         That is, the implementation is already required to take some vague
         position on the types of some objects, so people would be tempted
         to trap and use the implementation-specific heuristic operation we
         use for printing, and we just decided to publish it.  That doesn't
         make it clean and pretty or suitable for much of anything other
         than vague debugging work, and to the extent that anything in its
         definition gets in the way of anything else more important, I say
         TYPEP should bend and more importnat stuff should stand.

If there are other "assaults on intuitions", I don't know of them.  But in 
any case, I think Duane and I are in conceptual agreement that there are
some small, annoying discrepancies--we just differ on how to go about fixing
them and are, in part, having our discussion on the matter in public so
that we can assess community interest in these various things.

I personally think it's more important to make element-type NIL arrays
work than to abide by either of the abovementioned definitions to the point
that it would preclude them.  But that's just me.  My saying that x is more
important than y is not a statement that either x or y is of remarkably high
priority.

I could imagine using element-type NIL arrays, whereas I can't imagine caring
that type (ARRAY NIL) is a subtype of STRING since (a) I don't use it 
explicitly for such, (b) in any case I'm using TYPEP or 
UPGRADED-ARRAY-ELEMENT-TYPE to guard entry to a range of code in which I'm
manipulating strings, I'm content to have (ARRAY NIL) objects deflected from
such areas, and (c) the definition of STRING [as a union type] is already
so weirdly idiosyncratic that it requires delicate care to manipulate code
that does dynamic typing, and as such I don't imagine any really sophisticated
type algebra I do with it getting faked out.
From: Duane Rettig
Subject: Re: Amendments to ANS
Date: 
Message-ID: <4he5dbscy.fsf@beta.franz.com>
Kent M Pitman <······@world.std.com> writes:

> Duane Rettig <·····@franz.com> writes:
> 
> > Christophe Rhodes <·····@cam.ac.uk> writes:
> > 
> > > > I'm glad that your reaction from the perspective of SBCL is similar to
> > > > mine from the perspective of Allegro.  In particular, the need for an
> > > > array type specialized for nil, and the requirement for that type to be
> > > > stringp, not only consumes a type code, but also makes typechecking code
> > > > or inline type dispatch tables longer.  The cost might not be huge, but
> > > > the cost is systemic, and carries with it absolutely no useful increase
> > > > in the expressiveness or power of the language.
> > > 
> > > I'm inclined to agree, but when the (vector nil) issue first came out
> > > (not the string case, but the simple existence of such an array type),
> > > there was a surprising amount of positive commentary, and
> > > demonstrations (from Duane Rettig, among others) of an
> > > implementation.
> > 
> > Yes, I did the implementation of (array nil) on a whim, since it was
> > clearly specified _and_ because it had no other consequenses at the
> > time.  However, this little monster has grown into something that I
> > daresay no CL programmer or implementor could have imagined.  I cooled
> > off quite a bit to the idea as soon as it became apparent that these
> > (array nil) types had to be stringp, because the implications _and_ the
> > assault on the intuitions are much more than just plugging up some
> > trivial and never-before-visited holes.
> 
> My position on this is that it would be better for implementations to 
> willfully violate any issues related to
>      (a) upgraded-array-element-type
>  and (b) typep

Such a willful violation of a portion of the spec would also cause a
willful violation of a much more important part of the spec: that of
your excellent definition and use of "purports to conform".  This term
implies that where an implementation is shown to be at odds with the
spec, it is acknowledged as a bug in the implementation, and that the
intention of the implemetor is to eventually fix that bug.  Your
suggestion above suggests a new and different approach, perhaps
implying some level of priority to such conformance, or even suggesting
that the spec is wrong :-).  Of course, I don't believe that at all; I
only believe that there is a difference in what the spec says from what
it was intended to say. Unfortunately, it is very hard to codify such
intentions in the face of unknown uses or interpretations.  As you've
said yourself, the spec says what the spec says.

> since 
> 
>      (a) i believe this operator was intended to reveal implementation
>          decisions, not to constrain them (viz, the sample implementation),
>          and consequently i think any overspecificity of this operator is
>          the real bug, not the idea of a NIL type.
> 
>      (b) this operator exists only so that people don't do
>          (defun typep (x)
>            (or (let* ((*print-escape* (or *print-readably* *print-escape*))
>                       (*print-readably* nil)
>                       (x-string (prin1-to-string x))
>                       (pos))
>                  (when (and (string-equal x "#<" :end1 (max 2 (length x)))
>                             (setq pos (position #\Space x :start 2)))
>                    (read-from-string x nil nil :start 2 :end pos)))
>                ...other gross hacks...))
>          That is, the implementation is already required to take some vague
>          position on the types of some objects, so people would be tempted
>          to trap and use the implementation-specific heuristic operation we
>          use for printing, and we just decided to publish it.  That doesn't
>          make it clean and pretty or suitable for much of anything other
>          than vague debugging work, and to the extent that anything in its
>          definition gets in the way of anything else more important, I say
>          TYPEP should bend and more importnat stuff should stand.

I agree with this and had understood this to be the case, even though I was
not on the X3J13 committee.

> If there are other "assaults on intuitions", I don't know of them.

In case I gave the wrong idea - please understand that the "assault on
intuition" I refer to is not of your (or X3J13's) doing, but simply
an unfortunate consequence of written words not saying what they were
intended to say.  Such things happen all the time, and it is for that
reason why one needs lawyers to read and interpret legal documents, not
only for the purpose of defending the owner of the document in court, but
to ensure that the document actually says what the owner had intended to
say.

I think that in this case the "assault" really comes as a result of
every one of us in the CL community being blindsided - Paul Dietz's
arguments using the spec are logical and inconvtrovertible, but not
one CL implementation had had an (array nil) before these arguments,
and as far as I know, not one user had ever complained.  As far as I
know, clisp had previously given (typep t) ==> 'boolean rather than
'symbol, but it was in the minority, and that was as far as it went,
from what I understand of it.  In other words, implementors and users
simply had never even thought along these lines, and this is why I
call it an "assault on intuition".

>  But in 
> any case, I think Duane and I are in conceptual agreement that there are
> some small, annoying discrepancies--

Yes, I think we do agree.

> we just differ on how to go about fixing them

Well, perhaps we differ less than you might think.  Perhaps it is just a
question of what hat each of us wears (and although Steve Haflich and I
work for the same company, one should not confuse the implementor's hat
I primarily wear at this time with the standards hat Steve currently wears
here in c.l.l.).

> and are, in part, having our discussion on the matter in public so
> that we can assess community interest in these various things.
> 
> I personally think it's more important to make element-type NIL arrays
> work than to abide by either of the abovementioned definitions to the point
> that it would preclude them.  But that's just me.  My saying that x is more
> important than y is not a statement that either x or y is of remarkably high
> priority.

Right.  The priority on correctness that I place on such an obviously
"unimportant" issue (one that had never really come up in real practice)
tests the spec/implementations dynamic and is much more important as such
a test than it is as an actual issue.  If the most important question for
Common Lisp is "Can we trust the spec to be implementable and portable?",
and these are the worst issues that we can throw at the spec, then I say
that the answer is a resounding "Yes!"

> I could imagine using element-type NIL arrays, whereas I can't imagine caring
> that type (ARRAY NIL) is a subtype of STRING since (a) I don't use it 
> explicitly for such, (b) in any case I'm using TYPEP or 
> UPGRADED-ARRAY-ELEMENT-TYPE to guard entry to a range of code in which I'm
> manipulating strings, I'm content to have (ARRAY NIL) objects deflected from
> such areas, and (c) the definition of STRING [as a union type] is already
> so weirdly idiosyncratic that it requires delicate care to manipulate code
> that does dynamic typing, and as such I don't imagine any really sophisticated
> type algebra I do with it getting faked out.

I have currently halted all work on those of Dietz's conformance tests
which have to do with typep, u-a-e-t, and (array nil), and probably won't
start back on those particular ones until we see what direction the
community takes in the matter.  Paul has told me that he is making the
tests annotatable, so that tests under contention can be marked as such.

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: Kent M Pitman
Subject: Re: Amendments to ANS
Date: 
Message-ID: <sfwr84h2upt.fsf@shell01.TheWorld.com>
Duane Rettig <·····@franz.com> writes:

> > My position on this is that it would be better for implementations to 
> > willfully violate any issues related to
> >      (a) upgraded-array-element-type
> >  and (b) typep
> 
> Such a willful violation of a portion of the spec would also cause a
> willful violation of a much more important part of the spec: that of
> your excellent definition and use of "purports to conform".

Certainly not.  Not if you believe (which is my understanding) that
"something has to give".  That is, that something is overspecified.
That's my position.  In that case, the implementor must make some
decisions about what to believe and what not.  That doesn't mean the
implementor has abandoned the spec--it means they are doing the best
they can.

> This term
> implies that where an implementation is shown to be at odds with the
> spec, it is acknowledged as a bug in the implementation, and that the
> intention of the implemetor is to eventually fix that bug.

Right.  And I believe it's a bug that element-type NIL arrays are not
supported.  You have chosen to read the spec otherwise, and I don't
dispute the sincerity of your reading--there are clearly multiple readings.
I just think that there is a minor oerspecificational glitch and that
if I _were_ going to resolve it, I'd resolve it in the way I mentioned.

> Your
> suggestion above suggests a new and different approach, perhaps
> implying some level of priority to such conformance, or even suggesting
> that the spec is wrong :-).

In the case where conformance was in conflict, which I take all this
tommyrot about element-type NIL being a subtype of STRING to be.  I
can't speak for them, but I don't think any of the original designers
intended this or wanted this.  I can say that none has stepped forward
(that I am aware of) to say they intentionally did want this .

> Of course, I don't believe that at all; I
> only believe that there is a difference in what the spec says from what
> it was intended to say. Unfortunately, it is very hard to codify such
> intentions in the face of unknown uses or interpretations.  As you've
> said yourself, the spec says what the spec says.

Certainly.  A lot of this hinges on whether you think the spec says
that element-type NIL should be permitted.  I think it does say that,
and if you don't, then you'd arrive at a different world model,
locally in which you might mistakenlyl believe I was advocating a
willful violation, but in my world model (also, I believe, a valid
interpretation), I don't think I am.

> > If there are other "assaults on intuitions", I don't know of them.
> 
> In case I gave the wrong idea - please understand that the "assault on
> intuition" I refer to is not of your (or X3J13's) doing, but simply
> an unfortunate consequence of written words not saying what they were
> intended to say.

Certainly.  I hope I'm not sounding defensive about the wording.  Even where
I may have introduced faulty wording (which might or might not be here,
though I don't think so), I figure it's kind of "par for the course" that
something I would say would cause some problem.  To write that many sentences
and have none of them lead to controversy must surely be statistically
improbable, so I've tried to have good humor about that.  My interest here
is as a user, not as editor.  Indeed, as a technical participant, I was
very iffy on the entire way that arrays and element types and all that were
specified.

> Such things happen all the time, and it is for that
> reason why one needs lawyers to read and interpret legal documents, not
> only for the purpose of defending the owner of the document in court, but
> to ensure that the document actually says what the owner had intended to
> say.

Sure.
 
> I think that in this case the "assault" really comes as a result of
> every one of us in the CL community being blindsided - Paul Dietz's
> arguments using the spec are logical and inconvtrovertible, 

But my reading is that they appear to lead to an "incontrovertible 
contradiction", which is to say, they appear to lead to things that the
spec obviously doesn't want on its face, and the thing we have (as a
community) done in such cases (viz, the return value of PROG2) is to
just do the right thing.

The problem that is caused here touches on the issue of what a
technical error and what a editing error is, on what is obvious and
what is not.  As some have pointed out in other venues, obvious is a
function of context (including time), and what is obvious is a
function of what one has already noticed, so once you've noticed a
problem, it's really obvious.  But since we did not have the value of
this detailed forward-chaining at the time we originally did this, it
wasn't obvious, and what we wanted instead _was_ obvious, so that now
that we suddenly find that some obscure conclusion is newly obvious, I
don't think it's fair to say that it is not obvious what to do.  You
"obviously" think otherwise, but I observe, at least, the possibility
that there is ambiguity about the issue of obviousness.  And that
itself is sad, in much the same way as it was sad that it was
"amibiguous" whether changing the spec's "credits" section required a
technical or administrative change (there never having been precedent
within ANSI, and worse, where we set the precedent that it should be
treated as technical ... ugh) and cost us many months of delay in
getting the spec out.

I have, in the past, said that when there is no rule as to whether
there is an ambiguity about obviousness, that the community should
observe whethere there is unanimity of interpretation.  The sad thing
is that there are two competing ambiguities here, and the one that is
winning is (a) destabilzing existing implementations [which I consider
bad] and (b) apparently [to me] winning because part of the argument
involves the use of "formal logic" even though both arguments rely,
ultimately, on non-logical elements.

Just as I do not believe in "proving program correctness" but only
"proving program specifications correct" [that is, proving the formally
specified elements of programs, there being forever a zeno's paradox of
'attachment of specification to the real world' that makes proof of real
world issues elusive because the fact of a convergence in the limit is
uncertain], I similarly do not believe you can "prove implications of the
spec", you can only "prove implications of your interpretation of the spec"
and  must always have your eyes open to your interpretation being wrong.
That is, my meta-interpretation is that it is a deliberate choice we made
NOT to use a formal specification language EXACTLY IN ORDER TO assure that
"real world intuitions" (which everyone has) and not "proof technology" 
(which I find a bit [a] elitist and [b] capable of doing the kind of
unwanted surprise that we just encountered) should dominate.  The use of
English was, I believe, a safeguard.  Then again, that's my interpretation,
and you can argue otherwise, since nothing requires my interpretation.
Just don't expect me to back down unless I see a common sense argument
rather than a "logic requires" argument, because the "logic" is attached
to a set of foundational elements that defy "obvious readings" and so I
am more doubtful of the logic than of the obvious readings.

> but not
> one CL implementation had had an (array nil) before these arguments,
> and as far as I know, not one user had ever complained.

But it seems to me to be common-sensicically called for, and inhibited
only by what I could call "laze" [by which I mean the kind of "lazy
implementation" that you find in "lazy evaluation", not something more
pejorative.  Further, when you went to implement it, it appeared to be
inhibited by something that did not seem to me or anyone as common sense,
only as a "necessary implication" [as you more or less characterize it]
tying our hands in violation of common sense readings, which reading I
reject because it's in conflict with the more basic reading that 
element-type can take type specifiers of any type.

> As far as I
> know, clisp had previously given (typep t) ==> 'boolean rather than
> 'symbol, but it was in the minority, and that was as far as it went,
> from what I understand of it.  In other words, implementors and users
> simply had never even thought along these lines, and this is why I
> call it an "assault on intuition".

And I agree.
 
> >  But in 
> > any case, I think Duane and I are in conceptual agreement that there are
> > some small, annoying discrepancies--
> 
> Yes, I think we do agree.
> 
> > we just differ on how to go about fixing them
> 
> Well, perhaps we differ less than you might think.

Or more than you think, since I bet you take issue with some of what I've
said above.. :)  I know we've talked about some of the issues before,
but these above are largely new, at least in their level of detail.

> Perhaps it is just a
> question of what hat each of us wears (and although Steve Haflich and I
> work for the same company, one should not confuse the implementor's hat
> I primarily wear at this time with the standards hat Steve currently wears
> here in c.l.l.).

I think it's a matter of having actually written code that wants this.
I claim I have, even though I can't find it.  I mentioned this to Chris
Stacy--he also thinks he's run into situations where he would want 
element type NIL.  I believe our united position on this is that most
people don't write code where this would come up, and that in some sense
they should not get a vote.  I mean this not to be elitist but to characterize
the same sense of feeling as I mean when I say I have no vested stake in
how floating point works since I largely do not use it--I consider it the
realm of a certain kind of important application, and I consider that my
interfering in it would be inappropriate because it's not something I
depend on.  I think, in a sense, that if you don't think you'd ever want this,
you are opting out of a sense of caring about the outcome.  It is simply
not fair to claim that your [generic "you"] disinterest in a feature should
imply that it should go away... to paraphrase the saralee cheesecake 
jingle ("everbody doesn't like something, but nobody doesn't like saralee"),
"everybody doesn't use something, but nobody doesn't use common lisp".

> > and are, in part, having our discussion on the matter in public so
> > that we can assess community interest in these various things.
> > 
> > I personally think it's more important to make element-type NIL
> > arrays work than to abide by either of the abovementioned
> > definitions to the point that it would preclude them.  But that's
> > just me.  My saying that x is more important than y is not a
> > statement that either x or y is of remarkably high priority.
> 
> Right.  The priority on correctness that I place on such an obviously
> "unimportant" issue (one that had never really come up in real practice)

But what comes up is deceptive.  When it comes up, it comes up all the time.
This is a multi-dimensional quality: how many people have code that use it,
how often is that code run, etc.  You could add to that "How susceptible to
rewrite is it" but that particular argument leads to the omittability of
many things, so be careful pushing on this one.

> tests the spec/implementations dynamic and is much more important as such
> a test than it is as an actual issue.  If the most important question for
> Common Lisp is "Can we trust the spec to be implementable and portable?",
> and these are the worst issues that we can throw at the spec, then I say
> that the answer is a resounding "Yes!"

You only reach this position if you think your position leads you to a set
of consistent readings. I don't think it does. I respect your having taken
specific positions that you are comfortable with, but I _do not_ think that
the set of results you've achieved leaves you any more conforming than you
would be if you followed my suggestions, that is, I think you are just
choosing different things not to conform to.  Are you conforming "as best
you can"? yes.  But that's not the same.
 
> > I could imagine using element-type NIL arrays, whereas I can't imagine caring
> > that type (ARRAY NIL) is a subtype of STRING since (a) I don't use it 
> > explicitly for such, (b) in any case I'm using TYPEP or 
> > UPGRADED-ARRAY-ELEMENT-TYPE to guard entry to a range of code in which I'm
> > manipulating strings, I'm content to have (ARRAY NIL) objects deflected from
> > such areas, and (c) the definition of STRING [as a union type] is already
> > so weirdly idiosyncratic that it requires delicate care to manipulate code
> > that does dynamic typing, and as such I don't imagine any really sophisticated
> > type algebra I do with it getting faked out.
> 
> I have currently halted all work on those of Dietz's conformance tests
> which have to do with typep, u-a-e-t, and (array nil), and probably won't
> start back on those particular ones until we see what direction the
> community takes in the matter.  Paul has told me that he is making the
> tests annotatable, so that tests under contention can be marked as such.

This was absolutely needed from the beginning.  I'm surprised this is the
first such situation.  If this is the only controversial test, then I suspect
his coverage is not as good as I had thought it was, or else that his tests
are in for some surprises and controversies in other extant or conceivable
implementations.  I worry greatly based on these remarks that people will
infer that these tests constrain the possible set of implementations
to those interpretations that are extant, which could be a horrible disservice
to the expandability of various aspects of the language.  I'd love to audit
the tests, though doubt I'll have the dollars to do this unfunded, in the
sense that it's likely to take time I don't have to offer.  There's a natural
desire to use these tests as a way of coming up with hypotheses and then
testing those hypotheses against existing implementations to "confirm his
understanding", but that could be quite an inappropriate thing.  I'm not saying
that it will hurt implementations per se to confront these tests, but what I'm
saying is that no _programmer_ should read these and assume that a given test
implies an exhaustive enumeration of possible implementation options.  
Additional implementation flexibility would simply go unchecked ...
From: Duane Rettig
Subject: Re: Amendments to ANS
Date: 
Message-ID: <4el0h6x0l.fsf@beta.franz.com>
Kent M Pitman <······@world.std.com> writes:

> Duane Rettig <·····@franz.com> writes:
> 
> > > My position on this is that it would be better for implementations to 
> > > willfully violate any issues related to
> > >      (a) upgraded-array-element-type
> > >  and (b) typep
> > 
> > Such a willful violation of a portion of the spec would also cause a
> > willful violation of a much more important part of the spec: that of
> > your excellent definition and use of "purports to conform".
> 
> Certainly not.  Not if you believe (which is my understanding) that
> "something has to give".  That is, that something is overspecified.
> That's my position.  In that case, the implementor must make some
> decisions about what to believe and what not.  That doesn't mean the
> implementor has abandoned the spec--it means they are doing the best
> they can.

Well, yes, of course, something will give, but we do not yet know what
that is, and I'm waiting to see what the results are.

> > This term
> > implies that where an implementation is shown to be at odds with the
> > spec, it is acknowledged as a bug in the implementation, and that the
> > intention of the implemetor is to eventually fix that bug.
> 
> Right.  And I believe it's a bug that element-type NIL arrays are not
> supported.

I agree, and have fixed this in my development version.

>  You have chosen to read the spec otherwise, and I don't
> dispute the sincerity of your reading--there are clearly multiple readings.

I don't understand how you're concluding this.  I have never said, to
my memory, that (array nil) was invalid, and in fact have implemented
it and have not backed out that implementation.  There are two issues
regarding (array nil) which I have also decided upon after my first
writings on the subject here, and so I will clarify them now:

 1. The question of whether there can be an (array nil 10).  I had started
out with the position that such an array could not exist, because it could
not be initialized, but have since seen that there is no support for that
position, because it is only the access of such non-zero-sized arrays which
must signal an error.  Make-array need not initialize its elements, and
thus an (array nil 10) can exist if it is uninitialized.

 2. Whether (subtypep '(array nil) 'string) ==> t.  I believe that the
spec says with consistency that it does, _but_ my knowledge of how the
spirit of the spec fits in to a specific implementation has caused me to
back out the initial changes I had made.  This backing-out has no basis
for argument based on what the spec _says_, because the spec is in fact
consistent.  In fact, I'd love it if you could provide an argument
otherwise, because then I could justify such a willful violation.  But
I think that currently the only argument against the reading that an
(array nil) is a string is that that was not what the original designers
had intended - certainly a good emotional argument, and perhaps even one
which many would accept, but it simply is not a vbalid specificational
argument.

> I just think that there is a minor oerspecificational glitch and that
> if I _were_ going to resolve it, I'd resolve it in the way I mentioned.
> 
> > Your
> > suggestion above suggests a new and different approach, perhaps
> > implying some level of priority to such conformance, or even suggesting
> > that the spec is wrong :-).
> 
> In the case where conformance was in conflict, which I take all this
> tommyrot about element-type NIL being a subtype of STRING to be.  I
> can't speak for them, but I don't think any of the original designers
> intended this or wanted this.  I can say that none has stepped forward
> (that I am aware of) to say they intentionally did want this .

I agree completely.

> > Of course, I don't believe that at all; I
> > only believe that there is a difference in what the spec says from what
> > it was intended to say. Unfortunately, it is very hard to codify such
> > intentions in the face of unknown uses or interpretations.  As you've
> > said yourself, the spec says what the spec says.
> 
> Certainly.  A lot of this hinges on whether you think the spec says
> that element-type NIL should be permitted.  I think it does say that,
> and if you don't, then you'd arrive at a different world model,
> locally in which you might mistakenlyl believe I was advocating a
> willful violation, but in my world model (also, I believe, a valid
> interpretation), I don't think I am.

I do believe that (array nil) is permitted and even mandated.  I think
perhaps you've somehow misunderstood my position at some point.


 [ ... ]

> > I think that in this case the "assault" really comes as a result of
> > every one of us in the CL community being blindsided - Paul Dietz's
> > arguments using the spec are logical and inconvtrovertible, 
> 
> But my reading is that they appear to lead to an "incontrovertible 
> contradiction", which is to say, they appear to lead to things that the
> spec obviously doesn't want on its face, and the thing we have (as a
> community) done in such cases (viz, the return value of PROG2) is to
> just do the right thing.

I don't see this contradiction, and that's precisely the problem I
have.  If you can demonstrate this contradiction, without having to
use the words "that's not what the original designers intended", then
I would be intensely happy and would have no problem violating such an
inconsistent interpretation of the spec.

> The problem that is caused here touches on the issue of what a
> technical error and what a editing error is, on what is obvious and
> what is not.  As some have pointed out in other venues, obvious is a
> function of context (including time), and what is obvious is a
> function of what one has already noticed, so once you've noticed a
> problem, it's really obvious.  But since we did not have the value of
> this detailed forward-chaining at the time we originally did this, it
> wasn't obvious, and what we wanted instead _was_ obvious, so that now
> that we suddenly find that some obscure conclusion is newly obvious, I
> don't think it's fair to say that it is not obvious what to do.  You
> "obviously" think otherwise, but I observe, at least, the possibility
> that there is ambiguity about the issue of obviousness.  And that
> itself is sad, in much the same way as it was sad that it was
> "amibiguous" whether changing the spec's "credits" section required a
> technical or administrative change (there never having been precedent
> within ANSI, and worse, where we set the precedent that it should be
> treated as technical ... ugh) and cost us many months of delay in
> getting the spec out.
> 
> I have, in the past, said that when there is no rule as to whether
> there is an ambiguity about obviousness, that the community should
> observe whethere there is unanimity of interpretation.  The sad thing
> is that there are two competing ambiguities here, and the one that is
> winning is (a) destabilzing existing implementations [which I consider
> bad] and (b) apparently [to me] winning because part of the argument
> involves the use of "formal logic" even though both arguments rely,
> ultimately, on non-logical elements.
===================^^^

I would agree with this whole section if you had used the term
"non-intuitive" rather than "non-logical".  The argument is indeed
non-intuitive, but unfortunately air-tight logically, barring some
insight which shows it to be in contradiction.

> Just as I do not believe in "proving program correctness" but only
> "proving program specifications correct" [that is, proving the formally
> specified elements of programs, there being forever a zeno's paradox of
> 'attachment of specification to the real world' that makes proof of real
> world issues elusive because the fact of a convergence in the limit is
> uncertain], I similarly do not believe you can "prove implications of the
> spec", you can only "prove implications of your interpretation of the spec"
> and  must always have your eyes open to your interpretation being wrong.

All then that might be needed is a formal addendum to the spec saying what
the correct interpretation is.

> That is, my meta-interpretation is that it is a deliberate choice we made
> NOT to use a formal specification language EXACTLY IN ORDER TO assure that
> "real world intuitions" (which everyone has) and not "proof technology" 
> (which I find a bit [a] elitist and [b] capable of doing the kind of
> unwanted surprise that we just encountered) should dominate.  The use of
> English was, I believe, a safeguard.  Then again, that's my interpretation,
> and you can argue otherwise, since nothing requires my interpretation.
> Just don't expect me to back down unless I see a common sense argument
> rather than a "logic requires" argument, because the "logic" is attached
> to a set of foundational elements that defy "obvious readings" and so I
> am more doubtful of the logic than of the obvious readings.

But for the last 10 years or more, logical readings are _precisely_ how
we've all approached the spec.  It's the only way that one can truly
approach the reading of a spec,  and until now it's worked perfectly well -
these issues are the first case I've ever seen where the logic and the
intuition diverge significantly.

> > but not
> > one CL implementation had had an (array nil) before these arguments,
> > and as far as I know, not one user had ever complained.
> 
> But it seems to me to be common-sensicically called for, and inhibited
> only by what I could call "laze" [by which I mean the kind of "lazy
> implementation" that you find in "lazy evaluation", not something more
> pejorative.  Further, when you went to implement it, it appeared to be
> inhibited by something that did not seem to me or anyone as common sense,
> only as a "necessary implication" [as you more or less characterize it]
> tying our hands in violation of common sense readings, which reading I
> reject because it's in conflict with the more basic reading that 
> element-type can take type specifiers of any type.

I think that this unfortunate hyperbole of mine has strengthened the
perception you seem to have that I believe that (array nil) is invalid.
Perhaps I should have said something like "not one CL implementation had
even had an (array nil), let alone making it a string, and as far as I
know not one user had ever complained".  Again, to be clear, I truly do
read the spec as unambiguously calling for (array nil), and I personally
don't have any problem intuitionally with that.

> > > we just differ on how to go about fixing them
> > 
> > Well, perhaps we differ less than you might think.
> 
> Or more than you think, since I bet you take issue with some of what I've
> said above.. :)  I know we've talked about some of the issues before,
> but these above are largely new, at least in their level of detail.

I think that most of what you've said that I take issue with is where I think
you've misunderstood my position.  After my clarifications above, do you still
believe it to be the case that we differ so much?

 [ ... ]

> > tests the spec/implementations dynamic and is much more important as such
> > a test than it is as an actual issue.  If the most important question for
> > Common Lisp is "Can we trust the spec to be implementable and portable?",
> > and these are the worst issues that we can throw at the spec, then I say
> > that the answer is a resounding "Yes!"
> 
> You only reach this position if you think your position leads you to a set
> of consistent readings. I don't think it does. I respect your having taken
> specific positions that you are comfortable with, but I _do not_ think that
> the set of results you've achieved leaves you any more conforming than you
> would be if you followed my suggestions, that is, I think you are just
> choosing different things not to conform to.  Are you conforming "as best
> you can"? yes.  But that's not the same.

Well, therein lies the rub - I completely agree with your objection to the
readings, but disagree with your assertion that it is inconsistent.  Perhaps
some of the CMUCL or SBCL people would be willing to chime in as to whether
the strict interpretation of the spec that they have followed has lead to
any inconsistencies.  I believe that the answer is currently "no".  I have
chosen temporarily to take the implementaional route that
(subtypep '(array nil) 'string) ==> nil, not because of any inconsistency in
the spec, but only for intuitional reasons, and because of that I believe I
am definitely on shakey ground.

> > > I could imagine using element-type NIL arrays, whereas I can't imagine caring
> > > that type (ARRAY NIL) is a subtype of STRING since (a) I don't use it 
> > > explicitly for such, (b) in any case I'm using TYPEP or 
> > > UPGRADED-ARRAY-ELEMENT-TYPE to guard entry to a range of code in which I'm
> > > manipulating strings, I'm content to have (ARRAY NIL) objects deflected from
> > > such areas, and (c) the definition of STRING [as a union type] is already
> > > so weirdly idiosyncratic that it requires delicate care to manipulate code
> > > that does dynamic typing, and as such I don't imagine any really sophisticated
> > > type algebra I do with it getting faked out.
> > 
> > I have currently halted all work on those of Dietz's conformance tests
> > which have to do with typep, u-a-e-t, and (array nil), and probably won't
> > start back on those particular ones until we see what direction the
> > community takes in the matter.  Paul has told me that he is making the
> > tests annotatable, so that tests under contention can be marked as such.
> 
> This was absolutely needed from the beginning.  I'm surprised this is the
> first such situation.  If this is the only controversial test, then I suspect
> his coverage is not as good as I had thought it was, or else that his tests
> are in for some surprises and controversies in other extant or conceivable
> implementations.

Paul has been tesing his test suite against as many implementations as he can
get his hands on, and has worked with implementors as much as is possible.

In cases where an implementor (e.g. me) poses a logical argument against a
particular test, Paul has been extremely responsive in disabling the test
with a comment as to why it could be interpreted as invalid.  So in a sense,
this was indeed always the case from the beginning.

The issue of whether an (array nil) is stringp is the first which he has
not responded in this way, and I think he is within his right to do so,
although I've discussed the issue with him extensively.  This is the first
issue which has really needed such annotation.

  I worry greatly based on these remarks that people will
> infer that these tests constrain the possible set of implementations
> to those interpretations that are extant, which could be a horrible disservice
> to the expandability of various aspects of the language.  I'd love to audit
> the tests, though doubt I'll have the dollars to do this unfunded, in the
> sense that it's likely to take time I don't have to offer.  There's a natural
> desire to use these tests as a way of coming up with hypotheses and then
> testing those hypotheses against existing implementations to "confirm his
> understanding", but that could be quite an inappropriate thing.  I'm not saying
> that it will hurt implementations per se to confront these tests, but what I'm
> saying is that no _programmer_ should read these and assume that a given test
> implies an exhaustive enumeration of possible implementation options.  
> Additional implementation flexibility would simply go unchecked ...

As an implementor, I have always had the same concern with a test suite,
especially since we have enough trouble with our own regression test
suites, where we might not be testing a feature correectly and thus it
might fail on a new architecture.  But my experience with Paul Dietz and
his test suite has so far allayed my natural fears of such overconstraint -
he is very careful and assumes only what the spec tells him he can assume.
My only beef has been that the test suite has not allowed for any intuition,
but in a sense that is a Good Thing, since that brings out into the open
those intuitive assumptions that we've all made all these years...

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: Kent M Pitman
Subject: Re: Amendments to ANS
Date: 
Message-ID: <sfwllupp5mi.fsf@shell01.TheWorld.com>
Duane Rettig <·····@franz.com> writes:

> Kent M Pitman <······@world.std.com> writes:
> 
> I do believe that (array nil) is permitted and even mandated.  I think
> perhaps you've somehow misunderstood my position at some point.

Ah.  Either that or it got lost in the shuffle.  Trying to keep a lot of
things in my head as I discuss this.  Yes, I see your problem now and I
concur that you're stuck.  Sorry that the rest of my text led you in an
apparent wild goose chase.  I still appreciate your responding in detail
so that we could synch back up.

> > You only reach this position if you think your position leads you to a set
> > of consistent readings. I don't think it does. I respect your having taken
> > specific positions that you are comfortable with, but I _do not_ think that
> > the set of results you've achieved leaves you any more conforming than you
> > would be if you followed my suggestions, that is, I think you are just
> > choosing different things not to conform to.  Are you conforming "as best
> > you can"? yes.  But that's not the same.
> 
> Well, therein lies the rub - I completely agree with your objection to the
> readings, but disagree with your assertion that it is inconsistent.

Right.
From: Kent M Pitman
Subject: about test suites in general [was: Re: Amendments to ANS]
Date: 
Message-ID: <sfwfzkxp5jo.fsf_-_@shell01.TheWorld.com>
Duane Rettig <·····@franz.com> writes:

> Kent M Pitman <······@world.std.com> writes:
> 
> > Duane Rettig <·····@franz.com> writes:
...
> > > I have currently halted all work on those of Dietz's conformance tests
> > > which have to do with typep, u-a-e-t, and (array nil), and probably won't
> > > start back on those particular ones until we see what direction the
> > > community takes in the matter.  Paul has told me that he is making the
> > > tests annotatable, so that tests under contention can be marked as such.
> > 
> > This was absolutely needed from the beginning.  I'm surprised this
> > is the first such situation.  If this is the only controversial
> > test, then I suspect his coverage is not as good as I had thought
> > it was, or else that his tests are in for some surprises and
> > controversies in other extant or conceivable implementations.
> 
> Paul has been tesing his test suite against as many implementations as he can
> get his hands on, and has worked with implementors as much as is possible.
> 
> In cases where an implementor (e.g. me) poses a logical argument against a
> particular test, Paul has been extremely responsive in disabling the test
> with a comment as to why it could be interpreted as invalid.  So in a sense,
> this was indeed always the case from the beginning.
> 
> The issue of whether an (array nil) is stringp is the first which he has
> not responded in this way, and I think he is within his right to do so,
> although I've discussed the issue with him extensively.  This is the first
> issue which has really needed such annotation.
> 
> > I worry greatly based on these remarks that people will infer that
> > these tests constrain the possible set of implementations to those
> > interpretations that are extant, which could be a horrible
> > disservice to the expandability of various aspects of the
> > language.  I'd love to audit the tests, though doubt I'll have the
> > dollars to do this unfunded, in the sense that it's likely to take
> > time I don't have to offer.  There's a natural desire to use these
> > tests as a way of coming up with hypotheses and then testing those
> > hypotheses against existing implementations to "confirm his
> > understanding", but that could be quite an inappropriate thing.
> > I'm not saying that it will hurt implementations per se to
> > confront these tests, but what I'm saying is that no _programmer_
> > should read these and assume that a given test implies an
> > exhaustive enumeration of possible implementation options.
> > Additional implementation flexibility would simply go unchecked
> > ...
> 
> As an implementor, I have always had the same concern with a test suite,
> especially since we have enough trouble with our own regression test
> suites, where we might not be testing a feature correectly and thus it
> might fail on a new architecture.  But my experience with Paul Dietz and
> his test suite has so far allayed my natural fears of such overconstraint -
> he is very careful and assumes only what the spec tells him he can assume.
> My only beef has been that the test suite has not allowed for any intuition,
> but in a sense that is a Good Thing, since that brings out into the open
> those intuitive assumptions that we've all made all these years...

Sure.  As long as it's taken in this light and the set of things in it are
not published as "examples of good code to be emulated", that's ok.  There
is nothing to a test suite other than "challenge/response" but a correct
response only proves you didn't step out of bounds.  Nothing prevents the
case of:

 (progn (print "Type in a word that means 'one' in some language: ")
        (let ((one (read)))
          (unless (member one '(one uno))
            (error "The word you typed, ~A, doesn't mean 'one'." one))
          one))

And EVEN IF you enumerated EVERY language known to man, it STILL would 
not be sufficient to say that the test was finally correct, since new
languages might be invented or discovered later.

None of this is to say that the test is not useful to someone who 
knows what they are using the test for, but it's just the case that the
original intent should not be forgotten.

I'm reminded of the observation of someone that for now, programs like
TurboTax try to follow the US Tax Law, but it's not unlikely that
at some point it might be administratively simpler to simply _define_
these programs to be correct (as some languages define their only 
implementation to be correct) in order to be able to prove that the
program will never be non-conforming, and thus in order to avoid the need
to check the results of the program.  This is just a meta-tendancy of humans,
and perhaps nature, to simplify, grinding out what seems like unneeded
overhead.  

The test quite could easily morph along similar lines in people's minds if 
we did not remind ourselves that this is not so.

Just look at how people have come to see the web as 'what browsers implement'
and to forget that the original design did not have every URL beginning
with 'http://' but actually intending that there be a rich vocabulary of
contact protocols ... people quickly become used to something they use a lot,
and then just as quickly extinguish their imagination about what else it 
could have been.
From: Christophe Rhodes
Subject: Re: Amendments to ANS
Date: 
Message-ID: <sq7k6989zv.fsf@lambda.jcn.srcf.net>
Duane Rettig <·····@franz.com> writes:

> Kent M Pitman <······@world.std.com> writes:
>
>> You only reach this position if you think your position leads you to a set
>> of consistent readings. I don't think it does. I respect your having taken
>> specific positions that you are comfortable with, but I _do not_ think that
>> the set of results you've achieved leaves you any more conforming than you
>> would be if you followed my suggestions, that is, I think you are just
>> choosing different things not to conform to.  Are you conforming "as best
>> you can"? yes.  But that's not the same.
>
> Well, therein lies the rub - I completely agree with your objection to the
> readings, but disagree with your assertion that it is inconsistent.  Perhaps
> some of the CMUCL or SBCL people would be willing to chime in as to whether
> the strict interpretation of the spec that they have followed has lead to
> any inconsistencies.  I believe that the answer is currently "no".  I have
> chosen temporarily to take the implementaional route that
> (subtypep '(array nil) 'string) ==> nil, not because of any inconsistency in
> the spec, but only for intuitional reasons, and because of that I believe I
> am definitely on shakey ground.

There have been no inconsistencies that I've found in implementing a
(vector nil) type that is a subtype of string.  I believe that support
for it is essentially complete in the (frozen) version of SBCL that
will shortly be released as version 0.8.2 (by the end of the week,
probably).  This version will not include the fix that I am preparing
in the implementation of MAKE-STRING-OUTPUT-STREAM, which currently
does not respect the possibility of something of the form

  (with-output-to-string (s nil :element-type 'nil)
    nil)
  => "" ; a (vector nil) with no elements

but apart from this there have been no reports of any kind of bug, let
alone inconsistency.  (Not, I suspect, that most of the system's users
are leaping up and down for joy at their newly-found ability to
compare "" and (make-array 0 :element-type 'nil) under STRING= ;-)

I'd just like to reiterate, lest the strong implementational line that
I am currently taken be confused with the position I take on what I
believe the specification ought to say (I'm too young to remember
one-argument TYPEP, I'm afraid, and I wasn't steeped in the rich oral
tradition of the glory days :-), that I would welcome at the very
least discussion of an amendment to the description of the string
type, because I believe that the cost to users of mandating 
  (subtypep '(vector nil) 'string)
is too great.  Maybe users could chime in if they disagree at this
point?

>> This was absolutely needed from the beginning.  I'm surprised this is the
>> first such situation.  If this is the only controversial test, then I suspect
>> his coverage is not as good as I had thought it was, or else that his tests
>> are in for some surprises and controversies in other extant or conceivable
>> implementations.
>
> Paul has been tesing his test suite against as many implementations as he can
> get his hands on, and has worked with implementors as much as is possible.
>
> In cases where an implementor (e.g. me) poses a logical argument against a
> particular test, Paul has been extremely responsive in disabling the test
> with a comment as to why it could be interpreted as invalid.  So in a sense,
> this was indeed always the case from the beginning.

I'd like to second Duane's view here, too; Paul has been extremely
responsive when presented with credible alternative readings that
invalidate his tests.  Yes, it's true that the space of current
implementations does not explore implementation space completely, and
consequently absence of evidence is not evidence of absence; however,
following the progress of these tests as they have been developed
gives me a certain amount of confidence in those I have not
specifically audited.

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)
From: Christophe Rhodes
Subject: Re: Amendments to ANS
Date: 
Message-ID: <sqoezl8k42.fsf@lambda.jcn.srcf.net>
Duane Rettig <·····@franz.com> writes:

> I think that in this case the "assault" really comes as a result of
> every one of us in the CL community being blindsided - Paul Dietz's
> arguments using the spec are logical and inconvtrovertible, but not
> one CL implementation had had an (array nil) before these arguments,
> and as far as I know, not one user had ever complained.  

Quite.  This is why I consider a (user)-cost-free implementation of
(array nil) to be reasonable, given the relative ease in which it
appears to be implementable (clisp, sbcl and your development version
of acl all dealing with it); since the cost of mixing it into the
string type appears to be non-trivial, I would be all for an amendment
to the description of the string type to exclude (vector nil)
specifically.

> As far as I
> know, clisp had previously given (typep t) ==> 'boolean rather than
> 'symbol, but it was in the minority, and that was as far as it went,
> from what I understand of it.  

Ah, you're talking about TYPE-OF?  What problems has this caused?

> [snip]
> If the most important question for
> Common Lisp is "Can we trust the spec to be implementable and portable?",
> and these are the worst issues that we can throw at the spec, then I say
> that the answer is a resounding "Yes!"

Be careful of early triumphalism -- Paul hasn't started to look at
pathnames yet. ;-) But yes, so far it's not too bad.

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)
From: Kent M Pitman
Subject: Re: Amendments to ANS
Date: 
Message-ID: <sfwu19d2uu5.fsf@shell01.TheWorld.com>
Christophe Rhodes <·····@cam.ac.uk> writes:

> > As far as I
> > know, clisp had previously given (typep t) ==> 'boolean rather than
> > 'symbol, but it was in the minority, and that was as far as it went,
> > from what I understand of it.  
> 
> Ah, you're talking about TYPE-OF?  What problems has this caused?

In Maclisp and Franz Lisp [both pre-CL dialects, neither extant today
in other than museum-piece implementations, as far as I know], TYPE-OF
was called TYPEP, and I guess Duane and I were just using the old name
without thinking of it.  During the transition (1984, with CLTL), we often
referred to "one argument typep" and "two argument typep".
From: Paul F. Dietz
Subject: Re: Amendments to ANS
Date: 
Message-ID: <ZK2dnSijgeKjKr6iU-KYuQ@dls.net>
Christophe Rhodes wrote:

> Heh :-).  I don't think that the cost of these specialized arrays is
> enormous -- certainly not as great as the string/vector-nil; I'm
> willing to be persuaded by an example, though, and if there is a good
> way of cleaning up this one I'd be all for it.

Is the marginal cost of (vector nil) strings really all that large,
if the lisp is also supporting multiple 'real' string types (for example,
byte strings and 16-bit unicode strings?)  One presumably must
dynamically dispatch on simple strings anyway in this case.

This is not to argue that (vector nil) strings are useful, mind you.

	Paul
From: Christophe Rhodes
Subject: Re: Amendments to ANS
Date: 
Message-ID: <sqk7a4rrwe.fsf@lambda.jcn.srcf.net>
"Paul F. Dietz" <·····@dls.net> writes:

> Christophe Rhodes wrote:
>
>> Heh :-).  I don't think that the cost of these specialized arrays is
>> enormous -- certainly not as great as the string/vector-nil; I'm
>> willing to be persuaded by an example, though, and if there is a good
>> way of cleaning up this one I'd be all for it.
>
> Is the marginal cost of (vector nil) strings really all that large,
> if the lisp is also supporting multiple 'real' string types (for example,
> byte strings and 16-bit unicode strings?)  One presumably must
> dynamically dispatch on simple strings anyway in this case.

I don't think it is, in terms of impact on user code, but the key word
in that question is "if".  None of CMUCL, SBCL and Allegro CL have
historically offered more than one string type, and the marginal cost
of supporting (vector nil) is then measurable (though not, as far as I
can tell, immense).

> This is not to argue that (vector nil) strings are useful, mind you.

An issue was pointed out to me recently, actually; in an (hypothetical
-- at least I don't know of any) implementation offering support for
character repertoires (CLHS 13.1.2.2), one would wish, by similar
arguments to those employed by U-A-E-T, that performing type algebra
on repertoires not remove the essential characterness of the
repertoires' members... which draws one towards the necessity of
supporting arrays specialized on the empty type as strings. :-(

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)
From: Steven M. Haflich
Subject: Re: Is there any standardized way to obtain an instance of class METHOD-COMBINATION?
Date: 
Message-ID: <3F1D6EF6.4090703@alum.mit.edu>
Christophe Rhodes wrote:

> Right.  How does one get the ball rolling?  (Probably the ball should
> only start rolling once Paul is happy with his magnum opus; but maybe
> the ball needs to be pushed for a while before it sets off?)

In point of fact, anyone at all can take an issue to INCITS/J13 and
request the committee to address it.  But in practice, the committee
would only address something they felt was important enough (to the
members) to warrant the time to address it., and for which there was
enough interest and available resource to do the job.

In this case, these several conformance issues are fairly important to
my organization, so I'm inclined to bring it up with the committee myself
and deal with the administrative issues to get things going.
From: Marco Antoniotti
Subject: Re: Is there any standardized way to obtain an instance of class METHOD-COMBINATION?
Date: 
Message-ID: <3F1562E1.3090502@cs.nyu.edu>
Steven M. Haflich wrote:
> Paul Dietz wrote:
> 
>> No, of course not (to the question).  But it's moderately annoying
>> to me that features are included in the language (such as,
>> the :method-combination argument to ensure-generic-function)
>> that cannot be tested *at all* by conforming tests.  Wouldn't
>> it have been easier to just leave that out, and let the keyword
>> argument be part of the extension (MOP, I presume) that would
>> provide values that would make it useful?
> 
> 
> I have read the subsequent discussion on this thread, but I must
> admit that I can't understand the premise of the discussion at all.

I think the starting point of ths discussion is the same of

	What should

		(pathname-name (parse-namestring ".cshrc"))

	return on an UNIX system?

I.e. it is one of the "rough edges" that are there in the ANSI standard 
(Please do not start a thread about the example I gave.  It is just 
rethorical).

I answered Paul's message because at some point I was playing around 
with method combinations and bumped exactly in the 
ENSURE-GENERIC-FUNCTION roadblock.

Moreover, AFAIK, not even in the MOP there is a way to just get a method 
combination object.  This is IMHO a problem.  The only thing to do is to 
figure out its magnitude.

Cheers

--
Marco
From: Barry Margolin
Subject: Re: Is there any standardized way to obtain an instance of class    METHOD-COMBINATION?
Date: 
Message-ID: <lrdRa.199$0z4.126@news.level3.com>
In article <················@alum.mit.edu>,
Steven M. Haflich <·················@alum.mit.edu> wrote:
>(First, there is the minor point tha the ANS was _not_ written in
>order to proved a well-formed canonical convex exercise for the
>writer of a conformance suite.

I suspect he recognizes that this wasn't an explicit goal.  However, this
inability is an indication of poor, or perhaps incomplete or inconsistent,
design of the language.

-- 
Barry Margolin, ··············@level3.com
Level(3), Woburn, 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: Pascal Costanza
Subject: Re: Is there any standardized way to obtain an instance of class    METHOD-COMBINATION?
Date: 
Message-ID: <bf0ud8$slg$1@f1node01.rhrz.uni-bonn.de>
Steven M. Haflich wrote:

> The X3J13 action that adopted CLOS into the draft ANS happened in 1989.
> At that time there were no mature industrial implementations and relatively
> little experience coding with CLOS.  (PCL existed, but did not qualify as
> mature, industrial quality code.)  The most-excellent subcommittee that had
> drafted the proposed CLOS standard presented it in three parts, the first
> two parts of which were the portion currently embodied in the ANS and the
> third of which was the MOP.  They recommended (forcefully!) that the first
> two sections be accepted exactly as they stood (since the design of CLOS
> is subtle, and innocent plenum committee tweaks could easily have broken
> the design) but they recommended justas strongly that the MOP portion be
> deferred until there was more experience both implementing and exploiting
> the MOP.  This is what X3J13 enacted, and I believe it was the wise path.
> Objectively ("objectively" is a synonym for my subjective opinion :-) the
> CLOS definition has survived with little need for tweaking, while the MOP
> would need a few objectively-minor tweaks before being officially
> standardized.

I recall reading that X3J13 had already already known about potential 
holes/issue/problems (?!?) with the MOP. Is this documented somewhere? 
(I am interested in these mainly for historical reasons. I am thinking 
about something like the very informative issue writeups in the HyperSpec.)

And does anybody have a well-educated opinion wether these issues have 
been resolved in the meantime?

In particular, what tweaks to the MOP do you think are needed?


Pascal

-- 
Pascal Costanza               University of Bonn
···············@web.de        Institute of Computer Science III
http://www.pascalcostanza.de  R�merstr. 164, D-53117 Bonn (Germany)