Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 22:45
    SethTisue commented #728
  • 22:42
    SethTisue assigned #728
  • 22:36
    SethTisue opened #728
  • 21:45
    octonato commented #9279
  • 21:44
    som-snytt commented #9275
  • 21:43
    som-snytt ready_for_review #9275
  • 21:35
    dwijnand review_requested #9278
  • 21:35
    dwijnand edited #9278
  • 21:34
    som-snytt commented #9279
  • 21:33
    SethTisue commented #9278
  • 21:32
    dwijnand commented #9279
  • 21:30
    SethTisue labeled #2453
  • 21:30
    SethTisue labeled #9279
  • 21:30
    som-snytt commented #9279
  • 21:29
    dwijnand commented #1265
  • 21:29
    dwijnand commented #1265
  • 21:28
    dwijnand edited #1265
  • 21:20
    som-snytt synchronize #9275
  • 21:16
    octonato commented #9279
  • 21:16
    octonato commented #9279
Harrison Houghton
@hrhino
please report it?
Martijn Hoekstra
@martijnhoekstra
def test1(f: Foo): Unit = {
  import f.{bar => baz}
  baz += 1  // no
}
sounds like it should work. I'd investigate if not working is not a bug.
Luciano
@lJoublanc
@JanBessai Thanks for your hint. I've managed to minimize the use case, as follows:
import simulacrum.typeclass

@typeclass trait MyTypeclass[F[_[a] <: Option[a]]] {
  def foo[A,G[a] <: Option[a],H[a] <: Option[a]](fa : F[G]) : F[H]
}

trait Test[A] {
  type F[a] <: Option[a]
  type B <: Int
}

object Test {

  type Aux[A,F0[a] <: Option[a], B0 <: Int] = Test[A] { type F[a] = F0[a] ; type B = B0 }

  def apply[A,F0[a] <: Option[a],B0 <: Int] : Aux[A,F0,B0] = new Test[A] { type F[a] = F0[a]  ; type B = B0 }

  implicit def instance[A,B] : MyTypeclass[Aux[A,?[_],B]] = ???
}
And I think I know what causes this ... I now recall asking this before. I think it's a problem with partial unification.
This doesn't raise errors when F0[a] is the last parameter.
Harrison Houghton
@hrhino
@martijnhoekstra it's a bug because when the rewrite happens, the setter is referenced by name, not by symbol
or at least, that's what I'd say
Martijn Hoekstra
@martijnhoekstra
I'd say the same, but the spec surprised me before. Then again, if this is as specced, I'd argue it's a bug in the spec and the implementation both
Harrison Houghton
@hrhino
If x is a parameterless method defined in some template, and the same template contains a setter method x_= as member, then the assignment x = e is interpreted as the invocation x_=(e) of that setter method. Analogously, an assignment f.x = e to a parameterless method x is interpreted as the invocation f.x_=(e).
hmm, so, that's vaguely ambiguous since x is a symbol, not a name, but it doesn't explain what a "setter method" is
other than that in this case x's setter method is x_=

when it comes to imports,

If x is bound by an import clause, then the simple name x is taken to be equivalent to the qualified name to which x is mapped by the import clause.

which is also kinda ambiguous

but I would argue that on the whole, if some expression works with a non-renaming import, it should work with the renaming import modulo α-conversion of the name within the scope of the import
Martijn Hoekstra
@martijnhoekstra

If x is a parameterless method defined in some template, and the same template contains a setter method x_= as member

if you import rename x => y, that doesn't change that the template doesn't contain a setter method x_=

so I'd call it a bug in both spec and impl :D
Harrison Houghton
@hrhino
right...
although that's not the correct spot, because that's the bit that deals with class T { var x = 1 ; x = 2 }
the "analogously..." sentence is the applicable one
I would say it should define "setter method" as "the method in the same template with the name derived from x by appending _=", or something
segeljakt
@segeljakt
What type of polymorphism is:
def func[A,B,C](a: A, b: B, c: C) = ...
func(3, "abc", 'o')
Harrison Houghton
@hrhino
then the method has a setter method...
@klassegeljakt just your bog standard parametric polymorphism.
Martijn Hoekstra
@martijnhoekstra
I'll leave you to the specese. gl;hf
Harrison Houghton
@hrhino
nah
I'd rather just fix the bug, and let others write the specese
segeljakt
@segeljakt
ok, what type of polymorphism is
def func[T](l: T*) = ...
func(3, "abc", 'o')
Harrison Houghton
@hrhino
Exact same.
Parametric polymorphism is polymorphism done with type parameters, hence the name
Fabio Labella
@SystemFw
well, that case is weird
well, not weird
but not strictly parametric polymorphism either, it's interacting with variance and sub typing there
Harrison Houghton
@hrhino
as opposed to, say, inheritance polymorphism, which is done by having an interface as a superclass of everything you want to accept
ah, true
Fabio Labella
@SystemFw
basically in a language with no sub typing, that would be an example of parametric polymorphism that doesn't compile :)
ah, you changed it
now it doesn't compile in Scala either :)
segeljakt
@segeljakt
oh
is Seq not covariant?
Fabio Labella
@SystemFw
ah, with Seq yeah, it does
Martijn Hoekstra
@martijnhoekstra
T is inferred to be Any - so the question is also "what kind of polymorphism is def func(l: Any*) = ???; func(3, "abc", 'o')" - to which the answer is "that not polymorphism, that's just making me cry"
Fabio Labella
@SystemFw
yeah pretty much
segeljakt
@segeljakt
I thought the first one was first-class monomorphic and the second one was second-class polymorphic
I don’t know the terms strictly
Fabio Labella
@SystemFw
yeah, no
that doesn't make a lot of sense :)
Harrison Houghton
@hrhino

@martijnhoekstra

        if (treeInfo.mayBeVarGetter(varsym)) {
          lhs1 match {
            case treeInfo.Applied(Select(qual, name), _, _) =>
              val sel = Select(qual, name.setterName) setPos lhs.pos
              val app = Apply(sel, List(rhs)) setPos tree.pos
              return typed(app, mode, pt)

            case _ =>
          }
        }

so yeah, it's doing a naïve name-based lookup. if you don't feel like filing a bug, lmk and I will

segeljakt
@segeljakt
Second class = upcast to common supertype?
Fabio Labella
@SystemFw
no, that terminology doesn't really exist afaict
segeljakt
@segeljakt
"So here we have the crux of the problem — we can have first-class monomorphic function values and we can have second-class polymorphic methods, but we can’t have first-class polymorphic function values … at least we can’t with the standard Scala definitions. And yet it’s first-class polymorphic function values that we need to map over an HList … what to do?"
Fabio Labella
@SystemFw
no, first class polymorphism is a different thing