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.
[EMAIL PROTECTED]: 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 [EMAIL PROTECTED] _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
