On 2003-12-17T12:45:17-0500, Joe Marshall wrote:
> 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.
Let me try again to understand what you're saying, then. I think we
agree that there are several potential problems to a program like Make
that tries to build and execute a pipeline of conversions from one kind
of file to another, from an extensible list of single conversion steps.
1. dvi2ps may generate PDF when Make expects PS, making the god of
trees hate you.
2. dvi2ps may generate PS when Make expects PS, but Make isn't
convinced that it will get PS from dvi2ps, making Make's planning
process draconianly sound.
3. It is annoying to have to tell Make explicitly to expect PS from
dvi2ps, rather than having dvi2ps provide that information.
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. But then you may be faced
with one or more of the above problems. Type inference may mitigate
problem 3, but either problem 1 or problem 2 will persist, at least
theoretically, because program behavior is in general undecidable.
Because you complained about problem 1 (to my understanding), I
suggested one tradeoff away from problem 1 but (necessarily) toward
problem 2. Perhaps you were not complaining about problem 1, or you
were concerned about some fourth problem that I haven't listed, or you
disagree with what I took as given in the previous paragraph...?
> 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)'.
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? 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. 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)".
> So using return-type dispatch will give my programs the power,
> expressivity and reliability of Make?
No.
--
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