Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 08:22

    lrytz on 2.13.x

    Teach backend to emit `iinc` in… Merge pull request #9713 from h… (compare)

  • 08:22
    lrytz closed #9713
  • 08:22
    lrytz closed #7452
  • 06:59
    som-snytt edited #9712
  • 06:56
    som-snytt synchronize #9712
  • 06:16
    mpartel opened #12436
  • 03:35
    harpocrates synchronize #9713
  • 03:30
    harpocrates synchronize #9713
  • 03:11
    NthPortal commented #12400
  • 02:43
    SethTisue labeled #9713
  • 02:43
    SethTisue labeled #7452
  • 02:42
    SethTisue labeled #7452
  • 02:42
    SethTisue unassigned #7452
  • 02:42
    SethTisue milestoned #7452
  • 02:42
    SethTisue demilestoned #7452
  • 02:39
    scala-jenkins milestoned #9713
  • 02:39
    harpocrates opened #9713
  • 00:13
    som-snytt commented #769
  • Jul 29 23:58
    SethTisue commented #769
  • Jul 29 22:43
    som-snytt synchronize #9712
Martijn
@martijnhoekstra:matrix.org
[m]
I think the point is that there may be some C extends A with B, but I don't understand what the point is anymore
Rob Norris
@tpolecat
But X is B. We know it’s not C.
Tom Grigg
@griggt
yes, it reduces if at least one of A or B is sealed
Martijn
@martijnhoekstra:matrix.org
[m]
there is more documentation on the documentation of match types: https://dotty.epfl.ch/docs/reference/new-types/match-types.html, which mentions
The compiler implements the following reduction algorithm:

If the scrutinee type `S` is an empty set of values (such as Nothing or String & Int), do not reduce.
Sequentially consider each pattern Pi
If S <: Pi reduce to Ti.
Otherwise, try constructing a proof that S and Pi are disjoint, or, in other words, that no value s of type S is also of type Pi.
If such proof is found, proceed to the next case (Pi+1), otherwise, do not reduce.
Rob Norris
@tpolecat
We know B is not a subtype of A.
Why do we care if there may some day be a value that’s both an A and a B?
Match types are absolutely baffling.
Martijn
@martijnhoekstra:matrix.org
[m]
They are covariant in some way it seems
trait Base
class Derived extends Base

type M[X] = X match {
  case Base => Int
  case Derived => String
}

def testit: Int = 7: M[Derived]
this compiles
Rob Norris
@tpolecat
...
ooookay
Martijn
@martijnhoekstra:matrix.org
[m]
😶
Bjorn Regnell
@bjornregnell
Would it be possible to also allow the new control syntax in 2.13.x? if then, while do, for do
Guillaume Martres
@smarter
@tpolecat, it's not very different from term match, if you write case x: Base => ...; case x: Derived => ... you're always going to hit the first case
in fact the whole point is that you can write your term match to mirror your match type
(and give your term match an expected type which is that match type, and have that infer correctly)
and the compiler prevents you from doing the reduction in situations where it cannot know at compile-time which case would be taken at runtime
Rob Norris
@tpolecat
Thanks, that’s helpful.
Guillaume Martres
@smarter
I'm glad :)
Rob Norris
@tpolecat
It seems awkward to me to have type and term-level representations of the same program, plus all the machinery to ensure that they are consistent, as opposed to the shapeless style where they are woven together. I will have to play around with it some more.
Seth Tisue
@SethTisue

Would it be possible to also allow the new control syntax in 2.13.x? if then, while do, for do

if a pull request came in adding that under -Xsource:3 I can't see why it wouldn't be accepted

Bjorn Regnell
@bjornregnell
@SethTisue That would be really cool in these times of migration.

if a pull request came in adding that under -Xsource:3 I can't see why it wouldn't be accepted

Would it be sensible if I create an issue on scala/bug for this enhancement?

Oron Port
@soronpo
There is something very annoying yet very satisfying in minimizing compiler crash issues. It can take up to several hours of mind-numbing work, but still it calls to me like a moth to a flame.
Jasper Moeys
@Jasper-M

It seems awkward to me to have type and term-level representations of the same program, plus all the machinery to ensure that they are consistent, as opposed to the shapeless style where they are woven together.

