What is Expressiveness in a Computer Language
jo at durchholz.org
Fri Jun 16 23:57:10 CEST 2006
> Many lists are heterogenous, even in statically typed languages.
> For instance lisp code are lists, with several kinds of atoms and
Lisp isn't exactly a statically-typed language :-)
> A car dealer will sell cars, trucks and equipment..
> In a statically typed language you would need to type the list on a common
Where's the problem with that?
BTW the OO way isn't the only way to set up a list from heterogenous data.
In statically-typed FPL land, lists require homogenous data types all
right, but the list elements aren't restricted to data - they can be
functions as well.
Now the other specialty of FPLs is that you can construct functions at
run-time - you take a function, fill some of its parameters and leave
others open - the result is another function. And since you'll iterate
over the list and will do homogenous processing over it, you construct
the function so that it will do all the processing that you'll later need.
The advantage of the FPL way over the OO way is that you can use ad-hoc
functions. You don't need precognition to know which kinds of data
should be lumped under a common supertype - you simply write and/or
construct functions of a common type that will go into the list.
> What would then be the point of statical typing , as you stilll need to type
> check each element in order to process that list ?
Both OO and FPL construction allow static type checks.
> Sure you can do this in a
> language, you just need to make sure some relevant ancestor exists. In my
> you'll end up with the base object-class more often than not, and that's
> what i call dynamic typing.
Not quite - the common supertype is more often than not actually useful.
However, getting the type hierarchy right requires a *lot* of
experimentation and fine-tuning. You can easily spend a year or more
(sometimes *much* more) with that (been there, done that). Even worse,
once the better hierarchy is available, you typically have to adapt all
the client code that uses it (been there, done that, too).
That's the problems in OO land. FPL land doesn't have these problems -
if the list type is just a function mapping two integers to another
integer, reworking the data types that went into the functions of the
list don't require those global changes.
>> Give a case of calling nonexistent functions that's useful.
> I might want to test some other parts of my program before writing this
That's unrelated to dynamic typing. All that's needed is an environment
that throws an exception once such an undefined function is called,
instead of aborting the compilation.
I'll readily admit that very few static languages offer such an
environment. (Though, actually, C interpreters do exist.)
> Or maybe will my program compile that function depending on user input.
Hmm... do I really want this kind of power at the user's hand in the age
> As long as i get a warning for calling a non-existing function, everything
> is fine.
For software that's written to run once (or very few times), and where
somebody who's able to correct problems is always nearby, that's a
perfectly viable strategy.
For safety-critical software where problems must be handled within
seconds (or an even shorter period of time), you want to statically
ensure as many properties as you can. You'll take not just static
typing, you also want to ascertain value ranges and dozens of other
properties. (In Spark, an Ada subset, this is indeed done.)
Between those extremes, there's a broad spectrum.
More information about the Python-list