6 ms·

Yes, you can write the function using entirely dynamic types: Map Dynamic Dynamic -> [Dynamic] -> Dynamic -> Map Dynamic Dynamic But would you actually wr

Yes, you can write the function using entirely dynamic types: Map Dynamic Dynamic -> [Dynamic] -> Dynamic -> Map Dynamic Dynamic But would you actually write a function like that? Of course not. Not only is it a pain to unwrap nested maps of dynamic types, but you lose almost all the advantages of a static type system. So what's the alternative? As you point out, a more idiomatic way is to use lenses, as they solve a similar problem but can be typed. However, in Clojure we can use assoc-in or lenses. Dynamically typed languages are not constrained by what is feasible to statically type. In Haskell, it is hard to the point of being infeasible to robustly type assoc-in, so it's not idiomatic to use it. But in Clojure we're not restricted by the limitations of a static type system; we can use functions like assoc-in. This is the trade off of static typing. A static type system limits what solutions are feasible and idiomatic; even functions that are simple to express and reason about, can be extremely hard to accurately type.

tel 9y ago
I wouldn’t because once I’ve got a type system the tradeoff never works out. But the same thing can be expressed. I don’t see the thrust of your argument. You can write both styles of program in both languages, but you can only have type guarantees in a language with a type system. So, you’ve shown that assoc-in can be written so long as type guarantees are thrown away. That seems like a reasonable reason to pick lenses either way.
- weavejester 9y ago
  "You can write both styles of program in both languages" No you can't, not in any way that's practical. It's possible to write Haskell by wrapping every value in a Dynamic type, but possible does not mean feasible. If you don't believe there's a distinction, then try writing a functionally equivalent `assoc-in` in Haskell. I don't mean sketch out a design in pseudo-code; I mean produce a fully working function that operates seamlessly with all possible types of Data.Map. "So, you’ve shown that assoc-in can be written so long as type guarantees are thrown away. That seems like a reasonable reason to pick lenses either way." Well, that's the question: is it?. Lenses can be typed, but `assoc-in` is conceptually simpler. Haskell advocates using only solutions that can be typed; Clojure advocates using the simplest solution. Static typing is a constraint, because it limits the solutions that are feasible and idiomatic. In return it provides a compile-time guarantee. The question is whether the guarantee is worth the solutions that are (for all practical purposes) removed. Immutability is another type of constraint. As is automatic memory management, variable scoping... programming languages are designed around constraints. Pretending that you can introduce a constraint and not narrow the solution space is wishful thinking.
  - tel 9y ago
    It’s feasible and easy to write assoc-in atop of Dynamic... it’s just not done because nobody programming in Haskell thinks it’s valuable. We could choose to support much more opt-out dynamic behavior no sweat, but nobody wants to. The idea of assoc-in working for every type of Map also doesn’t make sense. Map only exists statically. Types as Clojure discusses them exist at runtime, are statically Dynamic, and it’s trivial to write assoc-in that works over all of them in any language. Your argument hinges on the idea that it’s impractical to write using Dynamic in Haskell. I do not think this is true. There is perhaps some value in greater library support, but it is easy to do this. It is simply not considered valuable.
    - weavejester 9y ago
      "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

tel 9y ago

I wouldn’t because once I’ve got a type system the tradeoff never works out. But the same thing can be expressed. I don’t see the thrust of your argument. You can write both styles of program in both languages, but you can only have type guarantees in a language with a type system. So, you’ve shown that assoc-in can be written so long as type guarantees are thrown away. That seems like a reasonable reason to pick lenses either way.

weavejester 9y ago
"You can write both styles of program in both languages" No you can't, not in any way that's practical. It's possible to write Haskell by wrapping every value in a Dynamic type, but possible does not mean feasible. If you don't believe there's a distinction, then try writing a functionally equivalent `assoc-in` in Haskell. I don't mean sketch out a design in pseudo-code; I mean produce a fully working function that operates seamlessly with all possible types of Data.Map. "So, you’ve shown that assoc-in can be written so long as type guarantees are thrown away. That seems like a reasonable reason to pick lenses either way." Well, that's the question: is it?. Lenses can be typed, but `assoc-in` is conceptually simpler. Haskell advocates using only solutions that can be typed; Clojure advocates using the simplest solution. Static typing is a constraint, because it limits the solutions that are feasible and idiomatic. In return it provides a compile-time guarantee. The question is whether the guarantee is worth the solutions that are (for all practical purposes) removed. Immutability is another type of constraint. As is automatic memory management, variable scoping... programming languages are designed around constraints. Pretending that you can introduce a constraint and not narrow the solution space is wishful thinking.
- tel 9y ago
  It’s feasible and easy to write assoc-in atop of Dynamic... it’s just not done because nobody programming in Haskell thinks it’s valuable. We could choose to support much more opt-out dynamic behavior no sweat, but nobody wants to. The idea of assoc-in working for every type of Map also doesn’t make sense. Map only exists statically. Types as Clojure discusses them exist at runtime, are statically Dynamic, and it’s trivial to write assoc-in that works over all of them in any language. Your argument hinges on the idea that it’s impractical to write using Dynamic in Haskell. I do not think this is true. There is perhaps some value in greater library support, but it is easy to do this. It is simply not considered valuable.
  - weavejester 9y ago
    "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