[proposal] unification: using '() as list identity deref arg

Started by hartrock, November 27, 2013, 10:14:16 AM

Previous topic - Next topic

hartrock

[update] -> 10.5.6.



During writing some code to ease navigation in lists, I've stumbled about something. Let's speak code for itself.



Assumed there is a definition for ref-parent and some example list:



;; nil for non-existing parent

(define (ref-parent r)
  (if (null? r) nil (0 -1 r)))
;;
(setq l_nested '("1" "2" "3"
                  ("4" "5" "6"
                   ("7" "8" "9"))
                 "10" "11" "12"
                  ("13" "14" "15"
                   ("16" "17" "18")))
      )

Now it's possible to eval:

> (l_nested (ref-parent (ref "14" l_nested)))
("13" "14" "15" ("16" "17" "18"))

; but it is not possible to eval:

> (l_nested (ref-parent (ref "11" l_nested)))

ERR: missing argument

Reason is, that:

> (ref-parent (ref "14" l_nested))
(7)

; but:

> (ref-parent (ref "11" l_nested))
()

: here '() is not being accepted as deref argument.



What about introducing '() as allowed deref argument, which dereferences list itself to which it is applied to?

Then the following would work:

> (l_nested (ref-parent (ref "11" l_nested)))
("1" "2" "3" ("4" "5" "6" ("7" "8" "9")) "10" "11" "12" ("13" "14" "15" ("16" "17" "18")))


This seems to be a neat unification regarding dereferencing lists by refs.



Because ref'ing a non-existing element gives:

> (ref "not there" l_nested)
nil

; '() seems to be free for this purpose.

If there is:

> (ref-all "not there" l_nested)
()

, we get a '(). But this is no problem, because for dereferencing refs gotten this way, we have to iterate through this list, which would do nothing here.



Are there any problems with this proposal, which I don't see?



What do you think?



Feedback to this proposal is appreciated (as usual).

Lutz

I like the idea: http://www.newlisp.org/downloads/development/inprogress/CHANGES-10.5.6.txt">http://www.newlisp.org/downloads/develo ... 10.5.6.txt">http://www.newlisp.org/downloads/development/inprogress/CHANGES-10.5.6.txt



... working as expected on your example.

hartrock

Thanks: it works like a charm :-)

Could be a speed record from making a proposal to getting it done... :-)

xytroxon

No...



He usually adds the functionality before you have fully described (or understood), what functionality it is that you want added...



Then to add insult to injury, his solution works better and is more elegant... (Although it may take you a day or two to fully realize it ;o)



-- xytroxon
\"Many computers can print only capital letters, so we shall not use lowercase letters.\"

-- Let\'s Talk Lisp (c) 1976

xytroxon

Case in point, from this weekends inprogress  newlisp-10.5.6.tgz



I was just thinking about how integer numbers could be used as hashkeys, and I find this addition in  CHANGES-10.5.6.txt


Quote
Integers are accepted as hash keys. This allows creating sparse vectors:

       (new Tree 'V)

       (V 123 "hello")

       (V 123) => "hello"


( I thought Lutz's PhD was in psychology, not parapsychology!!! ;o)



-- xytroxon
\"Many computers can print only capital letters, so we shall not use lowercase letters.\"

-- Let\'s Talk Lisp (c) 1976

TedWalther

Quote from: "xytroxon"Case in point, from this weekends inprogress  newlisp-10.5.6.tgz



I was just thinking about how integer numbers could be used as hashkeys, and I find this addition in  CHANGES-10.5.6.txt


Quote
Integers are accepted as hash keys. This allows creating sparse vectors:

       (new Tree 'V)

       (V 123 "hello")

       (V 123) => "hello"


( I thought Lutz's PhD was in psychology, not parapsychology!!! ;o)



-- xytroxon


Sweet!
Cavemen in bearskins invaded the ivory towers of Artificial Intelligence.  Nine months later, they left with a baby named newLISP.  The women of the ivory towers wept and wailed.  \"Abomination!\" they cried.