[Openmcl-devel] deftype bug?

[Paul Krueger]

It's certainly not difficult to code in a way that doesn't assume  
serialized behavior for the "and" and "or" combiners, although it is  
definitely a nuisance since you have to encapsulate otherwise useful  
predicates in functions that do other type checking. And in fact this  
behavior makes the use of the "and" combiner not very useful if you  
also include a "satisfies" type. I'm curious if anyone knows why the  
serial semantics that were so clearly defined in CLtL2 were not  
adopted for the standard; oversight or choice?

I suppose I would argue that if this was an explicit choice, then the  
syntax for type combinations should have been changed to use  
"intersection" and "union" rather than "and" and "or" respectively,  
since the latter are at least suggestive of the serial semantics that  
results when those terms are used elsewhere in Lisp.

Paul

On Mar 18, 2010, at 4:03 AM, Gary Byers wrote:

>
>
> On Thu, 18 Mar 2010, Nikodemus Siivola wrote:
>
>> On 18 March 2010 05:11, Gary Byers <gb at clozure.com> wrote:
>>
>>> It's being handled incorrectly; preserving the left-to-right/short- 
>>> circuit
>>> order of the AND specifier's subforms is only one of the things  
>>> that goes
>>> wrong there.
>>
>> Not to butt in here, but... I'm pretty sure
>> left-to-right/short-circuit is not specified for AND/OR as a type
>> specifiers. If someone can point to language in the spec requiring
>> otherwise, I'm happy to be corrected.
>
> I've looked for it before, and I'm not aware of any language in the
> ANSI spec as written that specifies how intersection or union are
> determined either, which seems to indicate that an implementation can
> process the types in an AND or OR specifier in any order - whether
> "reasonable" (by some definition of "reasonable") or not - and still  
> be
> compliant.
>
>
>>
>> I believe that for portable code functions used in SATISFIES type
>> specifiers should accept all types of arguments.
>
> Yep.  One unfortunately can't count on any definition of reasonable
> behavior across all implementations.
>
> There's a (separate) bug in how Paul's example is handled, and I
> personally think that it's reasonable for AND and OR type specifiers
> to be processed (as if) with the left-to-right/short-circuit semantics
> described in CLtL2 (and in widespread use for many years before that),
> but you're obviously right that that part of CCL's misbehavior here  
> isn't a
> matter of non-compliance.
>
>>
>> Cheers,
>>
>> -- Nikodemus
>>
>>