Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 29 19:38
    TheElectronWill labeled #15383
  • Sep 29 19:38
    TheElectronWill commented #15383
  • Sep 29 19:37
    TheElectronWill commented #15383
  • Sep 29 19:35
    TheElectronWill commented #15383
  • Sep 29 17:53
    carlosedp commented #16124
  • Sep 29 17:52
    carlosedp opened #16124
  • Sep 29 17:52
    carlosedp labeled #16124
  • Sep 29 17:52
    carlosedp labeled #16124
  • Sep 29 17:47
    armanbilge commented #15383
  • Sep 29 17:43
    armanbilge commented #15383
  • Sep 29 17:19
    odersky commented #16115
  • Sep 29 17:19
    odersky commented #16115
  • Sep 29 17:18
    odersky commented #16115
  • Sep 29 17:18
    odersky labeled #16115
  • Sep 29 17:18
    odersky unlabeled #16115
  • Sep 29 17:08
    odersky synchronize #16122
  • Sep 29 17:05
    odersky assigned #16122
  • Sep 29 17:04
    odersky review_requested #16122
  • Sep 29 16:53
    odersky commented #14514
  • Sep 29 16:49
    odersky assigned #14514
Jakub Kozłowski
@kubukoz
Has new type Foo = Int been considered as syntax for opaque types? It doesn't require any new keywords (unlike opaque)
Also, A *: () is totally kiss syntax
odersky
@odersky
There are some comments on new type at the end of the Opaque Types thread on Discourse.
megri
@megri
@kubukoz kiss like Unit kisses A?
Jakub Kozłowski
@kubukoz
@odersky thank, will look
@megri yeah, reads RTL :joy:
Matthew Pickering
@mpickering
Just to clear things up: The dotty principled metaprogramming implementation doesn't have implicit cross-stage persistence for values but does for types?
I am also a bit unclear about the representation for quotations, is the representation syntax trees which are explicitly typed and contain implicit evidence?
Matthew Pickering
@mpickering
It seems that the syntax was changed at some point to use ~ rather than $ but the documentation has not been updated .https://dotty.epfl.ch/docs/reference/other-new-features/principled-meta-programming.html
odersky
@odersky
The docs about meta programming are currently outdated. @biboudis and @nicolasstucki are preparing new docs.
Andriy Plokhotnyuk
@plokhotnyuk
:+1:
Rich
@Rich2
I was looking at the doc on Typeclass derivation and there didn't seem to be any facility for ad-hoc sum types.
Matthew Pocock
@drdozer
hey - just wondering - is there a reason that postfix decorator syntax works only on single values, and not on full argument lists?
trait PdbColumn[C[_], T] {
  def (charStart: Int, charEnd: Int, field: String, definition: String) col[T]: C[T]
}
So I can't do this, sadly
The hack is:
trait PdbColumn[C[_], T] {
  def col[T](charStart: Int, charEnd: Int, field: String, definition: String): C[T]
  def (ts: Tuple4[Int, Int, String, String]) col[T]: C[T] = col[T](ts._1, ts._2, ts._3, ts._4)
}
Alessandro Vermeulen
@spockz
It seems that the link to multiversal equality on the homepage is broken: http://dotty.epfl.ch/docs/reference/other-new-features/multiversal-equality.html << gives a 404}
PR to update broken links are welcome
Xavier GUIHOT
@xavierguihot
Hi, playing with the new parameter untupling feature; any plans to also have the possibility to do this in the future?
def f(a: Int, b: Int): Int = a * b
List((1, 2), (3, 4)).map(f(_, _ * 2))
Guillaume Martres
@smarter
good question, I'm not sure
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 ... =>
:D
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/