[HARLEQUIN][Common Lisp HyperSpec (TM)] [Previous][Up][Next]


Issue SUBTYPEP-ENVIRONMENT Writeup

Issue:             SUBTYPEP-ENVIRONMENT

References: DEFTYPE,

TYPEP, SUBTYPEP,

UPGRADED-ARRAY-ELEMENT-TYPE,

UPGRADED-COMPLEX-PART-TYPE

Related issues: Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS

Issue CLOS-MACRO-COMPILATION

Issue DEFTYPE-DESTRUCTURING

Issue CONSTANTP-ENVIRONMENT

Category: CHANGE, ADDITION

Edit history: V1, 02 Jan 1989, ???

V2, 12 Feb 1991, Sandra Loosemore

Problem description:

Defining macros including DEFTYPE, DEFSTRUCT, DEFCLASS, and

DEFINE-CONDITION are permitted to note type definitions at

compile-time in such a way that those definitions are visible only to

the file compiler and not to the evaluator. This can lead to

incorrect behavior in user code that deals with the type system, for

example in macro expansion functions. Such code needs to explicitly

indicate in some way whether it wishes to deal with the type system as

seen by the file compiler (the "remote environment"), or in the

current environment.

Proposal (SUBTYPEP-ENVIRONMENT:ADD-ARG):

Add an optional environment argument to TYPEP, SUBTYPEP,

UPGRADED-ARRAY-ELEMENT-TYPE, and UPGRADED-COMPLEX-PART-TYPE. If the

argument is NIL or not supplied, it defaults to the null lexical

environment and current global environment.

Clarify that &ENVIRONMENT may appear in the lambda-list of a DEFTYPE

form, as with DEFMACRO.

Examples:

???

Rationale:

This is consistent with the mechanism used elsewhere to specify what

environment name/definition lookups should be performed in.

Current Practice:

Chestnut's Lisp-to-C translator supports this mechanism.

Cost to Implementors:

Minor. Implementations that don't support the notion of "remote

environments" can ignore the environment arguments.

Cost to Users:

Minor. Users may have to be more careful about passing environment

arguments around.

Cost of non-adoption:

Programs that try to manipulate type information at compile-time will

break in some implementations.

Performance impact:

Minor.

Benefits:

The cost of non-adoption is avoided.

Esthetics:

Looks OK to me.

Discussion:

Version 1 of this issue was lost. Version 2 is a completely new

writeup.

Loosemore and Barrett support this proposal.

There may be confusion about why TYPE-OF does not need an

environment argument. Recall that compile-time type definitions made

by DEFSTRUCT, DEFCLASS, and DEFINE-CONDITION are permitted to be

partial or incomplete. Essentially, the only information that is

required at compile-time is that a name/type mapping exists and the

subtype/supertype relationships between all of the type specifiers.

On the other hand, the type must be fully defined before instances can

be created. If no instances can be created, then TYPE-OF has no need

to know about the type. TYPE-OF also has no need to know about type

specifiers defined with DEFTYPE.

-------


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996, The Harlequin Group Limited. All Rights Reserved.