1. 10
  1.  

  2. 8

    The Haskell vs Math slide is ridiculous.

    In mathematics it’s sufficient to provide an equivalence relation across two types and call that your equality, in computer science you need a decision process for such a relationship. Prime example, functions. Define two functions f and g to be equal if and only if, whenever x = y, then f x = g y. This is clearly an equivalence relationship and just as clearly undecidable in the general case.

    All Haskell types can be equipped with a logical equivalence relation which is essentially “In for every Program P missing a expression of type A, if a and b when put in this whole cause P to yield the same result they are equal” but this is completely undecidable.

    So Set is an fact a functor from the category of Haskell types equipped with a decidable equality instance to Hask, not an endofunctor.

    1. 3

      Also, it’s not because of CanBuildFrom (the thing he’s trying to push with that slide) which allows Set to have a broken functor map - it’s because of broken parametricity, everything having equality on it, like he was actually describing!

      Not sure why he’s trying to push CanBuildFrom by attacking a completely unrelated but useful property of Haskell! Very strange.

    2. 5

      There’s something about Scala’s collections library that people don’t often talk about, but it’s important.

      It’s a library.

      It’s JUST a library.

      You could write your own. In fact, Paul Phillips is. (was?)

      This is the list of Actual Language Features that make life easier for collections but have… less… justification to exist otherwise.

      • methods whose names end with a colon (“:”) are right-associative, so the :: and +: (‘cons’) operators do the right thing
      • uh…
      • I guess the implicit resolution rules were stretched a bit to make CanBuildFrom JustWork™.
      • …I can’t think of anything else at the moment.

      Let’s see your language do this. I mean really, I’m not claiming they don’t exist, I’m asking you to show me yours.

      1. 2

        In my opinion, psp-views are really a step into the right direction, but I’d really like to see some non-trivial implementations of collection types before I cast a final judgement, because currently most of the stuff is either trivial or just forwarding to scala.collection.

        I think if psp-views were stand-alone and had roughly the coverage of the existing collection library, it would really make sense to start thinking about how we can facilitate the migration to the new library and deprecate/remove the old one.

      2. 3

        Curious combination of very clear and high-level points and down-in-the-dirty-details arguments bordering on rant. Luckily, it starts and ends on good points, so there’s the serial position effect at work for you.

        There is a slide towards the end about the power of implicit arguments. This is one of the killer features in Scala for me. As an example, I recently had to use code written by a Scala beginner (who learned by “typing until it works”). He used global state everywhere throughout his module, with functions branching on globals set in other functions, etc. I had to make his code callable multiple times and in parallel. I defined a module-local Env class and moved all the global variables in there, the idea being that I could pass an instance of Env around in related invocations. This was achieved by adding to each function declaration a second argument block (implicit env : Env), and at the first line of each function the import statement import env._. There, your environment is threaded properly.

        (Needless to say, this was a “we need this prototype to produce numbers now” situation…)

        1. 3

          Implicits are weird though because their resolution isn’t fixed. It prevents efficient Set implementations in Scala because it’s difficult to know that the sense of order a Set is constructed upon will be the same as the one it’s read using.

          1. 3

            Exactly, this is known as the type-class coherency/confluence/consistency problem and it’s the reason why “implicits as type-classes” almost misses the point of type-classes completely!

            1. 1

              Note that this is not the use of implicits I was talking about. Implicits-as-type-classes are fundamentally tied to generic types. Implicits-as-environment-carriers are a much simpler form, and would be useful even in untyped languages.

              1. 1

                Even more useful is the reader monad, which does a much better job at implicit environments than implicit parameters do.