Interestingly Java's generics allow the dual construction on interfaces:
public <T extends Interface1 & Interface2> void someMethod(T param) {...}
I really like the idea of having the anonymous unions/joins and
considering that the resulting type system should be a complete lattice
they sound manageable to me -- both for the compiler and the human
reader. Does anyone know reasons why no language seems to have this feature?
Peter
James Iry wrote:
>
>
> On Tue, Aug 18, 2009 at 3:13 AM, Peter Becker <peter.becker.de
> <http://peter.becker.de>@gmail.com <http://gmail.com>> wrote:
>
>
> What I would really like to see is a meet/or/disjunction/union
> operator
> in the type system, with a case-like construct to resolve the
> resulting
> types. Scala has two things that are halfway there (Either, case
> classes), but neither is the full monty.
>
>
> Few type systems have true union types. The algebraic data types of
> the ML and Haskell families, for instance, do not allow unioning of
> types without explicitly creating a new type with its own
> "constructors". See Either which in Haskell looks like.
>
> data Either a b = Left a | Right b
>
> In Scala, Haskell, or SML Either is really just a way of faking union
> typing in a type system that doesn't do union typing.
>
> Java is actually very unusual in that the small bit of its type system
> devoted to exceptions basically has union types. If a method says it
> throws A,B,C then the union "A,B,C" forms a type and the type "A,B" is
> a subtype, the type "A,B,C,D" is a supertype. With regards to
> declared exceptions on methods Java is covariant. I know that's not
> how checked exceptions are normally presented, but that's how the type
> rules work.
>
> But then Java, as usual, isn't very regular about this union typing
> business. You can write
>
> Integer myFunction(File file) throws IOException, MyBusinessException
> {...}
>
> But if you try to make it "first class" with something like
>
> interface Function<In, Out, Exc> {
> Out apply(In in) throws Exc;
> }
>
> You can't then write something like
>
> new Function<File, Integer, {IOException, MyBusinessException}> {...}
>
> Your first class function has to pick one exception or declare that it
> throws a common supertype.
>
> Project Coin proposed the ability to catch mutliple exception types
> with one catch block. That can be seen as extending union typing just
> a touch further, but it still doesn't cover exception types as type
> parameters.
>
> It's not surprising to me at all that Java remains virtually the only
> language with checked exceptions. They might be a fine idea, but
> making them usable and consistent across the language is very tough
> business. Checked exceptions are what's called an effects system,
> which is a way to extend a type system so that functions describe
> effects they might have beyond computing a value. Creating an effects
> system that is usable and consistent across the language is very much
> ongoing research. See Disciple
> http://www.haskell.org/haskellwiki/DDC/EffectSystem, but I warn you
> it's not for the faint of heart.
>
>
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
