[Openmcl-devel] deftype bug?
plkrueger at comcast.net
Thu Mar 18 07:11:17 PDT 2010
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.
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-
>>> 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
>> 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.
>> -- Nikodemus
More information about the Openmcl-devel