[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [r6rs-discuss] [scheme-reports] Scheme pattern matching & R*RS

On 12/14/2010 01:14 AM, Peter Kourzanov wrote:

> Per, et.al.,
> I am completely with you on this - we need a shorter form for lambda.

While not disagreeing, that wasn't quite what I was saying, which is:

The (default/preferred) syntax for lambda should do pattern-matching
*without* having to use a verbose name like match-lambda*.  I don't
want either of these:
(1) People learning and using Scheme having to mix 2 sets of
keywords depending on whether they want to use pattern-matching.
(2) Having to use keywords that are *even more* verbose than R6RS.

> In fact, I am toying with the idea of using Unicode for this (we are
> living in the 21st century, right?). Let me spare you the need to browse
> W3 pages - there are 5 different small lambda's in Unicode (here I am

If we did this, we should also allow GREEK SMALL LETTER LAMBDA.  In fact,
it would be preferable, I think, as it has a standard HTML escape: λ
(Neither, alas, seems to have a standard compose-key binding, though
perhaps we could lobby X.org to have the greek letters added.  For example
lambda == compose+g+l, using "g" as a prefix for Greek letters.)

> Concerning the other half of your mail, I would like to keep (define)
> orthogonal to (lambda), i.e., using a syntax like this (also using LIGHT
> VERTICAL BAR, i.s.o | because in some implementations | is reader's
> special quotation)

Those two characters are too similar to each other.

A unrelated problem, where using "more of Unicode" can help:
Using the same character for both the start and end of a "string"
is bad design, especially if you allow multi-line strings.  The problem
it is not robust in terms of errors, or (worse) incomplete programs:
Imagine a syntax highlighter or other on-the-fly parser trying to
keep up while you're editing an expression containing multi-line
string literals - what is inside vs outside the string literal
changes from moment to moment.

Unfortunately, there aren't any good start-quote/end-quote pairs.
The old texinfo way of using apostrophe `like this' is wrong with
current fonts and Unicode semantics.  One could use {braces} or
[brackets], but they're more naturally used for other things.
One could use a #"2-character sequence"# but that is ugly and

However Unicode provides options: «double angle quotation marks»
or “double quotation marks”.  Both of these have standard HTML
named-character escapes *and* compose-key combinations.  The
«former» is I think more readable (and has an easier compose-key
sequence).  (The problem with “double quotation marks” is that it
is harder to see the difference between “ and ” and " - at least
with the font and eyes I'm using.)
	--Per Bothner
per@x   http://per.bothner.com/

r6rs-discuss mailing list