Re: Python / Haskell (fwd)
[Forwarded to this list with Phil Wadler's permission.]
Greg Wilson wrote: Hi, Phil. I was talking to a couple of colleagues over the weekend, one of whom learned Miranda as his second language and never really recovered :-). I was wondering: if you could add one or two features of Haskell to Python, what would you choose? And why?
Philip Wadler
[Greg Wilson, quoting Philip Wadler]
Well, what I most want is typing. But you already know that.
So invite him to contribute to the Types-SIG <0.5 wink>.
Next after typing? Full lexical scoping for closures. I want to write:
fun x: fun y: x+y
Not:
fun x: fun y, x=x: x+y
Lexically scoped closures would be a big help for the embedding technique I described [GVW: in a posting to the Software Carpentry discussion list, archived at
http://software-carpentry.codesourcery.com/lists/sc-discuss/msg00068.html
which discussed how to build a flexible 'make' alternative in Python].
So long as we're not deathly concerned over saving a few lines of easy boilerplate code, Python already supports this approach wonderfully well -- but via using classes with __call__ methods instead of lexical closures. I can't make time to debate this now, but suffice it to say dozens on c.l.py would be delighted to <wink>. Philip is understandably attached to the "functional way of spelling things", but Python's way is at least as usable for this (and many-- including me --would say more so).
Next after closures? Disjoint sums. E.g.,
fun area(shape) : switch shape: case Circle(r): return pi*r*r case Rectangle(h,w): return h*w
(I'm making up a Python-like syntax.) This is an alternative to the OO approach. With the OO approach, it is hard to add area, unless you modify the Circle and Rectangle class definitions.
Python allows adding new methods to classes dynamically "from the outside" -- the original definitions don't need to be touched (although it's certainly preferable to add new methods directly!). Take this complaint to the extreme, and I expect you end up reinventing multimethods (suppose you need to add an intersection(shape1, shape2) method: N**2 nesting of "disjoint sums" starts to appear ludicrous <wink>). In any case, the Types-SIG already seems to have decided that some form of "typecase" stmt will be needed; see the archives for that; I expect the use above would be considered abuse, though; Python has no "switch" stmt of any kind today, and the use above can already be spelled via if isinstance(shape, Circle): etc elif isinstace(shape, Rectange): etc else: raise TypeError(etc)
participants (2)
-
gvwilson@nevex.com
-
Tim Peters