given a type like this one:   (and symbol (satisfies fboundp)).

Would you think that

  (typep 3 '(and symbol (satisfies fboundp)))

can signal an error?

In this case the order of type checks is important.
(typep 3 'symbol)  is fine.
But (typep 3 '(satisfies fboundp))  would call
(fboundp 3), which would lead to an error.

Is a conforming implementation of ANSI Common Lisp
allowed to run the tests in any order for
AND types? Will all test be running? From left to
right until a test fails?

Above could be replaced by

  (typep 3 '(satisfies symbol-fbound-p)

given that symbol-fbound-p is a function
that checks for symbolp and fboundp.

But I would like to avoid that. ;-)

Any opinions?

Regards,

Rainer Joswig

It seems that in CLtL2 there was real wording for that:

http://lispm.dyndns.org/documentation/cltl2/clm/node48.html#SECTION00...

I can't find anything like that in ANSI CL.

 (and t1 t2 ... tn)

simply ``denotes'' the domain of objects which are in the intersection
of those two sets.

I see the more serous issue as being the behavior of SATISFIES.
Actually two issues.

Issue 1.

  If the given function blows up if given the object as an argument, then
  obviously, that object does not satisfy that function! So SATISFIES ought to
  trap the error and return NIL.

But maybe there are good reasons not to do that.

One good reason is that maybe you can use SATISFIES as a building block for
implementing your own flavor of the operator which does have that behavior.
If SATISFIES caught errors, you woudl not be able to use it as a building
block to make a flavor of SATISFIES which passes thorugh errors.

This brings us to:

Issue 2.

  The argument of SATISFIES must be a symbol, and not just anything
  that can serve as a function name. In particular, lambda expressions
  are explicitly disallowed.

See, if you could write (satisfies (lambda (x) ...)), you'd have it made,
thanks to this deftype:

  (deftype satisfies* (function)
    `(satisfies (lambda (x) (ignore-errors (,function x)))))

Now you could do:

  (typep 3 '(satifies* fboundp))

Alas, no luck!

Is there some other way to do this? How about:

  (defmacro define-safe-type-predicate (alias-name target-function-name)
    `(defun ,alias-name (arg) (ignore-errors (,target-function-name arg))))

  (define-safe-type-predicate fboundp* fboundp)

  (typep 3 '(satisfies fboundp*)) -> NIL

Ugh. I hate that! Would it be to gross a hack if a user-defined type operator
had the side effect of defining a function? Are you ready for this:

(deftype satisfies* (function)
    (let ((fun (gensym)))
      (setf (symbol-function fun) (lambda (x)
                                     (ignore-errors (funcall function x))))
      `(satisfies ,fun)))

If a symbol with a global function bidning it wants, a symbol with
a global function binding it gets! :)

 (typep 3 '(satisfies* fboundp)) -> NIL

Still, I have a small problem with the little fact that each occurence of
'(satisfies* fboundp) generates a SATISFIES with a different symbol, i.e. two
compound forms that are not EQUAL! That's bound to screw something up.

Like when types are compared, how is that done? It's certainly not going make
inferences about what the SATISIFED functions do. Type comparison is probably
based on the simple structural equivalence of the expanded forms.

Indeed, in this here CLISP implementation, we have a problem:

 (subtypep '(satisfies* fboundp) '(satisfies* fboundp)) -> NIL

 (subtypep '(satisfies fboundp) '(satisfies fboundp)) -> T

Whoops! The hack must be even more skanky to make it work; instead of using a
GENSYM, it should use an interned symbol. We can use a dedicated package for
these:

  (defpackage #:secret-package-of-safe-aliases (:use))

  (deftype satisfies* (function)
    (let ((fun (intern (symbol-name function)
                       '#:secret-package-of-safe-aliases)))
       (unless (fboundp fun)
         (setf (symbol-function fun) (lambda (x)
                                        (ignore-errors (funcall function x)))))
       `(satisfies ,fun)))

This works for me now in CLISP:

 (subtypep '(satisfies* fboundp) '(satisfies* fboundp)) -> T ; T

The Scieneer CL interprets the 'and compound type specifier as
intersection and the type may be rewritten or tested in any order.
The type system tries hard to simplify compound types and the
compiler makes good use of the type information.

This does require that the function of a 'satisfies type specifier
can accept objects of any type.  It is recommended to still use
a compound type when it exposes more type information, for example:

(defun safe-fboundp (symbol)
  (and (symbolp symbol) (fboundp symbol)))

Then use the type '(and symbol (satisfies safe-fboundp)).

It may be possible to rework the type algorithms to maintain
the ordering constraint but there are many obvious algorithms
that do not maintain this constraint.

Some CL implementations just ignore an error and return false
upon an error, but then real errors are lost.

Regards
Douglas Crosher

On Dec 6, 8:19 am, Rainer Joswig <jos...@lisp.de> wrote:

it would interest me what lead to the current version
in ANSI CL? Was it a change from CLtL2 or an omission?
Two of the ANSI CL examples don't seem to fit into the
ANSI CL version.

There is the issue of backward compatibility, since
CLtL2 described something different.

From what I got as feedback and from what I read
in ANSI CL, it seems that your interpretation
is a) 'legal' and b) the rules have been relaxed
(from CLtL2 to ANSI CL) to allow such an interpretation
(this is what I guess).

So, it looks like 'we' will have to change the CL-HTTP code
from (and symbol (satisfies fboundp))
to something like (and symbol (satisfies safe-fboundp))
as a type specifier.

Regards,

Rainer

I don't recall there having been an explicit request to change this,
so if in fact it was stronger under CLTL [note that CLTL2 is not in
the pedigree of ANSI CL--CLTL2 is a "rogue document", if you'll pardon
the colorful characterization] and no one can find a clean up issue
(there probably isn't one, but maybe I'm forgetting one), then you can
blame it on an editing error.  That doesn't mean the error goes away,
but you at least know someone to frown at.

Nonetheless, having already accepted the possible guilt for causing
the problem, I hope you'll now allow me to go ahead and argue that
this shouldn't be treated as a bug without criticizing me for trying
to defend my good name (now already sullied :).

I will say that if I were an implementation, I would treat everything
to the left of a satisfies as something that must be done first, left-
to-right, for pragmatic reasons, even if the standard didn't require
it, as long as the standard doesn't forbid it (which I'm pretty sure
it doesn't).  There are several reasons:

(1) It's likely to be the case that the function call is more
expensive.  The typechecks should be done first in a lot of cases, and
the ordering of the tests should presumably give you a cue of what is
least to most expensive to do.  I think doing them in arbitrary order
isn't meaningful if you are not inlining everything, which is
presumably rare.  You may be able to guess the speed of the
typechecks, but since the satisfies functions will be opaque, you've
got to trust the programmer.

(2) A great many functions useful as predicates are not total
functions and have type restrictions. oddp, plusp, etc.  Those
functions become unuseful in this context if not allowed to be
ordered.  If you do that, the usefulness of AND then becomes quite a
lot less.  The primary idioms of use for AND in any combination with
SATISFIES are almost always to guard a predicate with appropriate type
checks, so to claim you can do a SATISFIES in any order is marginal.
(Note that nothing requires you to not mix tests where the user can't
tell. You can do (AND FOO BAR (SATISFIES BAZ)) in either order for FOO
and BAR because if the answer will be undetectably different it's just
a proper optimization... assuming FOO and BAR are not deftypes
expanding into other AND and SATISFIES, I mean.  It's when a user-
visible effect happens that you mustn't shuffle things, and that's
where SATISFIES happens.

(3) I totally dislike the notion that someone has some pet
optimization and that all language semantics have to bend to that
optimization.  Admittedly, this isn't specified, so you can claim it's
not part of the semantics, but it will take you little effort to
realize that it was a meta-feature of the language design that we
consistently made the left-to-right decision rather than the arbitrary-
order decision. That's why we didn't make things non-deterministic in
class precedence lists, that's why we did floating point contagion as
we did, that's why the function call argument order evaluation is as
it is, that's why defsetf and a ton of related mechanism is as it
is, ... so why would we throw that away in this one case?
Optimizations should suit the language; languages should try not to be
merely bizarre syntaxes for asking for particular compiler
optimizations.

(4) If there is a history of a previous interpretation and no evidence
of cleanup on the matter and there's a lot of code already deployed
that seems to interpret this a certain way, I think it's disruptive to
the normal state of affairs for a bunch of people with an alternate
interpretation that's clever but not evidenced as "relied upon" to
move in and say everyone else should rewrite their code just for
this.  It's not been demonstrated that the relevant efficiency cannot
be achieved another way.

(5) If I could take a vote today, it would not be in support of
allowing arbitrary ordering, and that would have nothing to do with
legacy--it would have to do with the global design principle mentioned
in (3).

But that's just my personal opinion and has no official status. Your
mileage may vary. :)

And it's a good thing that there isn't such a requirement, because it
would make a mess out of the type system. As it is, intersection types
can be simplified -- with a left-to-right ordering this could become
absurdly complex. Take for example:

 (and number (satisfies evenp)
      ... (and ... unsigned-byte ...) ... (and ... fixnum ...)
      ... (and ... bit ...))

Do you really want to prohibit simplifying that to

 (and bit (satisfies evenp) ...)

or even (eql 0) or nil, depending on what's in the ... ?

The suggested requirement on the 'satisfies type predicate simply
seeks to maintain the commutative property within the
intersection and union types.  This is a very useful property
both for the programmer and the compiler.  No other types in
Common Lisp break this property.

For example: if the commutative property is not preserved then
given that (subtypep type1 '(and a b (satisfies c))) is
a valid test then the following become erroneous:
(subtypep type1 '(and b (satisfies c)))

The proposed solution simply requires the predicate to accept all
objects without error.

Keep in mind that types are used for both type tests and also for
declaration and I believe your comments address only the former
and thus miss other valid points of view.

The 'satisfies type is not used widely in declarations because it
is of limited use for compiler optimization and commutativity is
important to simple design.

On Dec 8, 12:06 pm, pit...@nhplace.com wrote:

The compiler can make good use of other types in an intersection
type along with a 'satisfies type.  For example, with a
'(and symbol (satisfies keywordp)) declaration the compiler can infer
that a value is a 'symbol even if the 'satisfies test does not help
and this is useful for optimization.

Preserving the commutative property that exists among all other
types hardly seems to fit.

I see merit in multiple points of view on this matter.

Changes have been contributed to CL-HTTP.

No one is trying to impose a style on others.  If there were strong
preferences each way then I am sure a flag would be added to support
both options.

ANSI-CL: "subtypep is permitted to return the values false and
false only when at least one argument involves one of these type
specifiers: and, eql, the list form of function, member, not, or,
satisfies, or value"

However a CL implementation is not required to give up when a
type involves 'satisfies, and only in this context does the issue
arise.  CMU-CL does not give up and just ignores any errors from
the predicate.

It would be very handy for the type system to be able to work with
arbitrary subsets of intersection and union types rather than
having to work around the 'satisfies type.

Consider type '(and a (satisfies b) c) which allows the subset
'(and a (satisfies b)) to be compared with subtypep, but not the
subset '(and (satisfies b) c).

Moving the 'satisfies type to the end does not resolve this, and the
subset '(and c (satisfies b)) can not be compared.

Further the type '(and a c (satisfies b)) does not allow any subsets
containing '(satisfies b) to be compared.

Juanjo's proposal could be implemented by just giving up on the
'satisfies
type without reworking the 'and type or imposing an ordering
constraint.
The type system would just not call the predicate and subtypep would
just
return (values nil nil).  'typep would still call the predicate, and
Rainer's
code would work as he expects.  I see some merit in this too.  If
would also
be easy to add a flag to control this and make it an option.

Depending on type errors being caught is not practical because they
may
not be signaled in un-safe code.  A change to compilation policy,
lowering
the safety level, could break code badly, cause heap corruption, and
this
would occur unexpectedly because it was previously masked.