[Gcl-devel] Re: arity

[Camm Maguire]

Robert Boyer <address@hidden> writes:

> > The type algebra is not working properly on values types.
> 
> There is almost a logical absurdity inflicted on those who
> try thinking about types such as
> 
>    (list 'values x y z)
> 
> What can it possibly mean?  What I think it tries to mean is
> that here something is returned that may have any number of
> values, but it if does return three or more values, then the
> first must be of type x, the second of type y, and the third
> of type z; if it does return exactly 2 values, the first
> must be of type x, the second of type y, and nil must have
> type z; if it does return exactly 1 value, the first must be
> of type x, and nil must be of both type y and z; if it
> returns exactly no values, then nil must be of types x, y,
> and z.
> 
> So because NIL is definitely not a fixnum,
> 
>    '(values fixnum fixnum)
> 
> says "returns at least two values", and the first two must
> be fixnum, whereas
> 
>    '(values t t)
> 
> says nothing at all!  Maybe returns no values.  Am I
> delirious?
> 
> I wonder if it is not necessary to shift focus from some
> idealized notion of Common Lisp semantics, which may not
> even exist, to a more practical notion of what GCL/GCC is
> actually doing at a particular point and what, therefore,
> other GCC/GCL code can rely upon.  Trying to integrate this
> concrete notion of abstract C behavior with crazy PROCLAIM
> may be impossible, and a complete change of nomenclature may
> be advisable.  I.e., just utterly ignore COMMON-LISP's
> PROCLAIM and use some other word, e.g., ARITY for what you,
> qua implementor, mean, deduce, and implement.
> 

Greetings!  OK, as posted earlier, this is what is done, separating
the values type logic away from subtypep into the compiler.  We still
are integrated with proclaim, and so we should make a decision at some
point how to resolve the interaction if any between proclaim ftype and
autoproclamation. 

Here is how it works now:

If *compiler-auto-proclaim* is set, an automatic '(proclaim (ftype
...)) is done before the values are read in a later stage of
compilation to set the function signature.  So if this is not set, the
user determines the behavior as before.  If this switch is set, any
user settings are essentially ignored.  Furthermore, the information
is duplicated from its traditional location on the symbol's plist, to
an entry in the global si::*call-hash-table*.  Hence any new value
type semantics is currently using the proclaim mechanism to get its
message across.

Some possibilities:

1) Have proclaim follow purely ansi semantics, like subtypep, and use
   the auto stuff purely in the call-hash-table.  User proclaims
   should probably override compiler auto-determinations, though the
   latter are somewhat superior at the moment.  This preserves
   backward compatability with the older (make-all-proclaims) should
   anyone want to use it

2) Ignore proclaim ftype, as other implementations apparently do, and
   have the compiler alone set the function signature.  The type
   semantics are then up to us.

3) Other possibilities?

Take care,

> Bob
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah