Home Original page

Python 1.6 The balanced language

Alex Martelli aleaxit at yahoo.com
Tue Sep 5 03:53:42 EDT 2000 
"Manuel Gutierrez Algaba" <thor at localhost.localdomain> wrote in message
news:slrn8r8cla.hrg.thor at localhost.localdomain...
    [snip]
> So types go against "functional".

Most functional languages have (good) typesystems -- Haskell's being
definitely worth studying, for example -- so this claim is peculiar
on the fact of it (of course, Erlang shows you don't *need* [static]
types in a functional language, but in the same way Haskell shows
they most definitely don't *hurt* the functional aspects, either!).

To continue your pipes/fluids analogy: not all fluids are safe to
run in every kind of pipe.  A language with types basically *lets*
you state that (some *make* you state that, but "good" typesystem
implies some measure of type-inferencing, by definition of 'good':-).

A typeless language just doesn't model that particular aspect of
safety, relying on runtime checks for it exclusively; a dynamically
typed language (more common than 'typeless'... BCPL is an example
of 'typeless', and it's hard to find many others...) may structure
the checking for you (to some extent) though it's still runtime.

So, back to the analogy: I declare (or the system infers) that
this here pipe is made of pressed cardboard (using 'type' analogy
to 'what matter is it made of').  A very good type system will infer
that it's unsafe to route a fluid through it if that fluid's "type"
is, e.g., concentrated sulphuric acid; a decent one will let me
_state_ that if it's unable to infer it; a maybe-too-rigid one may
*force* me to state what families of fluids are allowed to pass
through this pipe.  A typeless system (and to some extent a fully
dynamically-typed one) is equivalent to a plumbing-modeling system
that does not model materials-issues -- which doesn't mean it's
*useless*, absolutely not: it's still very useful to model a fluid
flow system even in a more abstract way, without consideration of
materials' properties; but it would be silly to claim that being
able to model materials as well (or, even, being _forced_ to do so)
makes a fluid-flow simulation system useless or innatural.

The analogy can be stretched -- a big risk for naive users of
good typesystems (or anal-retentive ones) is the *illusion of
safety* they may engender; by offering some guaranteed checks
about fluid-material to pipe-material compatibility, they may
delude the naive user into believing fluid-to-pipe compatibility
checks may be relaxed, tests may be skimpier, etc.  No way.

Water *as a material* may be ok for a pipe whose material is
pressed-cardboard *from a purely materials-science POV*, but
compatibility still needs to be tested and checked: if the
water's temperature is 90 Celsius, or the cardboard's thickness
is 0.1 mm, big runtime trouble is still in store if that fluid
is every allowed to flow in that pipe.  The designer still needs
to design-in the appropriate checks, and run lots of tests...

Somewhat-Haskellishly:

myPipe    :: (Noncorrosive a) => [a] -> [a]
myPipe []    =    []
myPipe (x:xs)
    | temperature x <  90    = x : myPipe xs
    | temperature x >= 90    = error "too hot!"

Here, I could rely on an assumed 'Noncorrosive' type class to
ensure against, e.g., sulphuric acid ever being run through
my poor little pipe -- but, since in the analogy types model
materials (immutable characteristics of certain objects), the
temperature-test I've had to perform explicitly (as temperature
is an "accident" in the Aristotelic sense, i.e. an aspect that
changes from time to time, from case to case, while material
is here modeled as "substance", intrinsic to an object's
nature/identity).

I may have come (after decades of using many different
languages, mostly rather typed and pretty anal-retentive
about it) to a personal preference for dynamic typing, but
that doesn't stop me from recognizing that being able to
diagnose SOME errors at compile-time (and thus prevent
them) also has its use...!  In functional languages just
as well as in imperative or mixed ones.


Alex
More information about the Python-list mailing list