Who's minister of propaganda this week?

[Alex Martelli]

"Marcin 'Qrczak' Kowalczyk" <qrczak at knm.org.pl> wrote in message
news:slrn9bbin2.11r.qrczak at qrnik.zagroda...
    [snip]
> Design patterns designed for C++ and Java are not applicable to
> languages which use algebraic types and don't use subtyping. C++
> and Java don't have a convenient way to express "either this or that
> or these" (wrapping each case in a class is not convenient enough).
> 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?  (And
the "O" in O'Haskell too, but you're not addressing that one).


> 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, ...).  In Java, objects can never be
truly unrelated, as they all derive from a common ancestor (Object);
thus, you can always hold anything through a reference to Object, and
try casting (which will fail with a predictable, catchable exception
if need be) to obtain usable interfaces.  The exact C++ translation
is not standard, as dynamic_cast<> with a void* argument need not be
implemented by all standard C++ compilers, so, you _do_ need to
explicitly provide some 'remote relation' on which dynamic_cast<>
can be portably applied (that 'relation' need not DO anything, just
as the interface used in 'Acyclic Visitor' doesn't -- as long as it
has SOME virtual, typically a virtual destructor, dynamic_cast<>
will work).


> Tell what do you really want to archieve. The whole thing looks like
> a poor fit to the style of these languages. You don't want to have a
> net of containers of everything. For example if they are registered

I'm not going to retype the whole relevant section of "Design
Patterns" -- please look it up for yourself.  Again, there is
pronominal ambiguity in the "these".  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,
because of the language limitations imposed by the desire to
allow static type-checking.

> to let somebody do something with them, you would rather register
> "do something with them" actions instead of objects themselves.
> Objects are rarely mutable so even this looks very suspicious.

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

Python allows and strongly encourages object-oriented programming,
as do other languages which implement compile-time static type
checking.  Haskell (as opposed to O'Haskell) doesn't; O'Caml, to
the extent that it does, also introduces ref/mutability and
other complexities.

Debating the need/opportunity for static/dynamic typing in
languages that focus on FP, not O-O, may no doubt be quite
interesting (I keep thinking that Erlang's real-world success,
and the huge boost it gives to programmer productivity, may
have something to do with its being dynamically typed albeit
in an FP context) but has precious little to do with this
thread, or with any language lacking such an FP focus.


Alex