replace-assoc with implicit indexing?

[HPW]

This works from the doc:

Code Select Expand


> (set 'aList '((a 1 2 3)(b 4 5 6)(c 7 8 9)))
((a 1 2 3) (b 4 5 6) (c 7 8 9))
> (replace-assoc 'b aList '(q "I am the replacement"))
((a 1 2 3) (q "I am the replacement") (c 7 8 9))
> aList
((a 1 2 3) (q "I am the replacement") (c 7 8 9))

This do not work (as I hoped)

Code Select Expand


newLISP v.9.2.0 on Win32.

> (set 'aList '(((a 1 2 3)(b 4 5 6)(c 7 8 9))))
(((a 1 2 3) (b 4 5 6) (c 7 8 9)))
> (replace-assoc 'b (aList 0) '(q "I am the replacement"))
((a 1 2 3) (q "I am the replacement") (c 7 8 9))
> aList
(((a 1 2 3) (b 4 5 6) (c 7 8 9)))
>

It seems not to be destructive on the nested list.

So whats the best way?

[Jeff]

Implicit indexing (when you used (aList 0)) creates a new list.  If you first assign a symbol to (aList 0), you can then destructively modify that list and retain the value using procedural code like that.



For deep lists, it's better to use ref or ref-all (or a find expression) to find the index of a cell and then use nth-set to set its contents.  You could also use nth-set with the result of (aList 0):

Code Select Expand

(set 'aList '(((a 1 2 3)(b 4 5 6)(c 7 8 9))))
> (nth-set (aList 0) (replace-assoc 'b (aList 0) '(q "I am the replacement")))
((a 1 2 3) (b 4 5 6) (c 7 8 9))
> aList
(((a 1 2 3) (q "I am the replacement") (c 7 8 9)))

[HPW]

Thanks for the hint.



Maybe Lutz can think about to make this optional in replace-assoc, so when it gets a Implicit indexing then it does also the nth-set.



Anyway the doc could be updated to show either the new use or your sample to show how to use it in this case.

[Jeff]

Well, technically you aren't operating on an association list.  You are operating on a list that contains an association list as one element.



My feeling is that this is a special case.  The language should be broad so that it can handle special cases but not so specific in all special cases that it handles that it becomes Java with lots of parenthesis.

[HPW]

The language should be broad so that it can handle special cases but not so specific in all special cases that it handles that it becomes Java with lots of parenthesis.

I do not see that it becomes java when adding some optional arguments/argument-formats.

In newLISP development there was always the motto 'Get more with less typing'.



So when a:

Code Select Expand


(replace-assoc 'b (aList 0) '(q "I am the replacement"))

would do the same as:

Code Select Expand


(nth-set (aList 0) (replace-assoc 'b (aList 0) '(q "I am the replacement")))

it would be less to read.

(Detecting a implicit list would internaly make the nth-set)



Then this would not be wrong in the doc:

A destructive operation, replace-assoc changes the contents of the list.

Of course it is not mentioned in the doc that implicit indexed lists are allowed there.



Another sample:

Code Select Expand


(length someList 0 0)

instead of:

Code Select Expand


(length (someList 0 0))


Less typing and it does not break old code since the arguments are optional.



Anyway, Asap Lutz has to decide and whatever he make it will make newLISP better and better!!



;-)