[Python-Dev] Re: Python / Haskell (fwd)
Tim Peters
tim_one@email.msn.com
Wed, 1 Mar 2000 02:36:03 -0500
[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)