Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Adriaan Moors <adriaan.moors-p8DiymsW2f8 <at> public.gmane.org>
Subject: Re: [scala] higher-kinded types notation and compostion
Newsgroups: gmane.comp.lang.scala.internals
Date: Thursday 18th March 2010 10:14:22 UTC (over 7 years ago)
Hi Jason,

As you've noticed, this is already supported. "All that is needed" is to
actually parse these types and shake out the bugs that will be triggered by
the weird type functions you'll be writing ;-)

I've recently been working on a bug related to anonymous type functions
(#2741, #3106). See http://github.com/adriaanm/scala/tree/ticket/2741,
also
check out http://github.com/adriaanm/scala/tree/ticket/2741_continued,
specifically
http://github.com/adriaanm/scala/commit/43ac58de15fe73973d8346dff6db702d3d4a1f98

None of this has landed in trunk yet, though. A minimal fix for 2741
hopefully will make its way into trunk before I leave on vacation in two
days :-)  (need to think it through some more as we're focussing on not
breaking anything for the 2.8 release ;-)).

In any case, I think it would make for a fun project for you to try and
implement syntax like

[X, Y] Pair[Y, X]
// would prefer : [X, Y] -> Pair[Y, X] , but  -> was an identifier before,
can't steal it as reserved keyword
// also, not sure [X, Y] => Pair[Y, X] would work

My fix for 2741 introduces typeFunAnon, which you can use to construct
these
types. Also, the work started
in 43ac58de15fe73973d8346dff6db702d3d4a1f98 should be carried out fully: we
should introduce the type NullaryMethodType to model method types without
argument lists, so that PolyType is only used for type functions and
universally quantified types. I'll be working on this when I get back from
vacation.

It obviously won't be trivial to implement everything that logically
follows
from having anonymous type functions, as we currently don't have the
necessary infrastructure to allow people to write higher-kinded type
aliases, for example:

type MyTypeFun = [X, Y] Pair[Y, X] // desirable, but hard to support with
the current implementation (we look at the type params of a symbol to infer
its kind)

(desirable by analogy to val myFun = (x: Int) => x+1)

other related features would be: support for multiple type parameter lists
and currying, explicit kind annotations, higher-order unification for type
constructor inference ...

cheers
adriaan

On Mon, Mar 15, 2010 at 4:25 PM, Jason Zaugg
<[email protected]> wrote:

> Okay, let's propose a better notation!
>
> The placeholder notation, implied by your original mail, is already
> taken by existential types, and is a shortcut for forSome.
>
> Set[List[_]]  ==> Set[List[X] forSome { type X} ]
>
> In errors and debug output, the scalac uses:
>
> List  ==> [X]List
> type S[X] = Set[List[X]]; S  ==> [X]Set[List[X]]
>
> I don't mind this notation. I wonder if it could be added to the
> language in a backwards compatible manner?
>
> -jason
>
> On Mon, Mar 15, 2010 at 3:52 PM, Meredith Gregory
>  wrote:
> > Dear Jason and Luc,
> > Thanks for your notes! i guess my note was a little too elliptical. i
> > understand that one can use type alias' to side-step the issue. i was
> just
> > wondering if people found this notational design to be a bit
off-putting.
> To
> > my eyes the pair of errors just makes the particular notation look
> broken.
> > Best wishes,
> > --greg
>
 
CD: 3ms