lampepfl/dotty

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

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.

Andreas Joseph Krogh

@andreak

Is features on http://dotty.epfl.ch/#so-features up2date?

Guillaume Martres

@smarter

http://dotty.epfl.ch/docs/reference/overview.html is

Andreas Joseph Krogh

@andreak

Ok, maybe remove the "features"-section from the main page, and add link, to avoid confusion?

Guillaume Martres

@smarter

PR welcome :)

Dermot Haughey

@hderms

man i like the way dotty is turning out

Ben Hutchison

@benhutchison

I went to take a look at Dotty at the suggested site [https://dotty.epfl.ch/] and the Features section of the homepage contains two broken links [http://dotty.epfl.ch/docs/reference/other-new-features/auto-parameter-tupling.html, http://dotty.epfl.ch/docs/reference/other-new-features/multiversal-equality.html].

It creates a poor initial impression of Dotty's maturity.

Xavier GUIHOT

@xavierguihot

Hi, is there a scaladoc for dotty's api?

Olivier ROLAND

@newca12

No not yet. lampepfl/dotty#2541

Olivier ROLAND

@newca12

@benhutchison @andreak @smarter I will fix the doc

Guillaume Martres

@smarter

Thanks!

Olivier ROLAND

@newca12

Done lampepfl/dotty#6449

Ólafur Páll Geirsson

@olafurpg

FYI, it looks like Scastie supports now the latest Dotty https://scastie.scala-lang.org/ZDPtyziPSAqXM8OrPy9ZNA

Nicolas Rinaudo

@nrinaudo

I (think I) understand match types, but I'm not super clear on the point of them. Is there a motivating example, or existing Scala patterns that are made clearer / simpler by their addition?

Miles Sabin

@milessabin

Here's something I'm experimenting with,

  type LiftP[F[_], T] = T match {
    case Unit => Unit
    case (a, b) => (F[a], LiftP[F, b])
  }

This is much simpler than the equivalent using implicit induction and path dependent types.

Nicolas Rinaudo

@nrinaudo

err... so. This lifts all the components of tuple type T into type constructor F?

Miles Sabin

@milessabin

Exactly.

ml10

@ml10

@milessabin Curious if you and Edwin Brady are considering a reprise of your Scala/Idris talk from 2013 once Dotty and Blodwen are out. :)

Nicolas Rinaudo

@nrinaudo

@milessabin any reason other than this is just a quick sample I typed for you not to declare T <: Tuple?

Miles Sabin

@milessabin

It's not something I've thought about or we've discussed, but that's not a bad suggestion :-)

@nrinaudo the bound is redundant given the cases.

ml10

@ml10

Nice! Of course I undertand if it doesn’t happen, but I think it would be enlightening.

Nicolas Rinaudo

@nrinaudo

In that case, I'm not sure why it's not infered, at least for Xs, in the dotty documentation:

 type Concat[+Xs <: Tuple, +Ys <: Tuple] <: Tuple = Xs match {
    case Unit => Ys
    case x *: xs => x *: Concat[xs, Ys]
  }

ah. Tuple arity?

Miles Sabin

@milessabin

I think the bound on Xs might be redundant there. But the bound on Concat is needed to satisfy the bound on the RHS of *: and that means that we need the bound on Ys for the Unit case.

Where communities thrive

People

Repo info

Activity