[Masinter.pa: Re: questions]

[Masinter.pa@Xerox.COM]

I should have cc'd this group on these, I think.


     ----- Begin Forwarded Messages -----

Date: 21 Jul 88 07:48 PDT
 From: Masinter.pa
Subject: Re: questions
In-reply-to: chapman%aitg.DEC@decwrl.dec.com's message of 19 Jul 88 13:55
To: chapman%aitg.DEC@decwrl.dec.com


    Are the return values for close, in-package, inspect,
    provde, and require specified?


My guess is that close returns the stream, in-package returns the new pacakge,
inspect returns the item inspected (or a new item if your inspector allows
that), and provide and require return no values. Lets bundle them together until
someone asks to separate them.

    Is there a list of allowed query functions against a closed file?

Not that I know of. You mean a stream that is  the result of OPEN (since we've
established that where CLtL says file it might be OK to talk to Unix's /dev/null
but not a make-two-way-stream thing). You might want to make a best guess and
circulate them. 

    On page 354, "When the @xlisp printer types out the name of a
    special character, it uses the same table as the @f[#\] reader;
    therefore any character name you see typed out is acceptable as
    input (in that implementation).  Standard names are always
    preferred over non-standard names for printing."
    I'd like to change the last sentence to read "... are required
    over non-...".  Do you see a problem with that?


Well, I thought preferred was put there for a reason, and I can imagine
situations where a short-name might be preferred (the case I have in mind is
NewLine. If you're running on a system that talks both to cr and lf based file
systems, you might want to emphasize #\cr #\lf vs #\newline.) 

    On page 160,
    "@f[(ignore @i[var1] @i[var2] ... @i[varn])] affects only variable
    bindings and specifies that the bindings of the specified
    variables are never used.  It is desirable for a compiler to issue
    warning if a variable so declared is ever referred to or is also
    declared special, or if a variable is lexical, never referred to,
    and not declared to be ignored."
    Where is "issue a warning" defined? Should it be defined by the standard?


The compiler committee, bless their collective hearts, are supposed to help with
this issue. What the charter of the compiler is, what warnings it can and cannot
issue, is not specified well enough, which is why this is fuzzy. I'd suggest
editorially that you move this to a section on Compiler Operations (with a
forward reference to it) to give them something to focus on; what is and isn't
allowable behavior for a compiler should be separated from the semantics of the
language, however. 

One possibility is to establish another kind of error situation, a "warnable
condition", that is, something that is legal within the formal semantics of the
language but that a user might expect a compiler to warn about, including misuse
of ignore, a call to 
(+ 3 T) or some such. But I'm reaching.

    On page 24,
    "Symbols have a component called the @i[property list], or @i[plist].
    By convention this is always a list whose even-numbered
    components (calling the first component zero) are symbols,
    here functioning as property names, and whose odd-numbered components
    are associated property values.  Functions are provided for manipulating
    this property list; in effect, these allow a symbol to be treated as an
    extensible record structure."
    Can I change the "by convention" to say "it is required" or something like
    that?


Well, one of the cleanup proposals was discarded because (someone) asserted that
CLtL required property lists had to have an even number of components. I'm less
sure about GETF, which doesn't operate on symbol property lists. 

    On page 67,
    "Other implementation-dependent bookkeeping actions may be taken as well
    by @f[defun]."
    Can I leave this out?

I think so.

    Where a result is not specified to be a copy,
    does that mean it can or can't be, or that it's not allowed? 


I think it means that it can or can't be. That's been the interpretation for
lots of things, that it was deliberately left unspecified.

    The following have underspecified arguments:
	logbitp
	make-dispatch-macro-character
	make-hash-table
	make-sequence 
	make-string 
	nthcdr 
	parse-integer 
    Should I choose the "obvious" specification for the arguments or
    generate clean-up proposals for each one?


I think you should (a) choose the obvious specification, and (b) circulate a
single omnibus document saying that these are the editorial choices you've made,
anyone who wants to hear about the issues on any of them, we'll write it up in
full "cleanup" form. I don't want to bog down the process with stuff that isn't
controversial, however.

    When it is stated that a function supplied to another function
    (e.g. merge) "should not have any side effects", does that mean 
    "it is an error for the function to have side effects", or does it
    mean that if the function has side effects, the result will be
    implementation-dependent?


I'm a little fuzzy on the distinction between "it is an error" and "if you do
it, the results are implementation-dependent". 

     ----- End Forwarded Messages -----