[Openmcl-devel] deftype bug?

[Daniel Weinreb]

Paul Krueger wrote:
> 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.
You can use it if your "satisfies" function just happens
to always return (rather than signal) for any Lisp object.
But that usually isn't the case, unfortunately.

>  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?
>   
It was so long ago that it's hard to say.  I'm guessing
that it was an oversight, because there is an example
in CLtL that obviously assumes the behavior analogous
to the "and" special form.

-- Dan
> 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
>>>
>>>
>>>       
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20100319/0b0de0d5/attachment.htm>