Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • May 18 23:07
    griggt commented #15216
  • May 18 22:23
    sjrd commented #15207
  • May 18 21:05
    noti0na1 commented #15096
  • May 18 21:01

    bishabosha on main

    Fixed a typo in the documentati… Merge pull request #15225 from … (compare)

  • May 18 21:01
    bishabosha closed #15225
  • May 18 20:59
    noti0na1 unassigned #15096
  • May 18 20:37
    smarter commented #15185
  • May 18 20:18
    smarter review_requested #15229
  • May 18 20:18
    smarter labeled #15229
  • May 18 20:18
    smarter assigned #15229
  • May 18 20:18
    smarter opened #15229
  • May 18 20:14
    rmgk labeled #15228
  • May 18 20:14
    rmgk labeled #15228
  • May 18 20:14
    rmgk opened #15228
  • May 18 20:02
    rmgk opened #15227
  • May 18 20:02
    rmgk labeled #15227
  • May 18 20:02
    rmgk labeled #15227
  • May 18 19:32
    bishabosha auto_merge_enabled #15225
  • May 18 19:03
    rmgk commented #15226
  • May 18 18:59
    griggt commented #15185
Denis Rosset
@denisrosset
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
no
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
Ó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.
Bounds are infectious.
Nicolas Rinaudo
@nrinaudo
That makes sense. Thank you!
Xavier GUIHOT
@xavierguihot

Hi, would there be a way, via the new export feature to achieve smthg like:

final class MyClass(a: String) { def f = println(a) }
trait MyTrait { def g = println("boo") }
val x = new MyClass("hello world")
class MixMyTrait[T](x: T) extends MyTrait { export x._ }
new MixMyTrait(x).f
|^^^^^^^^^^^^^^^^^^^
|value f is not a member of MixMyTrait[T]

I tried with a ClassTag as well, but doesn't help

Xavier GUIHOT
@xavierguihot
Hi, will it be possible to also use vararg patterns on case classes:
case class Point(x0: Int, x1: Int, x2: Int, x3: Int, x4: Int)
Point(1, 2, 3, 4, 5) match { case Point(x, rest: _*) if x > 0 => true; case _ => false }
                                  ^^^^^^^^^^^^^^^^^^
  // Wrong number of argument patterns for Point; expected: (Int, Int, Int, Int, Int)
Ghost
@ghost~54f4b69115522ed4b3dcb16d

@xavierguihot compare scalac -Xlint

scala> case class C(i: Int, js: Int*)
defined class C

scala> C(42) match { case C(x, y, rest @ _*) => }
                          ^
       warning: Sequence wildcard (_*) does not align with repeated case parameter or extracted sequence; the result may be unexpected.
scala.MatchError: C(42,ArraySeq()) (of class C)
  ... 30 elided

and dotty

scala> case class C(i: Int, js: Int*)
// defined case class C

scala> C(42) match { case C(x, y, rest : _*) => }
1 |C(42) match { case C(x, y, rest : _*) => }
  |                   ^^^^^^^^^^^^^^^^^^
  |            Wrong number of argument patterns for C; expected: (Int, Int*)

I haven't followed the changes, but indiscriminate scarfing of pattern args is pretty dicey.

Xavier GUIHOT
@xavierguihot
This would mean using a vararg definition of the class parameter though; seeing the List example in dotty's doc, I'm wondering if it would be possible to do the same on a classical case class
Ghost
@ghost~54f4b69115522ed4b3dcb16d
@xavierguihot I meant to suggest that the usual expectation is that the pattern "looks like" the constructor. If they don't align, it's confusing and error-prone. Since they tightened the case of varargs, it's even less likely they would extend the syntax for the case you propose.
Ben Hutchison
@benhutchison

Ive started experimenting with Dotty in VSCode. Im really impressed by the library compatibility with Scala 2.x using withDottyCompat in build.sbt. I have been able to throw Typelevel libs into a Dotty project and so far (almost) everything "just works"...

.. but it seems like the IDE isn't reloading/reimporting build.sbt changes, as editor is complaining about missing library imports, while SBT CLI is fine. Is there a key-combo I should hit to trigger reimport of the SBT build?