Re: [r6rs-discuss] [scheme-reports] Scheme pattern matching & R*RS
Per Bothner
(14 Dec 2010 17:24 UTC)
|
Re: [Scheme-reports] [r6rs-discuss] [scheme-reports] Scheme pattern matching & R*RS
John Cowan
(14 Dec 2010 17:39 UTC)
|
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] need to overload (case) for pattern-matching
Peter Kourzanov
(14 Dec 2010 18:12 UTC)
|
Re: [r6rs-discuss] [Scheme-reports] [scheme-reports] Scheme pattern matching & R*RS
Jim Wise
(21 Dec 2010 15:51 UTC)
|
Re: [Scheme-reports] [r6rs-discuss] [scheme-reports] Scheme pattern matching & R*RS
Peter Kourzanov
(21 Dec 2010 16:42 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