Robert Boyer <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
