4 ms·

Maps literally have a module definition that ends up being similar to dicts if you want to swap them in directly. You can know a data structure's keys in advan

Maps literally have a module definition that ends up being similar to dicts if you want to swap them in directly. You can know a data structure's keys in advance while still having it dynamic and not a record: proplists, key/val lists, and so on are like that. The user has to know the keys to use them sometimes. The data structure definition doesn't. The weakness of dicts and gb_trees is two-faced: they're both slower than maps promise to be, and they do not have pattern matching. Records and maps are distinct in my opinion. I, for example, won't expect to be able to use Dialyzer and do type checking of specific key's values (much like with dicts, trees, k/v lists), but will do so with records. Maps are pretty much dicts and trees with pattern matching added more than anything. They even have the same issues with considering the equality of integers and floats. Records still have their use case as is right now. Maps have more in common semantically with dicts than they have with records, where the similarity is syntactical. I prefer to prioritize semantics over syntax.

colanderman 13y ago
Maps literally have a module definition that ends up being similar to dicts if you want to swap them in directly. So? Having a similar interface doesn't mean they have comparable implementations. Even in the maps runtime implementation, we see a benefit of knowing that a structure is homogeneous: run-time type information can be lifted out of the structure, saving memory and time. You can know a data structure's keys in advance while still having it dynamic and not a record: proplists, proplists are like, the poster child static heterogeneous structure, precisely because I do know all the keys in advance! It's just that in a given instantiation, some of them map to the value "undefined"! The weakness of dicts and gb_trees is two-faced: they're both slower than maps promise to be Then reimplement the dict module. How does syntax help here? and they do not have pattern matching. Again, why do you need to pattern match something whose keys are determined at runtime? I've never wanted such an ability in a language; I don't see the benefit. Records and maps are distinct in my opinion. I, for example, won't expect to be able to use Dialyzer and do type checking of specific key's values (much like with dicts, trees, k/v lists), but will do so with records. Why not? OCaml can perform typechecking of structurally typed values. That's a solved problem. If there's no plans to support it in Dialyzer I'll add it myself. Maps have more in common semantically with dicts than they have with records, where the similarity is syntactical. I think we disagree on what a "map" is. You say a map is one thing (a replacement for a key-value store), but when I see syntax that looks, walks, and quacks like a structurally typed record, I see a structurally typed record, and I'm utterly baffled why those things should have anything to do with each other.
- nox_ 13y ago
  A structurally-typed record would be a frame, as defined by Richard O'Keefe in his paper [1]. Maps aren't frames. Maps fit where dict and friends do. [1] http://www.cs.otago.ac.nz/staffpriv/ok/frames.pdf http://www.cs.otago.ac.nz/staffpriv/ok/frames.pdf
  - colanderman 13y ago
    OK, great. I want frames. But how can I get them if there's already similar syntax for something that can kind of do what frames do but isn't optimized for that use case? That's a difficult sell: "Oh, yes, Erlang has structurally typed records! No, it's not the syntax that looks like a record without a name, it's this other syntax." Maybe I'm being pessimistic, but I think frames have pretty much zero chance of being implemented so long as maps have syntax support.
- mononcqc 13y ago
  You know that maps as envisioned in the EEP (http://www.erlang.org/eeps/eep-0043.html http://www.erlang.org/eeps/eep-0043.html) should let you do pattern matching using variables, right? It's not there now because it's a provisional implementation, but it will be there. We will be able to do X = 3, #{X := Val} = Map, ... to extract the value of 'Val' under the unknown key 'X'. This just hasn't been implemented yet, but is part of the total specification. What you see is the incomplete implementation of maps, not up to the total spec, because this is a RC1 implementation. They will support part of the record use case, but the entirety of the dict use case with more flexibility there (including comprehensions, from_list, etc.) They are, by specification and once complete, going to be far more feature-equivalent with dicts than records.
  - colanderman 13y ago
    We will be able to do X = 3, #{X := Val} = Map, ... to extract the value of 'Val' under the unknown key 'X'. Yes. I don't understand the use case for that.
    - 13y ago

colanderman 13y ago

Maps literally have a module definition that ends up being similar to dicts if you want to swap them in directly. So? Having a similar interface doesn't mean they have comparable implementations. Even in the maps runtime implementation, we see a benefit of knowing that a structure is homogeneous: run-time type information can be lifted out of the structure, saving memory and time. You can know a data structure's keys in advance while still having it dynamic and not a record: proplists, proplists are like, the poster child static heterogeneous structure, precisely because I do know all the keys in advance! It's just that in a given instantiation, some of them map to the value "undefined"! The weakness of dicts and gb_trees is two-faced: they're both slower than maps promise to be Then reimplement the dict module. How does syntax help here? and they do not have pattern matching. Again, why do you need to pattern match something whose keys are determined at runtime? I've never wanted such an ability in a language; I don't see the benefit. Records and maps are distinct in my opinion. I, for example, won't expect to be able to use Dialyzer and do type checking of specific key's values (much like with dicts, trees, k/v lists), but will do so with records. Why not? OCaml can perform typechecking of structurally typed values. That's a solved problem. If there's no plans to support it in Dialyzer I'll add it myself. Maps have more in common semantically with dicts than they have with records, where the similarity is syntactical. I think we disagree on what a "map" is. You say a map is one thing (a replacement for a key-value store), but when I see syntax that looks, walks, and quacks like a structurally typed record, I see a structurally typed record, and I'm utterly baffled why those things should have anything to do with each other.

nox_ 13y ago
A structurally-typed record would be a frame, as defined by Richard O'Keefe in his paper [1]. Maps aren't frames. Maps fit where dict and friends do. [1] http://www.cs.otago.ac.nz/staffpriv/ok/frames.pdf http://www.cs.otago.ac.nz/staffpriv/ok/frames.pdf
- colanderman 13y ago
  OK, great. I want frames. But how can I get them if there's already similar syntax for something that can kind of do what frames do but isn't optimized for that use case? That's a difficult sell: "Oh, yes, Erlang has structurally typed records! No, it's not the syntax that looks like a record without a name, it's this other syntax." Maybe I'm being pessimistic, but I think frames have pretty much zero chance of being implemented so long as maps have syntax support.
mononcqc 13y ago
You know that maps as envisioned in the EEP (http://www.erlang.org/eeps/eep-0043.html http://www.erlang.org/eeps/eep-0043.html) should let you do pattern matching using variables, right? It's not there now because it's a provisional implementation, but it will be there. We will be able to do X = 3, #{X := Val} = Map, ... to extract the value of 'Val' under the unknown key 'X'. This just hasn't been implemented yet, but is part of the total specification. What you see is the incomplete implementation of maps, not up to the total spec, because this is a RC1 implementation. They will support part of the record use case, but the entirety of the dict use case with more flexibility there (including comprehensions, from_list, etc.) They are, by specification and once complete, going to be far more feature-equivalent with dicts than records.
- colanderman 13y ago
  We will be able to do X = 3, #{X := Val} = Map, ... to extract the value of 'Val' under the unknown key 'X'. Yes. I don't understand the use case for that.
  - 13y ago