You seem to be making the argument that dispatching by the return type
of a function makes code fragile because it requires static typing, and
static typing makes code fragile. Here "makes code fragile" seems to
mean that, even if some piece of code always works, the type system may
not be convinced of that fact. But dispatching by the return type of
a function does not depend on static typing; indeed, Makefiles are an
example of dispatching by the return type of a function that does not
use static typing or type inference.
On 2003-12-17T09:59:10-0500, Joe Marshall wrote:
> Suppose I `improved' my dvi2ps to produce PDFs resulting in the new
> type being `dvi -> (union ps pdf)'. If I have done this, I imagine
> that I have *also* modified the necessary programs (scripts) to cope
> with this. So on my machine, everything type checks and runs and I'm
> happy.
How would you modify the necessary programs, such as the implicit rules
in your Makefile (which is an instance of not static type inference but
redundant type information), in order to cope with this change? It is
unlikely that Make can take advantage of an implicit rule like
.dvi.(ps|pdf):
dvi2ps ...
Instead, you would probably keep the original rule and add a new one for
turning dvi into pdf:
.dvi.ps:
dvi2ps ...
.dvi.pdf:
dvi2ps --pdf ...
But the static-typing equivalent of such a pair of rules is that you
have not changed the type of dvi2ps to "dvi -> (union ps pdf)". Rather,
you have provided some sort of guarantee (it doesn't matter static or
dynamic) that dvi2ps will return ps when invoked in one way, and another
guarantee that dvi2ps will return pdf when invoked in some other way.
These two guarantees are together stronger than the guarantee that
dvi2ps will return either ps or pdf--
> Now comes John and he sees my nifty PDF output and I mention that I
> hacked dvi2ps to emit PDF files if you give it the --pdf argument. I
> give him the new program, but when he installs it, he suddenly cannot
> print things the old way because the other programs that depend on
> dvi2ps suddenly have to take into account the change in the output
> type.
>
> Of course static typing has prevented John from accidentally sending a
> PDF file to his postscript printer, but by the rather draconian means
> of preventing John from sending *anything* at all.
--and are easy to make either statically or dynamically. John is not
prevented from sending anything; rather, he is required to promise that
dvi2ps will not return pdf when invoked the way he does. Saying that
dvi2ps has the type "dvi -> (union ps pdf)" is like saying that every
shell command that Make might invoke has a type like "(union dvi ps pdf
tex) -> (union dvi ps pdf tex)": it is too weak a guarantee, and if such
a type really expressed all you knew about your programs, they wouldn't
be terribly useful to Make.
Again, I emphasize that what makes the "read" example and the "dvi2ps"
examples work is not static typing or type inference; it is simply
the ability to dispatch on the return type of a function without ever
invoking it. Make is a system with neither static typing nor type
inference that relies crucially on this ability. However, implicit
rules in Make contain redundant information.
--
Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig
Remember 9/11 * "It's untidy. And freedom's untidy. And free people are free
to make mistakes and commit crimes and do bad things." -- Donald Rumsfeld
China has listed the organization behind http://www.uygur.org/ as terrorist.
(http://www.mps.gov.cn/webpage/showNews.asp?id=1118&biaoshi=bitGreatNews)
Attachment:
signature.asc
Description: Digital signature