what's our status with LabelDefs?

[Eugene Burmako]

Do we still plan to remove than? Will it be hard?

[Paul Phillips]

On Sun, Dec 2, 2012 at 3:18 AM, Eugene Burmako <eugene....@epfl.ch> wrote:

Do we still plan to remove than? Will it be hard?

AFAIK, we do and it will. 

[Eugene Burmako]

Is there some sort of a roadmap? Can we expect this be done by, say,
2.10.2?

On Dec 2, 10:54 pm, Paul Phillips <pa...@improving.org> wrote:

[Paul Phillips]

On Mon, Dec 3, 2012 at 7:13 AM, Eugene Burmako <eugene....@epfl.ch> wrote:

Is there some sort of a roadmap? Can we expect this be done by, say,
2.10.2?

I've left the land of AFAIK and entered a world of pure speculation, but the official statement from the president of Purespeculand is "No and no."

[eruve]

Hello, I'm joining the discussion following Eugene's advice in my StackOverflow post:

http://stackoverflow.com/questions/11677750/using-labeldef-in-scala-macros-2-10#comment18760839_11677750

In Scala 2.10, the programmer can use LabelDef from the (experimental) macro API. Regardless of how it is used internally, I reckon it's an interesting mechanism because it allows to jump between labels at same level within a given block, in an efficient fashion: from what I've tried, the JVM-backend makes use of the 'goto' instruction to "jump to the LabelDefs". So for example, a DSL with GOTO-ish features can be implemented quite seamlessly with Scala 2.10.

Note that a LabelDef without arguments and that yields a Unit is sufficient for this kind of use. An example, not the best but it illustrates the pattern, can be found in my StackOverflow post.

However now there are discussions of dropping LabelDef from Scala 2.11. My concern is that, unless it is replaced with a similar mechanism, I don't see a way of purposely write a program so that performant JVM bytecodes are generated (i.e. making use of the JVM-goto) in the situation illustrated above. In that sense, the drop would translate in less programming flexibility. The workarounds (such as looping to simulate a jump to a previous label) would produce more bytecode and be less performant.

So my question is, have you considered such cases and if so, what is the proposed alternative once LabelDef becomes unavailable?

Cheers,

-eruve

[Eugene Burmako]

I've found this thread: http://groups.google.com/group/scala-internals/browse_thread/thread/dd193ca135f56073,
and in that discussion Adriaan proposed to replace LabelDefs with
DefDefs with the LABEL flag.

Since DefDefs are callable, one would be able to jump between labels
with ease. On the other hand, such DefDefs will be treated specially
by the backend to match current behavior of LabelDefs.

However the thread in question in almost 8 months old, so I don't
whether the plans have changed or not. To the best of my knowledge
there were no subsequent discussions of the LabelDef refactoring till
now.

On Dec 4, 10:31 am, eruve <4f7b8...@mmxi.interstellabs.net> wrote:
> > Hello, I'm joining the discussion following Eugene's advice in my
> > StackOverflow post:
>

> >http://stackoverflow.com/questions/11677750/using-labeldef-in-scala-m...

[Grzegorz Kossakowski]

On 3 December 2012 16:13, Eugene Burmako <eugene....@epfl.ch> wrote:

Is there some sort of a roadmap? Can we expect this be done by, say,
2.10.2?

I'll let Adriaan have final word on this but I'd say that no refactorings of that size/complexity will go into 2.10.x. If we get rid of LabelDefs it'll be in master.

--
Grzegorz Kossakowski

[eruve]

I remember reading that too, but thought it was to resolve internal issues only, since Adriaan mentioned Symbols; while AFAIK the LabelDef/DefDef macros do not require symbols. One sure thing, it'd be great if the developer who uses macros had the same features available (without a hack to borrow symbols, that is).

Another point, "in absence of a next-label-call, at the end of the method execution, control flow will return to where the method was called from", so that's a behavior which is different from LabelDef's. I'm not sure of the consequences at this time, in particular in the bytecode.

[Adriaan Moors]

I would like to do this refactoring, but it will be done in master. I'm not ruling out backporting it to 2.10.x at some point, for suitably large values of x.

