Hi Rick,

> I think (I’m speculating, that is) that the confusion was due to the
> unusual (but not incorrect) choice of having key/val pairs stored in symbol
> property lists as
> 
>       +-----+-----+
>       | VAL | KEY |
>       +-----+-----+
> 
> where VAL is the the CAR position and KEY in the CDR position. There is not
> right or wrong about this, that’s just how it works. I find this point very
> interesting. I believe it has something to do with streamlining the
> picolisp (C or asm) code regarding properties, but I don’t know for sure.
> Alex?

No, this is in fact a fundamentak design decision. It allows the 'var'
concept to be extended to properties, using the 'prop' and '::'
functions.

If the value VAL of a property cell is in the CAR, all functions which
accept a location (noted as 'var' argument in the reference) can
directly operate on it. The KEY is relatively unimportant, it is
only used internally to locate the cell in the property list.


For example, give the symbol 'A' a property with KEY = 'cnt' and VAL
zero:

   : (put 'A 'cnt 0)
   -> 0

If you get the property cell (the pair VAL / KEY above):

   : (prop 'A 'cnt)
   -> (0 . cnt)

you see that the value is in the CAR and the KEY in the CDR.

Now you can increment this:

   : (inc (prop 'A 'cnt))
   -> 1

Check:
   : (get 'A 'cnt)
   -> 1
   : (prop 'A 'cnt)
   -> (1 . cnt)


Another examples with 'push':

   : (push (prop 'A 'lst) 1)
   -> 1
   : (push (prop 'A 'lst) 2)
   -> 2
   : (push (prop 'A 'lst) 3)
   -> 3
   : (get 'A 'lst)
   -> (3 2 1)
   : (prop 'A 'lst)
   -> ((3 2 1) . lst)

   : (with 'A
      (println (pop (:: lst)) (pop (:: lst)))
      (push (:: lst) 7)
      (: lst) )
   3 2
   -> (7 1)

♪♫ Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Reply via email to