Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 12:33

    anatoliykmetyuk on ci-test-4

    Disable Mill caching for the co… (compare)

  • 12:24
    vtitov starred lampepfl/dotty
  • 12:09

    anatoliykmetyuk on ci-test-3

    (compare)

  • 12:09

    anatoliykmetyuk on ci-test-2

    (compare)

  • 12:08

    anatoliykmetyuk on ci-test-1

    (compare)

  • 11:43
    zdelta-io starred lampepfl/dotty
  • 07:59
    Eastsun edited #8344
  • 07:57
    Eastsun edited #8344
  • Feb 20 16:45
    nicolasstucki synchronize #8342
  • Feb 20 16:39
    anatoliykmetyuk edited #8353
  • Feb 20 16:39
    anatoliykmetyuk edited #8353
  • Feb 20 16:39
    anatoliykmetyuk edited #8353
  • Feb 20 16:39
    anatoliykmetyuk labeled #8353
  • Feb 20 16:39
    anatoliykmetyuk assigned #8353
  • Feb 20 16:39
    anatoliykmetyuk opened #8353
  • Feb 20 16:16
    anatoliykmetyuk commented #8351
  • Feb 20 15:40

    nicolasstucki on master

    Clean tests output An environm… Merge pull request #8352 from d… (compare)

  • Feb 20 15:40
    nicolasstucki closed #8352
  • Feb 20 14:40
    anatoliykmetyuk commented #8351
  • Feb 20 14:39
    anatoliykmetyuk commented #8351
Guillaume Martres
@smarter
see Microsoft/vscode#50140 for example
yup
There's also the scalameta parser which is lagging way behind Dotty's
Anatolii Kmetiuk
@anatoliykmetyuk
Why aren’t scalameta & Dotty sharing the same parser? Would make sense, since they are a part of the same ecosystem
Guillaume Martres
@smarter
scalameta's parser outputs scalameta AST representation which is designed to preserve all syntactic elements to allow source-to-source transformations (as used by scalafix, scalafmt)
It even keeps track of all tokens for each tree node I think
and I heard it's not very fast
also scalameta tries to parse everything from 2.10 onwards, and even supports sbt syntax
Anatolii Kmetiuk
@anatoliykmetyuk
So that’s Scalameta, Dotty and various IDE & text editor parsers that need to be maintained consistent at the same time?
Guillaume Martres
@smarter
Yeah, it's not ideal
If we stop changing syntax every week it's not too bad though :)
and if every IDE/text-editor/syntax-highlighting-library standardizes on tree-sitter
Anatolii Kmetiuk
@anatoliykmetyuk
What’s so special about tree-sitter? As I see they don’t even have Scala support so far, it is still in development?
Guillaume Martres
@smarter
Anatolii Kmetiuk
@anatoliykmetyuk
The official site marked that repo under “under development” section
Guillaume Martres
@smarter
There's a few talks at the bottom of https://tree-sitter.github.io/tree-sitter/ which explains what the point is
Dotty's parser main concerns are: 1) Be fast enough to not be a bottleneck (which isn't too hard since everything else takes so much time), 2) Provide good error messages 3) Preserve the position of every element (to provide good error messages in later phases and good IDE support) 4) Recover from parsing errors to still produce a valid AST that we can typecheck, mostly so that IDE features like go-to-definition don't suddenly break when your file doesn't parse (which is most of the time when you're typing in an IDE), this isn't perfect yet: lampepfl/dotty#4463
Guillaume Martres
@smarter
I think tree-sitter's main concerns are: 1) provide a framework to describe the grammars of most languages 2) be very fast (when I open a file in my IDE, syntax highlighting should be instantaneous), 3) Recover from parsing errors in a consistent way (I don't want syntax highlighting to do random things when I start typing in my IDE) 4) probably more stuff I forget because I watched the talk a while ago :)
In any case, it can hardly be worse than a million regexps wrapped in xml
and yes it's still in development, but considered good enough to be used in Atom: https://github.blog/2018-10-31-atoms-new-parsing-system/
Anatolii Kmetiuk
@anatoliykmetyuk
There’s quite a lot to these things when you start looking closer into them. And that’s just the parsing part of the programming language. Complex stuff.
Guillaume Martres
@smarter
Everything is fractal :)
Also everything has weird trade-offs: lampepfl/dotty#5928
Olivier ROLAND
@newca12
@smarter thanks for the gitter activity stream resurrection :-)
Jacob Wang
@jatcwang

