Dear readers,
Is there a better way to test if something is a type
specifier than doing
(ignore-errors (subtypep type-specifier-maybe 't))
which would return T NIL if the value of
type-specifier-maybe is a valid type specifier and
NIL non-NIL otherwise.
Apart from the fact that this is kludgy, I don't think
that the standard really guarantees that it would work
(as far as I can interpret the hyperspec).
Just testing explicitly for all type specifiers defined
in the language description will not cover user-defined
ones (by DEFCLASS, DEFSTRUCT, DEFTYPE). Of course
I can handle DEFCLASS by FIND-CLASS and shadow DEFSTRUCT
and DEFTYPE by wrappers that register the defined
specifier by adding it to a set that initially includes
the standard type specifiers, but that would be even
more kludgy. It would be nice to have TYPE-SPECIFIER-P
predefined, but one cannot expect everything to
be predefined. On the other hand, if I can reasonably
expect that most implementations have their own
(idiosyncratic) functions that accomplish this task,
then one could define TYPE-SPECIFIER-P on a non-portable
per-implementation basis and then use it portably.
Best regards,
Vassil.
Vassil Nikolov <········@bgearn.acad.bg> (+359-2) 713-3813
Department of Information Research
Institute of Mathematics and Informatics fax: (+359-2) 9713649
Acad. G. Bonchev, block 8, Sofia 1113, Bulgaria
Vassil Nikolov <········@math.acad.bg> writes:
> Is there a better way to test if something is a type
> specifier than doing
> (ignore-errors (subtypep type-specifier-maybe 't))
We talked about adding such. I'll try to find the proposal
and find out why it failed.
One issue, though, is it that CL permits forward references,
so
(defun f (x) (if x (typep x 'garbage)))
is not in error as long as the type garbage becomes defined
before (f <non-nil>) is done (if indeed it is ever done).
So, for example, a macro would be incorrect in doing
something like
(defmacro g (x)
(check-type x type-specifier)
...)
in your proposed definition of the type specifier. At bare
minimum, it would need an env arg, and in the presence of
forward references, that would still not be enough. It would
lead to lots of program errors. As strange as it sounds,
(check-type x (or symbol cons class) "a type specifier")
is going to be more likely to be right in a lot of places.
Oh, and incidentally, there are two other things people have
often asked for:
(type-specifier-p exp env)
and (type-expand exp env)
But I think there's also some issue about how type-expand
bottoms out in the presence of forward-references (calling it
again later might yield a new result due to later definition
OR redefinition).
And there's an issue about things like
(satisfies <pred>)
which might refer to a predicate that only dynamically has
a definition in a certain context. (I think it's a design
error in CL that these type specifiers are lists with no
environment; they should be forms capable of capturing the
lexical contour so that it's possible to know more reliably
if <pred> in a SATISFIES does or does not have a definition.)
But ignoring that, suppose you know that FOO is undefined,
is (SATISFIES FOO) a type specifier or not? After all,
(defun bar (x) (foo x)) doesn't cease to define a function
just because FOO is undefined. There are some weird
philosophical issues surrounding "definedness" when you
deal with the data structures which name types (which
is what type specifiers are) rather than types as objects
(which are really not manifest in CL except in the class
system).
Well, that's something to chew on while I research the history
of what happened when the exact operator type-specifier-p,
which I'm sure was proposed, didn't make it in.
Vassil Nikolov <········@math.acad.bg> writes:
My recent remarks about the pitfalls of programming with it
notwithstanding (see JonL's apt remarks on the dangers of
over-philosophizing below), my records of the X3J13 proceedings show a
proposal named TYPE-SPECIFIER-P written by Sandra Loosemore
in Feb-Mar 1991 which proposed three options, each to be voted
independently:
* TYPE-SPECIFIER-P spec &OPTIONAL env
* TYPE-NAME-P spec &OPTIONAL env
* TYPE-EXPAND-1 spec &OPTIONAL env
TYPE-EXPAND spec &OPTIONAL env
There were descriptions of each, but I'm abbreviating here.
The last pair worked sort of like MACROEXPAND-1 and MACROEXPAND.
My records further show that this was on the agenda for the Mar 1991
but got skipped for lack of time and was never returned to. This
happened to a lot of issues. Probably it was because we'd done a
feature freeze much earlier and we had to have exceptional reason to
be adding new features at this "late date" when we were trying to
freeze for public review (which finally happened in December 1992).
[Standards work on a glacial time scale. I think the feature freeze
might have tried to happen in 1988, although we continued to make
exceptions here and there for long after.]
The writeup for TYPE-SPECIFIER-P (version 2) mentions that this
operator was on Steele's list of "non-controversial" changes in 1985
... That list is of historical interest for how badly named it was.
The massive controversy over just about every item on it was a major
force leading us to a realize we were dead in the water if we didn't
"shop for" a stanards body to help resolve our differences. Until the
first CLTL, we had operated under clumsy ad-hoc rules because there
really were no implementations of CL yet, but after the book came out
there became large dollar investments in CL and so people were more
picky about procedure. And what was uncontroversial to one was often
explosive to another. So the list of "non-controversial" items never
got endorsed.
However, my personal records show that...
Moon and I were mostly ok with any of the proposed items.
Moon wanted TYPE-SPECIFIER-P to check the whole expression,
not just the CAR.
Barrett didn't like TYPE-NAME-P because it was badly named
and was supposed to return true for class objects; but he
thought TYPE-SPECIFIER-P was ok.
JonL's comment was:
TYPE-SPECIFIER-P has been in Lucid Common Lisp for years, and has
received wide usage. We have discussed at length, in the past, the
uncertainty about poorly-formed syntaxes, and about side-effects and
errors in deftype expansions; yet none of [these] seems to bear on
the actual usages I've seen. I'd very much hate to see the recent
"philosophical" discussions justify the removal of it from the ANSI
proposal just because some angels slip while dancing on a pinhead.
Seems to me like things were pretty aligned and it would have
passed on its merits, but that it was overlooked either by accident
or by procedural requirement (too late in the process). Sounds like
a good candidate for next time around, though. At least
TYPE-SPECIFIER-P ... and I bet a lot of implementations have it
internally if you go looking...
From: Howard R. Stearns
Subject: presentation type-specifiers, dylan (was: how to test for a type specifier?)
Date:
Message-ID: <3444E246.446B9B3D@elwood.com>
After the kids and my wife have gone to sleep, I have lately been
sneaking out Chapter 23 of the CLIM spec, and pondering whether
presentation types (which defines a presentation-type-specifier-p) might
be usefully integrated into the type system. It might provide:
- a sort of MOP or "open implementation" for the type system, in
which advanced programmers would have controlled access to the
implementation of typep, subtypep, deftype and the list form type
specifiers.
- a way to provide some Dylan-style type semantics to CL/CLOS, such as
limited types, general type metaobjects, etc. Perhaps, as in Dylan,
arbitrary (presentation) type metaobjects might be valid as method
specializers.
- a way to try to clarify some of the type-expansion/&environment
issues already mentioned, as well as forward references and
interactions between multiple occurrences of
deftype/defstruct/defclass/define-condition and find-class that use
the same type name.
Any comments?
Kent M Pitman wrote:
>
> Vassil Nikolov <········@math.acad.bg> writes:
>
> My recent remarks about the pitfalls of programming with it
> notwithstanding (see JonL's apt remarks on the dangers of
> over-philosophizing below), my records of the X3J13 proceedings show a
> proposal named TYPE-SPECIFIER-P written by Sandra Loosemore
> in Feb-Mar 1991 which proposed three options, each to be voted
> independently:
>
> * TYPE-SPECIFIER-P spec &OPTIONAL env
>
> * TYPE-NAME-P spec &OPTIONAL env
>
> * TYPE-EXPAND-1 spec &OPTIONAL env
> TYPE-EXPAND spec &OPTIONAL env
>
> There were descriptions of each, but I'm abbreviating here.
> The last pair worked sort of like MACROEXPAND-1 and MACROEXPAND.
>
> My records further show that this was on the agenda for the Mar 1991
> but got skipped for lack of time and was never returned to. This
> happened to a lot of issues. Probably it was because we'd done a
> feature freeze much earlier and we had to have exceptional reason to
> be adding new features at this "late date" when we were trying to
> freeze for public review (which finally happened in December 1992).
> [Standards work on a glacial time scale. I think the feature freeze
> might have tried to happen in 1988, although we continued to make
> exceptions here and there for long after.]
>
> The writeup for TYPE-SPECIFIER-P (version 2) mentions that this
> operator was on Steele's list of "non-controversial" changes in 1985
> ... That list is of historical interest for how badly named it was.
> The massive controversy over just about every item on it was a major
> force leading us to a realize we were dead in the water if we didn't
> "shop for" a stanards body to help resolve our differences. Until the
> first CLTL, we had operated under clumsy ad-hoc rules because there
> really were no implementations of CL yet, but after the book came out
> there became large dollar investments in CL and so people were more
> picky about procedure. And what was uncontroversial to one was often
> explosive to another. So the list of "non-controversial" items never
> got endorsed.
>
> However, my personal records show that...
>
> Moon and I were mostly ok with any of the proposed items.
> Moon wanted TYPE-SPECIFIER-P to check the whole expression,
> not just the CAR.
>
> Barrett didn't like TYPE-NAME-P because it was badly named
> and was supposed to return true for class objects; but he
> thought TYPE-SPECIFIER-P was ok.
>
> JonL's comment was:
>
> TYPE-SPECIFIER-P has been in Lucid Common Lisp for years, and has
> received wide usage. We have discussed at length, in the past, the
> uncertainty about poorly-formed syntaxes, and about side-effects and
> errors in deftype expansions; yet none of [these] seems to bear on
> the actual usages I've seen. I'd very much hate to see the recent
> "philosophical" discussions justify the removal of it from the ANSI
> proposal just because some angels slip while dancing on a pinhead.
>
> Seems to me like things were pretty aligned and it would have
> passed on its merits, but that it was overlooked either by accident
> or by procedural requirement (too late in the process). Sounds like
> a good candidate for next time around, though. At least
> TYPE-SPECIFIER-P ... and I bet a lot of implementations have it
> internally if you go looking...
In article <·················@elwood.com>, "Howard R. Stearns"
<······@elwood.com> wrote:
> After the kids and my wife have gone to sleep, I have lately been
> sneaking out Chapter 23 of the CLIM spec,
those real Lispers will be rewarded...
> - a way to provide some Dylan-style type semantics to CL/CLOS, such as
> limited types, general type metaobjects, etc. Perhaps, as in Dylan,
> arbitrary (presentation) type metaobjects might be valid as method
> specializers.
Well, it would be nice to use KL-ONE (e.g. Classic) like
concept descriptions for dispatching.
Write special methods for
- windows where all subviews are graph-views
- students which have been at the university for longer then 10 years
- a turbine with more than 3 failures in the last year
e.g. use the description logic machinery for finding applicable
methods. A sort of logic-based pattern matching.
Like in http://kogs-www.informatik.uni-hamburg.de/~moeller/papers/oopsla-96.pdf
--
http://www.lavielle.com/~joswig/
From: Thomas A. Russ
Subject: Re: presentation type-specifiers, dylan (was: how to test for a type specifier?)
Date:
Message-ID: <ymi7mbdu61k.fsf@sevak.isi.edu>
······@lavielle.com (Rainer Joswig) writes:
>
> In article <·················@elwood.com>, "Howard R. Stearns"
> <······@elwood.com> wrote:
>
> > After the kids and my wife have gone to sleep, I have lately been
> > sneaking out Chapter 23 of the CLIM spec,
>
> those real Lispers will be rewarded...
>
> > - a way to provide some Dylan-style type semantics to CL/CLOS, such as
> > limited types, general type metaobjects, etc. Perhaps, as in Dylan,
> > arbitrary (presentation) type metaobjects might be valid as method
> > specializers.
>
> Well, it would be nice to use KL-ONE (e.g. Classic) like
> concept descriptions for dispatching.
>
> Write special methods for
> - windows where all subviews are graph-views
> - students which have been at the university for longer then 10 years
> - a turbine with more than 3 failures in the last year
>
> e.g. use the description logic machinery for finding applicable
> methods. A sort of logic-based pattern matching.
> Like in http://kogs-www.informatik.uni-hamburg.de/~moeller/papers/oopsla-96.pdf
As in the functionality provided by Loom, a KL-ONE descendant knowledge
representation language? Loom provides a method dispatching language
based on the ability to satisify arbitrary queries using the concept
language.
One interesting additional issue is that there is not necessarily a
unique most specific method in a description-logic based dispatching
scheme. For example, suppose one had a collection of methods named M
that dispatch on the type of its first argument. Suppose there are
specific methods M for "Student" and also for "Employee". Since it is
possible for an individual to satisfy both concepts, both of those
methods would be applicable and neither one is more specific than the
other.
This is a consequence of allowing multiple types at the instance level.
It requires the use of additional specifications for deciding which
method(s) to invoke. In Loom, one can choose to invoke all methods, all
most-specific methods, signal an error if there isn't a single most
specific method, pick one of the methods at random [Hey, Loom gives lots
of options, they aren't always useful :]
Disclaimer: I am one of the Loom implementors.
________________________________________________________________________
Thomas A. Russ, Senior Research Scientist ···@isi.edu
USC/Information Sciences Institute WWW: http://www.isi.edu
4676 Admiralty Way, Marina del Rey, CA 90292 (310) 822-1511x775