NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/lang/scheme/2808

Internet Message Format | 1992-12-22 | 3.6 KB

Path: sparky!uunet!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!gatech!destroyer!cs.ubc.ca!columbia.cs.ubc.ca!not-for-mail
From: [e-mail] (Vincent Manis)
Newsgroups: comp.lang.scheme
Subject: Re: standards
Date: 21 Dec 1992 18:32:12 -0800
Organization: Institute for Pure and Applied Eschatology
Lines: 57
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
NNTP-Posting-Host: columbia.cs.ubc.ca

In article <[e-mail]> [e-mail]
(Brian Harvey), subjunctively, talks of R5RS.

>* graphics.  Simple.  (DRAW-LINE x1 y1 x2 y2) is almost enough for me.
>Oh, and clearing the screen or the window.
Absolutely! I'd put these facilities in the same class as load or
transcript-on: they're not logically necessary, but it's worth defining
them, simply so that each implementation doesn't end up reinventing
them.

>I don't care if there is a standard window control package.]
I would vote no on a window control package. Provide a minimal set of
interaction/graphics facilities, and leave the rest to implementations.
I suspect that anyone who wants to do real graphics in Scheme will end
up using real graphics primitives, and I don't think that RnRS is the
right place to formalize window semantics.

>* Expunge "the return value is unspecified" from the standard.  All of them
>should be replaced by "the return value is the non-printing object."  This
>sounds trivial but it's really a pain in the neck for beginners.
Not quite. `The non-printing-object' is a hack. A void type should be
identified. Following Chez Scheme, we add (void), which returns the sole
value of this type, and (void? x) which is a type predicate. We further
include void in the list of disjoint types. Although R4RS doesn't talk
much about a top level, a note should be added to the effect that it is
intended that, in a top level, a void result should produce no printout.

>* Clarify what happens when you open-output-file a name that already exists.
>I vote for replacing the old one, but again, any consistent thing is
>tolerable.
>* Delete-file.
Again, these are trivial to specify in ways which are OS-independent.
It's fine with me if they produce errors, but *some* clearly specified
action should be defined.

I'm co-writing a book which uses Scheme. The only other non-standard
features which  we rely on, other than the above, are trace and gensym.
gensym is pretty trivial to define if it's non-present (and therefore
not worth putting into the standard, as far as I'm concerned). trace is
difficult (particularly for handling tail recursion), but I'd really
like to see some sort of specification on it.

I was really happy with the way the R4RS process was opened up, via the
mailing list, but I would really appreciate some more formal
consultation process the next time around. For example, drafts could be
left on altdorf for some clearly-defined period, and an email address
could be established for submitting proposals. It's clearly the
committee's call as to what's in the Report, but it might help make
their job easier if they know that some trivial feature has wide demand,
whereas another is really of no interest to anyone.


--
\    Vincent Manis <[e-mail]>      "There is no law that vulgarity and
 \   Computer Science, Langara College     literary excellence cannot coexist."
 /\  100 W. 49th Ave, Vancouver, BC, Canada [phone]  -- A. Trevor Hodge
/  \ Co-author of ``The Schematics of Computation'', Prentice-Hall, Jan 1994