Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 13:02
    odersky commented #7083
  • 13:02
    odersky commented #7083
  • 12:53
    sdual starred lampepfl/dotty
  • 12:28
    aappddeevv commented #4672
  • 12:25
    smarter commented #4672
  • 12:22
    aappddeevv commented #4672
  • 12:20
    milessabin commented #7078
  • 12:00
    smarter synchronize #7019
  • 11:15
    smarter synchronize #7019
  • 10:28
    smarter synchronize #7019
  • 09:17
    joan38 commented #7083
  • 09:12
    LPTK commented #7083
  • 09:09
    joan38 commented #7083
  • 09:01
    joan38 commented #7083
  • 08:59
    joan38 commented #7083
  • 08:29

    odersky on master

    Allow infix operators at start … Merge pull request #7031 from d… (compare)

  • 08:29
    odersky closed #7031
  • 08:25
    odersky commented #7083
  • 08:04
    erinmez starred lampepfl/dotty
  • 07:02
    joan38 commented #7083
Guillaume Martres
@smarter
Haskell does use higher-ranked types to make ST safe,, and you can do the same in Dotty
but it doesn't change the fact that there are other language constructs you can call which allow you to perform side-effects
In Haskell, they can say "this is sound as long as you don't screw up when you use unsafePerformIO / etc"
In Scala, we can't do that
Wojciech Daniło
@wdanilo
@smarter interesting. What would need to change in the concept of Scala to allow such guarantees ?
Guillaume Martres
@smarter
Make Scala a purely functional language, abandon direct interop with Java.
So make a different language basically.
Ashwin Bhaskar
@ashwinbhaskar
class Ref[T](var x: T)
val f: [T] Ref[List[T]] = new Ref(Nil)   //This line does not compile

val r1: Ref[List[Int]] = f[Int]
val r2: Ref[List[String]] = f[String]
r1.x = List(1)
The second line compilation fails with the error '=>>' expected, but identifier found
@smarter was this example meant to be compiled?
Guillaume Martres
@smarter
@ashwinbhaskar no, it uses a hypothetical syntax for polymorphic values that doesn't exist
Ashwin Bhaskar
@ashwinbhaskar
@smarter okay
Oleg Galako
@ojow
hi, is there a way to avoid wrapping implicit functions when they are used as value with the same expected type? it keeps accumulating if used in loops
https://gist.github.com/ojow/2c7ec2683ca2c78ca27756740c151a56 note the difference between results for old style functions and implicit functions
Guillaume Martres
@smarter
@ojow No, this is a known issue
Oleg Galako
@ojow
thanks!
Henry Story
@bblfish
how much of the scala collections is in dotty?
Jamie Thompson
@bishabosha
@bblfish currently in 0.17.0-RC1 - all of the collections in the 2.12.8 scala-library
Henry Story
@bblfish
Ah ok: I was looking for Seq.unfold, but perhaps that was added to 2.13
Jamie Thompson
@bishabosha
@bblfish yes, I just checked that is new to 2.13 - we are working on upgrading to 2.13 library soon
Henry Story
@bblfish
+1
Thanks. It's actually LazyList I needed to calculate the fibonacci sequence :-) Super fast when done lazily.
Guillaume Martres
@smarter
You can use Stream in 2.12
aappddeevv
@aappddeevv

syntax errors for extension method returning implicit function: I get syntax errors with combining both of these together.

type Processor[T] = given Context => T
def (root: xml.Elem) process: Processor[Result] = ...
val root = XML.loadString(...)
given ctx as Context = ...
val result = root.process

gives an error value process is not a member of xml.Elem. However, def (root: xml.Elem) blah: Result typechecks fine. I'm using extension methods, implicits functions and typeclasses fine on their own. Thoughts?

