Re: [Gretl-devel] Request for Comments: gnuplot and foreign
On Thu, 2 Oct 2014, Allin Cottrell wrote:
Sorry it's taken me a while to reply on this, but here are my
thoughts.
I like the idea of using a "block" approach for non-trivial gnuplot commands
within gretl, for two main reasons:
1) to avoid option-overload and the somewhat fussy syntax we have at present
for appending "literal" lines to a plot specification; and
2) to streamline the handling of custom plots (i.e. those not supported by
gretl's built-in "gnuplot" options) so that package writers or others
don't
have to mess with low-level file I/O.
I think that that these two uses probably call for somewhat different
handling -- maybe two distinct modes of a "plot", or perhaps
"foreign",
block.
I've given this more thinking time, and I now think that we could combine
the two approaches that Allin suggested as follows: we scrap the "gnuplot"
command of most options and we leave it as a quick-n-dirty tool for basic
data visualisation: simple line graphs, xy plots, and the like. Then, we
introduce, for more sophisticated jobs, *two* new constructs:
(1) a "plot" environment like the first one Allin envisaged. That is, a
block inside which we allow for special syntax which translates internally
into gnuplot commands, but basically follows the old "gnuplot" command
conventions. In other words, a pidgin language that is neither hansl not
gnuplot. Allin's example
plot
data foo
option with-lines
literal set title "My title"
end plot
exemplifies this quite well. What you get between "plot" and "end
plot" is
simple syntax, with only a few rigid commands. Of course, you wouldn't be
able to use the full power of gnuplot, but in return you would have the
guarantee that the subset of gnuplot commands we'd use for producing the
output is compatible with our GUI editor, so that you could save the
result to the icon view and modify it via our gnuplot interaction GUI tool
if needed.
(2) a "literal" environment, which IMO could well be just another
incarnation of "foreign", as in
foreign language=gnuplot
...
end foreign
in which you could issue _any_ gnuplot command you want and unleash our
graphic engine to its (enormous) full potential. However, you'd lose the
ability to save the result into a gretl graph and, as fare as data passing
is concerned, you'd be totally on your own with solutions like temporary
files (ok, maybe we could envisage some form of string substitution).
Do you guys like this?
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------