Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 10:24
    nicolasstucki synchronize #16392
  • 10:17
    nicolasstucki synchronize #16427
  • 10:08
    dwijnand synchronize #16445
  • 10:03
    nicolasstucki synchronize #16427
  • 09:24
    nicolasstucki labeled #16447
  • 09:24
    nicolasstucki unlabeled #16447
  • 09:23
    nicolasstucki labeled #16447
  • 08:53
    KacperFKorban synchronize #16425
  • 08:49

    smarter on main

    Avoid incorrect simplifications… Avoid incorrect simplifications… (compare)

  • 08:49
    smarter closed #16410
  • 08:40

    prolativ on main

    Improve bisect script: * Use … Universal bisect script (#16398… (compare)

  • 08:40
    prolativ closed #16398
  • 08:39
    nicolasstucki synchronize #16427
  • 08:27
    prolativ commented #16286
  • 08:10
    nicolasstucki synchronize #16392
  • 08:00
    nicolasstucki synchronize #16392
  • 07:12
    liufengyun edited #16448
  • 07:12
    liufengyun edited #16448
  • 07:11
    liufengyun synchronize #16448
  • 05:59
    rayrobdod starred lampepfl/dotty
Guillaume Martres
@smarter
Yes, eventually the spec will be updated
Andrey
@sugakandrey
Makes sense, thanks for the clarification. Looking through the commit history, it looks like the MatchCase is a fairly recent addition.
Matthew Pocock
@drdozer
hey - I've got some higly parameterised code that's ended up building heavily left-nested tuples e.g. (((((((((((((String, Int), String), String), Char), Int), Char), String), Char), Int), Char), pdb.HelixClass), String), Int)
Is there a way to combine a new element onto the right of an existing tuple that doesn't cause this profligate nesting?
Guillaume Martres
@smarter
String *: Int *: String *: Unit should work
The last element must be Unit or a tuple
Matthew Pocock
@drdozer
thanks - is there a typeclass or whitness to that?
def f[A, B](a: A, b: B) = a *: b needs something to say that B is a type with *:
Guillaume Martres
@smarter
this is just syntactic sugar for tuples
or more precisely, in Dotty the type (A,B) is syntactic sugar for the type A *: B *: Unit
Matthew Pocock
@drdozer
thanks - adding the type bounds B <: Tuple has caused a compiler crash ...
(Compile / compileIncremental) java.nio.file.NoSuchFileException: /drone/src/github.com/lampepfl/dotty/library/src-3.x/scala/Tuple.scala
shall I open an issue?
Martin Egri
@megri
@smarter I've always thought Unit is just a type and () is its singleton instance. Is it a symbol in Dotty?
Guillaume Martres
@smarter
What ?
Unit is a type and () is the single instance of that type yes
not sure what you mean by symbol
Martin Egri
@megri
Oh I misread your earlier comment. So in Dotty tuples can be created like 1 *: 2 *: 3 *: () ? :)
Neither am I to be honest ;) I always mix up types and terms and symbols and those abstract words.
Well, Types are pretty obvious.
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.
Martin Egri
@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