<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body text="#000000" bgcolor="#ffffff">
<br>
<br>
Paul Krueger wrote:
<blockquote type="cite" cite="mid:1E0C3499-B89D-4EFA-95D1-2577D930D303@comcast.net">
<pre wrap="">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.</pre>
</blockquote>
You can use it if your "satisfies" function just happens<br>
to always return (rather than signal) for any Lisp object.<br>
But that usually isn't the case, unfortunately.<br>
<br>
<blockquote type="cite" cite="mid:1E0C3499-B89D-4EFA-95D1-2577D930D303@comcast.net">
<pre wrap=""> 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?
</pre>
</blockquote>
It was so long ago that it's hard to say. I'm guessing<br>
that it was an oversight, because there is an example<br>
in CLtL that obviously assumes the behavior analogous<br>
to the "and" special form.<br>
<br>
-- Dan<br>
<blockquote type="cite" cite="mid:1E0C3499-B89D-4EFA-95D1-2577D930D303@comcast.net">
<pre wrap="">
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:
</pre>
<blockquote type="cite">
<pre wrap="">
On Thu, 18 Mar 2010, Nikodemus Siivola wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 18 March 2010 05:11, Gary Byers <a href="mailto:gb@clozure.com" class="moz-txt-link-rfc2396E"><gb@clozure.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">I believe that for portable code functions used in SATISFIES type
specifiers should accept all types of arguments.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">Cheers,
-- Nikodemus
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
_______________________________________________
Openmcl-devel mailing list
<a href="mailto:Openmcl-devel@clozure.com" class="moz-txt-link-abbreviated">Openmcl-devel@clozure.com</a>
<a href="http://clozure.com/mailman/listinfo/openmcl-devel" class="moz-txt-link-freetext">http://clozure.com/mailman/listinfo/openmcl-devel</a>
</pre>
</blockquote>
</body>
</html>