strong typing?

[S.D.Mechveliani]

People write

Fergus Henderson:
H> [...]
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.

Jon.Fairbairn@cl.cam.ac.uk:
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 
wonder 
whether a notion of a strongly typed language is so 
scientifically important.
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'
?

-----------------
Serge Mechveliani
mechvel@botik.ru