Typing system vs. Java

Michael Abbott michael at rcp.co.uk
Tue Jul 31 04:56:29 EDT 2001


Jonathan Hogg <jonathan at onegoodidea.com> wrote in news:jonathan-
D4822F.08343331072001 at news.easynet.co.uk:

> I can though, think of plenty of places where strong static typing would 
> defeat intentional exploitation of the dynamic typing. Maybe this is 
> poor programming on my part, but I can't even think how one would type a 
> function like say:
> 
>    def f(zs): return reduce( lambda x, y: x + y, zs )
> 
> Python's dynamic typing has the most optimal type for this function:
> 
>    "A function that takes something looking like a sequence of
>     things that you can call "+" on, and returns something that
>     you might get back by "+"ing a bunch of such things together."
> 
> I just don't ever see Python with a static type system. What's more I 
> don't think I'd want it. If you want static types then code in something 
> else. If you find Java/C++ too horrific, then I'd seriously recommend 
> O'Caml - though this is just from a cursory look, I did most of my FP in 
> Haskell but I don't think I could recommend it unless you're willing to 
> become a serious FP-head and want to get to grips with Monads ;-)

Interesting example.  I for one would like to see a strongly typed variant 
of Python: if for nothing else, I'd like to be able to compile my code.

Giving your function a type really boils down to giving the function + a 
type, doesn't it?  In Haskell, I guess we could type f thus:

    	f :: Num a => [a] -> a

but this is perhaps a little unsatisfactory, since the type a is then 
required to support all the other numeric operations as well.

It would be nicer to be able to, for example, define:

    	class SemiGroup a where
    	    (+) :: a -> a -> a

    	f :: SemiGroup a => [a] -> a

but this seems both clunky and really a bit misleading (since we don't 
actually require the + we're using to be associative).

It's probably a good start to look at the type of reduce.  This is easy 
enough in Haskell:

    	reduce :: (a -> a -> a) -> [a] -> a

(need to cook up a more Python friendly syntax for this).

Ok, so the real problem is this: what is the type of + ?!

In Haskell, + is definitely of type

    	(+) :: Num a => a -> a -> a

which simply means that it is a member of the class Num (which also 
contains -, * and some other stuff; seems to be an ordered Ring) and is a 
binary operation which returns a value of the same type as its arguments.

The Haskell type model is too restrictive for Python, particularly since it 
is not possible for any global name to have more than one type (so, for 
example, we can *only* use + to name a method of the Num class).  However, 
I do think that some of the principles of Haskell typing can be profitably 
applied to Python.

Let me just observe this: statically typed Python would need to be a 
different language from standard Python, though hopefully close enough to 
interoperate and have the same name.


Can anyone comment on the current status of ideas for statically typing 
Python?  The SIG mailing list is only carrying spam at the moment, and 
several of the SIG links are broken, so things don't look promising...



More information about the Python-list mailing list