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

[John Cowan <cowan@x>]

Per Bothner scripsit:

> 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.

I quite agree.  However, I don't think it's too great an imposition
to ask people to write (import (scheme patterns)) at the top of their
code in order to get pattern-matching lambda, define, let, let*, etc.
That disposes of your point 2, and I don't understand your point 1
unless it is another way of stating your point 2.  Are you objecting
to syntactic keywords having different significance in different parts
of the code?

What is more, in R7RS (as currently proposed) a REPL may auto-import
whatever set of modules the implementer chooses, so it is conformant to
provide pattern matching in the REPL automagically.

> 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: λ

I agree that this character is more suitable, as it will normally
adjust to the font you are using for the rest of your code.  Note that,
in accordance with modern Greek orthography, the formal spelling of the
character's name is always LAMDA.

> (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.)

Sounds good to me.

> 
> > 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
> error-prone.
> 
> 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
> r6rs-discuss@x
> http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss

-- 
John Cowan    cowan@x    http://ccil.org/~cowan
Rather than making ill-conceived suggestions for improvement based on
uninformed guesses about established conventions in a field of study with
which familiarity is limited, it is sometimes better to stick to merely
observing the usage and listening to the explanations offered, inserting
only questions as needed to fill in gaps in understanding. --Peter Constable

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