[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

the array type mess....



re: To say the same thing in Lisp:
    . . . 
    (DEFUN IMPLEMENTATION-DEPENDENT-ARRAY-ELEMENT-TYPE (TYPE)
      (ARRAY-ELEMENT-TYPE (MAKE-ARRAY 0 :ELEMENT-TYPE TYPE))
    . . . 
    Should the IMPLEMENTATION-DEPENDENT-ARRAY-ELEMENT-TYPE function I have
    postulated as hidden inside TYPEP be made available as a standard function?


Your summary here is essentially the same as the proposal I sent to 
CL-CLEANUP on March 1, except I named it UPGRADE-ARRAY-ELEMENT-TYPE
to suggest that a possibly-non-trival super-type would be returned. 
Also, I think the functionality underlying UPGRADE-ARRAY-ELEMENT-TYPE 
is already in everyone's arrays implementation, regardless of how they 
handle the TYPEP mess.  For those not on the cl-cleanup list, I've
excerpted the relevant message below.


    Date: Tue, 1 Mar 88 13:09:10 PST
    From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
    To: Moon@stony-brook.scrc.symbolics.com
    Cc: cl-cleanup@sail.stanford.edu, vanroggen%aitg.decnet@hudson.dec.com,
	    Ram@c.cs.cmu.edu
    Subject: UPGRADE-ARRAY-ELEMENT-TYPE: a sloution for the array TYPEP problem
    . . .   a function (which
    would be "implementation revealing") named UPGRADE-ARRAY-ELEMENT-TYPE
    whose purpose would be to tell you what the canonical representation for a
    type name is (when used as an :element-type specifier).  
    . . . 
    [why not toss out "upgrading" altogether? because ...]
     to make types absolutely portable this way is a very pyrrhic success.
    Sure, your program will port to the Y machine -- it will just run two 
    orders of magnitude slower [because you started out on, say, a Multics 
    machine with (MOD 512) arrays optimized, and ported to an implementation 
    for an engineering workstation that prefers (UNSIGNED-BYTE 8) arrays ...].

    Finally, as I've said before, I don't think it's an acceptable solution 
    for Lisp to take the same route as C (and others) to achieve portability.
    The kinds of array types in such languages are limited to a small (albeit
    very useful) set that seems inspired by one particular hardware 
    architecture.

    -- JonL --

    P.S. Of course UPGRADE-ARRAY-ELEMENT-TYPE can currently be implemented
	in a "consy" way doing something like:
	    (array-element-type (make-array 0 :element-type 'foo))
	But the presence of a "first class" function UPGRADE-ARRAY-ELEMENT-TYPE
	would be more for the purpose of encouraging cognizance of these
	problems than for avoiding the consing.  Implicitly, such a function
	lies underneath any implementation of MAKE-ARRAY already.


    Date: Tue, 1 Mar 88 14:05:25 PST
    From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
    To: Ram@c.cs.cmu.edu
    Cc: cl-cleanup@sail.stanford.edu, Moon@scrc-stony-brook.arpa,
	    vanroggen%aitg.decnet@hudson.dec.com
    Subject: function-type-rest-list-element (really array types)
    ...
    This may be another way of trying to say that
	    `(ARRAY FOO)
    is type equivalent to
	    `(ARRAY ,(upgrade array-element-type 'foo))



-- JonL --