Arc Forumnew | comments | leaders | submitlogin
Lists as functions on symbol arguments
7 points by bogomipz 6135 days ago | 6 comments
I just thought of something. List-ref takes an integer index as argument, and in Arc a list in functional position translates to list-ref. What if the argument was also allowed to be a symbol, in which case the list elements were treated as interleaving keys and values?

  arc> (= foo '(a 1.3 b 42 c "bar"))
  (a 1.3 b 42 c "bar")
  arc> foo.1
  1.3
  arc> foo!b
  42
  arc>
It would then be trivial to write functions with keyword arguments without adding support for that to the language.

  arc> (def bar (a0 a1 a2 . kvp)
            (list a1 kvp!b))
  #<procedure: bar>
  arc> (bar 1 2 3 'a 4 'b 5)
  (2 5)
  arc>
This is not a full blown keyword argument implementation, though. The function signature does not reveal recognized keys (must be documented in the docstring), and there are no default forms. On the other hand, it kind of seems like the Arc way.


1 point by cchooper 6134 days ago | link

Alternatively, it could be used to do an assoc lookup, which would make alists more like hashes.

  (= x '((a 1) (b 2) (c 3)))

  x!b
  => 2
Note that it returns the value not the pair, as with hashes. It's not as powerful as assoc but more convenient in most cases.

-----

1 point by bogomipz 6134 days ago | link

And a third alternative is to use dotted pairs for the associations, but my point was that by treating a plain list as alternating keys and values, it plays nice with rest arguments in functions.

Generally, a list may be interpreted in different ways in different situations, and a common complaint about lisp is that you can't tell if a cons cell is supposed to be the starting point of a tree, an assoc list, a sequence, or something else. I think the way to tackle this in Arc should be to make better use of annotations.

A rest argument will always be a plain list without a tag. That's the reason for the suggested interpretation of kvp!b.

-----

1 point by nlavine 6133 days ago | link

Why are we assuming that keyword arguments must be passed as flat lists of keywords and values?

  (bar 1 2 ('foo 3) ('baz 4))
I agree the flat way is cleaner, but this is certainly a possibility too.

-----

1 point by cooldude127 6134 days ago | link

well, you could always just use pairs to turn the interleaved list into an alist.

-----

1 point by bogomipz 6134 days ago | link

Yes, with the overhead of the operation plus a let form.

My suggestion only really applies if pg decides against adding keyword arguments to Arc.

-----

2 points by cchooper 6134 days ago | link

Exactly. It's basically a roundabout way of adding keywords into the language. A better idea would be to just add them, and then list-functional notation could be used for something more generally useful.

-----