function-type-rest-list-element

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: 24 Feb 88 10:06:00 EDT
    From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>

      From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

      But the analogy to VECTOR is false!  (VECTOR element-type) does not
      mean a vector all of whose current elements are of type element-type.
      Nor does it mean a vector constrained such that that all elements
      that can be stored into it are of type element-type.  The ambiguous
      language on CLtL p.47 might lead you to think that's what it means,
      but CLtL p.45 makes it clear.  For declaration, (VECTOR element-type)
      [via (ARRAY element-type (*))] means a one-dimensional array
      of the most specialized type that is capable of holding objects of
      type element-type.  Therefore, unless element-type is STRING-CHAR
      or BIT, or a subtype of one of them, this guarantees exactly nothing
      about the types of the elements of the vector.
  
      Maybe the element-type argument to these type-specifiers should mean
      something else, but that's what it means in Common Lisp as currently
      defined.

    The discussion of ARRAY type specifiers on p.45 is talking about the
    permissible and expected representations of arrays, not of the possible
    types of the elements of such arrays.  So what's on p.45 doesn't make
    anything clear here.

    What would you expect to be the type of the result of the following code:
     (let ((a ...))
       (declare (type (vector foo) a))
       (aref a 3))

I don't see anything in CLtL that addresses this question.

    I believe that in every implementation, the result should be of type FOO,
    for any type FOO.  What is discussed on p.45 says that A might not be of
    type (VECTOR FOO).  But this is unrelated to the question of whether
    the elements of the array have any particular type.

    Setting an element of A to be something that's not of type FOO is
    an error.  The representation might allow it, because the new value
    might be (TYPEP x (ARRAY-ELEMENT-TYPE A)), but that doesn't make it
    correct.  It's just a matter of whether the array happened to
    remember the precise type it was created with.

I agree that this is a reasonable approach.  I don't think CLtL says
this, but I don't think it says anything that contradicts it, either.  I
think this is not too relevant to my point that the (VECTOR FOO)
type-specifier does not mean a vector all of whose elements are of type
FOO.  As you point out, it means that a portable program "should" (in
CLtL "is an error" sense) assume that it can only store elements of type
FOO into that vector.  But I think your proposed meaning for (LIST FOO)
was rather stronger.  Perhaps I should make my point a different way:
I don't think that Common Lisp's current type system for compound types
is well enough specified for this kind of extension to work obviously
and naturally without exposing problems.

    I haven't read any clean-up mail, so if you've talked about this
    issue and resolved it somehow, please tell me.

It's been discussed periodically but I don't think it's ever come close
to resolution.  It's perhaps too large an issue for the Cleanup committee.

    The problem here is in trying to use lambda-list syntax for describing
    function calls.  Already there's a slight contortion by having the
    actual keywords be included in the function type for &KEY arguments.
    So it isn't quite as simple as just taking the real lambda-list,
    deleting all the init forms and &AUXen, and replacing parameter names
    with their types.  But I think this way of looking at how function
    type specifiers are derived is easier than starting with just a
    positional approach (i.e., the second arg, if supplied, has to be of
    type X, etc.) and then modifying it to also convey number-of-args and
    keyword information.  Thus one would prefer having the type specifier
    for the &REST argument be the real type specifier for the &REST argument.

I agree with you, up to the last sentence, which I can't understand.
There isn't such a thing as an "&REST argument" in Common Lisp, unless
you mean the last argument to APPLY.  If where you said "argument" you
meant "parameter", then I understand what you're saying but don't agree
with it.  One could equally well conclude from the preceding paragraph
that the type specifier for the &REST arguments (note the plural)
should be the type specifier for each actual argument.  Since there isn't
a one to one correspondence of arguments to parameters in this one case,
the analogy of function type specifiers to lambda-lists doesn't really
give us any guidance.

I'm being too long-winded here, since I don't even know what these
FUNCTION type specifiers are useful for, anyway.  My main reason for
jumping in was to point out a possible misconception about how strong
the VECTOR type specifier is in current Common Lisp.

    Date: Thu, 25 Feb 88 09:19:28 PST
    From: Jon L White <edsel!jonl@labrea.Stanford.EDU>

    re: The discussion of ARRAY type specifiers on p.45 is talking about the
	permissible and expected representations of arrays, not of the possible
	types of the elements of such arrays.  So what's on p.45 doesn't make
	anything clear here.

    Well, it's true that CLtL pp45-47 are anything but "clear".  But what
    Dave is saying (I think) is that a number of wizards have groveled over 
    those pages and all agree that there is only one interpretation of them
    consistent with the rest of CLtL.  And that interpretaton is at variance 
    with your comments:

	Setting an element of A to be something that's not of type FOO is
	an error.  The representation might allow it, because the new value
	might be (TYPEP x (ARRAY-ELEMENT-TYPE A)), but that doesn't make it
	correct.  It's just a matter of whether the array happened to
	remember the precise type it was created with.

    Perhaps the clearest indicator that CLtL really isn't saying this is
    found on p291, under the description of ARRAY-ELEMENT-TYPE.  Note how
    this section really is "clear" that an array made by
	    (make-array 5 :element-type '(mod 5))
    may legitimately have an element stored into it that is of type (mod 8)
    but not necessarily of type (mod 5).

Well, this is simply another way of stating the root problem here.  CLtL
isn't sure whether its data types are portable, fairly abstract types or
are ways to find out about implementation details.

    Date: Sat, 27 Feb 1988  21:17 EST
    From: Ram@C.CS.CMU.EDU

    Well, I don't agree with VanRoggen's stand on the &rest type issue,
    but I think he is pretty close to the mark about array types.  This
    isn't inconsistent, since the desirability or feasilibility of a typed
    list specifier is pretty unrelated to the &rest issue.

Not really, since VanRoggen's proposal was to employ a typed list
specifier in the resolution of the &rest issue.

By the way, I'm not arguing in favor of the way array types currently
are defined, I'm just pointing out the facts.  If we're now going to
redesign array types, I think that's a good idea, or at least an
interesting one, but I'll probably limit my contribution to pointing out
that it isn't easy, i.e. the obvious trivial fixes don't completely
work.

    The only rationale under which one could store something not (mod 5)
    into that array would be that they could make the array, then call
    ARRAY-ELEMENT-TYPE to find out that element types it can actually
    hold, and then store randomness into it.  I don't believe that this is
    a reasonable thing to do.

But someone else might believe that it is.  See my comment above that
CLtL isn't sure what the goal of the type system is.

    This basically amounts to bogotifying the language in order to make
    ARRAY-ELEMENT-TYPE work.  This is a bad idea, since I think that the
    semantics of ARRAY-ELEMENT-TYPE are just as seriously flawed as the
    semantics of TYPE-OF. (which is another flame)

    It is much easier to give types a clean semantics in Common Lisp if
    ARRAY-ELEMENT-TYPE and TYPE-OF are ignored.  For example, without
    these functions, there would be no way for users to even know that
    "array element type upgrading" exists.  (Assuming the array TYPEP
    "feature" mentioned in the manual is fixed.)

Yes, the semantics would be cleaner if there weren't compound objects,
or if there weren't implementation dependencies.  No argument about that.
I think removing those primitives from the language may be just sweeping
the problem under a rug, not solving it, though.  Admittedly that would
be in the tradition of Common Lisp.