Re: More on dispatching by function return type

[Joe Marshall <address@hidden>]

Ken Shan <ken@digitas.harvard.edu> writes:

> You seem to be making the argument that dispatching by the return type
> of a function makes code fragile because it requires static typing, 

No, I don't think that dispatching on the continuation type requires
static typing, I think that it can make code fragile with or without
static typing.  However, you suggested that 

  ``the soundness of the type system prevents new-and-improved
    dvi2ps from possessing the type "dvi -> ps", so the problem is
    discovered and fixed before even TeX is run.  This is a
    classical example of how static typing can catch at least some
    problems early.''

Which seems to assert that fragility can be avoided or mitigated by
static typing.

> 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 ...

Here I am quite confused.

Yes, that is probably how I'd deal with the problem in a Makefile, but
this is a very different thing from dispatching on return type.

In a Makefile, you have a set of rules and a set of actions intended
to produce the transformation specified by the rules.

But there is no reasoning about the type of dvi2ps going on here.  I
could just as easily have this rule:
    .dvi.pdf:
        rm -f *

and Make would happily apply it despite the fact that rm does not
produce files of type PDF;  rm does not dispatch on its return type.

> 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--

In the Makefile, yes, but if dvi2ps were to dispatch on return type,
(say, for example, by looking at the extension of the target file),
then it really is the case that `dvi2ps -> (union ps 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.

Actually, any shell command Make might invoke *does* have type
any->any.  Make is very gullible in this regard.

> 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.

So using return-type dispatch will give my programs the power,
expressivity and reliability of Make?