Saturday, January 14, 2006

learning to read papers: why calculating is better than scheming

I just finished reading Why calculating is better than scheming, and it's good stuff. But I get the feeling that I'll need to read a lot more papers to get up to date with programming languages.

One thing that bothers me occassionally is this: I don't think I know enough about programming language theory yet to talk with specialists about it. So there's an isolating feeling I get about reading early papers, because I think it's cool stuff, and yet it's probably so elementary that everyone else is so beyond it already.

But, despite all these being elementary, I still do want to write what I'm getting out of reading these papers, just in case I make conclusions that are absolutely wrong. If it's public, then there's still some chance that someone out there can correct me. *grin* So here goes...

A few of the critiques made in Wadler's paper are addressed in PLT Scheme. For example, pattern-matching does exist in a library. The sum Miranda code in the paper:



sum [] = 0
sum (x:xs) = x + sum xs



can be written in PLT Scheme as:


(require (lib "plt-match.ss"))
(define sum
(match-lambda
((list) 0)
((list-rest x xs) (+ x (sum xs)))))



though this also brings up a point about syntax: the Miranda code does use an appealing syntax, whereas everything in Lisp is an s-expression. Syntax is also an issue, though I think Wadler discounts too much the role of macros in Lisp-like languages.

The points for a type discipline seem fair, and I suspect a proper use of MrFlow would catch the same kind of mistakes that a static type system would catch. (Though I don't know yet: I haven't played with MrFlow seriously.)


Wadler's term "free data types" goes over my head slightly. *grin* Concretely in terms of Scheme, I think he's trying to say that equal? only works on s-expressions, and that trying to do equal? on arbitrary compound data might not work because we're never sure what the choice of representation is.

Does PLT Scheme's structure and inspector support meet the requirements of free data type definition? It seems to me that:


;; a structure is either a Weight or a Mobile.
(define-struct Weight (n) (make-inspector))
(define-struct Mobile (left right) (make-inspector))

(define-struct Branch (length structure) (make-inspector))


could also be considered a way to define free data types, though I'm probably missing something subtle.

Anyway, better stop now and sleep.