The fall-through behavior of LabelDefs (which isn't spec'ed, but is reasonable to expect) is not a problem for the kinds of label defs that we emit, since they all end in jumps as far as I know. It's not a problem in general either, since we statically know where to jump when synthesizing these label-like MethodDefs, so that we could insert calls to the next method to encode the implicit next-label-call.

[Eugene Burmako]

This probably means that reflection will be experimental at least until 2.11?

[Adriaan Moors]

Nope, I don't see it becoming un-experimental in 2.10.x.

We should strive for it shaking that stigma in 2.11.x

[Grzegorz Kossakowski]

On 5 December 2012 18:27, Adriaan Moors <adriaa...@typesafe.com> wrote:

Nope, I don't see it becoming un-experimental in 2.10.x.

We should strive for it shaking that stigma in 2.11.x

It's rather sad that downstream libraries won't be able to use Scala reflection for another year.

See also: https://groups.google.com/d/msg/scala-internals/v9mMzMBNlLI/4Rh3WsaYijQJ

Shall we make it more clear that people shouldn't depend on scala-reflect when working on their libraries?

--
Grzegorz Kossakowski

[Eugene Burmako]

Why won't be able to use Scala reflection for another year? You make it sound as if it's totally unreliable :)

[Daniel Sobral]

The fact that it is experimental means mostly that early users should be prepared for incompatible changes between releases, without long deprecation cycles. That means reflection won't be "for everyone", but I agree it's hardly a "do not use" sign. If it were, there would be no point in making it available at all.

Manifests were also experimental, and that hardly stopped anyone. Dynamic was experimental, and no one used it, but I attribute that to lack of interest + lack of a scala reflection library.

Given how many libraries are already looking into macros, and, therefore, reflection, to do stuff, I think it's safe to say reflection will follow the pattern of the former, not of the latter.

--
Daniel C. Sobral

I travel to the future all the time.

[Grzegorz Kossakowski]

On 7 December 2012 15:47, Eugene Burmako <eugene....@epfl.ch> wrote:

Why won't be able to use Scala reflection for another year? You make it sound as if it's totally unreliable :)

Guarantees we give on source/binary compatibility make it totally unreliable. If one library depends on scala-reflect.jar 2.10.0 and another on 2.10.1 things might potentially blow up so downstream users (that might pull in scala-reflect dependency through long chain) will have to deal with this even if they don't use reflection themselves anywhere in their code. That's the whole problem with binary compatibility.

Therefore, if you are library author and you don't want to be a pain in the ass for your users you should avoid using scala-reflection.

Alternatively, we promise BC and source compatibility for scala-reflect during 2.10.x series. However, if we do that we have to decide now.

--
Grzegorz Kossakowski

[Grzegorz Kossakowski]

On 7 December 2012 15:55, Daniel Sobral <dcso...@gmail.com> wrote:

The fact that it is experimental means mostly that early users should be prepared for incompatible changes between releases, without long deprecation cycles. That means reflection won't be "for everyone", but I agree it's hardly a "do not use" sign. If it were, there would be no point in making it available at all.

Manifests were also experimental, and that hardly stopped anyone. Dynamic was experimental, and no one used it, but I attribute that to lack of interest + lack of a scala reflection library.

Given how many libraries are already looking into macros, and, therefore, reflection, to do stuff, I think it's safe to say reflection will follow the pattern of the former, not of the latter.

Transitive dependencies make everything difficult. I don't think analogy with Manifests and Dynamic is correct in this situation because Manifests were stable in 2.9.x series (AFAIK) and Dynamic doesn't affect binary compatibility.

--
Grzegorz Kossakowski

[Eugene Burmako]

From what I understood, yesterday we agreed that we'll maintain source compatibility within 2.10.x.

Speaking of binary compatibility, I think, we can make it work as well. Let's just set up MIMA validator to include scala-reflect.jar.

[Adriaan Moors]

Great. I think our only choice is to maintain binary compatibility in all transitive Scala dependencies in the 2.10.x series, based on Grzegorz's comments.

Let's put MIMA on the job, and focus on stabilizing and cleaning up the reflection API so that it can ship as a first-class citizen in 2.11.0.