Thu, 18 Oct 2001 16:10:43 +0400
H> The whole idea of letting you omit method definitions for methods with
H> no default and having calls to such methods be run-time errors is IMHO
H> exceedingly odd in a supposedly strongly typed language, and IMHO ought
H> to be reconsidered in the next major revision of Haskell.
F> I agree too, but being able to omit method definitions is
F> sometimes useful -- would it be possible to make calls to
F> those methods a /static/ error? I suspect this would be hard
F> to do.
I am not a specialist and can mistake and confuse things, but I
whether a notion of a strongly typed language is so
The same is with the `compile-time' and `run-time' separation.
There is no scientific reason why all computations with types and
type resolution should preceed all computations with non-types.
Very often the types need to behave like ordinary data.
Would it be reasonable to avoid as possible the restriction of
strong typing in language specification?
The essence of compiling is to spend once an effort to reorganize
some piece of data P into P' in order to reuse P' many times and
win performance. For a program PP introducing P1 ... P100,
why all compilations P1 -> P1' ... P100 -> P100'
should preceed all usages of P1' ... P100'