This page is no longer maintained — Please continue to the home page at www.scala-lang.org

-Xfuture & -Xexperimental

4 replies
Daniel Mahler
Joined: 2009-05-25,
User offline. Last seen 1 year 24 weeks ago.

Is there a simple way to find out what -Xfuture & -Xexperimental
actually enable for any given release/snapshot?

thanks
Daniel

Adriaan Moors
Joined: 2009-04-03,
User offline. Last seen 42 years 45 weeks ago.
Re: -Xfuture & -Xexperimental
I'm afraid the only way I know of is to grep the compiler source for either settings.Xexperimental.value, settings.future.value
From a quick inspection, it seems the only thing that actually (mostly) works is dependent method types, which allow you to write, e.g.:
def reallyTheIdentity(x: Any): x.type = x
adriaan
On Sun, Oct 11, 2009 at 2:07 AM, Daniel Mahler <dmahler [at] gmail [dot] com> wrote:
Is there a simple way to find out what  -Xfuture & -Xexperimental
actually enable for any given release/snapshot?

thanks
Daniel


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Ben Hutchison
Joined: 2009-01-21,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: -Xfuture & -Xexperimental

On Wed, Oct 14, 2009 at 2:29 AM, Adriaan Moors
wrote:
> I'm afraid the only way I know of is to grep the compiler source for
> either settings.Xexperimental.value, settings.future.value
> From a quick inspection, it seems the only thing that actually (mostly)
> works is dependent method types, which allow you to write, e.g.:
> def reallyTheIdentity(x: Any): x.type = x

I would really like to use this facility in everyday Scala code.

What are the criteria for promoting this from experimental to regular Scala?

> On Sun, Oct 11, 2009 at 2:07 AM, Daniel Mahler wrote:
>> Is there a simple way to find out what  -Xfuture & -Xexperimental
>> actually enable for any given release/snapshot?

IMHO there really ought to be. If a feature is too speculative to
identify and document, perhaps it belongs in a branch rather than
trunk?

-Ben

Adriaan Moors
Joined: 2009-04-03,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: -Xfuture & -Xexperimental


On Wed, Oct 14, 2009 at 1:06 AM, Ben Hutchison <ben [at] playscapegames [dot] com> wrote:
On Wed, Oct 14, 2009 at 2:29 AM, Adriaan Moors
<adriaan [dot] moors [at] cs [dot] kuleuven [dot] be> wrote:
> I'm afraid the only way I know of is to grep the compiler source for
> either settings.Xexperimental.value, settings.future.value
> From a quick inspection, it seems the only thing that actually (mostly)
> works is dependent method types, which allow you to write, e.g.:
> def reallyTheIdentity(x: Any): x.type = x

I would really like to use this facility in everyday Scala code.

What are the criteria for promoting this from experimental to regular Scala?
Martin (or someone else who knows the type checker well enough...) having time to implement and test it fully. Obviously I can't comment on a time frame for that, although I would [expect/hope for] it to land somewhere in a 2.8.x release near you. 
adriaan
rytz
Joined: 2008-07-01,
User offline. Last seen 45 weeks 5 days ago.
Re: Re: Re: -Xfuture & -Xexperimental


On Wed, Oct 14, 2009 at 01:19, Adriaan Moors <adriaan [dot] moors [at] cs [dot] kuleuven [dot] be> wrote:


On Wed, Oct 14, 2009 at 1:06 AM, Ben Hutchison <ben [at] playscapegames [dot] com> wrote:
On Wed, Oct 14, 2009 at 2:29 AM, Adriaan Moors
<adriaan [dot] moors [at] cs [dot] kuleuven [dot] be> wrote:
> I'm afraid the only way I know of is to grep the compiler source for
> either settings.Xexperimental.value, settings.future.value
> From a quick inspection, it seems the only thing that actually (mostly)
> works is dependent method types, which allow you to write, e.g.:
> def reallyTheIdentity(x: Any): x.type = x

I would really like to use this facility in everyday Scala code.

What are the criteria for promoting this from experimental to regular Scala?
Martin (or someone else who knows the type checker well enough...) having time to implement and test it fully. Obviously I can't comment on a time frame for that, although I would [expect/hope for] it to land somewhere in a 2.8.x release near you. 

I think the implementation should be re-worked.

The current implementation uses a special type called `DeBruijnIndex` because
back when it was done, a method type had the form
  MethodType(args: List[Type], res: Type)

Since 2.8.0, with named arguments, method types now are
  MethodType(args: List[Symbol], res: Type)
so the parameter symbols are available through the type. This means that
we no longer need the DeBruijnIndicies.

One thing that should be investigated: I guess that similar to type parameter
symbols, there will be two symbols for each parameter, the one in the type
and the one used to type-check the method body (aka `skolemize` / `deSkolemize`).
This already happens now I think (parameter symbols are cloned), but there's
no way to get from one to the other.

Cheers: Lukas

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland