Re: [Scheme-reports] Boolean hemlines

[Alex Shinn <alexshinn@x>]

On Thu, Apr 12, 2012 at 11:29 AM, Alan Watson <alan@x> wrote:
> A long time ago, some people made the decision that #t/#f were in some sense better than #!true/#!false. More recently, the WG1 have made a different decision that #true/#false are in some sense better than #t/#f.
>
> This decision is not without cost. If an R7RS Scheme writes a boolean datum as #true or #false, it likely cannot be read by a R4RS, R5RS, or R6RS Scheme. It is unrealistic and probably undesirable to require perfect compatibility between iterations of Scheme, but changing the spelling a fundamental data is perhaps unexpected. The WG1 needs to decide if this cost is acceptable, and if not either revert their decision to allow #true/#false or require write to produce #t/#f.

Thank you for the feedback.  However, before you jump to the conclusion that
we threw this in frivolously, or that the WG members voted without thinking
at all about the consequences, perhaps you could ask for our rationale?

First, as John says, in practice implementations will certainly output
#t/#f by default and only support the long versions for read.  The only
implementations which support this syntax currently (Chibi and Chicken
with the SRFI-38 egg needed for R7RS read/write support) both do so.
We could consider a warning to this effect, but I don't think it would
even be necessary.

Second, readability is truly a problem.  Many people read _very_
large amounts of Scheme code and data in a variety of mediums,
including tiny terminals and web interfaces with no font control
such as gmail.  Often we read quickly, and want to skim long
lists of alternating #t/#f.  If you never make a mistake doing so,
it is no doubt because you spend too much time focusing on
the character, losing the overall readability of the whole.  In this
very list, John Cowan earlier reported behavior incorrectly for
a test case for a Scheme implementation because he was looking
through many results and mistook a #t for a #f (or vice versa?).

Third, the argument for binding a default value to true and false
variables is weak, partly because if there's a good or better default
we should provide it, but also because it doesn't work at all for
data.  One of the most common use-cases was config files, where
you very often have long alists of (key . value) pairs, and where value
is often boolean.  I have long such config files for various server
settings, and unless the booleans are spelled out I have to stop and
*look* at the values when I could be reading with just a glance.

Fourth, we want to be friendly to newcomers.  The language
as a whole is beautiful and tends to read like prose.  A well
written Scheme program tends to be readable to even someone
who doesn't know the language at all - except for #t and #f.
All modern languages I'm aware of spell these keywords out.

I encourage people to think about and continue discussing this
issue.  I thought about it for a long time myself and didn't vote
lightly.  But at the current time no new arguments have been
raised, and we therefore have no grounds for re-opening the ticket.

-- 
Alex

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports