Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!psuvax1!hsdndev!husc6!carlton
From: carlton@husc10.harvard.edu (david carlton)
Newsgroups: comp.lang.scheme
Subject: Re: format [topics from hell, part 1]
Message-ID: <CARLTON.91Apr20004133@husc10.harvard.edu>
Date: 20 Apr 91 04:41:33 GMT
References: <22449@yunexus.YorkU.CA>
Sender: news@husc6.harvard.edu
Organization: Citizens for Boysenberry Jam
Lines: 68
In-reply-to: oz@nexus.YorkU.CA's message of 18 Apr 91 16:29:33 GMT

In article <22449@yunexus.YorkU.CA> oz@nexus.YorkU.CA (Ozan Yigit) writes:
   What is better for scheme? A low-level (string-producing) format primitive
   [which should probably be called something other than "format", to avoid
   confusion], or the classic format-as-io-primitive-that-can-return-strings
   approach?

This isn't an answer to what you asked, but a related suggestion: how
'bout adding string ports to Scheme?  I.e., add a function

(open-input-string string)

that would return an input port which would return the successive
characters in the string?  Obviously, you also want an
open-output-string to go along with that, though it's less clear how
that would behave - perhaps it could take no arguments and could
return an output port, and there could be an additional function

(force-output-string port)

which would return a string containing all of the characters that have
been written to the port.  For that matter, since the value that
close-output-port returns is unspecified, it could return a string if
the output port happened to be a string port, though I'm not sure how
much I like that.  I don't think that it would make much sense to pass
open-output-string a string, since there is no way to change the
length of a string currently.  (A decision which I think I agree
with.)

Of course, what we (at least I) want is a compelete overhaul of
Scheme's i/o, which I believe is one of the weakest sections of the
standard.  It's all well and good to talk about adding multiple return
values and modules and other such fancy things, but I would like to
firm up what is already there first.  Here is what I would like, in no
particular order:

1) Add string ports, as above.

2) Ditch call-with-input-file and call-with-output-file.  (Did these
get removed in the final IEEE standard?  All that I have is P1178d4.)

3) Have open-{input,output}-file return #f if the file doesn't exist.
Currently, implementations are forced to signal an error in such a
situation, which is ridiculous, since it makes it impossible to handle
that situation, which is a fairly common one.

4) Add {display,write}-to-string.  I often want to be able to convert
an arbitrary object into a printed representation of it and find that
I can't.  Of course, adding string ports would make this unnecessary,
albeit perhaps useful enough to be added separately anyways.

5) Encourage implementations not to buffer output to terminals.  How
many of you have had to write non-portable code to convince T to do
what you want in a program using prompts?

6) Leave in with-{input-from,output-to}-file.  I noticed that these
were gone from P1178d4, and I don't like that - the notion of a
current input/output port is a lot less useful, IMHO, if it can't be
changed...  Of course, there is always the question of how this
interacts with continuations, and I confess that I certainly don't
have any good answes.  The right way to handle it would be with some
sort of unwind-protect or fluid-let mechanism - any move to add that
to Scheme?

How do these suggestions sound to people?  What else would people like
from Scheme's i/o?

david carlton
carlton@husc9.harvard.edu