On Thu, Apr 12, 2012 at 10:08 PM, Marc Feeley <feeley@iro.umontreal.ca> wrote:
> On 2012-04-12, at 7:51 AM, Alex Shinn wrote:
>
>> 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.
>
>
> The issue I see with the Boolean datums is that they are fundamental and used all over the place in code (new and old).  I'm worried that very simple new code (such as tutorials and one liner examples) written with the new syntax, will not work in many non-R7RS Scheme implementations.  That's going to cause a lot of confusion.

The idea is that we support the long names
read-only in R7RS, and can consider writing
them by default in R8RS.  I think concerns
about forward-compatibility are misplaced -
the only way to achieve that is not to add,
remove or change anything in the standard
at all.

I think the documentation argument is
stronger, since authors are likely to be among
the first to switch to a more readable syntax.

> Also, if there are two syntaxes, which one is used by the printer (write, pretty-print, etc)?  I would find it very confusing to see things like:
>
>> #true
> #t

I don't think this is any more or less confusing than:

> #T
#t
> #x10
16
> "\x65\x66\x67"
"ABC"
> call/cc
#<procedure call-with-current-continuation>

Many values have more than one written representation.

> I very much like the #T/#F syntax as it achieves the goal of making the two Booleans visually distinct, and perfectly compatible with R5RS.  The upper-case version could be the canonical external representation, so:

I don't consider #T/#F any better.  More than the
idea that people actively confuse #t/#f, I think it's
a problem that the two values are not visually
distinct.  My primary complaint is in long lists of
the two values.  Words we read from their shape,
and are easy to distinguish.  Characters like 1/0
are very visually (and topologically) different.
#T/#F still require me to focus.

This also doesn't address the argument that
#T/#F are unfriendly to newcomers.

--
Alex

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