Re: [O] [RFC] [PATCH] [babel] read description lists as lists of lists

[Aaron Ecay]

Hi Nicolas,

2014ko irailak 26an, Nicolas Goaziou-ek idatzi zuen:
> 
>> Why?  Babel’s representation is for babel.
> 
> Which I strongly frown upon.

Let’s back up a step.  The representation I am targeting with my change
is what babel uses to ship a list off as input to code in a babel block.
This code could be emacs lisp, but it could also be R, python, etc.  So
the question is, how to provide a consistent language-agnostic view of
org structure to other languages.  The resultant structure doesn’t hang
around inside babel, it just gets handed off to a code block.

> 
>> org-list-parse-list/-to-generic’s is for radio lists (although as I’ve
>> said this connection seems accidental rather than essential).  Babel
>> calls org-list-parse-list, but I don’t see why it should be forbidden
>> from doing more processing on the result before passing it along
>> (indeed, it already does some processing to remove the list type
>> indicators, remove nested structure, etc.).
> 
> It is best to use as much common ground as possible. We should strive to
> decrease need for such processing, not the other way.
> 
> As I already stated in my first answer, in the long run, it is the only
> sane way to proceed. I agree it is less work to simply tweak Babel right
> now and ignore the whole Org ecosystem, but it does no good to Org as
> a whole.

It’s not work that I’m afraid of: I offered to rewrite both babel and
radio lists in terms of org-elements.  Maybe I am insane, as you imply.

What I’m afraid of is old and disused sort-of-APIs like
org-list-parse-list calcifying and preventing good things from happening
to parts of org that people actually use.

What if I rewrote org-babel-read-list in terms of org-elements?  That
would satisfy me wrt. babel, and wouldn’t necessitate disturbing
org-list-parse-list, radio lists, or indeed anything outside of babel.

> 
> `org-list-parse-list' handles nested lists just fine. Another advantage
> of not re-inventing the wheel in every part of Org.

I know.  But babel’s processing of parse-list’s output strips the nested
structure:

#+name: a-list
- foo
- bar
  - abc
  - def
- baz

#+begin_src emacs-lisp :var lst=a-list
  (pp-to-string lst)
#+end_src

#+RESULTS:
: ("foo" "bar" "baz")

That’s because it’s hard to come up with a good representation of a nested
list in a language-agnostic way.  “List of strings” is a straightforward
datatype in every language babel supports, but not all of them have a
convenient “labeled n-ary tree with string leaves” (which you’d need for
arbitrarily nested lists).

Thanks,

-- 
Aaron Ecay