Re: [Gretl-devel] more function package news
On Wed, 26 Aug 2009, Sven Schreiber wrote:
I wonder whether it may be too ambitious to have this GUI thing
for packaging (as opposed to have a GUI for running the package,
that's a great feature). Package authors are probably
scripting-savvy enough so that they could be expected to prepare
one special script with a special package mark-up (like
<helper-function-start> ... <helper-function-end> or whatever,
you get the picture), and when this marked-up script is run a
package is produced. Would that help in eradicating the bugs?
I'd like to try to answer this in a bit more depth. Particularly
since, if Jack were with us (soon may he return!), I'm sure he'd
agree with you in general terms.
My first point pertains to your final question: "Would that
[bypassing a GUI function packager] help in eradicating the bugs?"
The answer to that is No. The bugs you found were not located at
the GUI level, they were at the level of the underlying code in
gretl_func.c that handles the relationships between individual
user-defined functions and packages.
I think I now have that code in much better shape, but there were
some easily-fixed, surface-level bugs in my new additions.
Anyway, coming back to your main point: is there really any need
for, or point to, the GUI packager?
Well, let's take this from the ground up. A gretl function is
something you might write on an ad hoc basis for use in a complex
script. In general there's no need to attach meta-information
such as author, date, version, description, help text, example
script, etc. But I take for granted that we _do_ need that sort
of information in a package. So we need some structured means of
recording meta-information.
Now, the method I originally chose for recording that sort of
information is XML, using a specially designed Document Type
Definition (DTD), namely gretlfunc.dtd (it's in the source
package). A current gretl function package (.gfn file) is an XML
document conforming to that DTD which contains one or more
function definitions. And the GUI packager is supposed to let you
produce such files fairly painlessly.
We can debate whether XML is the best way to go. It has the
drawback that some characters commonly found in gretl scripts have
to be escaped, which makes it awkward to hand-edit a script inside
a .gfn file unless you know a little about XML. But it has the
same sort of advantage as wearing a seat-belt: we get some useful
automatic protection by validating a putative function package
against the DTD.
Yes, this only concerns the gross syntatical features of the
package: a .gfn file could validate against the DTD yet be total
rubbish semantically; we need some intelligent human intervention
to validate packages in a substantive sense.
All the same, the functionality offered by libxml is useful. If
we weren't using XML we'd have to write custom, ad hoc, routines
to parse package files containing custom, ad hoc, representation
of the structural elements of a package. As a coder, I like the
XML seat-belt!
Plus, we have some history: for some time now gretl has supported
XML package files (however imperfectly -- and especially
imperfectly in the 1.8.3 release, alas!). The ideal of backward
compatibility says we should continue to support such files.
Moving forward, should we in addition support a quite different
form of package file, or should we try to augment the .gfn format
so that it can do more of what we want?
I'm trying to explore the latter option. I don't want to get into
embedding PDF documentation within an XML file -- Microsoft-style
yuck! -- but I can envisage a .gfn file that has an external
reference to PDF documentation, with the .gfn and the PDF wrapped
in a zip file. That way, I hope to keep some continuity while
supporting new features.
Allin.