Me:
> > Your 'partial' list would appear, from a initial
> > inspection, to leave little left of either type safety or referential
> > transparency.
KA:
> Could explain how they could. There is a very nice paper written up on
> True ad-hoc polymorphism. By a build in build in dynamic type system I
> mean being able to safely recover types from an existential collection
> using a runtime check.
That's immediately weakening what Haskell understands by 'type safety'.
(Though not necessarily unacceptable, as Fergus Henderson says, if
I can tell by the top-level type of a program whether it's statically
of sound type, or not.)
> I can not see how State encapsulation will
> weaken any type system.
No, that's be the 'referential transparency' part of the above.
(I assume you're talking about something considerably different
from state-by-monads, here.)
> > [...] It's not clear from the above agenda,
> > though, that it wouldn't be easier to define (C++)++ (the second ++ being
> > lazy evaluation, HOFs, partial ap., GC). Which don't get me wrong,
> > would be an entirely good thing, IMO.
> God NO, I like C++ because it is powerful but adding more features on an
> already ugly (but powerful languge) will make matters worse my making it
> more powerful but so ugly with so many pitfalls that no one will want to
> use it.
True; my Secret Agenda is that at some point they might start taking
'features' back out... (Case in point, Java: add in one nice feature,
GC, take out several ugly ones... resulting in a still pretty ugly
language, but there's more rejoicing in heaven, etc, etc... <g>)
Cheers,
Alex.
