-
Notifications
You must be signed in to change notification settings - Fork 199
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a map type to LF #2256
Comments
Rationale behind implementing our own map type in the Node.js bindingsApart from the JSON subset, which easily maps to DAML const m = new Map([[{a: 1}, 42], [{a: 1}, 47]]) // m is now Map { { a: 1 } => 42, { a: 1 } => 47 }
m.get({ a: 1 }) // returns undefined
const k = { a: 1 }
const n = new Map([[k, 42], [k, 47]]) // n is now Map { { a: 1 } => 47 }
n.get(k) // returns 47 Using this map could hurt the usability of the bindings because the keys would come from the network, so in order for the user to look up keys they would have to iterate the map, finding the key they're looking for and then actually perform the lookup (which basically defeats the purpose of using a map in the first place). Since implementing a simple hashmap should be a fairly easy task, I would recommend implementing our own rather than depending on external dependencies for this. /cc @bame-da |
@remyhaemmerle-da We need something like an |
@martin-drhu-da We need also something like |
What would we return/accept on the JSON API? |
The only sensible output for us to emit is an array of pairs as you said, but I would strongly discourage anyone from using both Object.fromEntries([[{"a": 1}, 42], [{"a": 1}, 47]])
// evaluates to { "[object Object]": 47 }, way less then desirable outcome If the API is consumed from JavaScript users can simply implement an associative array themselves or pull their favorite dictionary/map/associative array implementation from NPM. |
ProposalWe implement Insertion preserving map (called We provides the following builtins (with expected builtins):
In the ledger and in the ledger API, the map are represented as lists of pairs order as the insertion order. |
This part of #2256. CHANGELOG_BEGIN CHANGELOG_END
This part of #2256. CHANGELOG_BEGIN CHANGELOG_END
This part of #2256. CHANGELOG_BEGIN CHANGELOG_END
added in lf 1.11 |
There have been several discussion to add a new type
Map K V
to DAML-LF in order to give us maps with arbitrary keys in DAML and a sensible representation in app languages. The issues that arise are:Value
and using a tree map.[(K, V)]
on the wire. Again, to get determinism, this needs to be ordered so we have complexityn log(n)
somewhere.If I got this right, the work would be
Value
TreeMap K V
and serialisation to and from[(K, V)]
(with the write path doing the ordering and checking for duplicate keys)Map
type[(K, V)]
to and from idiomatic maps in Java and JSDA.TreeMap
DAML libAnd the main tradeoff is that our maps would be
O(log(n))
, but I find that perfectly acceptable. If anyone needs anO(1)
, they can always write aMapKey
instance.Anything I missed? Does this sound like a good way to go? If so, how much effort would this be?
The text was updated successfully, but these errors were encountered: