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

responses to your answers]



>    >Now somewhere in 6.1: The reference to APL is questionable, does this mean
>    >we are incorporating some specific standard by reference (then we should
>    >give its exact name), or is it just a general remark?
>    I cited the whole reference this time.
 
>It still doesn't tell me how to order a copy, or is that in a bibliography
>elsewhere?
I put the reference to the book in section 1.3 and cited that book in 
place of the acronym. 

>I'll let Guy Steele be the arbiter on this one, but I'm not sure that we want to
>just refer to another standard instead of giving the branch cut rules explicitly.
>There is too much room for ambiguity or mistakes in mapping between APL and Lisp.
>Maybe the branch cut rules are given explicitly, but I haven't been able to find
>them.  After mentioning the APL document, section 6.1 goes off to talk about
>something unrelated.
The branch cut rules that were in CLtL are located with the descriptions
of the functions to which they apply. Is that organization sensible? Are
there more branch cut rules in the reference that should be explicitly 
stated in the standard?
 
>Section 4.1:
> 
>  [If an operator symbol doesn't name a function, special form, or macro]
>  An error of type {\datatype undefined-function\/} might be signalled.
>  *** I have recorded that the issue UNDEFINED-VARIABLES-AND-FUNCTIONS
>  has been withdrawn. So I guess we can't adopt its contents, but what
>  about ``might'' in place of ``should''?
> 
>My notes say it's deferred to the June meeting to fix the CLOS slot
>part, not withdrawn.  That's independent of the function part, and I
>think "should" would be best here (as UNDEFINED-VARIABLES-AND-FUNCTIONS
>proposes).  Can we just change it to "should" or do we have to go
>through the cleanup committee?
Seems like `should' was a critical part of this proposal. But we could
assume this will pass and use `should' here, then take it out if it doesn't?