Why does Dynamic Typing really matter?!?

Donn Cave donn at drizzle.com
Thu Feb 6 23:18:46 EST 2003


Quoth Jp Calderone <exarkun at intarweb.us>:
| On Fri, Feb 07, 2003 at 12:36:24AM +0000, Alex Martelli wrote:
|> Jeremy Fincher wrote:
|> > [snip]
|> How much signature based polymorphism does the language
|> support?  That is one key question.  Haskell potentially offers a
|> lot, if you get your typeclasses right; various ML dialects offer
|> less, or none at all -- not supporting the concept of "classes of
|> types" (Haskell's typeclasses), they thereby don't let functions
|> you code be all that generic (except maybe in a few limit cases
|> such as SML supporting + on both floats and ints by special
|> casing). =20
|
|   Jeremy probably knows better than I, but doesn't Caml support a similar
| system to Haskell's typeclasses?  I forget the name, but something to effect
| of ...
|
|   type <symbol> =3D
|     <name0> of <type0>
|   | <name1> of <type1>
|   | ...;
|
|   Once upon a time, I wrote a serializer in Caml, and I used these to write
| generic functions for groups of types.

Variants - you'd use them to define a set of types over which a
function should be defined, but it's a different way to approach
the problem than Haskell's classes.  In my very inexpert guess,
it might work out about the same in terms of lines of code, but
Haskell's type classes are extensible.  If lots of people were
using your serializer for one thing and another, I'd guess they
would be coming back to you for every new case and asking you to
add | <name122> of <type122> etc. to that type, and possibly their
support functions also.

With type classes, it's up to them to make their new type an
"instance" of your class and define the necessary functions.

The Caml version could probably be designed to do the same thing,
but not as transparently so to speak.  I guess essentially you'd
be re-inventing the typeclass, as a record of functions that
implement the abstract interface for each (user) data type.

	Donn Cave, donn at drizzle.com




More information about the Python-list mailing list