newby: comment and review

[luc]

as a very newby in erlang, id like to receive some review on the
following piece of code, especially on the design viewpoint.

purpose: comp2html/2 render a composite structure  into html. test/0
illustrate this.
the source list is recusively like tagged_list={tag, value | [values],
[{tagged_list...}]}.
(this could result from an xml-tree for instance). currently only the
tag "name" is really trapped, for example purpose. other are expected.
same for format. italic() is used here <i>, but <li>, <h1,2..>, and so
on will be used.

A) uses of erlang.

1) basic : please comment on the use of the terminal clauses of
comp2html. I feel this can be done a better way... but i dont really
know how.

2) use of higer order function: are there any way to navigate this
composite structure with HOF ? ( adapting the strucuture, if neccessary)

B) extensibility and readability of the code

3) as the number of tags will grow, the code will grow messy, as it
mixes navigating the structure and formating the result in the same
place. would it be possible to separate them , say, one function that
navigate the structure, and another , the formatter , give as a fun to
the first one? the code should be clearer, and afford chage of tags more
easily. (kind of a visitor pattern in OO)

4)currently, only html is targetted. but other format , like docbook
sgml/xml is probable for printing. this will impact the formatter. but
we can also expect that the structure of the  target document may not
match 1:1 the input structure, but may rearrage it slightly, like
ignoring some tags, rearranging sort orders... depending on the document
expected (like a TOC, a REF, an index, ... reflect the same contents in
differents solution).
so ideally, borrowing from a sgml production chain, the following would
be separated: contents, structure, format.

and a result document would be the composition of a structure fun, over
a format fun .
(eg: format_comp ( one_per_page_structure , to_html, [taggeg_list...]),
where one_per_page_structure , to_html are fun. )

does it sounds realistically feasible, or just plain dream (or just
inconprehensible, as explained here ;-)? (note : i dont plan to reinvent
latex or jade  (yet...) ;-.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20000727/9c64a8fe/attachment.htm>