[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: More on dispatching by function return type
Ken Shan <firstname.lastname@example.org> writes:
> A related concern is Joe Marshall's worry that programs can be more
> fragile, for example when dvi2ps is changed to produce PDF as well. But
> the soundness of the type system prevenst new-and-improved dvi2ps from
> possessing the type "dvi -> ps", so the problem is discovered and fixed
> before eve TeX is run. This is a classical example of how static typing
> can catch at least some problems early.
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
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
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.
> In the end, I don't think any amount of CPS-conversion will make
> dispatching on the (return) type of functions seem any less weird (or,
> for that matter, more weird) to people. For example, Joe Marshall
> comments that "it seems weird to dispatch on the type of CONT when
> ultimately we are interested not in CONT but in FOO. Changes to FOO
> must take into account all the continuations that may be supplied to
> FOO." Reverting to direct style, that is just saying that it seems
> weird to dispatch on the return type of a function when ultimately
> we are interested not in the return but in the function. Changes to
> the function must take into account all the ways in which it may (be
> asked to) return.
Although this sounded like a very odd paraphrase on first reading it,
I agree. A function makes the important distinction between its
domain and its range. By dispatching on the continuation type (the
expected return type), we are conflating the range with the domain.
This puts constraints on the function. (Suppose I wrote something
like int a = (log b) mod c; )
This isn't necessarily a bad thing, but constraint programming is very
different from functional programming.