RE: Change in printing of Scheme values

["BLewis" <blewis at eatonvance dot com>]

If chars get treated the way strings are, it won't break existing code
that I know of.  But (display 2) (display #\:) (display 3) would break.

Here's a situation where you might want to jam numbers together: check
digits.  We actually deal with a vendor who always sends six-digit SEDOL
numbers, omitting the seventh check digit.  Code that displays the valid
seven-digit SEDOL might display two numbers jammed together.  I'm sure
there are other situations where code might display a base number jammed
together with its check digit(s).

-----Original Message-----
From: kawa-owner@sourceware.org [mailto:kawa-owner@sourceware.org] On
Behalf Of Per Bothner
Sent: Tuesday, November 14, 2006 9:53 AM
To: BLewis
Cc: kawa@sourceware.org
Subject: 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/