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