lampepfl/dotty

This channel is now CLOSED. Please use gitter.im/scala/scala for user questions and gitter.im/scala/contributors for compiler development.

odersky

@odersky

No, that can’t work. _ is used on two different levels here. So its translation is

x => f(x, y => y * 2))

Guillaume Martres

@smarter

ah right

Ghost

@ghost~54f4b69115522ed4b3dcb16d

I'm happy that in Scala 3, underscore still has levels. Is it too late to propose double-underscore syntax __ * 2 to mean expanding to the next enclosing Expr? Inductively for ___ and up, of course. I guess that would make arbitrarily long underscores reserved. That's OK, because then usage of case _________ => for alignment purposes can be more narrowly defined for the default case.

Soren

@srnb_gitlab

I'd be a fan of expanded underscore

Harrison Houghton

@hrhino

What about requesting no underscore? So you have something like case if ... =>

Martijn Hoekstra

@martijnhoekstra

you just repeat the no underscore to mean expanding to the next Expr?

I like that

Ghost

@ghost~55118a7f15522ed4b3ddbe95

@hrhino why stop there m match { x => ...; if p => ...; Some(y) => ... }

Ghost

@ghost~54f4b69115522ed4b3dcb16d

@hrhino I can't tell if you're getting my goat. scala/scala#6241

Harrison Houghton

@hrhino

I'm getting your goat, but in a sympathetic way.

I did see that PR.

Ghost

@ghost~54f4b69115522ed4b3dcb16d

@hrhino then you meant GOAT.

Denis Rosset

@denisrosset

Small question: how well do inline and @specializedplay together? I wrote a small library for specialized collections and used macro trickery to escape most specialization problems ( https://github.com/denisrosset/metal -- warning the macro use is quite gross).

Guillaume Martres

@smarter

Right now there is zero support for @specialized in Dotty

Denis Rosset

@denisrosset

Now, I'd like to see how inline can improve over that; but it seems to be applied at a stage where specialization cannot be recovered.

OK! thanks

So I'll stop looking.

Guillaume Martres

@smarter

And no immediate plan to bring it back

because it's a huge mess

method specialization is OK, but specializing non-final classes is really hard and even after years of work not completely correct in Scala 2

I'm assuming you're looking at this for Spire ? What kind of specialization do you use ? Have you checked how much it's still needed when using Graal for example ?

Denis Rosset

@denisrosset

Yes it is.. what I did in metal was to have nonspecialized traits, but specialized methods... so you call (set: MySet[A]).contains[A](a), where the first type parameter is nonspecialized (MySet[A]), but the magic happens in the def contains[@specialized B](b: B). The macro system is there to put the right type parameters.

My immediate problem with Scala specialization was that Map[@sp A, @sp B] fails to specialize for e.g. Map[AnyRef, Int].

Guillaume Martres

@smarter

that's interesting

Denis Rosset

@denisrosset

Spire behaves better in that respect: it's often pretty clear which type parameters would be scalars, and then we specialize only those.

But indeed, Spire on Dotty is an interesting thought. I have a talk at the ScalaDays about Spire generic approach. I haven't tried Dotty on it, neither Graal, that's an excellent suggestion.

Guillaume Martres

@smarter

Given your experience, it'd be great if you could write up what you think the compiler should provide in terms of specialization

maybe as a starting point for a discussion on https://contributors.scala-lang.org/

Denis Rosset

@denisrosset

Let me think of it. Will you be there at the Scala Days?

Guillaume Martres

@smarter

yep!

it's basically happening in my backyard so hard to miss it

Denis Rosset

@denisrosset

Ha!

I wonder if I'll have time to deeply think about specialization till the conference .. anyway, I'll dig into the generated bytecode, assembly for numerical code. While the presentation won't address specialization directly, it will give us food for thought!

Guillaume Martres

@smarter

sounds good!

Matthew Pickering

@mpickering

Does anyone know why the type representation is indexed by a type rather than its kind? How does the type system ensure that type splices are well-typed?

Dermot Haughey

@hderms

is it likely dotty will actually be faster to compile than scala 2?

Guillaume Martres

@smarter

right now they're about the same speed

so probably not, though we may get parallelization working well enough: lampepfl/dotty#4767

also if you're interested in speeding up either scala 2 or dotty, consider using graal: https://medium.com/graalvm/compiling-scala-faster-with-graalvm-86c5c0857fa3

Jamie Thompson

@bishabosha

@smarter has the effects “documentation” been erased, I knew it wasn’t concrete but is it dead?

Guillaume Martres

@smarter

don't know which documentation page you have in mind

Jamie Thompson

@bishabosha

it used to be on the overview

I was using it as a reference but maybe I shouldn’t because its too early

Guillaume Martres

@smarter

don't know what happened, you'll have to dig in the git history

odersky

@odersky

Effects won'’t make it for 3.0, but we keep working on them.

Eric K Richardson

@ekrich

@smarter I'm holding out for threads and a few other things needed for a Scala Native, Scala compiler. :smile:

Guillaume Martres

@smarter

a scala native compiled compiler would avoid the warmup time of the JVM but I don't think it'd be significantly faster than a warmed up JVM

Jamie Thompson

@bishabosha

@smarter @odersky Thank you both, I see its still live at overview-old.md.

Eric K Richardson

@ekrich

@smarter Denys is getting really good performance with his recent Interflow work.

Where communities thrive

People

Repo info

Activity