[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Cleanup issues from Japanese technical working group

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 

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]

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.
   << 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.

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 ()
    (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

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.


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

<< This has been asked for before. Issue SPECIAL-VARIABLE-TEST ? >>