[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Cleanup issues from Japanese technical working group
- To: CL-CLEANUP@Sail.Stanford.EDU
- Subject: Cleanup issues from Japanese technical working group
- From: Masinter.pa@Xerox.COM
- Date: 10 Dec 87 23:10 PST
I asked for the list of open Common Lisp issues from the JEIDA technical working
group. This is their list.
I've added some comments in <<brackets>>. Some of these will require separate
issues, while many are already being addressed.
----- Begin Forwarded Messages -----
Return-Path: <@RELAY.CS.NET:yuasa%tutics.tut.junet@UTOKYO-RELAY.CSNET>
Message-Id: <8712101502.AA05475@tutics.tut.junet>
Date: Thu, 10 Dec 87 15:02:57 jst
From: Taiichi Yuasa <yuasa%tutics.tut.junet@utokyo-relay.CSNET>
To: Masinter.pa
Subject: Re: US work on List standards
Question and Answers about Common Lisp. (Revised)
Q: Michiaki Yasumura (Hitachi)
A: TG/A members
[nn.nn.nn] indicates section numbers in CLtL
*******************************************************************
The following subjects should be clarified.
*******************************************************************
1) CLtL says nothing about whether structure or array is self evaluating
form. [5.1.1]
It is suggested that not only numbers, characters, and bit-vectors,
but also structures, arrays, vectors, packages be self-evaluating forms.
Yuasa: There may possibly be some reason that these objects are not
allowed to be evaluated. But the reason is not known.
This simplification is convenient both for the user and for the implementor.
Note that some implementations such as Exper Common Lisp signal an error
when those objects that CLtL does not explicitly say are self-evaluating
are being evaluated.
<<The Rationale for this could easily be provided in the standard.
Does this need an Issue? >>
2) Arguments of function are evaluated left to right. [12.1]
<<This is clearly stated and should be even more ambiguous given a
formal semantics. I think no issue. >>
3) It should be an error if two variables specified in a single lambda
list are named by a same symbol. [15.2]
<<This was discussed in the CL mail, but I suppose it needs
New issue LAMBDA-LIST-DUPLICATES? >>
4) For mapping functions (MAPCAR, SOME, EVERY, etc.) and DOLIST,
it is an error to perform destructive operations on the mapping argument.
The result will be implementation dependent. [7.8.4]
<<New issue MAPPING-DESTRUCTIVE-INTERACTION?>>
5) Property lists are global. There is no local property list even if
the symbol is locally bound. (Common Sense?) [10.1]
<<This is just confusion; symbols are not variables, they just name them.
I think no issue.>>
*************************************************************************
The following subjects are loosely stated in CLtL, and should be clarified.
*************************************************************************
1) If read-base is 16, `1E0' is read as an integer and not a float. [2.1.3]
<< I think this is a wording change rather than an Issue.>>
2) (LAMBDA (X) X) is both of the LIST type and of the FUNCTION type. [2.13]
Umemura: Cons cells must be regarded as function type objects, since
it is strange to check the syntactic validity when the type
of an object is computed.
<< Issue FUNCTION-TYPE would address this >>
3) DEFTYPE affect only the type checking mechanism and no more and less.
[4.7]
<< I'm not sure what this means. DEFTYPE also affects TYPEP, TYPECASE. >>
4) Symbols whose names begin with & are not allowed in a lambda list. [5.2.2]
<< I don't think this is true. It is a bad idea, but it isn't required.
Issue? >>
5) Same keyword parameter can appear more than once in an actual argument
list. [5.2.2]
This is necessary to overwrite passed keyword arguments.
<< New issue KEYWORD-ARGUMENT-DUPLICATES? >>
6) #C(5/3,7.0) is converted to #C(1.66666,7.0) because
real part and imaginary part must be of the same for efficient
calculation on complex numbers. [2.1.4]
<< This is clear, I thought, from CLtL >>
7) For destructive sequence functions such as DELETE, it is an error
to use the side effect of original data structure.
Implementation dependent result will be returned.
It is possible to defined DELETE as
(defun delete (&restâ??αβâ?§Â¬ÎµÏ?λ
!
â??â??â??â??â?©â?ªâ??â??â??â??â??â??â? $â?¤ by REMF-DESTRUCTION-UNSPECIFIED >>
8) It is an error to apply non-list arguments for the list handling
functions. [15.5]
<< I think is specified. No issue? >>
9) Structures defined with the option :TYPE LIST are simple lists
and there is no way to distinguish these data from lists. [19.5]
<< I this is specified. No issue? >>
**********************************************************
The following subject have problems in CLtL specification.
**********************************************************
1) ------
Q: What happens if a function is defined in a body of a function.
For example:
(defun bar ()
(bar)
(defun bar () (something))
(bar) ) ; <-- Should BAR be affected in the execution of FOO?
A: CLtL says the DEFUN is a simple macro which changes the symbols definition.
So, BAR should be affected.
Problems: If so, the tail merging optimization is very difficult.
We cannot know how to define the effect of DEFUN in order to allow this
optimization.
Yuasa: How about defining only the compiler semantics?
For almost all Common Lisp programs run in compiled code.
<< Unless BAR is proclaimed INLINE, you have to do tail optimization
by indirect thru the function cell. This was discussed at length.
Does this need an issue? FUNCTION-TAIL-RECURSION?>>
2) -----
Q: Is it possible to redefine predefined (built-in) functions and macros
such as DEFUN, AND, OR.
A: CLtL says nothing about this thing, but almost all implementations
allow such redefinition.
Problems: We cannot image what happens.
Suggestion: Redefining a predefined symbol signals an error.
However, Redefining user function does not signals an error.
<< This is issue LISP-SYMBOL-REDEFINITION >>
3) ---
Q: Is there any way to cancel the PROCLAIM.
A: No. There should be such a function.
<< Well, PROCLAIM-LEXICAL had such, but is in trouble. >>
4) ---
Q: Is there any way to escape from Lisp context.
A: Some systems, such as Lisp machine have no concept of escaping.
This is needed for Lisp systems under stock operating systems.
It is necessary to determine the name even if the function
may be implementation dependent.
Recommendation: (QUIT) will be a proper word for this operation.
<< Seems like it goes in the environment section. >>
5) --
Q: Is it possible to UNINTERN the DEFCONSTANTed symbols.
A: CLtL says yes, but it is hard to compile such a program.
Umemura: We should define the semantics of compile-file.
Changing readbase, readmacro, packaged in a file
also introduce similar problems.
<< This seems to be mainly about UNINTERN during file compilation.
seems like this is part of the compiler specification. >>
***************************************************************
These function can be defined in CLtL itself, but should be
added to CLtL for the efficiency or user convenience.
***************************************************************
1) ---
Q: Is there any way to test whether a symbol is special or not?
A: We can define such a function in a tricky way,
But there should be this function, for compiler needs this function
and it seems that almost all implementations support such a function
internally.
<< This has been asked for before. Issue SPECIAL-VARIABLE-TEST ? >>