5 ms·

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 corre

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.
        weavejester 9y ago
        "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." That's not quite how I see things: I see static typing as a constraint that trades solutions for guarantees. "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 don't believe that power and convenience should be pursued above all other considerations; if I did, do you think I'd use a language where data structures are immutable by default? Immutability is a significant constraint, yet clearly I think it worth the cost. Constraints like static typing and immutability are useful only if the guarantees they deliver are worth more than the solutions they remove. You say that assoc-in is "not valuable", because it cannot easily be written without discarding type information; it's a net loss, because type information is more valuable to you. Where we ultimately disagree, I think, is the value we place upon static types. I don't think they're particularly valuable at all. Their cost hugely exceeds their usefulness, which to my mind is minor at best, and non-existant at worst. But my problem is not that you disagree with me over how valuable static types are, but that you seem to think they're not a trade-off. Forgive me if I've misunderstood you, but you don't seem to acknowledge that static types have any disadvantages associated with them at all.
  - tel 9y ago
    Honestly, at this point if you’d like to keep chatting, would you mind emailing me? I’d like to discuss these ideas further if it’s of interest.
    - weavejester 9y ago
      We might be at the point where we should to agree to disagree. It's interesting to debate a point, particularly since it forces me to justify my viewpoint to myself as well as to you, but I think the discussion may have run its course. :)

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.
      - weavejester 9y ago
        "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." That's not quite how I see things: I see static typing as a constraint that trades solutions for guarantees. "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 don't believe that power and convenience should be pursued above all other considerations; if I did, do you think I'd use a language where data structures are immutable by default? Immutability is a significant constraint, yet clearly I think it worth the cost. Constraints like static typing and immutability are useful only if the guarantees they deliver are worth more than the solutions they remove. You say that assoc-in is "not valuable", because it cannot easily be written without discarding type information; it's a net loss, because type information is more valuable to you. Where we ultimately disagree, I think, is the value we place upon static types. I don't think they're particularly valuable at all. Their cost hugely exceeds their usefulness, which to my mind is minor at best, and non-existant at worst. But my problem is not that you disagree with me over how valuable static types are, but that you seem to think they're not a trade-off. Forgive me if I've misunderstood you, but you don't seem to acknowledge that static types have any disadvantages associated with them at all.
- tel 9y ago
  Honestly, at this point if you’d like to keep chatting, would you mind emailing me? I’d like to discuss these ideas further if it’s of interest.
  - weavejester 9y ago
    We might be at the point where we should to agree to disagree. It's interesting to debate a point, particularly since it forces me to justify my viewpoint to myself as well as to you, but I think the discussion may have run its course. :)