Guillaume Martres
@smarter
sounds like you should open an issue.
aappddeevv
@aappddeevv
Ben Hutchison
@benhutchison
Is there any way to assert something shouldn't compile in Dotty, that compiles ;P ?
aappddeevv
@aappddeevv
not sure union type for types with type parameters is useful: I was trying to represent the result of parsing an xml file. I'm using a 3rd party lib that returns ParseResult[T]. I have 2 types of Ts that can be return T1 and T2, so type Result = ParseResult[T1] | ParseResult[T1]. The problem is that when I use match statements to operate on the results, type erasure means that I cannot distinguish between the two. Is there a better dotty way? ParseResult is a GADT with three possible subtypes.
Guillaume Martres
@smarter
Wrap in an either, or pattern match on values with more specific types inside the ParseResult term.
aappddeevv
@aappddeevv
Then I wind up with 6 pattern matches inside my match which felt fairly awkward. I have some more results that will not be ParseResult, but probably JsonResult[T] so I was hoping to stick with |.
Guillaume Martres
@smarter
e.g. if you List[Int] | List[Double], you can pattern match on the type of head to know which one you're dealing with
of course people will tell you that this is bad because of parametricity etc
aappddeevv
@aappddeevv
Seems like parametricity is the issue. I had also tried ParseResult[T1|T2] but then I get the 6 case statement problem again.
Does a match type help me? Seems like I would have the same problem.
Guillaume Martres
@smarter
when in doubt, keep it simple, use an ADT.
aappddeevv
@aappddeevv
I want to but the ParseResult is fixed so I don't think the "enum type" can be constructed.
Guillaume Martres
@smarter
your ADT can wrap values of type ParseResult
aappddeevv
@aappddeevv
Good point, a wrapper would take care of that.
At least I could managed the types then and I can extend it when I get to writing parsers for the other content that don't return the same type of result. I'll see how that looks.
aappddeevv
@aappddeevv
The enum worked well.
Henry Story
@bblfish

I was reading a paper that made an interesting claim about equalisers and coequalisers

Products and co-products are common, but equalizers and co-equalizers are not, perhaps because they correspond to dependent types (since they are objects depending on morphisms).

I had actually never thought of (co)equalisers as something that could appear in types, so I asked the authors if they might have an example in DOT as it is a Dependent Object Types. They showed me the following code in Coq, but thought did not know if this could be expressed in Scala.

Record Quotient {T} (R: T->T->Prop) (pf : equivalence T R) := mkQuo {
 Quo : Type;
 eqc : T -> Quo;
 repr: Quo -> T;
 pfResp1 : forall {a b}, R a b -> eqc a = eqc b;
 pfResp2 : forall {q}, R q (repr (eqc q));
 pfSurj  : forall q, eqc (repr q) = q;
}.
Axiom axiomQ : forall {T} (R:T->T->Prop) pf, Quotient R pf.  //quotients must be postulated in vanilla Coq

In the above, you can see very clearly that the type Quo is a function of the term R. But I do not know enough Dotty/Scala to be able to rule out such a type altogether.

Oleg Galako
@ojow
am I doing something wrong or is it a known issue?
scala> def bar(xs: Seq[given Int => String])  = classOf[ImplicitFunction1[Int, String]].isAssignableFrom(xs.asInstanceOf[Seq[Any]].head.getClass)
def bar(xs: Seq[given Int => String]): Boolean

scala> bar(Seq(""))
val res2: Boolean = true

scala> class A extends ImplicitFunction1[Int, String] { override def apply given Int: String = the[Int].toString }
// defined class A

scala> bar(Seq(new A))
1 |bar(Seq(new A))
  |        ^^^^^
  |        Found:    A
  |        Required: String
in other words class A extends ImplicitFunction1[Int, String]is not accepted where ImplicitFunction1[Int, String] is expected
Jamie Thompson
@bishabosha
@ojow I don’t think this has been reported before, you should make an issue: https://github.com/lampepfl/dotty/issues
but I believe it is because ImplicitFunction1 is actually not a class, just some magic
Guillaume Martres
@smarter
It's a class as far as the typechecker is concerned
But the logic that deals with implicit functions looks for direct instances of implicitfunctionN
It's intended behavior but I'm not completely happy with it
We should either disallow extending implicitfunctionN or change the logic
Oleg Galako
@ojow
thanks for the replies, here's the issue lampepfl/dotty#7090
aappddeevv
@aappddeevv

I'm trying to use AnyKind but I'm not sure its working in this case (this involves connecting to AWS, sttp, Zio):

type RequestType = [T]=>> RequestT[Id, T, Nothing]
trait RequestSigner[R <: AnyKind] extends (R => R) { ... }
class AWSSigner() extends RequestSigner[RequestType] { 
  def apply[T](r: RequestType[T]): RequestType[T] = { ... }
}
trait Client[R <: AnyKind] extends (R => R) { def host: String }
class ESClient(signer: RequestSigner[RequestType]) extends Client[RequestType] {
  def apply[T](r: RequestType[T]) = signer[T](r)
  def host = "blah"
}

The error I get is

method apply in trait Function1 does not take type parameters
[error]   def apply[T](r: RequestType[T]) = signer[T](r)

I've tried signer[T] and signer(r) and other things. It seems that the (R => R) in Client causes a problem and I wonder if the (R => R) is handling AnyKind correctly as I would expect it to adapt to the right kind of function argument.
Thoughts?

aappddeevv
@aappddeevv
I did some more reading and it appears that the extends R=>R is not polymorphic so I'll probably just hard code -> into RequestSigner and Client for now unless there is a way to encode around this.