Who's minister of propaganda this week?

Marcin 'Qrczak' Kowalczyk qrczak at knm.org.pl
Mon Mar 19 17:05:44 CET 2001

Mon, 19 Mar 2001 13:19:22 +0100, Alex Martelli <aleaxit at yahoo.com> pisze:

> > OTOH Haskell and OCaml don't work by implicit coercion of elements
> > to a common supertype.
> Isn't that what the "O" in O'Caml adds to plain good old Caml?

Well, coercion upwards is explicit, but it's not as often as in C++ or
Java because functions generally accept "object of any type providing
these methods of these types" instead of "object coerced to the class
which declares these methods".

There is no coercion downwards (except unsafe Obj.magic) nor typecase.

The class system is rarely used. The module system, higher order
functions or algebraic types are often more appropriate and better
fit the rest of the language. There is "O" in the language, but in
practice it often doesn't matter.

> > Note that in these languages it's meaningless to mix all types of
> > objects together in a container. If they are unrelated, you can't
> > apply any operation to an unspecified member of them.
> Not sure if by "these" you mean, here, "the former" (C++, Java, ...)
> or "the latter" (ML, Haskell, ...).

ML, Haskell.

> Assuming now that by 'these' you mean 'Haskell' (or ML or Caml
> without the 'O'), it's not true that I don't _want_ to built
> heterogeneous, structured containers -- it's that I _can't_ do
> it conveniently,

It's both.

> because of the language limitations imposed by the desire to allow
> static type-checking.

I don't call this a limitation. You could embed a complete Python-like
object model in Haskell or ML. Python's classes won't correspond
to types in Haskell or ML, but to values, with explicit method
dictionaries etc.

Syntax might be a bit awkward, and the library would have to be
adapted, but in can be done. High level functional languages are
especially convenient in building a sublanguage with its own rules
inside them. Although I don't think that anybody would make a totally
isolated object model, because of necessary glue with the rest of

Viewed from that point, it's not a limitation wrt. Python's model,
but an extension.

> Objects are rarely mutable _in functional programming_ -- they
> are commonly mutable _in object oriented programming_, and this
> makes a very substantial difference.

What about object oriented functional programming?

I guess they are often immutable, as opposed to functional object
oriented programming :-)

 __("<  Marcin Kowalczyk * qrczak at knm.org.pl http://qrczak.ids.net.pl/
  ^^                      SYGNATURA ZASTĘPCZA

More information about the Python-list mailing list