(resend <- actually, it works even better with plain text i.s.o. HTML)
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 Unicode, otherwise imagine a lambda
where you see 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
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.
_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
