Hacker News new | ask | show | jobs
by lispm 4442 days ago
Named arguments are there to be interfaces to procedures. With hash-tables you know nothing about them. With named arguments, we can ask for argument lists, check for missing arguments, complete arguments, prompt for arguments, ... Much of that can be done in the IDE or at compile time.

Named arguments had been introduced to Lisp with MDL (a Lisp dialect, brought to Lisp Machine Lisp and then to Common Lisp).

Using hash-tables for it is a step back from the view of development support.

1 comments

  ; CL keyword arg syntax, taken from Practical Common Lisp
  (defun foo (&key (a 0) (b 0)) (+ a b))
  (foo :a 1) -> 1
  (foo :a 1 :b 2) -> 3

  ; hypothetical table keyword arg syntax
  ; clojure defines commas to be whitespace, you can pretend they aren't there if you want
  (defun foo ({a: 0, b: 0}) (+ a b))
  (foo {a: 1}) -> 1
  (foo {a: 1, b: 2}) -> 3
I fail to see why the table syntax would be any less usable or introspectable by compilers or editors. They'd have the advantage (which would be shared with alists, if Common Lisp had used them for keyword args) of sharing the syntax for keyword args with a syntax for optional structure properties (think XML's attributes)
Basically the syntax for specifying keyword arglists is based on assoc lists. The calling syntax is based on property lists.

There is nothing to be gained by hashtables.

The Common Lisp keyword syntax actually is a bit more powerful then what your PCL example shows:

(defun foo (&key ((var keyword) init var-arg-supplied-p) ...)

Generally I think it is a slight mistake to use specific data types in arglists - basically mixing syntax and data types.

> Generally I think it is a slight mistake to use specific data types in arglists - basically mixing syntax and data types.

That's kinda what alists and plists do! They mix up the abstract "map" or "table" data structure (something that maps keys to values) with some concrete implementation of it. '((key . value) (key . value)) and '(key value key value) are literal representations of two particular map-like data structures, whereas {key: value} or {key = value} could have any concrete representation that the language implementer desires.

Maybe I should have dropped the "hash" from "hash table" in my above posts, so that it was clear that I was interested in the syntactic benefit of using one syntax for mapping names to values, and not some imagined efficiency gains from having (read keyword-function-call) include a hash table instead of an alist.

    (defun foo (&key foo) ...)
In Common Lisp an implementation can implement a call like (foo :bar 10) how it wants. There is nothing said about lists, hash tables, property lists or assoc lists.

Whereas having a syntax for hash table {} and using this syntax in definitions/calls clearly indicates a conflict. What is it? Coincidence? Purpose?