Benefits of P-Lists vs Structs vs Classes?

[helmut.r...@gmail.com]

I'm working on a citation management system for academic publications and I'm wondering about the trade-offs representing citations as plists, structs, or classes.

Currently the system uses plists to represent citations. They look something like:

'(:author "Mark Twain"
:selection "Some Thoughts on the Science of Onanism"
:title "Selected Short Works of Mark Twain"
:publisher "Right Hand Publishing"
:year 2009
:pages (27 31))

These plist citations are raw data, they are written out in whatever format the users specifies (MLA, APA, Chicago, etc...). And, yes, the formatting rules are user-extensible (it just wouldn't be a Lisp application then ;) ).

The advantage from this is that these can be written and edited in a text file, then read directly into the program. In addition, they can be decorated with additional fields quite easily:

(defun add-editor (editor citation)
(nconc (list :editor editor) citation))

(add-editor "Jack Handcock" twain-citation)

=> '(:editor "Jack Handcock"
:author "Mark Twain"
:selection "Some Thoughts on the Science of Onanism"
:title "Selected Short Works of Mark Twain"
:publisher "Right Hand Publishing"
:year 2009
:pages (27 31))

With CLOS or structs, this would have to done with object composition closer to something like the Decorator pattern, wouldn't it?

Now the question is am I doing something unidiomatic here? Would I be better off representing these in the program as CLOS objects or structs, then reading/storing them as plists? Are there any general rules-of-thumb of when to use which?

[Pascal J. Bourguignon]

plist structure clos object

printable-readably x x -
O(1) access - x* x
adding slots cons - with mop
functional shadowing cons - with a meta-class
method dispatching cons structure class

*: with pure structures, or structures implemented as vector.



Since you need a textual representation for editing, you could use
as well plists or structures:

#S(citation
:author "…"
:title "…"
…)

CLOS objects would need more work to provide an printable-readbly
format, but it can be simple enough to do:

(apply (function make-instance) 'citation (read stream))


Note, you can also do something similar for structures:

(apply (function make-citation) (read stream))


Slot accesses are faster with structures and objects, but with less than
5 slots, it won't make a lot of difference. Locallity may be better
with structures and objects than with lists too.


Adding slots at run-time is not possible with structures. This may also
be a problem if you have to support different versions of files. With
CLOS object it's simple enough to do with MOP. With plist, it's
trivial: (list* :new-field new-value old-plist).

Functional shadowing (ie. "modifying" a field of a structure as a
functional data structure), is not possible with structures, trivial
with plist (list* :old-field new-value old-plist), and doable with MOP,
defining a meta-class.

Plist may also have an advantage in a situation where the set of fields
may change from object to object (eg. if there are a lot of optional
fields), but this can also be dealt with subclasses (both for CLOS
objects and for structures) if that granularity correspond to the
problem.

If you want to write methods specific to your entities, then plist are
as cons cells, and you can distinguish them from other kind of lists,
while dispatching on a structure or clos class is trivial.



So, there's nothing unidiomatic. Unless you have other reasons to
choose to define citations as CLOS classes (you may very well have, I
imagine citations of books would differ from citations of articles would
differ from citations of movies, etc), I often find more practical to
use structure than plist in my programs. You could still easily keep
the plist format for the human editable files.


In any case this should not be a problem to switch from one to the
other, since you are using functional abstractions.

--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.

[RG]

In article <b56bf1a7-0a76-4d79...@googlegroups.com>,

IMHO making this decision is a premature optimization. The Right Way to
write this kind of code (or just about any kind of code for that matter,
but this kind in particular) is to introduce a layer of abstraction that
makes it easy to swap different underlying implementations in and out,
e.g.:

http://flownet.com/ron/lisp/dictionary.lisp

rg