--- "Jonathan S. Shapiro" <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-01-28 at 12:39 +0100, J�rgen Hermanrud
> Fjeld wrote:
> > Hi,
> > I just wondered if you have considered the work on
> extensional polymorphism
> > by Furuse [1] as a framework for
> > overloading?
>
> We haven't, and we will look at it. My guess is that
> extensional
> polymorphism is way too complex for what we are
> trying to do. If I could
> get rid of overloading entirely and still have a
> language with adequate
> support for abstraction, I'ld do it in a heartbeat.
>
> > As far as I understand that would give the
> programmer explicit control
> > over overload resolution, as well as provide
> static type safety.
>
> Giving the programmer control over overloading in
> general is definitely
> a bad idea. There are certain *kinds* of control
> that may be okay, but
> every "option" available to the user is a
> multiplication by two of the
> semantic complexity of the language.
>
> > Also I wondered work on multi-staging [2] and
> macros [3] would be relevant?
> > Especially since multi-staging researched fro
> O'Caml can be statically
> > type checked.
Does avoiding polymorphism and static type checking
exclude things like type classing in Haskell?
Type classing in Haskell is a very elegant solution to
developing generic algorithms and doesn't bring with
it all the problems that OO polymorphism has. However,
I can understand why this would cause problems with
theorem provers and other kernel runtime issues.
Shawn Garbett
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
