Circular Lists that are not lists?

Circular Lists that are not lists?

[Thorsten Jolitz]

Hi List, 

in a parse-tree produced calling 'org-element-parse-buffer' in
org-buffer "tmp.org" I see that the first first-level headline is tagged
with a :CATEGORY attribute:

,---------------------------------------
| (headline (:CATEGORY #1=\"tmp\" ...))
`---------------------------------------

and that the other headlines in the parse-tree reference the attribute
value:

,-------------------------------
| (headline (:CATEGORY #1# ...))
`-------------------------------

except when a category is explicitly specified for them:

,------------------------------------------------
| (headline (:CATEGORY \"My Category Name\" ...))
`------------------------------------------------

Now ignore the Org-mode specific stuff, this question is really about
circular lists. 

This seems to be a case where circular lists are applied to strings -
should they rather be called circular sequences? 

How can I distinguish the three cases shown when mapping the parse-tree,
i.e. not on the textual level after printing the tree with (print-circle
t), but while mapping the nested list?

 - case 1 :: value defined #1=\"tmp\"

 - case 2 :: value referenced #1#

 - case 3 :: custom value without circular characteristics

?

When getting the property's values, they are all just strings ...

-- 
cheers,
Thorsten

Re: Circular Lists that are not lists?

[Teemu Likonen]

[-- Attachment #1: Type: text/plain, Size: 382 bytes --]

Thorsten Jolitz [2013-09-14 15:48:51 +02:00] wrote:

> | (headline (:CATEGORY #1=\"tmp\" ...))

> | (headline (:CATEGORY #1# ...))

> This seems to be a case where circular lists are applied to strings -
> should they rather be called circular sequences?

There is no circular structure here. #1# points to the object defined
with #1=. Those are just references to the same object.

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Circular Lists that are not lists?

[Pascal J. Bourguignon]

Thorsten Jolitz <tjolitz@gmail.com> writes:

> Hi List, 
>
> in a parse-tree produced calling 'org-element-parse-buffer' in
> org-buffer "tmp.org" I see that the first first-level headline is tagged
> with a :CATEGORY attribute:
>
> ,---------------------------------------
> | (headline (:CATEGORY #1=\"tmp\" ...))
> `---------------------------------------
>
> and that the other headlines in the parse-tree reference the attribute
> value:
>
> ,-------------------------------
> | (headline (:CATEGORY #1# ...))
> `-------------------------------
>
> except when a category is explicitly specified for them:
>
> ,------------------------------------------------
> | (headline (:CATEGORY \"My Category Name\" ...))
> `------------------------------------------------
>
> Now ignore the Org-mode specific stuff, this question is really about
> circular lists. 
>
> This seems to be a case where circular lists are applied to strings -
> should they rather be called circular sequences? 
>
> How can I distinguish the three cases shown when mapping the parse-tree,
> i.e. not on the textual level after printing the tree with (print-circle
> t), but while mapping the nested list?
>
>  - case 1 :: value defined #1=\"tmp\"
>
>  - case 2 :: value referenced #1#
>
>  - case 3 :: custom value without circular characteristics
>
> ?
>
> When getting the property's values, they are all just strings ...

#= and ## are just a way to refer to the same object when reading a
sexp.

This has nothing to do with circular lists, or circular structures,
other than they're the only way to build such circular lists or circular
structures at read time.

But references can be used without anything circular.

    (defvar *knights-saying* '(#1=Ni! #1# #1#))
    *knights-saying* ; --> (Ni! Ni! Ni!)

They can also be used without any list:

    (defvar *recursive-vector* '#1=[a #1# vector])
    (let ((print-level 4)
          (print-circle nil))
      (print *recursive-vector*))
    ;; in any sane lisp system should print:
    [a [a [a [a # vector] vector] vector] vector]
    ;; but in emacs it doesn't
    ; -> #1=[a #1# vector]

And notice how there can't be any notion of circular vector!  But the
structure built by this vector is "circular" meaning that walking it
leads to a circle in the graph of objects and references.

I won't give an example with defstruct since in emacs structures are
actually vector, so we're reduced to the previous case.  But you may try
it as an exercise, both in emacs lisp and in Common Lisp.

Use:
 (setf *print-length* 10 *print-level* 4 *print-circle* nil) 
in Common Lisp.



Circular lists are lists, in the sense that: (deftype list () '(or cons null))


-- 
__Pascal Bourguignon__
http://www.informatimago.com/

Re: Circular Lists that are not lists?

[Thorsten Jolitz]

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:

Hi,

> Thorsten Jolitz <tjolitz@gmail.com> writes:
>
>> Hi List, 
>>
>> in a parse-tree produced calling 'org-element-parse-buffer' in
>> org-buffer "tmp.org" I see that the first first-level headline is tagged
>> with a :CATEGORY attribute:
>>
>> ,---------------------------------------
>> | (headline (:CATEGORY #1=\"tmp\" ...))
>> `---------------------------------------
>>
>> and that the other headlines in the parse-tree reference the attribute
>> value:
>>
>> ,-------------------------------
>> | (headline (:CATEGORY #1# ...))
>> `-------------------------------
>>
>> except when a category is explicitly specified for them:
>>
>> ,------------------------------------------------
>> | (headline (:CATEGORY \"My Category Name\" ...))
>> `------------------------------------------------
>>
>> Now ignore the Org-mode specific stuff, this question is really about
>> circular lists. 
>>
>> This seems to be a case where circular lists are applied to strings -
>> should they rather be called circular sequences? 
>>
>> How can I distinguish the three cases shown when mapping the parse-tree,
>> i.e. not on the textual level after printing the tree with (print-circle
>> t), but while mapping the nested list?
>>
>>  - case 1 :: value defined #1=\"tmp\"
>>
>>  - case 2 :: value referenced #1#
>>
>>  - case 3 :: custom value without circular characteristics
>>
>> ?
>>
>> When getting the property's values, they are all just strings ...
>
> #= and ## are just a way to refer to the same object when reading a
> sexp.
>
> This has nothing to do with circular lists, or circular structures,
> other than they're the only way to build such circular lists or circular
> structures at read time.
>
> But references can be used without anything circular.
>
>     (defvar *knights-saying* '(#1=Ni! #1# #1#))
>     *knights-saying* ; --> (Ni! Ni! Ni!)
>
> They can also be used without any list:
>
>     (defvar *recursive-vector* '#1=[a #1# vector])
>     (let ((print-level 4)
>           (print-circle nil))
>       (print *recursive-vector*))
>     ;; in any sane lisp system should print:
>     [a [a [a [a # vector] vector] vector] vector]
>     ;; but in emacs it doesn't
>     ; -> #1=[a #1# vector]
>
> And notice how there can't be any notion of circular vector!  But the
> structure built by this vector is "circular" meaning that walking it
> leads to a circle in the graph of objects and references.
>
> I won't give an example with defstruct since in emacs structures are
> actually vector, so we're reduced to the previous case.  But you may try
> it as an exercise, both in emacs lisp and in Common Lisp.
>
> Use:
>  (setf *print-length* 10 *print-level* 4 *print-circle* nil) 
> in Common Lisp.
>
> Circular lists are lists, in the sense that: (deftype list () '(or
> cons null))

Quite a lot of very interesting stuff to digest. Since this
'object-reference' syntax is presented as circular-list read-syntax in
the manual, I thought it was tightly bound to the concept of circular
lists (as the function `print-circle' suggests too), so I was surprised
to see it used with string objects. 

Thanks for info (Pascal and Teemu).

-- 
cheers,
Thorsten