On Fri, 2010-12-17 at 00:52 -0800, Per Bothner wrote:
> > (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.
There is no such thing as separator for (let), since pattern matching
inside it implies that all patterns must match.
> I'm not sure that works all that well:
>
> (match <val>
> <pat> <body> <body> ...
> | <pat> <body> <body> ...
> ...)
I would like it to support also:
(match <val>
| <pat> <body> <body> ...
| <pat> | <pat> => <body> <body> ...
...)
besides:
(match <val> <pat> <body> <body> ...)
I think its easy to check if there are no forms between <val> and |.
So, (match) should be the same as (case). In some implementations, its
already called match-case;-)
>
> 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.
This could be workable. Alternatively, Unicode way should be supported
too (with LIGHT-VERTICAL-BAR).
>
> > 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.
Why? Isn't Scheme syntax supposed to be malleable? I am clearly not
extending semantics much by adding a => or ->. We can consider these
as visual aids that help navigating through all these parentheses
(the problem is getting much bigger of course with more stuff added to
either of the three blocks in each rule):
(lambda (x y) (> x 1) (list y x)
(x y) #t (list x y))
In addition, you are not getting abbreviations this way - all 3 parts
(pattern, guard, expansion) must be given. And the body must always be
just one expression... forsaking compatibility to original lambda.
So, to keep pattern-matching lambda compatible to original lambda, some
syntactic dispatch is direly needed.
Moreover, hasn't => in (cond) and (case) been added for exactly the same
reason (albeit a little more implicit one)? In pattern matching, we
are doing binding of pattern variables, much the same way as we are
getting a binding for the result of the predicate in (cond).
> 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".
It could be. I have to say that I am both attracted to Scheme semantic
minimalism and to Scheme syntax malleability, neither of which I find in
other functional languages. So I could live with more verbose proposals,
as long as all of the stuff I need can be expressed as syntax.
Most other users, however, are probably just keen on expressing their
programs in the simplest way possible, which, we all have to admit, is
not exactly the primary appeal of Scheme as it stands right now.
> 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.)
Thanks for the link, although I am not a particular fan of indent-based
syntax.
Regards,
Pjotr
_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
