Lambda the Ultimate

inactiveTopic Algebraic patterns in Scheme
started 10/1/2002; 12:21:49 AM - last post 10/3/2002; 6:25:05 AM
Ehud Lamm - Algebraic patterns in Scheme  blueArrow
10/1/2002; 12:21:49 AM (reads: 2695, responses: 5)
Algebraic patterns in Scheme
Eli Barzilay is doing some cool things with Scheme. His latest hack is extending Scheme with pattern matching (a la ML).


> (map (lambda ((list x y)) (list y x)) '((1 2) (3 4)))
((2 1) (4 3))

Posted to functional by Ehud Lamm on 10/1/02; 12:21:59 AM

jon fernquest - Re: Algebraic patterns in Scheme  blueArrow
10/2/2002; 2:10:57 AM (reads: 962, responses: 0)
> the intention is for ML-like patterns that have the
> same syntax as the constructors.

Combined with pattern matching on input arguments (like Haskell guards) you'd really get more concise and meaningful Scheme code.

Scheme proves once again is capable of morphing itself semantically into different languages (e.g. Olin Shiver's Awk) while keeping its s-expressions syntax constant.

Luke Gorrie - Re: Algebraic patterns in Scheme  blueArrow
10/2/2002; 11:47:48 AM (reads: 941, responses: 1)
There's a bit of a downside of language extensions vs. integrated languages features though, I think. If we accept for the moment that pattern matching makes programs more concise and meaningful, then we can get that benefit from using these macros. But still - most Scheme programs _won't_ use them, and thus won't get the benefit. On the other hand, the ML programs will get the advantage, because in ML you do use pattern matching.

NB: There are several other pattern matching macro packages around for Scheme, but I've never seen them used in a program (not that I've seen that many scheme programs). I've considered using them once or twice, but decided to keep my code more "idiomatic" in the end, even though I do love pattern matching in my Erlang programs.

But perhaps Real Men should just use all the language extensions they like, and I'm just a wimp :-)

Ehud Lamm - Re: Algebraic patterns in Scheme  blueArrow
10/2/2002; 1:11:13 PM (reads: 984, responses: 0)
This is simliar to the problem with reuse. Finding the right module for your needs is such a pain, it is often chaper to write something new from scratch.

Or in this case: Using standard language features is chaper than finding a useful language extension.

By the way, these two angle combine: that why languages provide standard libraries.

jon fernquest - Re: Algebraic patterns in Scheme  blueArrow
10/3/2002; 3:34:10 AM (reads: 901, responses: 0)
> There's a bit of a downside of language extensions vs. integrated languages features.........

The distinction between language extension and language feature is hard to make in Scheme. Hygienic macros are a feature that the language is even defined in, but you usually have to install SLIB to get a working version of them. They're turned off by default in Bigloo, because they are too slow.

Is there really a standard Scheme, Scheme is more like a family of related standards that are often hard to get to work together.

The record extension is absolutely essential for EOPL and SLIB is the best to get it in an implementation neutral way and in EOPL2 there's a new abstract data type that seems to be absolutely essential. If you look at the Guile cookbook code at PLEAC you'll see that Guile makes extensive use of the SRFI's for lists, strings, dates and times, etc.

There is nothing in the syntax that clearly marks the pattern matching, so mixed in with standard code it will probably cause confusion and panic....I think.

If I didn't know there was pattern matching lurking in that example code I .....I.....would have rewritten it with cars and cdrs.

> There are several other pattern matching macro packages around for Scheme

A comparison would be nice.
I'll re-read their papers and post them to Scheme.

But I still think there's a programming ideal lurking in ML and Haskell pattern matching that Scheme could assimilate:

When you program with these in ML or Haskell it's like *the function has no inside*, which has to be the *ultimate in refactoring code*, giving the smallest possible idea embodied in the abstraction of a function. No car'ing and cdr'ing data out of a cons structure in some gigantic hard to unravel cond (itional).

> But perhaps Real Men should just use all the language extensions they like, and I'm just a wimp :-)

I think the Real Men are the ones who write them. Have you tried reading the implementation code? Eegads, can I refactor it into something I can understand.

I used to lurk and listen in on all the discussions on comp.lang.scheme about how Scheme should be abandoned for the strong typing of ML.

My philosophy: before you just dump something, you should see if you can do what you are moving to (ML) in or with what you already have (Scheme).

And Scheme is the only language that I know of that just continues and continues and continues, continually branching off extensions, trying to bring all paradigms and new ideas under its fold, that's probably why Stallman chose it for Guile the GNU scripting/extension language (and Photoshop-like GIMP ) and that's why I'm glad Scheme is sprouting a new ML head to complement its many other beautiful faces.

I know Haskell and ML syntax are a lot more suited to types and pattern matching nowadays, but a couple years from now we'll probably all be programming with customized notations/fonts (using TeX or some MS Intentional Programming system) or diagrams out of category theory and reading any sort of textual syntactical representation of a program will be asking someone to read the machine code generated by their program or the printout from a core dump.

I also wonder whether there could be a language that was a neutral medium for other language, that is programs in that language could be translated into equivalent programs in other languages, perhaps even in other paradigms.....and also translated back (roundtrip) preserving meaning.

Luke Gorrie - Re: Algebraic patterns in Scheme  blueArrow
10/3/2002; 6:25:05 AM (reads: 912, responses: 0)
Seems strange that it's hard to implement, maybe they're doing something fancy. I did Erlang-style pattern matching in Emacs Lisp in 173 lines of very simple code, much like in Paradigms of AI Programming. I use that all the time in one particular program that's large enough to justify its own programming style, but probably never will in any others.

If you're curious, my pattern matcher is at

The beautiful thing about using Emacs Lisp is that you get a guilt-free 'eval' :-)