This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: Change in printing of Scheme values
BLewis wrote:
-----snippet of Original Message-----
Sent: Monday, November 13, 2006 4:00 PM
#|kawa:2|# (display 3)(display 4) (display 5)
3 4 5
------End snippet-----
This is a hugely incompatible change. It would break every (for-each
display ...) out there. My employer has a lot of exports to delimited
files, and this would insert spurious white space around numbers.
The feature only inserts spaces *between* numbers, not *around* numbers.
It is hard for me to come up with cases where the traditional
output makes sense and would change.
Could you explain what kind of code where the change would cause
a problem? Perhaps play with the SVN code to get a feel for how
it works. (It is of course possible there are unintended bugs.)
One example I can think of is where you write a number next to a list:
(display '(the answer is)) (display 9)
which would display:
(the answer is) 9
as opposed to the traditional:
(the answer is)9
but it seems rather far-fetched to prefer the latter.
It shouldn't be difficult to tweak the algorithm so for example we
don't insert spaces between lists.
For display, I'd strongly suggest not incompatibly changing the
behavior. Rather create a new function name for the space-inserting
functionality. That might make xquery harder to implement, but it's
important for Scheme.
The mechanism is there and there is no reason to change XQuery.
For Scheme it would be easy to suppress this feature by adding a
call to gnu.text.PrettyWriter.clearWordEnd.
A major motivation for the Scheme side isn't so much explicit calls to
display, but the implicit ones from the read-eval-print-loop. It seems
hard to argue that:
(values 1 2 3)
should display
123
rather than
1 2 3
The repl output in Kawa is the same as display. It is then nice if:
(display (values 1 2 3))
be the same as:
(display 1) (display 2) (display 3)
be the same as plain
(values 1 2 3)
which again should be the same as typing multiple expressions
on the same line:
1 2 3
Not all of these equivalences are essential for "Scheme". They might
be more appropriate for a new not-constrained-by-compatibility language.
If there is consensus that this feature will break too much code, then
I can disable it for Scheme without too much difficulty, I think.
But before that I'd appreciate it if people could try it out.
Does it really break much or any of your existing code?
--
--Per Bothner
per@bothner.com http://per.bothner.com/