oz@nexus.YorkU.CA (Ozan Yigit) (04/18/91)
Has anyone in the scheme community given any serious thought to (or produced a proposal for) a format primitive for some n, R^nRS inclusion? Existing implementations seem to provide two slightly different version of this primitive: one that takes a port argument (and thus like fprintf in C) and another that does not, and returns the formatted string (and thus like sprintf in C). Unfortunately, both versions are called "format". The former is presumably a carry-over from the past, where destination parameter specifies where the formatted string should go, and if that is nowhere flag (nil or #f) the function returns the formatted string, and thus provides the non-io functionality of the latter. Over the years, I found the latter to be the most convenient form, probably because it is a simpler form that only does one thing and one thing alone. Producing a wrapper around to get the "extended" functionality of the former is, of course, trivial. 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? oz --- In seeking the unattainable, simplicity | Internet: oz@nexus.yorku.ca only gets in the way. -- Alan J. Perlis | Uucp: utai/utzoo!yunexus!oz
Alan@lcs.mit.EDU (Alan Bawden) (04/20/91)
Date: 18 Apr 91 16:29:33 GMT From: Ozan Yigit <oz@nexus.yorku.ca> ... Producing a wrapper around to get the "extended" functionality of the former is, of course, trivial.... Unless you have format operators that use the state of the output port. Consider the Common Lisp format operator "~&", which outputs a newline unless the stream is already at the start of a line.
carlton@husc10.harvard.edu (david carlton) (04/20/91)
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