[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.lisp

What should the return value be of (subtypep '(eql :x) 'keyword

Jim Newton

1/13/2016 11:00:00 AM

This is indeed a strange result. Shouldn't subtype be easily able to tell whether
EQL and MEMBER types are subtypes of anything?

I get the following result in SBCL.

CL-USER> (subtypep '(eql :x) 'keyword)
NIL
NIL
CL-USER> (subtypep '(member :x) 'keyword)
NIL
NIL
3 Answers

smh

1/14/2016 1:10:00 PM

0

The result (values t t) would be correct and more useful. Allegro and some other implementations compute correctly over the member and eql subtypep relations.

However, the ANS does not _require_ this. It specifically allows an implementation to return (values nil nil) for member and eql and a few others. See the ANS dictionary page for subtypep, which would have answered your question and saved a posting. :-)

The requirements on subtypep are arguably too weak. X3J13 didn't want to impose new requirements on implementations, but most of the allowed exceptions are in fact easily computable. I think the only necessary exception is satisfies, although the subtleties of the values type (with different numbers of values) might make it hard to use.

Barry Margolin

1/14/2016 3:28:00 PM

0

In article <20f8241a-6842-4287-8108-acea97343f85@googlegroups.com>,
smh <shaflich@gmail.com> wrote:

> The requirements on subtypep are arguably too weak. X3J13 didn't want to
> impose new requirements on implementations, but most of the allowed
> exceptions are in fact easily computable.

So? What are the *practical* uses for them? Like the example in the OP.

Why make implementors go to the trouble of implementing all this type
calculus if it will never be used?

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

smh

1/15/2016 2:30:00 AM

0

On Thursday, January 14, 2016 at 7:27:57 AM UTC-8, Barry Margolin wrote:

> So? What are the *practical* uses for them? Like the example in the OP.
>
> Why make implementors go to the trouble of implementing all this type
> calculus if it will never be used?

Perhaps you cannot conceive how a more-complete type system would be useful because the CL type system is so little used in typical CL programming style (except of course in generic function class dispatch) because it is so weak.
One can check if an object is in the type (member a b c ...) simply be calling memberp, but that doesn't work if you want to pass an arbitrary type to a function that might want to compute unions or intersections. We modern CL programmers don't do these elegant things because they aren't guaranteed to work.

In fact about 25 years ago Duane and I figured out the sybtypep dispatches for and, or, not, eql, and member in a couple hours (and then a couple subsequent bugfixes :-).

Consider also that it is impossible in the CL type system (without satisfies) to declare the type for all square arrays. That would be useful in some mathematical code, but would require parameterized type specifiers.

The restriction that all type specifiers expand finitely is also limiting, but removing that restriction would require serious disruptive work in typical implementation.