3 ms·

"It’s feasible and easy to write assoc-in atop of Dynamic..." Then why don't you do it and post up the code? If it's as easy as writing the same function in a

"It’s feasible and easy to write assoc-in atop of Dynamic..." Then why don't you do it and post up the code? If it's as easy as writing the same function in a dynamically typed language it shouldn't take more than a minute or two. "The idea of assoc-in working for every type of Map also doesn’t make sense. Map only exists statically." Maybe you're misunderstanding me? I mean it should work for every `Data.Map k a`, where `k => Ord`, just like all the other Data.Map functions. "Your argument hinges on the idea that it’s impractical to write using Dynamic in Haskell. I do not think this is true." Then try it?

tel 9y ago
> I mean it should work for every `Data.Map k a`, where `k => Ord`, just like all the other Data.Map functions. This is where we're got a difference of opinion. My statement is that assoc-in doesn't do anything close to working over "every `Data.Map k a`". Data.Map is a compile-time idea classifying names in the language and the Data.Map functions are designed to respect that both dynamically (manipulate some memory properly) and statically (create updated contexts with new and different information). On the other hand, assoc-in works only dynamically/at runtime over all kinds of (Clojure and Java) data. In particular, it has meaningful semantics for every possible input value although it only has "interesting" semantics for certain runtime shapes. That's easy to write in Haskell. https://gist.github.com/tel/bb84fcc3f1b7488b53349156284b509a https://gist.github.com/tel/bb84fcc3f1b7488b53349156284b509a
- weavejester 9y ago
  Your code doesn't compile. I can fix the obvious typos and missing imports and language pragma, but the type errors that remain are beyond my knowledge to correct.
  - tel 9y ago
    Apologies, quick sketch in an airport between flights. May fix this later when I’ve actually got an internet connection.
  - tel 9y ago
    I fixed the type errors in what I presented before. Little changed: I had to fix the typos, bad imports, and missing pragmas, and then I had to instantiate Val as Hashable and Eq, but since all things inside of Val are Hashable and Eq it was straightforward. https://gist.github.com/tel/bb84fcc3f1b7488b53349156284b509a https://gist.github.com/tel/bb84fcc3f1b7488b53349156284b509a
    - weavejester 9y ago
      Can you give an example of use? It's not clear to me how this interacts with standard Haskell data structures. If I have an existing map, do I need to walk the tree and encase everything in a `Val`, and vice versa when I want to pull values out?
      - tel 9y ago
        It doesn’t really. I’m not claiming this works with standard Haskell practice. Typed techniques don’t translate directly to untyped things. The act of traversing each time is “forgetting”/“synthesizing” type information and is exactly the issue. Dynamic code destroys type information.
        weavejester 9y ago
        "It doesn’t really. I’m not claiming this works with standard Haskell practice." Then I don't understand where you disagree with me. I'm not saying assoc-in is impossible; just that it's impractical. We can write assoc-in with dynamic types, but that doesn't integrate with existing functions, and is generally a pain to work with. Alternatively we can try and to statically type it, but then we run into the limitations of Haskell's type system. assoc-in is a solution that doesn't really work in Haskell, because the constraints of the language prevent it. Adding static typing to a language adds practical limitations in exchange for compiler guarantees.
        tel 9y ago
        I disagree it’s impractical—it’s just not valuable. Assoc-In reads as convenient to you, and it is if you’ve already thrown away type information, and reads as destructive to me, a force for destroying information. Lenses aren’t better because they’re inconvenient but happen to work with types. They’re better because they properly relate to the typing context and persist important information. Lenses in dynamically typed languages don’t exploit this fact and usually are implemented in a way that’s “easy” but destructive. What you see as practical limitations are seen by me as practical advantages. What you see as convenience and power I see as loss and destruction. To my eyes, the reason is that you’re most interested in abilities that help you fluently write programs/create values. I’m interested in balancing the power to create with the power to analyze. I want my programs to have meaning both as runtime interpretations and as logical statements. I can choose other type systems to satisfy this balance, but if you just side with “power to create” then I think you lose big.

tel 9y ago

> I mean it should work for every `Data.Map k a`, where `k => Ord`, just like all the other Data.Map functions. This is where we're got a difference of opinion. My statement is that assoc-in doesn't do anything close to working over "every `Data.Map k a`". Data.Map is a compile-time idea classifying names in the language and the Data.Map functions are designed to respect that both dynamically (manipulate some memory properly) and statically (create updated contexts with new and different information). On the other hand, assoc-in works only dynamically/at runtime over all kinds of (Clojure and Java) data. In particular, it has meaningful semantics for every possible input value although it only has "interesting" semantics for certain runtime shapes. That's easy to write in Haskell. https://gist.github.com/tel/bb84fcc3f1b7488b53349156284b509a https://gist.github.com/tel/bb84fcc3f1b7488b53349156284b509a

weavejester 9y ago
Your code doesn't compile. I can fix the obvious typos and missing imports and language pragma, but the type errors that remain are beyond my knowledge to correct.
- tel 9y ago
  Apologies, quick sketch in an airport between flights. May fix this later when I’ve actually got an internet connection.
- tel 9y ago
  I fixed the type errors in what I presented before. Little changed: I had to fix the typos, bad imports, and missing pragmas, and then I had to instantiate Val as Hashable and Eq, but since all things inside of Val are Hashable and Eq it was straightforward. https://gist.github.com/tel/bb84fcc3f1b7488b53349156284b509a https://gist.github.com/tel/bb84fcc3f1b7488b53349156284b509a
  - weavejester 9y ago
    Can you give an example of use? It's not clear to me how this interacts with standard Haskell data structures. If I have an existing map, do I need to walk the tree and encase everything in a `Val`, and vice versa when I want to pull values out?
    - tel 9y ago
      It doesn’t really. I’m not claiming this works with standard Haskell practice. Typed techniques don’t translate directly to untyped things. The act of traversing each time is “forgetting”/“synthesizing” type information and is exactly the issue. Dynamic code destroys type information.
      - weavejester 9y ago
        "It doesn’t really. I’m not claiming this works with standard Haskell practice." Then I don't understand where you disagree with me. I'm not saying assoc-in is impossible; just that it's impractical. We can write assoc-in with dynamic types, but that doesn't integrate with existing functions, and is generally a pain to work with. Alternatively we can try and to statically type it, but then we run into the limitations of Haskell's type system. assoc-in is a solution that doesn't really work in Haskell, because the constraints of the language prevent it. Adding static typing to a language adds practical limitations in exchange for compiler guarantees.
        tel 9y ago
        I disagree it’s impractical—it’s just not valuable. Assoc-In reads as convenient to you, and it is if you’ve already thrown away type information, and reads as destructive to me, a force for destroying information. Lenses aren’t better because they’re inconvenient but happen to work with types. They’re better because they properly relate to the typing context and persist important information. Lenses in dynamically typed languages don’t exploit this fact and usually are implemented in a way that’s “easy” but destructive. What you see as practical limitations are seen by me as practical advantages. What you see as convenience and power I see as loss and destruction. To my eyes, the reason is that you’re most interested in abilities that help you fluently write programs/create values. I’m interested in balancing the power to create with the power to analyze. I want my programs to have meaning both as runtime interpretations and as logical statements. I can choose other type systems to satisfy this balance, but if you just side with “power to create” then I think you lose big.