strong typing?
S.D.Mechveliani
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.Fa...@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
mec...@botik.ru
_______________________________________________
Haskell mailing list
Has...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Brian Boutel
>
> 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?
No scientific reason, but a strong engineering reason.
The engineering idea is to test a design with all available tools before
building it. That way there will be no disasters that could have been
forseen. The computing equivalent of an engineering disaster is for a
program to get a run-time error or to produce an incorrect result. If
this outcome is acceptable, then the program probably wasn't important
enough to be worth writing in the first place.
--brian
hw
Thursday, October 18, 2001, 3:10:43 PM, you wrote:
SDM> I am not a specialist and can mistake and confuse things, but I
SDM> wonder whether a notion of a strongly typed language is so
SDM> scientifically important.
SDM> The same is with the `compile-time' and `run-time' separation.
Because by properly separating these concepts You can reason about the
program and You can enforce (or ensure) some properties of program.
This may be important in some critical areas of application of
software where there is a need to have programs with some proven
capabilities (time-space constraints, behavioral characteristics
(i.e. unhandled dynamic dispatch methods in OOP and so on)).
From the other point of view, the goal of science is to
_separate_and_study_ concepts ;-)
--
Best regards,
hw mailto:h...@ksue.kharkov.ukrtel.net
Jerzy Karczmarczuk
> > There is no scientific reason why all computations with types and
> > type resolution should preceed all computations with non-types.
> No scientific reason, but a strong engineering reason.
>
> The engineering idea is to test a design with all available tools before
> building it. That way there will be no disasters that could have been
> forseen. The computing equivalent of an engineering disaster is for a
> program to get a run-time error or to produce an incorrect result. If
> this outcome is acceptable, then the program probably wasn't important
> enough to be worth writing in the first place.
If an entity is sufficiently complex, there will be always a margin of
error. Good if avoidable, but...
Would you apply the same philosophy of "non-importance" of a possibly bugged
result, to procreating children?...
Jerzy Karczmarczuk
Caen, France
Brian Boutel
>
> Brian Boutel to Sergey Mechveliani:
>
> > > There is no scientific reason why all computations with types and
> > > type resolution should preceed all computations with non-types.
>
> > No scientific reason, but a strong engineering reason.
> >
> > The engineering idea is to test a design with all available tools before
> > building it. That way there will be no disasters that could have been
> > forseen. The computing equivalent of an engineering disaster is for a
> > program to get a run-time error or to produce an incorrect result. If
> > this outcome is acceptable, then the program probably wasn't important
> > enough to be worth writing in the first place.
>
> If an entity is sufficiently complex, there will be always a margin of
> error. Good if avoidable, but...
>
> Would you apply the same philosophy of "non-importance" of a possibly bugged
> result, to procreating children?...
Comparing breeding children to programming is surely a little
far-fetched. I always enjoyed programming, but not nearly as much as
procreating ;-)
Anyway, procreating children is not science, nor yet engineering. It
must be art, where the concept of "bug" does not exist.
--brian