Re: [r6rs-discuss] Scheme pattern matching R*RS
On 12/17/2010 06:34 AM, Jim Wise wrote:
* a proper or improper list of N subpatterns with the literal `...`
symbol
occurring once or more in any position except either the first position
of any list, or the last position of an improper list.
examples:
{{{
(a ... b c)
(a (b c) ... d)
(a b ... . d)
}}}
in this case, the pattern list is matched as in the above proper or
improper list cases, except that the subpattern before the `...` symbol
can match zero or more instances of the pattern preceding the `...`
symbol. Variables bound by a subpattern preceding a `...` are bound to
a (possibly empty) list of all values matched by the pattern as if by a
`map` of the `match` operator for that subpattern over each individual
value matched.
Note this is inconsistent with syntax-rules patterns, which requires ...
also in each *use* of the match. I.e. the variables bound by a
subpattern preceding
a '...' are matched to some kind of *handle* to a list, not an actual list.
(match '((a . 1) (b. 2) (c . 3))
(((x . y) ...) (cons (list x ...) (list y ...
== ((a b c) . (1 2 3))
I think requiring ... in expressions is a feature, not a problem.
For example, it enables:
(match '((a . 1) (b. 2) (c . 3))
(((x . y) ...) (list (y . x) ...)))
== ((1 . a) (2 . b) (3 . c))
I'm working on a sequence/iteration/looping framework that
makes use of this idea. Coming soon ...
--
--Per Bothner
p...@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
Re: [r6rs-discuss] Scheme pattern matching R*RS
On Fri, 2010-12-17 at 01:47 -0500, John Cowan wrote: I've posted it at http://trac.sacrideo.us/wg/wiki/MatchingWise. I removed the section on exceptions (which is still unsettled) and changed the MUSTard. I've also removed the (rnrs match core) library in favor of just renaming on import. I believe we should have some more MUSTard: the (case) (case x ((alternatives ...) body) clause ...) should be generalized to (case x (pattern = body) (pattern ! guard = body) (pattern | pattern ... = body) clause ...) As with lambda, this can work on top of existing case construct (dispatch on = or -): If there is no arrow in (cadr (reverse clause)) then interpret (caddr (reverse clause)) as a list of literal alternatives... Since after =, this is a fixed structure, maybe we should even remove parenths around clauses: (case x | pattern = body | pattern ! guard = body | pattern | pattern ... = body | clause ...) Regards, Pjotr ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Scheme pattern matching R*RS
On 12/17/2010 12:17 AM, Peter Kourzanov wrote: On Thu, 2010-12-16 at 23:42 -0800, Per Bothner wrote: For example this would be mis-parsed in an unexpected manner: (lambda (x y) (list y x)) My definition *is* (I believe) compatible (i.e. a super-set) of traditional lambda. But it still allows for only one pattern rule. Why not have: (lambda (x y) (list y x) | (x y z) (list z y x)) I agree some separator like that would work, and be quite readable, IMO. One issue is that if you use | (or some other separator to separate cases) then you'd really want to be consistent and use the same separator for match, let, etc etc. I'm not sure that works all that well: (match val pat body body ... | pat body body ... ...) This seems a bit less inelegant. I actually considered something similar, but using double bars: (lambda (x y) (list y x) || (x y z) (list z y x)) This would actually be consistent with using | for symbol quoting - in that case the empty symbol || would separate different cases. or, with arrows (and guards): (lambda (x y) ! ( x 1) = (list y x) | (x y) ! otherwise = (list x y)) Nothing wrong with going in that direction - but you're getting further and further away from what people think of as Scheme, and I suspect most people here are going to be skeptical. Language design means more than just throwing out ideas - you need to work out a coherent language from it all. And I'm not sure the direction you're going has the Scheme nature. You might find this interesting http://per.bothner.com/blog/2010/Q2-extensible-syntax/ The article does not describe a coherent language (there will be more as I have time), and certainly not anything I'd call a Scheme, but it's a working-out of some my ideas. (I intend to support patterns and unification, but haven't had time yet.) -- --Per Bothner p...@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
Re: [r6rs-discuss] Scheme pattern matching R*RS
One quick correction -- the (removed) (rnrs match core) library renamed match-lambda* - lambda while this edit renames match-lambda. - Lambda which will not work. Sent from my iPhone. Digital signature available upon request. On Dec 17, 2010, at 1:59, John Cowan co...@mercury.ccil.org wrote: Per Bothner scripsit: I think that misses the point - it becomes too much hassle to manually type in the renames, so people aren't going to do it. Ah, but the default names are the overrides, *not* the match- forms. Sneaky, eh? -- John Cowan co...@ccil.org http://ccil.org/~cowan Assent may be registered by a signature, a handshake, or a click of a computer mouse transmitted across the invisible ether of the Internet. Formality is not a requisite; any sign, symbol or action, or even willful inaction, as long as it is unequivocally referable to the promise, may create a contract. --Specht v. Netscape ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Scheme pattern matching R*RS
Per Bothner p...@bothner.com writes: Regardless: (lambda (pat body body ...) (pat body body ...) ...) is incompatible with core:lambda - i.e. it is not a super-set of traditional lambda, and it's not just a matter of rare corner cases. That makes it unacceptable, IMO. You're right. The existing pattern matching libraries I'd looked at all made the distinction between match-lambda, good for creating a single-argument function which destructures that argument, and match-lambda*, which creates a multi-argument function which takes those arguments as a list and destructures that list. I think this has to do with the development history of the original Wright pattern-matching library, and in any case is indeed not very well suited to renaming either as the core lambda form. I'd like to propose the following revision: do away with the one-argument special case currently known as match-lambda (this can be easily implemented in terms of the multi-argument case, and make the pattern matching version of lambda take one pattern and any number of body statements, for compatibility with core lambda: (lambda pat body) == (core:lambda x (match x (pat body ...))) and then use case-lambda from (rnrs control) for the multi-pattern case: (case-lambda (pat body) ...) == (control:case-lambda x (match x (pat body) ...)) Thoughts? -- Jim Wise jw...@draga.com pgpTuN4aMSV2W.pgp Description: PGP signature ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Scheme pattern matching R*RS
Jim Wise jw...@draga.com writes:
I'd like to propose the following revision: do away with the
one-argument special case currently known as match-lambda (this can be
easily implemented in terms of the multi-argument case, and make the
pattern matching version of lambda take one pattern and any number of
body statements, for compatibility with core lambda:
(lambda pat body) ==
(core:lambda x (match x (pat body ...)))
and then use case-lambda from (rnrs control) for the multi-pattern case:
(case-lambda (pat body) ...) ==
(control:case-lambda x (match x
(pat body)
...))
Thoughts?
For consideration, enclosed is an updated version of MatchingWise
containing this change, and removing a lingering reference to (rnrs
match core) in the introduction.
== Pattern Matching ==
This is a proposal for a WG2 pattern matching library. The motivation of
this proposal is to provide a pattern-matching facility similar to that in
the ML family of languages [Harper 2008], as such a facility allows the
succinct expression of some algorithms in a language very similar to the
underlying mathematics of the problem set.
The Pattern Matching package can be imported as `(rnrs match)`, which
provides new versions of several `(rnrs core)` forms. Renaming or prefixing
can be used to make the pattern-matching forms provided by `(rnrs match)`
available without replacing forms from `(rnrs core)`.
Pattern matching algorithms have been provided as an extension to standard
Scheme syntax by a number of existing implementations, including Bigloo
[Serrano 2010], Chicken Scheme [Chicken Team 2009], Racket [Flatt 2010] and
others. Many of these implementations have been influenced by a widely used
platform independent pattern matching library by Andrew K. Wright [Wright
1994]. A more recent library by Alex Shinn [Shinn 2010] provides similar
functionality in a mostly R5RS-compliant implementation.
A similar pattern matching language for macro definition is also provided by
the core `syntax-case` form.
In addition, very limited forms of non-pattern value matching are supported
by the argument syntax of the R6RS Scheme `lambda`, `case-lambda`, and
`define` forms. A limited pattern functionality is provided in Common Lisp
by the `DESTRUCTURING-BIND` macro.
Where the above sources for pattern matching come into conflict, this
proposal attempts to provide compatibility first with the RNRS `syntax-case`
form, and secondly to the existing implementations.
== Patterns ==
The forms in this library work by attempting to ''match'' a Scheme value of
arbitrary complexity against one or more patterns. If such a match
succeeds, zero or more variable bindings are created for the scope of a
corresponding body expression or expressions. Match failure generally
triggers attempted matching against another pattern specified in the same
form, and a ''match error'' is generated if none of the provided patterns
match the given value.
=== Simple Patterns ===
A pattern can be
* a boolean, number, string, character, or byte-vector literal, or the
empty list
examples:
{{{
#\A
42
()
}}}
in this case, the value MUST match in the sense of `equal?`, and no
variable is bound by this match.
* a quoted datum
examples:
{{{
'b
(quote (a b (c d)))
}}}
in this case, the value MUST match in the sense of `equal?`, and no
variable is bound by this match
* the special symbol `_`
in this case, any value will match, and no variable is bound by this
match.
* any other symbol
examples:
{{{
a
matched-val
}}}
in this case, any value will match, and that symbol is bound to the
matched value for the scope of the body expression or expressions of the
pattern matching form used.
=== Aggregate Patterns ===
Patterns can be aggregated into more complex patterns in a couple of ways.
When this is done, multiple constituent patterns (subpatterns) can be
required to match, and all symbols bound to a value by any matching
subpattern are bound for the scope of the body expression or expressions of
the pattern matching form used.
It is a syntax violation for the same symbol to appear more than once in a
pattern.
An aggregate pattern can be
* a proper list of N subpatterns
examples:
{{{
(a b c)
(a '= b)
(_ middle _)
(a (b c) d)
}}}
in this case, any list value of the same length where each subpattern in
the pattern list matches the corresponding element in the value list
will match, and the bindings corresponding to each subpattern will be
carried out.
* an improper list of N subpatterns
examples:
{{{
(a b . c)
(a (b c) . d)
}}}
in this case, every subpattern but the last MUST match the corresponding
element of the value list, and the last subpattern of the improper
pattern list MUST match the corresponding
Re: [r6rs-discuss] Scheme pattern matching R*RS
Jim Wise jw...@draga.com writes:
For consideration, enclosed is an updated version of MatchingWise
containing this change, and removing a lingering reference to (rnrs
match core) in the introduction.
One more quick formatting fix:
== Pattern Matching ==
This is a proposal for a WG2 pattern matching library. The motivation of
this proposal is to provide a pattern-matching facility similar to that in
the ML family of languages [Harper 2008], as such a facility allows the
succinct expression of some algorithms in a language very similar to the
underlying mathematics of the problem set.
The Pattern Matching package can be imported as `(rnrs match)`, which
provides new versions of several `(rnrs core)` forms. Renaming or prefixing
can be used to make the pattern-matching forms provided by `(rnrs match)`
available without replacing forms from `(rnrs core)`.
Pattern matching algorithms have been provided as an extension to standard
Scheme syntax by a number of existing implementations, including Bigloo
[Serrano 2010], Chicken Scheme [Chicken Team 2009], Racket [Flatt 2010] and
others. Many of these implementations have been influenced by a widely used
platform independent pattern matching library by Andrew K. Wright [Wright
1994]. A more recent library by Alex Shinn [Shinn 2010] provides similar
functionality in a mostly R5RS-compliant implementation.
A similar pattern matching language for macro definition is also provided by
the core `syntax-case` form.
In addition, very limited forms of non-pattern value matching are supported
by the argument syntax of the R6RS Scheme `lambda`, `case-lambda`, and
`define` forms. A limited pattern functionality is provided in Common Lisp
by the `DESTRUCTURING-BIND` macro.
Where the above sources for pattern matching come into conflict, this
proposal attempts to provide compatibility first with the RNRS `syntax-case`
form, and secondly to the existing implementations.
== Patterns ==
The forms in this library work by attempting to ''match'' a Scheme value of
arbitrary complexity against one or more patterns. If such a match
succeeds, zero or more variable bindings are created for the scope of a
corresponding body expression or expressions. Match failure generally
triggers attempted matching against another pattern specified in the same
form, and a ''match error'' is generated if none of the provided patterns
match the given value.
=== Simple Patterns ===
A pattern can be
* a boolean, number, string, character, or byte-vector literal, or the
empty list
examples:
{{{
#\A
42
()
}}}
in this case, the value MUST match in the sense of `equal?`, and no
variable is bound by this match.
* a quoted datum
examples:
{{{
'b
(quote (a b (c d)))
}}}
in this case, the value MUST match in the sense of `equal?`, and no
variable is bound by this match
* the special symbol `_`
in this case, any value will match, and no variable is bound by this
match.
* any other symbol
examples:
{{{
a
matched-val
}}}
in this case, any value will match, and that symbol is bound to the
matched value for the scope of the body expression or expressions of the
pattern matching form used.
=== Aggregate Patterns ===
Patterns can be aggregated into more complex patterns in a couple of ways.
When this is done, multiple constituent patterns (subpatterns) can be
required to match, and all symbols bound to a value by any matching
subpattern are bound for the scope of the body expression or expressions of
the pattern matching form used.
It is a syntax violation for the same symbol to appear more than once in a
pattern.
An aggregate pattern can be
* a proper list of N subpatterns
examples:
{{{
(a b c)
(a '= b)
(_ middle _)
(a (b c) d)
}}}
in this case, any list value of the same length where each subpattern in
the pattern list matches the corresponding element in the value list
will match, and the bindings corresponding to each subpattern will be
carried out.
* an improper list of N subpatterns
examples:
{{{
(a b . c)
(a (b c) . d)
}}}
in this case, every subpattern but the last MUST match the corresponding
element of the value list, and the last subpattern of the improper
pattern list MUST match the corresponding element of the value list if
the value list is improper and has the same length as the pattern list,
or the (possibly empty) remainder of the value list otherwise, and the
bindings corresponding to each subpattern will be carried out.
* a proper or improper list of N subpatterns with the literal `...` symbol
occurring once or more in any position except either the first position
of any list, or the last position of an improper list.
examples:
{{{
(a ... b c)
(a (b c) ... d)
(a b ... . d)
}}}
in this case, the
Re: [r6rs-discuss] Scheme pattern matching R*RS
Jim Wise scripsit: Enclosed is the draft I've put together for this. Let me know if you would like me to send this to one or more of the wg or reports lists for further comment. I've posted it at http://trac.sacrideo.us/wg/wiki/MatchingWise. I removed the section on exceptions (which is still unsettled) and changed the MUSTard. I've also removed the (rnrs match core) library in favor of just renaming on import. -- LEAR: Dost thou call me fool, boy? John Cowan FOOL: All thy other titles http://www.ccil.org/~cowan thou hast given away: co...@ccil.org That thou wast born with. ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Scheme pattern matching R*RS
On 12/16/2010 10:47 PM, John Cowan wrote: I've also removed the (rnrs match core) library in favor of just renaming on import. I think that misses the point - it becomes too much hassle to manually type in the renames, so people aren't going to do it. -- --Per Bothner p...@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
Re: [r6rs-discuss] Scheme pattern matching R*RS
Per Bothner scripsit: I think that misses the point - it becomes too much hassle to manually type in the renames, so people aren't going to do it. Ah, but the default names are the overrides, *not* the match- forms. Sneaky, eh? -- John Cowan co...@ccil.org http://ccil.org/~cowan Assent may be registered by a signature, a handshake, or a click of a computer mouse transmitted across the invisible ether of the Internet. Formality is not a requisite; any sign, symbol or action, or even willful inaction, as long as it is unequivocally referable to the promise, may create a contract. --Specht v. Netscape ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Scheme pattern matching R*RS
Per Bothner scripsit: Cute. But there seems to be a mistake in the definitions of lambda and lambda* - they have the same definitions and expansions in terms of core:lambda. No, the former is defined as (core:lambda (id) ...) and the latter as (core:lambda id ...). The names may well be reversed, but I'll wait for the author to weigh in on that. -- John Cowan co...@ccil.org http://ccil.org/~cowan And now here I was, in a country where a right to say how the country should be governed was restricted to six persons in each thousand of its population. For the nine hundred and ninety-four to express dissatisfaction with the regnant system and propose to change it, would have made the whole six shudder as one man, it would have been so disloyal, so dishonorable, such putrid black treason. --Mark Twain's Connecticut Yankee ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Scheme pattern matching R*RS
John Cowan co...@mercury.ccil.org writes: Peter Kourzanov scripsit: Hence my question: what is the state of pattern matching in Scheme? Are there ideas to move this forward, or are we, the poor users, left to live with incompatible pattern matching interfaces and implementations? Working Group 2 has decided that an optional pattern matching module will be part of R7RS. The last few messages have focused on pattern matching in lambda expressions, whether through a new MATCH-LAMBDA syntax, or through extending the lambda list syntax used by LAMBDA/DEFINE. Are there plans to include explicit pattern matching operations, such as Common Lisp's DESTRUCTURING-BIND or Racket's match[1]? [1] http://www.ccs.neu.edu/home/samth/ifl-2010-abstract.pdf -- Jim Wise jw...@draga.com pgpdltzFu4cCs.pgp Description: PGP signature ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Scheme pattern matching R*RS
Per Bothner scripsit: To win pattern-matching really should be the default and integrated into the language core, rather than an optional module that uses separate keywords. E.g. there shouldn't be a difference between lambda and match-lambda*. The latter is too verbose! Being in the core and being spelled lambda are orthogonal points. The module can say (export (rename match-lambda* lambda)) and then importers will get the pattern-matching lambda, or they themselves can import it as (import (rename (scheme patterns) (match-lambda* lambda))). In a world of import and export renaming, the precise name of a procedure or syntax keyword is no longer much of an issue. At the least we could have a standard library that redefines the standard keywords lambda, let, ... etc to versions that support patterns. Exactly. The biggest issue appears to be define. Changing define to have the syntax: (define pattern expression) Why wouldn't it be (define (name . pattern) expression)? A define without an identifier being defined doesn't make much sense to me. (begin (def var1 exp1) ;; OR: (::= var1 exp1) etc (def var2 exp2) (def varn expn) Reading 'define' for 'def', this looks like R5RS to me. We only use 'let' out of habit, really; nine times out of ten, the definitions are independent, and any of 'let', 'let*', 'letrec', or internal 'define' (aka 'letrec*') will work. -- John Cowan co...@ccil.orghttp://ccil.org/~cowan No man is an island, entire of itself; every man is a piece of the continent, a part of the main. If a clod be washed away by the sea, Europe is the less, as well as if a promontory were, as well as if a manor of thy friends or of thine own were: any man's death diminishes me, because I am involved in mankind, and therefore never send to know for whom the bell tolls; it tolls for thee. --John Donne ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Scheme pattern matching R*RS
Jim Wise scripsit: Are there plans to include explicit pattern matching operations, such as Common Lisp's DESTRUCTURING-BIND or Racket's match[1]? We don't work in terms of plans, but in terms of proposals, and right now there are no concrete proposals. If you put together a concrete proposal (doesn't have to be detailed, just clear) and send it to me, I will be happy to post it for WG consideration. -- John Cowanco...@ccil.orghttp://ccil.org/~cowan There was an old manSaid with a laugh, I From Peru, whose lim'ricks all Cut them in half, the pay is Look'd like haiku. He Much better for two. --Emmet O'Brien ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Scheme pattern matching R*RS
John Cowan co...@mercury.ccil.org writes: Jim Wise scripsit: Are there plans to include explicit pattern matching operations, such as Common Lisp's DESTRUCTURING-BIND or Racket's match[1]? We don't work in terms of plans, but in terms of proposals, and right now there are no concrete proposals. If you put together a concrete proposal (doesn't have to be detailed, just clear) and send it to me, I will be happy to post it for WG consideration. I'd be willing to cull the list discussion as a proposal, if there seems to be a common thread. Are there any details on what's wanted in such a proposal? Or just the discussion on the list? Any standard formatting? FWIW, racket provides the following in its racket/match library: (match val (pattern body) ...) (match* (val ...) ((pattern ...) body) ...) and derivative forms (match-lambda (pattern body) ...) (match-lambda* (pattern body) ...) (match-let ((pattern expr) ...) which are equivalent to (lambda (x) (match x (pattern body) ...) (lambda l (match l (pattern body) ...) ((lambda (x ...) (match* (x ...) (pattern body) ...)) expr ...) and (match-let* ((pattern expr) ...) (match-letrec ((pattern expr) ...) Optionally, a second module could re-export match-lambda* as `lambda', though I'm not sure is needed (it should certainly be possible to use the matching module without getting this). Common Lisp's DESTRUCTURING-BIND is provided here by match-let. What pattern matching capabilities do other Scheme(-like)s provide? -- Jim Wise jw...@draga.com pgpYJtVJcGFO3.pgp Description: PGP signature ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Scheme pattern matching R*RS
Jim Wise jw...@draga.com writes: and derivative forms (match-lambda (pattern body) ...) (match-lambda* (pattern body) ...) (match-let ((pattern expr) ...) which are equivalent to (lambda (x) (match x (pattern body) ...) (lambda l (match l (pattern body) ...) ((lambda (x ...) (match* (x ...) (pattern body) ...)) expr ...) and (match-let* ((pattern expr) ...) (match-letrec ((pattern expr) ...) accidentally snipped ``which are equivalent to appropriately nested match-lambda* expressions.''. -- Jim Wise jw...@draga.com pgpC49ZpYho2D.pgp Description: PGP signature ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Scheme pattern matching R*RS
Jim Wise scripsit:
I'd be willing to cull the list discussion as a proposal, if there seems
to be a common thread. Are there any details on what's wanted in such a
proposal? Or just the discussion on the list? Any standard formatting?
Take a look at http://trac.sacrideo.us/wg/wiki/ArraysCowan for a sample.
The markup is ''...'' for italics and `...` for monowidth font. An
example should be preceded by a line containing just {{{, and followed
by a line containing just }}}. But if this is too much trouble, I can
insert the markup later.
--
The experiences of the past showJohn Cowan
that there has always been a discrepancyco...@ccil.org
between plans and performance. http://www.ccil.org/~cowan
--Emperor Hirohito, August 1945
___
r6rs-discuss mailing list
r6rs-discuss@lists.r6rs.org
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Scheme pattern matching R*RS
On 12/14/2010 06:44 AM, John Cowan wrote: The biggest issue appears to be define. Changing define to have the syntax: (definepattern expression) Why wouldn't it be (define (name .pattern)expression)? A define without an identifier being defined doesn't make much sense to me. I was thinking in terms of the patterns based on: http://download.plt-scheme.org/doc/372/html/mzlib/mzlib-Z-H-27.html#node_chap_27 I.e. where (var1 var2 var3) is a valid pattern matching a 3-element list. This syntax for patterns has the advantage that it is a generalization of syntax-rules patterns, in addition to being natural and compact. In that case, how do you distinguish: (define (function-name param1 param2) expression) from (define (var1 var2 var3) expression) (begin (def var1 exp1) ;; OR: (::= var1 exp1) etc (def var2 exp2) (def varn expn) Reading 'define' for 'def', this looks like R5RS to me. We only use 'let' out of habit, really; nine times out of ten, the definitions are independent, and any of 'let', 'let*', 'letrec', or internal 'define' (aka 'letrec*') will work. Right - but if we used a short keyword and added support for patterns, that would help encourage this style, which I think would be an improvement. -- --Per Bothner p...@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
Re: [r6rs-discuss] Scheme pattern matching R*RS
John Cowan co...@mercury.ccil.org writes:
Jim Wise scripsit:
I'd be willing to cull the list discussion as a proposal, if there seems
to be a common thread. Are there any details on what's wanted in such a
proposal? Or just the discussion on the list? Any standard formatting?
Take a look at http://trac.sacrideo.us/wg/wiki/ArraysCowan for a sample.
The markup is ''...'' for italics and `...` for monowidth font. An
example should be preceded by a line containing just {{{, and followed
by a line containing just }}}. But if this is too much trouble, I can
insert the markup later.
Sounds good -- I'll see what I can put together over the next day or two
(or longer if the discussion on the list seems to be diverging).
Thanks,
--
Jim Wise
jw...@draga.com
pgpjPmw8eAIdI.pgp
Description: PGP signature
___
r6rs-discuss mailing list
r6rs-discuss@lists.r6rs.org
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Scheme pattern matching R*RS
On Tue, Dec 14, 2010 at 12:45 PM, Per Bothner p...@bothner.com wrote: I was thinking in terms of the patterns based on: http://download.plt-scheme.org/doc/372/html/mzlib/mzlib-Z-H-27.html#node_chap_27 That documentation is very old, from December 2007. The current documentation for `match' is here: http://docs.racket-lang.org/reference/match.html -- sam th sa...@ccs.neu.edu ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Scheme pattern matching R*RS
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: lambda;
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
p...@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
___
r6rs-discuss mailing list
r6rs-discuss@lists.r6rs.org
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Scheme pattern matching R*RS
On 12/14/2010 09:48 AM, Sam Tobin-Hochstadt wrote: On Tue, Dec 14, 2010 at 12:45 PM, Per Bothnerp...@bothner.com wrote: I was thinking in terms of the patterns based on: http://download.plt-scheme.org/doc/372/html/mzlib/mzlib-Z-H-27.html#node_chap_27 That documentation is very old, from December 2007. The current documentation for `match' is here: http://docs.racket-lang.org/reference/match.html I was deliberately linking to the very old documentation, because it has the property that (var1 var2 var3) is a valid pattern matching a 3-element list. If I'm reading the newer documentation right, it requires you to write (list var1 var2 var3), which seems highly undesirable for a standard (built-in) pattern language, and is incompatible with syntax-rules. -- --Per Bothner p...@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
Re: [r6rs-discuss] Scheme pattern matching R*RS
On Tue, Dec 14, 2010 at 1:09 PM, Per Bothner p...@bothner.com wrote: On 12/14/2010 09:48 AM, Sam Tobin-Hochstadt wrote: On Tue, Dec 14, 2010 at 12:45 PM, Per Bothnerp...@bothner.com wrote: I was thinking in terms of the patterns based on: http://download.plt-scheme.org/doc/372/html/mzlib/mzlib-Z-H-27.html#node_chap_27 That documentation is very old, from December 2007. The current documentation for `match' is here: http://docs.racket-lang.org/reference/match.html I was deliberately linking to the very old documentation, because it has the property that (var1 var2 var3) is a valid pattern matching a 3-element list. If I'm reading the newer documentation right, it requires you to write (list var1 var2 var3), which seems highly undesirable for a standard (built-in) pattern language, and is incompatible with syntax-rules. You are reading the documentation correctly. The documentation for the legacy behavior is here: http://docs.racket-lang.org/mzlib/mzlib_match.html However, I think that the newer syntax is better. First, symmetry between lists and other data structures is a good idea. Second, requiring `list' makes the syntax extensible. For example, in Racket currently, structure patterns can be used simply with the constructor name. In the old syntax, that would be ambiguous. Additional, Racket support extensible pattern matching, which would again be ambiguous. Finally, there's no reason that this couldn't be implemented with `syntax-rules' and there's no reason for this to be a design concern given that R6RS supports procedural macros. -- sam th sa...@ccs.neu.edu ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Scheme pattern matching R*RS
Per Bothner scripsit: I.e. where (var1 var2 var3) is a valid pattern matching a 3-element list. This syntax for patterns has the advantage that it is a generalization of syntax-rules patterns, in addition to being natural and compact. Ah, I see. I think that the natural extension of define is to allow it to define a single named pattern-matching procedure rather than allowing it to define multiple names simultaneously. In that case, how do you distinguish: (define (function-name param1 param2) expression) from (define (var1 var2 var3) expression) The former is the only meaning, but with pattern-matching define you may also write (define (foo (v1 v2) v3) ...) to define a procedure which accepts two arguments, the first of which is a two-element list. -- John Cowan co...@ccil.org Not to know The Smiths is not to know K.X.U. --K.X.U. ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Scheme pattern matching R*RS
John Cowan co...@mercury.ccil.org writes:
Jim Wise scripsit:
I'd be willing to cull the list discussion as a proposal, if there seems
to be a common thread. Are there any details on what's wanted in such a
proposal? Or just the discussion on the list? Any standard formatting?
Take a look at http://trac.sacrideo.us/wg/wiki/ArraysCowan for a sample.
The markup is ''...'' for italics and `...` for monowidth font. An
example should be preceded by a line containing just {{{, and followed
by a line containing just }}}. But if this is too much trouble, I can
insert the markup later.
Okay, I've begun putting this together. For reference, I'm looking at:
* the thread so far on in this list and the wg* lists
* the pattern matching implementations provided with Bigloo, Chicken
Scheme, and Racket
* R6RS case and syntax-case
* the platform-independent pattern matching library described by
Andrew K. Wright and Bruce F. Duba in the paper ``Pattern Matching
for Scheme''
* Common Lisp's DESTRUCTURING-BIND macro
what else should I be looking at? What other scheme implementations
provide pattern matching support?
Thanks,
--
Jim Wise
jw...@draga.com
pgpIn2bSoKLqP.pgp
Description: PGP signature
___
r6rs-discuss mailing list
r6rs-discuss@lists.r6rs.org
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Scheme pattern matching R*RS
On Tue, Dec 14, 2010 at 4:58 PM, Jim Wise jw...@draga.com wrote: * R6RS case and syntax-case `syntax-parse' by Ryan Culpepper, as described here: http://docs.racket-lang.org/syntax/stxparse.html and here: http://www.ccs.neu.edu/scheme/pubs/#icfp10-cf -- sam th sa...@ccs.neu.edu ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Scheme pattern matching R*RS
Per Bothner scripsit: There is SRFI 16's case-lambda, but it's pretty simple. Case-lambda is on the table for WG1, and I expect it will most likely pass. That means that if R7RS supports optional arguments then the following (or something functionally equivalent) should be a valid pattern: (a b #!optional c (d 10)) Both optional arguments and keyword arguments will be WG2 modules, but I don't expect that DSSSL keywords will be the syntax, as that was the bottom-ranked choice in the WG1 vote. Also, a question to ponder: For implementations that provide some kind of abstract sequence type that is (at least) a superset of both list and vector: They might want to allow a list pattern to match either a sequence or vector. Not perhaps directly relevant to R7RS standardization, unless we're considering abstract sequences types for R7RS, but note that is a direction some of us might like to move towards. Generic sequences were voted down by WG2. -- John Cowanco...@ccil.org At times of peril or dubitation, http://www.ccil.org/~cowan Perform swift circular ambulation, With loud and high-pitched ululation. ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Scheme pattern matching R*RS
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: lambda; In my Emacs v23 (Ubuntu Linux), this letter resolved to l (as did the *LAMDA version), not something like 흺 . How did you try to input it? In my emacs (23 on FreeBSD), C-8 enter 03bb did insert the GREEK SMALL LETTER LAMDA properly In vim, C-K l * and C-V U 03bb both input the lambda properly. It looks like λ. However, I do not know how easy it is to input on other systems. If the greek letter was to replace the ASCII letters combination lambda, it would make teaching Scheme to freshmen problematic, as many of them use notepad or some similar unsuited tool for typing code, on some operating system that does not care about X.org. I doubt it's easy to input a greek lambda in most cases. Though not as cool, maybe there should be a possibility to have reader macros or something like that, to allow an alternative input of these symbols? I think that haskell's \ for lambda is, well, not that bad a way around the problem. I also think that APL should not be our ultimate objective. Cheers, P! -- Français, English, 日本語, 한국어 ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] Scheme pattern matching R*RS
On 12/12/2010 04:09 PM, John Cowan wrote: Working Group 2 has decided that an optional pattern matching module will be part of R7RS. To win pattern-matching really should be the default and integrated into the language core, rather than an optional module that uses separate keywords. E.g. there shouldn't be a difference between lambda and match-lambda*. The latter is too verbose! For example R6RS defines lambda as: (lambda formals body) Could we change it to: (lambda pattern body) where pattern could be based on pat in match.ss: http://download.plt-scheme.org/doc/372/html/mzlib/mzlib-Z-H-27.html#node_chap_27 True, there will be be some complications and incompatibilities, with R6RS and possibly with implementations that don't support patterns. At the least we could have a standard library that redefines the standard keywords lambda, let, ... etc to versions that support patterns. The biggest issue appears to be define. Changing define to have the syntax: (define pattern expression) conflicts with: (define (function formals) body) I don't see a safe way to generalize define to handle patterns in way that existing code will work. So I think we need a new keyword - but I'm hoping for something shorter than match.ss's match-define - preferably something even shorter than define. Perhaps one of: (def pattern expression) (::= pattern expression) Related: The traditional let makes for a lot of parentheses, which perhaps contributes to the Scheme-turn-off. Perhaps instead of: (let* ((var1 exp1) (var2 exp2) (varn expn)) bexp1 bexpn) perhaps the above should be discouraged and this style be recommended instead: (begin (def var1 exp1) ;; OR: (::= var1 exp1) etc (def var2 exp2) (def varn expn) bexp1 bexpn) Even more valuable than improved readability is that it makes the code more robust to changes: You can add, remove, and move variable definitions without having to add/remove let-blocks and changing indentation levels. -- --Per Bothner p...@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
Re: [r6rs-discuss] Scheme pattern matching R*RS
Peter Kourzanov scripsit: Hence my question: what is the state of pattern matching in Scheme? Are there ideas to move this forward, or are we, the poor users, left to live with incompatible pattern matching interfaces and implementations? Working Group 2 has decided that an optional pattern matching module will be part of R7RS. Just to mention a few: Bigloo's match-case, PLT/Racket match.ss variants and many more. If you care to do some work preparing one or more proposals either based on these, or on something else, or on suitable combinations of them, you will get much love from the WG. Just send it to me, and I will post it for WG2's consideration. -- He played King Lear as though John Cowan co...@ccil.org someone had played the ace. http://www.ccil.org/~cowan --Eugene Field ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
