Re: [Scheme-reports] [r6rs-discuss] Scheme pattern matching & R*RS Peter Kourzanov (14 Dec 2010 17:58 UTC)
Re: [r6rs-discuss] Scheme pattern matching & R*RS Adrien "Pied" PiƩrard (15 Dec 2010 02:23 UTC)
Re: [Scheme-reports] [r6rs-discuss] freshmen & unicode lambda's Peter Kourzanov (15 Dec 2010 09:28 UTC)

Re: [Scheme-reports] [r6rs-discuss] Scheme pattern matching & R*RS Peter Kourzanov 14 Dec 2010 17:57 UTC

On Tue, 2010-12-14 at 12:39 -0500, John Cowan wrote:
> 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.

Exactly. I would also hate having to know about the difference between
non-pattern-matching and pattern-matching forms. I think we should
consider regular Scheme variable binding in (lambda) and in (let) as a
special case of pattern matching. Because of this, we should let
(define) as it is I'm afraid.

Its already a better style to always use (define var (lambda args ...))
rather than (define (var . args) body ...) - separation of concerns the
first thing coming to mind...

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

In my Emacs v23 (Ubuntu Linux), this letter resolved to "l" (as did the
*LAMDA version), not something like 𝝺 .

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

Its the difference between |vs.❘ (| is found on your keyboard resp.
❘ from Unicode). Is | also special to other implementations of Scheme?

> >
> > 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@bothner.com   http://per.bothner.com/
> >
> > _______________________________________________
> > r6rs-discuss mailing list
> > r6rs-discuss@lists.r6rs.org
> > http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
>

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