ANSI Common Lisp introduced a third (optional) argument to TYPEP,
which is an environment.
Does it have the purpose of allowing access to the compilation
environment which during file compilation would contain
DEFTYPE names seen by the file compiler?
Vassil Nikolov
Permanent forwarding e-mail: ········@poboxes.com
For more: http://www.poboxes.com/vnikolov
Abaci lignei --- programmatici ferrei.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Vassil Nikolov <········@poboxes.com> writes:
> ANSI Common Lisp introduced a third (optional) argument to TYPEP,
> which is an environment.
>
> Does it have the purpose of allowing access to the compilation
> environment which during file compilation would contain
> DEFTYPE names seen by the file compiler?
Yes, that's a good reason. In general, it is wise to assume that any
piece of CL code only has meaning relative to an environment, even if,
for some particular piece, there's no obvious way that it depends on
the environment -- there might be implementation-specific information
in the environment, or a future extension could change things. A type
specifier is code, so one should pass an environment along with it
(omitting the environment argument constitutes a decision to pass the
default global environment).
--
Pekka P. Pirinen
There is enough in the world for man's need, but not for his greed.
- Gandhi
Pekka P. Pirinen wrote: [1999-08-12 20:44 +0100]
[answering my question about TYPEP's third argument]
Thanks; it hadn't occurred to me that DEFTYPE-defined expandes
might also need an environment.
Vassil Nikolov
Permanent forwarding e-mail: ········@poboxes.com
For more: http://www.poboxes.com/vnikolov
Abaci lignei --- programmatici ferrei.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Vassil Nikolov wrote:
>
> Pekka P. Pirinen wrote: [1999-08-12 20:44 +0100]
>
> [answering my question about TYPEP's third argument]
>
> Thanks; it hadn't occurred to me that DEFTYPE-defined expandes
> might also need an environment.
>
> Vassil Nikolov
> Permanent forwarding e-mail: ········@poboxes.com
> For more: http://www.poboxes.com/vnikolov
> Abaci lignei --- programmatici ferrei.
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
Maybe it's just me, but I get more and more confused the more I think
about this. Consider:
The functions SUBTYPEP, TYPEP, UPGRADED-COMPLEX-PART-TYPE and
UPGRADED-ARRAY-ELEMENT-TYPE are all specified as taking an optional
environment argument.
The specifications for SUBTYPEP, TYPEP and UPGRADED-COMPLEX-PART-TYPE
do not say what the environment argument is used for, but the
specification for UPGRADED-ARRAY-ELEMENT-TYPE says it "is used to
expand any derived type specifiers that are mentioned in the typesec."
This is consistent with the specification for DEFTYPE LAMBDA LISTS,
which says that "a deftype lambda list has the same syntax as a macro
lambda list, and can therefore contain the [same] lambda list keywords
as a macro lambda list." Since macro lambda lists can contain
&environment arguments for use in macro expansion, one assumes that
&environment arguments would be used the same way in type expansion.
However the specification for DEFTYPE says that "the lexical
environment for the body is the one which was current at the time the
deftype form was evaluated, augmented by the variables in the
lambda-list. This doesn't leave any room for type expansion to
introduce a new environment. (It also seems to me to be a much better
idea than the above, which it seems allows type expansion of the same
DEFTYPE to have different results in different contexts.)
Interestingly, COERCE and other functions which accept typespecs (such
as CONCATENATE and MAP) are not specified as taking optional
environment arguments.
I suspect my confusion has to do with the difference between lexical
environments (which should come from the code surrounding the DEFTYPE
definition) and top-level environments (which should come from the
compilation or evaluation environment which is passed to TYPEP, etc.).
I further suspect that the ommission of &optinal environment in COERCE,
CONCATENATE and MAP is a mistake (though pretty hard to fix given the
syntax of the latter).
Howard R. Stearns <······@citydesktopinc.com> wrote in article
<·················@citydesktopinc.com>...
> This is consistent with the specification for DEFTYPE LAMBDA LISTS,
> which says that "a deftype lambda list has the same syntax as a macro
> lambda list, and can therefore contain the [same] lambda list keywords
> as a macro lambda list." Since macro lambda lists can contain
> &environment arguments for use in macro expansion, one assumes that
> &environment arguments would be used the same way in type expansion.
It looks like you are right (unfortunately :-)
> However the specification for DEFTYPE says that "the lexical
> environment for the body is the one which was current at the time the
> deftype form was evaluated, augmented by the variables in the
> lambda-list. This doesn't leave any room for type expansion to
> introduce a new environment. (It also seems to me to be a much better
> idea than the above, which it seems allows type expansion of the same
> DEFTYPE to have different results in different contexts.)
>
> Interestingly, COERCE and other functions which accept typespecs (such
> as CONCATENATE and MAP) are not specified as taking optional
> environment arguments.
Going full-circle, maybe COMPILE should take an environment argument?
> I suspect my confusion has to do with the difference between lexical
> environments (which should come from the code surrounding the DEFTYPE
> definition) and top-level environments (which should come from the
> compilation or evaluation environment which is passed to TYPEP, etc.).
Sounds right, except that the &environment argument can contain lexical
information from the point of expansion as well as top-level definitions
(though there is no TYPELET to introduce lexical types!).
--
Martin Simmons
······@harlequin.co.uk
"Howard R. Stearns" <······@citydesktopinc.com> writes:
> The specifications for SUBTYPEP, TYPEP and UPGRADED-COMPLEX-PART-TYPE
> do not say what the environment argument is used for, but the
> specification for UPGRADED-ARRAY-ELEMENT-TYPE says it "is used to
> expand any derived type specifiers that are mentioned in the typesec."
>
> This is consistent with the specification for DEFTYPE LAMBDA LISTS,
> which says that "a deftype lambda list has the same syntax as a macro
> lambda list, and can therefore contain the [same] lambda list keywords
> as a macro lambda list." Since macro lambda lists can contain
> &environment arguments for use in macro expansion, one assumes that
> &environment arguments would be used the same way in type expansion.
Agreed.
> However the specification for DEFTYPE says that "the lexical
> environment for the body is the one which was current at the time the
> deftype form was evaluated, augmented by the variables in the
> lambda-list. This doesn't leave any room for type expansion to
> introduce a new environment.
This is a confusion about evaluation times. Consider:
(deftype foo (type &environment env)
;; A silly example.
`(or null ,(upgraded-array-element-type type env)))
When a (FOO BAR) is expanded, the environment for the body is used to
look up the bindings of the function UPGRADED-ARRAY-ELEMENT-TYPE and
the variables TYPE and ENV; the value bound to ENV will be another
environment (that of (FOO BAR)), which is then passed to
UPGRADED-ARRAY-ELEMENT-TYPE and used to interpret the value of TYPE.
> (It also seems to me to be a much better
> idea than the above, which it seems allows type expansion of the same
> DEFTYPE to have different results in different contexts.)
When you're compiling, you definitely want to get the expansion that
is specified for the target (from the compilation environment, to be
technical), rather than the one used by the running image, should they
be different. They might be different, because you didn't (or even
couldn't) load it before compiling it.
> Interestingly, COERCE and other functions which accept typespecs (such
> as CONCATENATE and MAP) are not specified as taking optional
> environment arguments.
Interesting point.
> I suspect my confusion has to do with the difference between lexical
> environments (which should come from the code surrounding the DEFTYPE
> definition) and top-level environments (which should come from the
> compilation or evaluation environment which is passed to TYPEP, etc.).
There's no difference, in theory; There's just _the environment_. One
can discuss the lexical and global ("top-level") items in it
separately, and in practice, those parts are implemented in very
different ways. (Which is why spec can nail down the lexical aspects,
but is very vague on global aspects.)
> I further suspect that the ommission of &optinal environment in COERCE,
> CONCATENATE and MAP is a mistake (though pretty hard to fix given the
> syntax of the latter).
The relevant X3J13 issue just doesn't mention them at all. I'm hoping
Kent has some insight into this.
--
Pekka P. Pirinen
Adpative Memory Management Team, Harlequin Limited
A feature is a bug with seniority. - David Aldred <david_aldred.demon.co.uk>
Pekka P. Pirinen wrote: [1999-08-16 20:06 +0100]
[further clarifications]
Thanks again. Your posts have been very useful for me.
Vassil Nikolov
Permanent forwarding e-mail: ········@poboxes.com
For more: http://www.poboxes.com/vnikolov
Abaci lignei --- programmatici ferrei.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.