5 ms·

The functions are basically inconsistent in both name and argument order. I think that's one of the problems they're working on correcting (a generic elt/getf),

The functions are basically inconsistent in both name and argument order. I think that's one of the problems they're working on correcting (a generic elt/getf), and more obvious ways of creating and using non-list data structures.

orthecreedence 13y ago
I think the hash table syntax is a huge step in the right direction. Almost every modernly-used language ever has hash table syntax. In lisp, I have to do (let ((myhash (make-hash-table :test 'equal))) (setf (gethash "name" myhash) "andrew" (gethash "location" myhash) "sf")) Instead of `#{"name" "andrew" "location" "sf"}`.
- johnwalker 13y ago
  Yep! It's necessary to modify slime (or light table? I've been interested in making a CL plugin for it) to take advantage of this syntax, but the absense of sane reader macros in the spec has always driven me nuts.
  - emiljbs 13y ago
    Huh? No you don't... Maybe I don't get what you mean. Here's the code for basic hashtable syntax: https://gist.github.com/ejbs/8924773 https://gist.github.com/ejbs/8924773
- mjn 13y ago
  I think this comes down to some historical baggage around the original idea that people would just use association lists ("alists") by default, while hashtables would be an advanced feature used mainly in the optimization phase, when profiling indicated that alist lookups were a bottleneck. The alist literal is a lot friendlier: '((name . "andrew") (location . "sf")) (Incidentally, you probably don't really want 'name and 'location to be strings.) It's curious that no quasi-standard reader macro for hash literals developed, though.
  - mcn 13y ago
    I think another factor is that while the primitives for modifying readtables made it into the standard, an interface for using them in a way that limits the changes to the code you own (and not, say, additional libraries you load) is something that the users had to come up with. It's not a lot of code or too complex to do that, but it's not obvious either and some people got it wrong or do it differently and I think that made reader modifications less common than they otherwise might have been. I haven't looked too closely at the details but some of cl21's changes look like they might try to address this issue.
- ruricolist 13y ago
  One could make the argument (I think so, at least) that if the number of associations you are dealing with is small enough to write out literally, then using a hash table is a mistake. It might be one of Common Lisp's strengths that is has ways to represent small tables efficiently and thus avoids the "hash addiction" that haunts languages where hash tables are used for everything. But even if a more compact way of constructing hash tables is called for, why a literal syntax instead of a more compact constructor? E.g. you could write (dict "name" "andrew" "location" "sf") with a compiler macro that produces exactly the above code.
- 6d0debc071 13y ago
  Or you can write a function for it and do something like: (let ((myhash (make-hash-table :test 'equal))) (add-hash-entry (("name" "Andrew") ("location" "sf")) myhash) Which seems, to me, easier than having more special-case syntax to learn. But I suspect this may be one of the drawbacks of Lisp, (indeed, it may turn out to be a problem with any powerful programming language.) It's so absurdly easy to do things like that, that incremental advances can be retarded by virtue of the steps along the way not being shared. And then when someone has to come along and use what you've written, without having been there for the steps along the way, the base level of abstraction they have to build up from is too low.
- waveman2 13y ago
  I think this reflects one of the fallacies that people from other languages bring to Lisp. They think that all languages are more or less immutable. If something annoys you (like funky function names) you can alias them or add whatever you think is missing to the language. E.g. You could define second as something like (defun second (list) (nth 1 list)) and use it forever, just as if it were in the base language. As an example I have a function L2HT which takes a list and returns a hash table: (l2ht '((1 "one") (2 "two))) (You can override the hash table type with various parameters if you like).
- lispm 13y ago
  That's two different things. The thing below is literal syntax for hash-table objects. It's easy to add to CL, btw.

orthecreedence 13y ago

I think the hash table syntax is a huge step in the right direction. Almost every modernly-used language ever has hash table syntax. In lisp, I have to do (let ((myhash (make-hash-table :test 'equal))) (setf (gethash "name" myhash) "andrew" (gethash "location" myhash) "sf")) Instead of `#{"name" "andrew" "location" "sf"}`.

johnwalker 13y ago
Yep! It's necessary to modify slime (or light table? I've been interested in making a CL plugin for it) to take advantage of this syntax, but the absense of sane reader macros in the spec has always driven me nuts.
- emiljbs 13y ago
  Huh? No you don't... Maybe I don't get what you mean. Here's the code for basic hashtable syntax: https://gist.github.com/ejbs/8924773 https://gist.github.com/ejbs/8924773
mjn 13y ago
I think this comes down to some historical baggage around the original idea that people would just use association lists ("alists") by default, while hashtables would be an advanced feature used mainly in the optimization phase, when profiling indicated that alist lookups were a bottleneck. The alist literal is a lot friendlier: '((name . "andrew") (location . "sf")) (Incidentally, you probably don't really want 'name and 'location to be strings.) It's curious that no quasi-standard reader macro for hash literals developed, though.
- mcn 13y ago
  I think another factor is that while the primitives for modifying readtables made it into the standard, an interface for using them in a way that limits the changes to the code you own (and not, say, additional libraries you load) is something that the users had to come up with. It's not a lot of code or too complex to do that, but it's not obvious either and some people got it wrong or do it differently and I think that made reader modifications less common than they otherwise might have been. I haven't looked too closely at the details but some of cl21's changes look like they might try to address this issue.
ruricolist 13y ago
One could make the argument (I think so, at least) that if the number of associations you are dealing with is small enough to write out literally, then using a hash table is a mistake. It might be one of Common Lisp's strengths that is has ways to represent small tables efficiently and thus avoids the "hash addiction" that haunts languages where hash tables are used for everything. But even if a more compact way of constructing hash tables is called for, why a literal syntax instead of a more compact constructor? E.g. you could write (dict "name" "andrew" "location" "sf") with a compiler macro that produces exactly the above code.
6d0debc071 13y ago
Or you can write a function for it and do something like: (let ((myhash (make-hash-table :test 'equal))) (add-hash-entry (("name" "Andrew") ("location" "sf")) myhash) Which seems, to me, easier than having more special-case syntax to learn. But I suspect this may be one of the drawbacks of Lisp, (indeed, it may turn out to be a problem with any powerful programming language.) It's so absurdly easy to do things like that, that incremental advances can be retarded by virtue of the steps along the way not being shared. And then when someone has to come along and use what you've written, without having been there for the steps along the way, the base level of abstraction they have to build up from is too low.
waveman2 13y ago
I think this reflects one of the fallacies that people from other languages bring to Lisp. They think that all languages are more or less immutable. If something annoys you (like funky function names) you can alias them or add whatever you think is missing to the language. E.g. You could define second as something like (defun second (list) (nth 1 list)) and use it forever, just as if it were in the base language. As an example I have a function L2HT which takes a list and returns a hash table: (l2ht '((1 "one") (2 "two))) (You can override the hash table type with various parameters if you like).
lispm 13y ago
That's two different things. The thing below is literal syntax for hash-table objects. It's easy to add to CL, btw.