Re: More on dispatching by function return type

[Joe Marshall <address@hidden>]

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

> Despite all these potential problems with a hypothetical program like
> Make, I take as a given that we want such a thing.  Make itself is
> clearly not perfect; what I am taking as given is that we want an
> extensible program that builds and executes a pipeline of conversions,
> even for trivial (single-step) pipelines.  Such programs abound in
> current software practice: mail readers, Web browsers, printing systems,
> clipboard interfaces, and text editors do it all the time.
>
> As soon as you have such a program, you are dispatching on the return
> type of a function without invoking it.  

I guess what I am saying is this:

   Dispatching on the type of the continuation changes a procedure
from a function to a relation with a constraint.

Programs based on relations and constraints are sometimes better,
sometimes worse, than programs based on composition of functions.  I
think my original objection was that I thought it was function, but it
was really a constraint in functional clothes.

---------------

To answer other questions:

> Do you mean that dvi2ps would be happy to produce ps if "asked to" on
> the command line, and also happy to produce pdf if "asked to" on the
> command line?  

Yes.


> Then the type of dvi2ps would not be "dvi -> (union ps pdf)" in
> usual notation; that type means that dvi2ps may produce either ps or
> pdf, at -its- discretion.

As far as other program are concerned, this really is the case.  The
program may base its choice solely on that single command line
argument, but the fact is that sometimes dvi2ps produces a ps file,
and sometimes a pdf file.

> The type that the just-described dvi2ps would take is a conjunction
> (intersection), not a disjunction (union): "dvi -> (intersection ps
> pdf)", or equivalently, "(dvi->ps, dvi->pdf)".

Intersection would be a file that is both a pdf and a ps file.


But this is just leading us to a situation where we'll have to design
a type language expressive enough that one can reason about classes of
output based on command line switches, and that isn't particularly
on subject.