That's my biggest issue with the type-level stuff in scala 3. The main issue against shapeless style type-level programming seemed to be that you have to switch to a Prologish mindset. But at least in that style all the type-level and value-level code beautifully works together. With scala 3 match types and mirrors and all that stuff, types and implementations are separated and often you have to use casts to make them agree.

cmhteixeira
@cmhteixeira

Dear type-level masters, how is the below possible?

class Door[State <: DoorState] {
    def doorKey: Int = 1
    def open[Phatom >: State <: Closed.type]: Door[Open.type] = new Door[Open.type]
    def close[Phatom >: State <: Open.type]: Door[Closed.type] = new Door[Closed.type]
}

sealed trait DoorState
case object Closed extends DoorState
case object Open extends DoorState

println(aClosedDoor.open.close.close.doorKey == 1)  // How come this is compiling?

I am able to close a closed door. The compiler is not enforcing type bounds
Is this a bug? Am I missing something?
(also published on scala/scala gitter channel)

Rob Norris
@tpolecat
You can make Open and Closed extend some supertrait and parameterized it as [A <: DoorState] if you like but it probably doesn't matter.
Upper bounds are rarely necessary.
Guillaume Martres
@smarter
@tpolecat conversation on this issue was moved to scala/scala
Rob Norris
@tpolecat
ah
Guillaume Martres
@smarter
(spoiler: it's fixed in dotty)
cmhteixeira
@cmhteixeira
@tpolecat As smarter says, its on scala/scala. Thanks. The question was also more with the objective of understanding why that was happening. I was already aware of the implicit alternative. I appreciate it though!
For reference, we ended up opening this ticket: scala/bug#12413
Rob Norris
@tpolecat
ok
Swoorup Joshi
@Swoorup
this should ideally fail type check isn’t it?
import scala.language.implicitConversions

type Timeframe = "1m" | "2m" | "1H"
type TimeframeN = 1 | 2 | 60

def manualConvertToN(tf: Timeframe): TimeframeN = tf match
  case "1m" => 1
  case "2m" => 2
  case "1H" => 60
  case "4H" => 60 // incorrect
Rob Norris
@tpolecat
Seems like a bug to me. Looks like it's checking that the LHS is a string (case true => ... fails) but it needs to check that it's a Timeframe.
Swoorup Joshi
@Swoorup
yep logged a bug: lampepfl/dotty#12805
seems to prematurly widen
sinanspd
@sinanspd
hmm
aren't Enums a better use for this ?
like i am actually not sure what the expected behavior here should be
You are creating a union type with concrete values, no?
sinanspd
@sinanspd
nvm it seems like this is in fact expected to work
Swoorup Joshi
@Swoorup
they are good near the boundaries interacting with other languages, or doing things like
def acceptFontSize(fontSize: 9 | 10 | “11rem”) = ???
widening/or unwidening are purely a compile time construct
Bjorn Regnell
@bjornregnell
I have problems translating "universal apply methods" and "creator applicators" to Swedish in my lectures. I'm considering instead to use the translation of "optional new" (in Swenglish this becomes "valfri new", which to me seems less intimidating to a beginner). Does anybody know why it is called "universal apply methods" (which to me seems kind of a bold name as the universe consists of more than classes ;)) and why the name "creator applicators" was dropped (if it was?) and if "optional new" is ok as a name for the language feature of a generated apply calling a/the constructor also for plain classes not just case classes?
som-snytt
@som-snytt
"auto-application of constructor proxy object"
scala> class C
// defined class C

scala> extension (c: C.type) def f = 42
1 |extension (c: C.type) def f = 42
  |              ^
  |              constructor proxy object C cannot be used as a value
Bjorn Regnell
@bjornregnell

"auto-application of constructor proxy object"

Wow that's a mouthful :emoji-with-mouthful:

Bjorn Regnell
@bjornregnell
The English "proxy" translates to Swedish as "ombud", which is a conceptual part of one of the few Swedish loanwords we have exported to English, namely "ombudsman". We also have exported "smorgasbord", which perhaps could be used as a generic collective name for all goodies in Scala 3. Or perhaps "smorgasbord" is what we get when we press TAB in the Scala 3 REPL. :)