Re: Python / Haskell (fwd)

[Forwarded to this list with Phil Wadler's permission.]
Philip Wadler <wadler@research.bell-labs.com> wrote: Well, what I most want is typing. But you already know that. 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]. 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. On the other hand, with disjoint sums it is hard to add a new shape, unless you modify all the existing switch statements for shapes. This is a well-known tradeoff, see e.g., the discussion in my paper with Odersky on Pizza, or the ECOOP 98 paper by Felleisen and Krishnamurthi. [GVW: the Pizza paper is available from: http://cm.bell-labs.com/cm/cs/who/wadler/topics/gj.html The Felleisen and Krishnamurthi paper is at: http://www.cs.rice.edu/CS/PLT/Publications/#tr98-299 ]

[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>.
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).
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)

[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>.
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).
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