6 ms·

I still think there's room for experimenting with a Lisp that has the hashmap (a.k.a. dictionary, associative array, property bag) as its organizing principle r

by gruseom 15y ago

I still think there's room for experimenting with a Lisp that has the hashmap (a.k.a. dictionary, associative array, property bag) as its organizing principle rather than the list. There's nothing better than hashmaps for exploratory programming. If there is something to be gained from building a Lisp in terms of them (from the ground up; I don't mean support for object literals), I'd like to know what it is. This has little to do with syntax.

cyrus_ 15y ago
You could argue that Javascript is a language with the hashmap as its central data structure. It doesn't have a macro system/quotations/other LISPy things, of course, but you can certainly frame your argument as "would JS benefit from <LISP feature>?"
- gruseom 15y ago
  Yes, JS certainly is that (or comes close), which is the thing I like the most about JS and miss the most in Lisp - so much so that I wrote macros to allow me to use JS-style objects wherever possible. (I don't mean JS-style OO, which I avoid at all costs. Hate "this" and "prototype", love "a.b" and "a[b]".) The benefit of the hashmap for exploratory programming is so great that it raises the question of whether a fully regular/metaprogrammable Lisp could be evolved from it. Not clear if it would be practical, or add anything of value, but if it did it would be interesting.
lisper 15y ago
This presents a very thorny language design problem. Lists have this very nice property that they are ordered, which lets you attach implied semantics to the position of an element, e.g.: (defun foo (a b c) ...) We know this is a function defining because the symbol DEFUN is in the FIRST position of the list. Associative arrays are unordered, so you have to explicitly label everything: { top-level-form : defun, arguments : { 1 : a, 2 : b, 3 : c }, ... } Or something like that. You can see where that would get annoying. Exercise for the reader: what happens if you base a Lisp-like language on vectors instead of cons cells?
- akkartik 15y ago
  Nobody seems to have mentioned the advantage of table literals: free syntax for ruby-style keyword arts.
- akkartik 15y ago
  I'll bite: cdr gets expensive? You could represent a list as a naked array of lisp pointers, but then cons gets expensive. And good luck garbage collecting the vectors.
  - lisper 15y ago
    > cdr gets expensive Yes, that's one thing. But do you really need CDR? > You could represent a list as a naked array of lisp pointers, but then cons gets expensive. Actually, it's much worse than that. CONS actually becomes impossible. (Think about it.) But maybe there's something else that you can use instead of CONS? > And good luck garbage collecting the vectors Why would that be a problem? Extant Lisps collect vectors just fine.
    - akkartik 15y ago
      "Extant Lisps collect vectors just fine." But they don't permit pointers inside the vectors, do they? I think if you permit internal pointers so you can have copyless cdr, computing reachability would get really expensive.
      - lisper 15y ago
        The phrase "permit pointers inside the vectors" doesn't really make sense. Vectors are just ordered collections of objects. They don't have insides and outsides, except insofar as the objects contained by the vector could be (but usually aren't) considered "inside" the vector. Lisp vectors are usually implemented as arrays of pointers, so in that sense pointers are "permitted" inside vectors. But I'm guessing that's not what you meant. (I have no idea what you actually meant.)
        15y ago
premchai21 15y ago
Lua tables are a general-purpose associative structure that are used for both map and list functions in that language: there's syntactic sugar for both consecutive integer keys and simple string keys, and the former are used to make sequences (with internal, semantics-preserving optimizations in the Lua runtime for storing them). They strike me as one of the best options for a single core data structure if one were limited to one.
- tikhonj 15y ago
  I haven't use Lua, but that sounds exactly like JavaScript objects. JavaScript does get on very well with basically just these objects.
  - premchai21 15y ago
    They're similar, but the Lua form is much cleaner. In particular, JS objects only permit string keys, which makes Arrays sort of preposterous; they also have other baggage related to the prototype system. Lua tables can have any type except nil (which is not truly first-class in Lua) as keys, and can also have "metatables", which are of similar or greater power to the latter baggage but semantically somewhat simpler. To me this makes a world of difference.

by gruseom 15y ago

cyrus_ 15y ago

You could argue that Javascript is a language with the hashmap as its central data structure. It doesn't have a macro system/quotations/other LISPy things, of course, but you can certainly frame your argument as "would JS benefit from <LISP feature>?"

gruseom 15y ago
Yes, JS certainly is that (or comes close), which is the thing I like the most about JS and miss the most in Lisp - so much so that I wrote macros to allow me to use JS-style objects wherever possible. (I don't mean JS-style OO, which I avoid at all costs. Hate "this" and "prototype", love "a.b" and "a[b]".) The benefit of the hashmap for exploratory programming is so great that it raises the question of whether a fully regular/metaprogrammable Lisp could be evolved from it. Not clear if it would be practical, or add anything of value, but if it did it would be interesting.

lisper 15y ago

This presents a very thorny language design problem. Lists have this very nice property that they are ordered, which lets you attach implied semantics to the position of an element, e.g.: (defun foo (a b c) ...) We know this is a function defining because the symbol DEFUN is in the FIRST position of the list. Associative arrays are unordered, so you have to explicitly label everything: { top-level-form : defun, arguments : { 1 : a, 2 : b, 3 : c }, ... } Or something like that. You can see where that would get annoying. Exercise for the reader: what happens if you base a Lisp-like language on vectors instead of cons cells?

akkartik 15y ago
Nobody seems to have mentioned the advantage of table literals: free syntax for ruby-style keyword arts.
akkartik 15y ago
I'll bite: cdr gets expensive? You could represent a list as a naked array of lisp pointers, but then cons gets expensive. And good luck garbage collecting the vectors.
- lisper 15y ago
  > cdr gets expensive Yes, that's one thing. But do you really need CDR? > You could represent a list as a naked array of lisp pointers, but then cons gets expensive. Actually, it's much worse than that. CONS actually becomes impossible. (Think about it.) But maybe there's something else that you can use instead of CONS? > And good luck garbage collecting the vectors Why would that be a problem? Extant Lisps collect vectors just fine.
  - akkartik 15y ago
    "Extant Lisps collect vectors just fine." But they don't permit pointers inside the vectors, do they? I think if you permit internal pointers so you can have copyless cdr, computing reachability would get really expensive.
    - lisper 15y ago
      The phrase "permit pointers inside the vectors" doesn't really make sense. Vectors are just ordered collections of objects. They don't have insides and outsides, except insofar as the objects contained by the vector could be (but usually aren't) considered "inside" the vector. Lisp vectors are usually implemented as arrays of pointers, so in that sense pointers are "permitted" inside vectors. But I'm guessing that's not what you meant. (I have no idea what you actually meant.)
      - 15y ago

premchai21 15y ago

Lua tables are a general-purpose associative structure that are used for both map and list functions in that language: there's syntactic sugar for both consecutive integer keys and simple string keys, and the former are used to make sequences (with internal, semantics-preserving optimizations in the Lua runtime for storing them). They strike me as one of the best options for a single core data structure if one were limited to one.

tikhonj 15y ago
I haven't use Lua, but that sounds exactly like JavaScript objects. JavaScript does get on very well with basically just these objects.
- premchai21 15y ago
  They're similar, but the Lua form is much cleaner. In particular, JS objects only permit string keys, which makes Arrays sort of preposterous; they also have other baggage related to the prototype system. Lua tables can have any type except nil (which is not truly first-class in Lua) as keys, and can also have "metatables", which are of similar or greater power to the latter baggage but semantically somewhat simpler. To me this makes a world of difference.