I am playing around with union types and typeclasses. I want to say "If all types in a union has a typeclass instance, we can derive an instance of the typeclass for the union type"
The following does not compile due to diverging implicit resolution.

  trait Boo[A]

  implicit val v: Boo[Int] = ???
  implicit val s: Boo[String] = ???
  implicit def unionInstance[A, B](implicit booA: Boo[A], booB: Boo[B]): Boo[A | B] = ???
  implicitly[Boo[Int | String]]

https://scastie.scala-lang.org/vTAr2PQ1Rpez4sGAMnSAaA

How would I go about solving this problem?

Guillaume Martres
@smarter
Type inference and union types don't interact in a very intuitive way
When the compiler sees Int | String <: ?A | ?B, it's first going to see if it can make Int | String <: ?A
so in your example it's probably trying unionInstance[Int | String, Nothing](<recursive search>)
I haven't been able to come up with an algorithm that behaves more intuitively and generalizes well (e.g., what if you did implicitly[Boo[Int | String | Bla]] ? Do you expect that to do unionInstance[Int | String, Bla], or unionInstance[Int, String | Bla], or something else entirely ?)
Jacob Wang
@jatcwang
Yeah union types are troublesome because they're flat and associative.
If the compiler has built in support for F[A] | F[B] => F[A | B] when it comes to implicit resolution then it can specialize the search algorithm. I think building that into the compiler might cause other problems though..
sry not just associative, it should be commutative too
Guillaume Martres
@smarter
If F is covariant in its type parameter, then F[A] | F[B] is a subtype of F[A | B]
so not sure what you mean by built-in support
Jacob Wang
@jatcwang
Basically, when a compiler need to look for a F[A | B], it will look for F[A] and F[B] individually and then combine them if both are found. (I'm not saying it's a good idea because my gut is telling me no :P )
Guillaume Martres
@smarter
ah, I see, yeah that sounds a bit scary
but if F is covariant, then this will just happen naturally, i.e. if we find an F[A] then we're good
if F is invariant, then even if you find an F[A] and an F[B] you can't make up an F[A | B]
Abel Nieto
@abeln
I synced today and noticed that all the submodules (collections-strawman, scala-backend, scala2-library) disappeared. What happened? Is this related to dotty bootstrapping only with dotty and not scalac?
I see they got inlined: lampepfl/dotty#5869
Guillaume Martres
@smarter
Abel Nieto
@abeln
Thanks. Where are we w.r.t the bootstrapping? Did the move to dotty-only bootstrapping happen/is planned to happen soon?
Guillaume Martres
@smarter
planned soon
pr to watch is lampepfl/dotty#5923
Abel Nieto
@abeln
ok, thanks
Miles Sabin
@milessabin

With boolean extractors, is there any reason why they have to be used as @ patterns?
The example is given as,

object Even {
  def unapply(s: String): Boolean = s.size % 2 == 0
}

"even" match {
  case s @ Even() => println(s"$s has an even number of characters")
  case s          => println(s"$s has an odd number of characters")
}

but it'd be a lot nicer if we could write,

object Even {
  def unapply(s: String): Boolean = s.size % 2 == 0
}

"even" match {
  case Even(s) => println(s"$s has an even number of characters")
  case s       => println(s"$s has an odd number of characters")
}
Guillaume Martres
@smarter
it's weird yeah
Miles Sabin
@milessabin
Weird as in "weird we should fix it" or as in "weird but we're stuck with it because reasons"?
Guillaume Martres
@smarter
I don't know :)
Miles Sabin
@milessabin

Concretely I have an example which I have to write as,

x match {
  case Complete(t) => ...
  case t @ Continue() => ...
}

which I'd like to be able to write as,

x match {
  case Complete(t) => ...
  case Continue(t) => ...
}

The former will be very error prone because people will expect the latter.

Guillaume Martres
@smarter
I'm all for fixing it