search

links-lang / links

Links: Linking Theory to Practice for the Web
http://www.links-lang.org
Other
320 stars 42 forks source link

Map / set data structures #753

Open SimonJF opened 5 years ago

SimonJF commented 5 years ago

I'm really beginning to miss having map and set structures. Both could be implemented on top of a self-balancing tree data structure, and added to the standard library.

jamescheney commented 5 years ago

There was an attempt at this using a form of dynamic FFI by Yuren Zhong a couple of years ago, which I meant to try to clean up and merge (cf. #285). I'd endorse this (and potentially also adding some kind of convenience notation for using them since Python has poisoned my brain now).

jamescheney commented 5 years ago

Also #309

dhil commented 5 years ago

I'm really beginning to miss having map and set structures. Both could be implemented on top of a self-balancing tree data structure, and added to the standard library.

Yes, it ought to be easy to implement using AVL trees.

There was an attempt at this using a form of dynamic FFI by Yuren Zhong a couple of years ago, which I meant to try to clean up and merge (cf. #285).

One problem with using the FFI is that an instance of a foreign data structure is tied to either the client or server (assuming we have a server-side FFI).

(and potentially also adding some kind of convenience notation for using them since Python has poisoned my brain now).

It would be convenient if we could use the "standard" literal object or map notation {1: "hello", 2: "world"}, but I am afraid such a thing would require adding some ugly hacks to the parser and lexer.

jamescheney commented 5 years ago

"standard" literal object or map notation

Yes, I would instead lean towards having some as-yet-unused bracket glyphs for maps, such as {| "a" : 1, "b" : 2 |}. An alternative could be to use {...} for maps and introduce new record brackets (at type and term level) but I assume this would be an incredibly painful change.