Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 08:40
    lrytz edited #9536
  • 08:39
    lrytz edited #9536
  • 08:39
    smarter commented #12396
  • 08:34
    lrytz edited #7785
  • 08:24
    lrytz edited #9615
  • 08:22
    lrytz labeled #9336
  • 08:14
    lrytz edited #770
  • 08:14
    lrytz edited #770
  • 08:14
    lrytz edited #770
  • 08:14
    lrytz edited #770
  • 08:13
    lrytz edited #9482
  • 08:13
    lrytz edited #9482
  • 08:12
    lrytz edited #9482
  • 08:12
    lrytz edited #9482
  • 08:11
    lrytz edited #9504
  • 08:03
    lrytz edited #9525
  • 07:56
    lrytz edited #9525
  • 07:55
    lrytz edited #9525
  • 07:48
    lrytz edited #9542
  • 07:47
    lrytz commented #2015
Rich
@Rich2
Have constructors for non-case classes become unfashionable?
Jose C
@jmcardon
it's not that, just rather that making a calculation inside the constructor paramter is not common in scala, I guess
Rich
@Rich2
No well I can't say I have seen it in other languages either. I guess the syntax is not possible in most languages.
Martijn Hoekstra
@martijnhoekstra
In the scala I write I don't think I've ever inhereied from a superclass with a constructor - but that might say more about me than about scala or whether or not that's a good idea.
Rich
@Rich2
I think not having constructors in traits, I suspect has got Scala developers into the habit of not using them.
Rich
@Rich2

I kind of got the impression that a lot of function programmers were quite receptive when they heard about Scala, a statically typed language for the JVM. But then some of them became quite angry when they discovered that Martin had not merely done the minimum OO to ease compatibility with Java, as say F# did with dot net but had actually expanded the power and capability of OO.

They liked to argue that the benefits of OO were totally outweighed by the costs. By expanding the benefits of OO under Scala Martin had made their argument more difficult. Without Scala OO might have gradually died out. It seems to me that Dotty with trait parameters, type member- parameter unification and soundness rigour of the dot calculus is going to again dramatically increase the OO power of the language. I wonder if we will see a similar reaction.

Martijn Hoekstra
@martijnhoekstra
maybe, I don't know
at the moment I can't remember when the last time was I thought it was useful to subclass a concrete class
maybe in Scala 3 I'll see that again
Fabio Labella
@SystemFw
I'm not sure that type parameter and members are actually fully unified in dotty
iirc when they actually tried to implement HKT that way they hit enough blocks that they had to settle for a direct representation of them instead
trepidacious
@trepidacious
Just looking at https://bartoszmilewski.com/2015/01/20/functors/ challenge 1, and I think that it IS a functor, but I also feel that must be wrong...
Also I can't find a complete set of answers, if there isn't one I could maybe put my answers up to be corrected :)
Fabio Labella
@SystemFw
have you read about the Functor laws?
(it's not a Functor btw)
@trepidacious
trepidacious
@trepidacious
@SystemFw Yup, preserving identity and composing? This makes me think I'm doing it wrongly ;)
Fabio Labella
@SystemFw
yeah, what does the identity law say?
Martijn Hoekstra
@martijnhoekstra
identity is fa.map(a => a) == fa
Fabio Labella
@SystemFw
yep, fmap id = id
then, with the definition in the challenge
Some(1).map(a => a) = None
Jose C
@jmcardon
btw what's the status of opaque types in good ol' dotty
or even in scala 2.13
Fabio Labella
@SystemFw
so defining fmap _ _ = Nothing breaks the identity law (haven't checked composition, but it doesn't matter, we've already seen it's not a Functor)
Martijn Hoekstra
@martijnhoekstra
the opaque types SIP is still pending. If the last SIP meeting was the December meeting, it hasn't been discussed yet
Jose C
@jmcardon
rip that's probably the SIP that I care the most about right now
trepidacious
@trepidacious
@SystemFw Ah yeah I was thinking that since _ => Nothing is the identity of Nothing it was enough, but I guess that is only enough if the type constructor was to Nothing, rather than to Maybe?
Fabio Labella
@SystemFw
see, Nothing can't be a type constructor
Jose C
@jmcardon
because opaque types being 0-cost with no .asInstanceOf casts would be so good
Fabio Labella
@SystemFw
that's where Scala is a bit weird
because Some and None have their own types
but the Functor is for Option
Martijn Hoekstra
@martijnhoekstra
it was on the agenda for last SIP meeting, but it got postponed @jmcardon - I don't know when the next SIP meeting is scheduled. Ask Jorge if you see him about.
trepidacious
@trepidacious
@SystemFw Yes it's the fact that the type constructor is Maybe that I was missing, I was kind of assuming that everything was Nothing ;)
Fabio Labella
@SystemFw
in Haskell is a bit clearer because Just can not be a type (I'm ignoring DataKinds ofc, but even in that case it's not the same)
Jose C
@jmcardon
:(
ok
thanks @martijnhoekstra
Fabio Labella
@SystemFw
yeah, Just and Nothing aren't types in Haskell at all, just constructors whose result has type Maybe a
Jose C
@jmcardon
Benching stuff, it's pretty nutty that .asInstanceOf casts can be equally expensive or more than creating a new object in the heap, as far as runtime is concerned
trepidacious
@trepidacious
@SystemFw And Nothing isn't a type constructor because it has no type parameter, whereas Const is, even though the type parameter does nothing?
Fabio Labella
@SystemFw
no
that's not the reason
data Maybe a = Just a | Nothing
the stuff to the right of = is data constructors, not types
Jose C
@jmcardon
yeah
you can't have stuff return Just I think
only Maybe
Fabio Labella
@SystemFw
in Scala you have a hierarchy of types/classes