Per, et.al.,
I am completely with you on this - we need a shorter form for lambda. 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 using MATHEMATICAL SANS-SERIF BOLD SMALL
LAMDA).
(I hope your mail client can render HTML, otherwise imagine a lambda
where you garbage:)
________________________________________________________________________
(map (𝝺 x => (f x)) list)
________________________________________________________________________
However, that would depend on native reader supporting Unicode (like
Bigloo, where this
example was tested). Are there any Schemes that still matter and don't
support Unicode
natively?
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)
________________________________________________________________________
(define interleave
(𝝺 () () -> ()
❘ (x . xs) (y . ys) =>
(cons x (cons y (interleave xs ys)))))
________________________________________________________________________
(the distinction between -> and => being implicit quasiquote around the
body)
So lets keep the (define (fun args ...) body ...) for for
non-pattern-matching functions. And use
(define fun (𝝺 pattern => body)) for pattern-matching. That should
remove a lot of complexity
from the spec.
About (let) I am actually for a complete replacement with
pattern-matching semantics. It is a
simple matter to detect if pattern matching is used with (let): is there
a single symbol naming
a binding or a more complex structure? It can be done simply with
syntax-rules, even.
As always, I welcome comments, feedback, etc.
Regards,
Pjotr Kourzanov
On Mon, 2010-12-13 at 16:46 -0800, Per Bothner wrote:
> 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.
_______________________________________________
r6rs-discuss mailing list
r6rs-discuss@lists.r6rs.org
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
