······@interaccess.com (Thaddeus L Olczyk) writes:
> (defun myfun(x)
> (declare (list foo x))
> ...
>
> Basically I want to declare x as being a list whose members are all
> foo.
What would you gain by it? The amount of storage cannot change since
the list will consist of cons cells, anyway. If there are some
unboxed values in the list (I don't know if any implementations do it
and whether it is at all possible or feasible), you should put a
declaration in the accessing form. Like here:
(defun myfun (x)
(dolist (item x)
(declare (type foo item)
...
process item
...)))
> Is it possible?
list is not a /compound type specifier/, so -- no.
--
Janis Dzerins
Eat shit -- billions of flies can't be wrong.
······@interaccess.com (Thaddeus L Olczyk) writes:
> (defun myfun(x)
> (declare (list foo x))
> ...
>
> Basically I want to declare x as being a list whose members are all
> foo. Is it possible?
> TIA
It depends on what you're trying to achieve.
It's very unlikely a compiler is going to do anything with information
that it does not anticipate you are going to provide.
You can arrange it for type testing but not in the easiest way. e.g.,
(defun check-list-elements (list type)
(block done
(dolist (element list)
(unless (typep element type) (return-from done nil)))
t))
(defun check-list-of-symbols (list)
(check-list-elements list 'symbol))
(deftype list-of-symbols ()
`(satisfies check-list-of-symbols))
(typep '(a) 'list-of-symbols) => T
(typep '() 'list-of-symbols) => T
(typep '(3) 'list-of-symbols) => NIL
Then again, if you're not using this for discrimination but only for
declaration, you may be wasting your time. I don't think a typical compiler
is equipped to infer the relevant things from this. I once in a while do
(defun foo (x)
(dolist (element x) (check-type element symbol))
...body...)
but CHECK-TYPE is again an issue of discrimination, not declaration.
Moreover, truths learned by the compiler in this LOOP are not likely to
propagate out of the loop. Better might simply be:
(defun foo (x)
(dolist (element x)
(declare (symbol element)) ;or check-type, of course
... one step of body...))
As I recall, we used to (under CLTL), allow you to put a lambda expression
here for SATISFIES, which would have allowed
(deftype list-of (element-type) ; non-conforming!
`(satisfies (lambda (list) (check-list-elements list ',element-type))))
If my memory is correct, the reason we took this feature out was two-fold:
- In a lot of cases, this wasn't going to get compiled. It was quoted
list data and would be expensive to do as a check.
- Being able to do this requires the ability to funcall a list (or
otherwise coerce a lambda expression to a function), which implies the
presence of the interpreter or compiler in a delivered image if there
is any call to TYPEP with a variable argument. This kind of thing
is the enemy of tree-shaking...
- There was no way to capture the lexical environment so there was a
constant risk of people doing stuff like:
(defun foo (x z)
(declare (type (satisfies (lambda (y) (eql y z))) x))
...)
but where the z being referred to in the type is really a global
(presumably special) Z, not the lexically enclosing Z.
Using function names reduced this problem a little, though still risks
someone will do
(defun foo (x z)
(flet ((lose (y) (eql y z)))
(declare (type lose x))
...))
At least in this case you can't put in the DECLARE with the binding of
X so that shouuld cue you that something is amiss. But also there is
a restriction that this be a globally defined function just for this
reason. The argument to satisfies is data, so the result of constructing
`#',arg will be evaluated in the null lexical environment.
I think it's because of issues of file externalizability (serialization,
I guess it's called in other languages), that it's not allowed to do
(deftype list-of (element-type)
`(satisfies ,#'(lambda (x) (check-list-elements x element-type))))
The above would create a pointer to a function as a literal datum in code,
and it might not write to a compiler output file and be re-read, so no point
in encouraging lossage.
It's also too bad that you can probably not get away with
(deftype list-of (element-type)
`(or null (list-of ,element-type)))
since probably a compiler will insist on type-expanding (list-of symbol)
and will not return from the attempt.
Thanks. Very well written as usual. However, this just begs for
CL EXTENSION THAT ALL IMPLEMENTATION SHOULD PROVIDE #42
The LIST declaration is extended in such a way that
(declare (type (list <type-specifier>) x))
is accepted. X is declared to be a "proper list" containing elements
of type <type-specifier>.....
Of course the correct wording and the inclusion or the exclusion of
provisions for recursive types is up for debate.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Thanks. Very well written as usual. However, this just begs for
>
> CL EXTENSION THAT ALL IMPLEMENTATION SHOULD PROVIDE #42
>
> The LIST declaration is extended in such a way that
>
> (declare (type (list <type-specifier>) x))
>
> is accepted. X is declared to be a "proper list" containing elements
> of type <type-specifier>.....
If I recall correctly, this was considered explicitly and the discussion
went something like:
Party A wanted (list fixnum) to mean "a list of fixnums".
Party B wanted (list fixnum) to mean "a list whose sole element is a fixnum".
Party C wanted (list fixnum) to mean "a list whose first element is fixnum
and whose other elements are undeclared.
Then someone proposed
(list &rest fixnum)
but then some people wanted to be able to nest types via destructuring
(list &rest (string . fixnum))
or
(list &rest (cons string fixnum))
but then some people wanted
(list &key (foo fixnum))
and then some people said what about plists--couldn't we have some sort
of alternation notation? Various bizarro notations for that were discussed,
even though most plists don't really lend themselves to heterogeneous
typing, since each property usually has an idiosyncratic type.
I remember thinking the "straw men" won on this and it should have been
resolvable, but it just wasn't.
> Of course the correct wording and the inclusion or the exclusion of
> provisions for recursive types is up for debate.
As are the rest of the details.
I believe the only reason we added the CONS type specifier was to make
pretty printer dispatching appear better integrated, since most of what
it needed could be implemented with existing typespecs and that was one
of the only ones that it needed that was missing. It could have just
used a pseudo-type-specifier, but we decided to make it look more graceful.
- - - - -
Score this absence as a reminder that it actually sometimes matters to
have _users_ present for the design of standards and not merely to
leave it to _implementors_, who tend to sometimes only speculate (and
often badly) about what matters to users.
Kent M Pitman <······@world.std.com> writes:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
> > Thanks. Very well written as usual. However, this just begs for
> >
> > CL EXTENSION THAT ALL IMPLEMENTATION SHOULD PROVIDE #42
> >
> > The LIST declaration is extended in such a way that
> >
> > (declare (type (list <type-specifier>) x))
> >
> > is accepted. X is declared to be a "proper list" containing elements
> > of type <type-specifier>.....
>
> If I recall correctly, this was considered explicitly and the discussion
> went something like:
>
> Party A wanted (list fixnum) to mean "a list of fixnums".
>
> Party B wanted (list fixnum) to mean "a list whose sole element is a fixnum".
>
> Party C wanted (list fixnum) to mean "a list whose first element is fixnum
> and whose other elements are undeclared.
>
..... Much interesting deleted.....
I understand.
The rationale for the notation (which should mean what Party A wanted)
is that today we have the *ml crowd that consistently uses
'a list
to mean "a list whose elements are of type 'a".
Moreover, in CL we have
(array integer)
as the type specifier that denotes those arrays whose elements are
integers.
Symmetry and practice kind of call for the "Party A" interpretation
(plus the requirement to be a "proper list").
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Kent M Pitman <······@world.std.com> writes:
...
> > Party A wanted (list fixnum) to mean "a list of fixnums".
> >
> > Party B wanted (list fixnum) to mean "a list whose sole element is a fixnum".
> >
> > Party C wanted (list fixnum) to mean "a list whose first element is fixnum
> > and whose other elements are undeclared.
> >
>
> ..... Much interesting deleted.....
>
> I understand.
>
> The rationale for the notation (which should mean what Party A wanted)
> is that today we have the *ml crowd that consistently uses
>
> 'a list
>
> to mean "a list whose elements are of type 'a".
> Moreover, in CL we have
>
> (array integer)
>
> as the type specifier that denotes those arrays whose elements are
> integers.
>
> Symmetry and practice kind of call for the "Party A" interpretation
> (plus the requirement to be a "proper list").
Symmetry and practice kind of demand it espcially if you don't look at how
types of arglists are declared. They call for the use of &optional, &key,
and &rest to be used to specify more than one element. So that's the
problem: a clash of two worlds. Either be incompatible with arglists for
specifying other things which are probably lists of args ... or use the
notation for args and be incompatible with the array notation.
I think it could have been resolved but it wasn't.
Probably the right thing is to make it compatible with arglists.
Arrays are homogeneous, but lists often aren't. The arglist notation
already allows for ``&rest fixnum'' which is as powerful as (list fixnum).
Plus the list stuff has other useful notions. It isn't powerful enough
for everything, but it is "good enough" that we could have gotten
things out of it.
Oh well.
I understand the argument about arglists.
However, the current situation is that a user and a compiler cannot use any
information whenever you have an homogenous list.
Right now arglists and homogenous (proper) lists all have type LIST.
Introducing the compound type specifier LIST will give you homogenous
lists by keeping the type of arglists to be LIST (or `(LIST T)' for
what matters). It is a small step which buys you quite a bit at list
at the documentation level.
IMHO the issue of arglists comes up if you consider the "syntax" with
which you describe lists and their components. If you want this you
can always specify thee types
LIST
SIMPLE-LIST [<type-specifier>]
COMPLEX-LIST [hairy, arglist-like type spefication]
Where
LIST == SIMPLE-LIST == (SIMPLE-LIST T) == COMPLEX-LIST
and maybe == (COMPLEX-LIST &rest T)
Ok. Time to go. Star Trek Enterprise is coming up at 8:00.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
From: Steven M. Haflich
Subject: Re: Is it possible to declare a list of foo?
Date:
Message-ID: <3C620882.D1AB9D0C@pacbell.net>
I want to endorse Kent's opinions here: Your original statement
The LIST declaration is extended in such a way that
(declare (type (list <type-specifier>) x))
is accepted. X is declared to be a "proper list" containing elements
of type <type-specifier>.....
is unfounded by anything in the ANS. If you can cite any evidence to
the contrary, please do.
Some further comments:
Marco Antoniotti wrote:
>
> I understand the argument about arglists.
>
> However, the current situation is that a user and a compiler cannot use any
> information whenever you have an homogenous list.
>
> Right now arglists and homogenous (proper) lists all have type LIST.
But they need not be proper lists. Function formal arglists must be
proper lists, but macro and destructuring arglists may be dotted.
> Introducing the compound type specifier LIST will give you homogenous
> lists by keeping the type of arglists to be LIST (or `(LIST T)' for
> what matters). It is a small step which buys you quite a bit at list
> at the documentation level.
IIRC the thingus you want can be defined this way:
(deftype true-list-of (x) `(or null (cons ,x (true-list ,x))))
It is certainly true that few compilers will make use of this, but
it is more likely that a compiler will see through something like this
than a declaration that employs cl:satisfies.
From: Steven M. Haflich
Subject: Re: Is it possible to declare a list of foo?
Date:
Message-ID: <3C6209C6.75ACAE55@pacbell.net>
"Steven M. Haflich" <·······@pacbell.net> wrote in message
······················@pacbell.net...
> Slight correction:
>
> > (deftype true-list-of (x) `(or null (cons ,x (true-list ,x))))
>
> Should be:
>
> (deftype true-list-of (x) `(or null (cons ,x (true-list-of ,x))))
That doesn't look like valid ANSI CL (deftype says "Recursive expansion of the
type specifier returned as the expansion must terminate, including the expansion
of type specifiers which are nested within the expansion.").
--
Martin Simmons
······@xanalys.com
rot13 to reply
"Martin Simmons" <······@xanalys.com> writes:
> "Steven M. Haflich" <·······@pacbell.net> wrote in message
> ······················@pacbell.net...
> > Slight correction:
> >
> > > (deftype true-list-of (x) `(or null (cons ,x (true-list ,x))))
> >
> > Should be:
> >
> > (deftype true-list-of (x) `(or null (cons ,x (true-list-of ,x))))
>
> That doesn't look like valid ANSI CL (deftype says "Recursive expansion of the
> type specifier returned as the expansion must terminate, including the expansion
> of type specifiers which are nested within the expansion.").
Another good reason to provide the built-in type
(simple-list <type-specifier>)
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Marco Antoniotti <·······@cs.nyu.edu> writes:
> "Martin Simmons" <······@xanalys.com> writes:
>
> > "Steven M. Haflich" <·······@pacbell.net> wrote in message
> > ······················@pacbell.net...
> > > Slight correction:
> > >
> > > > (deftype true-list-of (x) `(or null (cons ,x (true-list ,x))))
> > >
> > > Should be:
> > >
> > > (deftype true-list-of (x) `(or null (cons ,x (true-list-of ,x))))
> >
> > That doesn't look like valid ANSI CL (deftype says "Recursive
> > expansion of the type specifier returned as the expansion must
> > terminate, including the expansion of type specifiers which are
> > nested within the expansion.").
>
> Another good reason to provide the built-in type
>
> (simple-list <type-specifier>)
I believe I proposed specifically (list-of <type-specifier>) and it was
considered explicitly and decided not to move forward.
"Another good reason" for people here not to be Monday morning quarterbacks
but to actually get involved in the proper processes at the proper time.
Perhaps, had there been an active and interested newsgroup at the time, I
would have had more evidence I was not just making it up.
But then again, another issue that is hard to perceive from the users' point
of view, and this is in defense of the design that was to be done, was that
there were a virtually infinite list of "obvious" things users could want
and the process had to terminate. Another reason I may have been dismissed
is that I originally authored some very noticeable fraction of all cleanups,
and I'm sure the committee was exhausted and not just a little annoyed by
having to deal even with the ones that were just out-and-out bugs without
even worrying about the "features".
When you look at the trouble I had getting "compiler macros" accepted, and
the similar trouble (resulting in failure) I had in my quest to get
compile-flavor-methods [ok, maybe I called it compile-effective-methods]
accepted, you can see better how (list-of integer) was maybe in the noise.
And, finally, I think part of the reason you want (simple-list
integer) to work is that you think some vendor is going to make some
cool optimization based on that, but given the infrequency with which
people would declare this and the even greater infrequency with which
this will ever give new information not already possible to give in
other ways (e.g., by declaring the iteration variable that will
process this list), I just don't see it as a big issue, and I'm not so
sure any vendor would optimize this. CMU CL excepted, most already
don't optimize most of the other interesting declarations that they
could. One thing you wouldn't have gotten then or now is a requirement
that anyone use this declaration even if you could make it.
So why not just
(deftype simple-list (&optional (subtype 't))
(declare (ignore subtype))
't)
and move on?
Sometimes a kludge works as well as the real thing. I remember when porting
Macsyma to CL, I was annoyed that CL didn't have the LispM-style option of
using the variable IGNORE to mean "ignore this variable" without having to
proclaim in. And then I figured out that although (proclaim '(ignore ignore))
din't work, I could (proclaim '(special ignore)) and get the same effect.
It was even kind of handy in debugging to be able to see the ignored value. ;-)
But it allowed me to "move on".
Kent M Pitman <······@world.std.com> writes:
> And, finally, I think part of the reason you want (simple-list
> integer) to work is that you think some vendor is going to make some
> cool optimization based on that, but given the infrequency with which
> people would declare this and the even greater infrequency with which
> this will ever give new information not already possible to give in
> other ways (e.g., by declaring the iteration variable that will
> process this list), I just don't see it as a big issue, and I'm not so
> sure any vendor would optimize this. CMU CL excepted, most already
> don't optimize most of the other interesting declarations that they
> could. One thing you wouldn't have gotten then or now is a requirement
> that anyone use this declaration even if you could make it.
I wasn't thinking this would be an opportunity for optimizing for
speed, but it would be nice in conjunction with CMUCL's
optimize-interface declaration. No more looping through lists,
checking the types of the elements -- the compiler will do it for you.
Oh well ... (and I was fine not having this feature before I realized
I didn't have it)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Kent M Pitman <······@world.std.com> writes:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
...
> >
> > Another good reason to provide the built-in type
> >
> > (simple-list <type-specifier>)
>
> I believe I proposed specifically (list-of <type-specifier>) and it was
> considered explicitly and decided not to move forward.
>
> "Another good reason" for people here not to be Monday morning quarterbacks
> but to actually get involved in the proper processes at the proper time.
>
> Perhaps, had there been an active and interested newsgroup at the time, I
> would have had more evidence I was not just making it up.
>
...
Much deleted.
> And, finally, I think part of the reason you want (simple-list
> integer) to work is that you think some vendor is going to make some
> cool optimization based on that, but given the infrequency with which
> people would declare this and the even greater infrequency with which
> this will ever give new information not already possible to give in
> other ways (e.g., by declaring the iteration variable that will
> process this list), I just don't see it as a big issue, and I'm not so
> sure any vendor would optimize this. CMU CL excepted, most already
> don't optimize most of the other interesting declarations that they
> could. One thing you wouldn't have gotten then or now is a requirement
> that anyone use this declaration even if you could make it.
>
> So why not just
> (deftype simple-list (&optional (subtype 't))
> (declare (ignore subtype))
> 't)
> and move on?
>
> Sometimes a kludge works as well as the real thing. I remember when porting
> Macsyma to CL, I was annoyed that CL didn't have the LispM-style option of
> using the variable IGNORE to mean "ignore this variable" without having to
> proclaim in. And then I figured out that although (proclaim '(ignore ignore))
> din't work, I could (proclaim '(special ignore)) and get the same effect.
> It was even kind of handy in debugging to be able to see the ignored value. ;-)
> But it allowed me to "move on".
Well, if you do not have something you don't use it, or you go a long
way to get around it. Let's say that I am all for doing something
simple and move on. Here it is
(deftype simple-list (&optional (subtype 't))
(declare (ignore subtype))
'list)
(deftype complex-list (&rest arglist-like-spec)
(declare (ignore arglist-like-spec))
'list)
(or maybe 'cons)
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
"Steven M. Haflich" <·······@pacbell.net> writes:
> I want to endorse Kent's opinions here: Your original statement
>
> The LIST declaration is extended in such a way that
>
> (declare (type (list <type-specifier>) x))
>
> is accepted. X is declared to be a "proper list" containing elements
> of type <type-specifier>.....
>
> is unfounded by anything in the ANS. If you can cite any evidence to
> the contrary, please do.
I do not understand the comment. What I propose is not in the ANS.
Do you mean that what is contained in the ANS is contradictory with
the proposed extension?
> Some further comments:
>
> Marco Antoniotti wrote:
> >
> > I understand the argument about arglists.
> >
> > However, the current situation is that a user and a compiler cannot use any
> > information whenever you have an homogenous list.
> >
> > Right now arglists and homogenous (proper) lists all have type LIST.
>
> But they need not be proper lists. Function formal arglists must be
> proper lists, but macro and destructuring arglists may be dotted.
You are right. My mistake.
> > Introducing the compound type specifier LIST will give you homogenous
> > lists by keeping the type of arglists to be LIST (or `(LIST T)' for
> > what matters). It is a small step which buys you quite a bit at list
> > at the documentation level.
>
> IIRC the thingus you want can be defined this way:
>
> (deftype true-list-of (x) `(or null (cons ,x (true-list ,x))))
>
> It is certainly true that few compilers will make use of this, but
> it is more likely that a compiler will see through something like this
> than a declaration that employs cl:satisfies.
Yes. Essentially this is what I want. I would just go ahead and add
SIMPLE-LIST, and COMPLEX-LIST type declarations.
(deftype simple-list (x)
`(or null (cons ,x (simple-list ,x))))
COMPLEX-LIST cannot be expressed with a DEFTYPE (at least not in the
time daily allotted to news reading) :)
The advantage of having the type SIMPLE-LIST standardized would be to
simplify the life of a compiler in a few occasions, and to provide
better feedback to the user.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
"Kent M Pitman" <······@world.std.com> wrote in message
····················@shell01.TheWorld.com...
>
> (defun check-list-elements (list type)
> (block done
> (dolist (element list)
> (unless (typep element type) (return-from done nil)))
> t))
Is there a reason beyond personal style you chose to make a block explcitly
and return from it rather than
(defun check-list-elements (list type)
(dolist (element list)
(unless (typep element type) (return-from check-list-elements nil)))
t)
?
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
"Coby Beck" <·····@mercury.bc.ca> writes:
> "Kent M Pitman" <······@world.std.com> wrote in message
> ····················@shell01.TheWorld.com...
> >
> > (defun check-list-elements (list type)
> > (block done
> > (dolist (element list)
> > (unless (typep element type) (return-from done nil)))
> > t))
>
> Is there a reason beyond personal style you chose to make a block explcitly
> and return from it rather than
>
> (defun check-list-elements (list type)
> (dolist (element list)
> (unless (typep element type) (return-from check-list-elements nil)))
> t)
Yes. There are several contributing factors:
- It gives a bit of local self-documentation to the return-from.
- I rename functions a lot and this insulates me from changing the
function name to ELEMENT-TYPEP or some such thing and finding
that the RETURN-FROM no longer matches.
- I don't really like the feature of CL wherein there are these
implicit blocks and I try to program in the hypothetical world
where they are made not available and yet my code doesn't break.
(This is partly just a personal preference, but it also tests for
myself the reasonableness of the claim that these are not needed.
I get to find out if there are undue complications caused by having
this go away.)
Like most style choices, what I've said above doesn't mean it's a
crime to use the implicit block. It just means I have some personal
reasons for preferring not to.
Kent M Pitman <······@world.std.com> writes:
"Coby Beck" <·····@mercury.bc.ca> writes:
[...]
> Is there a reason beyond personal style you chose to
[...good question...]
Yes. There are several contributing factors:
[...excellent answer...]
Like most style choices, what I've said above doesn't mean it's a
crime to use the implicit block. It just means I have some personal
reasons for preferring not to.
So, your answer should really have been no, no?
(Sorry, just fooling around.)
From: Friedrich Domincus
Subject: Re: Is it possible to declare a list of foo?
Date:
Message-ID: <874rkug6no.fsf@fbigm.here>
······@interaccess.com (Thaddeus L Olczyk) writes:
> (defun myfun(x)
> (declare (list foo x))
Well you know that declare can be ignored. So IIRC you want to have
type-check, such that you can be sure tha x is
a) a list
b) just contains the symbol 'foo
Now how about
(defun ensure-foo-list (list)
(every #'(lambda (el) (eq el 'foo)) list))
(deftype foo-list-type ()
'(and list
(satisfies ensure-foo-list)))
and (defun myfun (x)
(check-type x foo-list-type)
....
than?
Regards
Friedrich