Re: Unintended consequences - things to think about

[Karl R. <ra...@un...>]

Am 13.11.2014 um 18:20 schrieb Philipp K. Janert:
> 
> Here are some things to think about:
> 
> 1) We now have loops. But we don't have an
> iterable data structure. No, wait, we have
> one - we fake it as white-space separated 
> string. (I admit the ingenuity of the thought,
> but - how kludgy is THAT?)
> 
> So, before too long, the loops will beget
> an array. That seems certain.

Arrays would be very, very useful for plotting. Think of a multiplot,
one plot with five datasets plus fitted curves, and an inset showing a
regression on the fitted parameters. The simplest way to do that in
gnuplot today is have an external script that generates your gnuplot
script. ;-)


> 2) Once we have arrays, there will be a
> desire to load files into them. Otherwise,
> why have arrays, right? So, arrays will
> beget a "read_file" feature. 

Yes. It´ll be a single command, not interfering with anything. With
that, I could e.g. leave all the fitting to another program (although
gnuplot does a very good job at it! Try fitting in Origin.) and hand the
parameters over to gnuplot in a straightforward manner.

> 3) Now that we can read file(s) into 
> arrays, it's natural that we want to 
> operate on them. One could do that with
> loops, but (again) it's natural to do 
> things like array1 + array2, right?

Same, but who would want it, if not to plot the result, which is very
reasonable for a plotting program?

> 
> 4) Whereas items 1-3 lie in the future, the 
> following is already an issue today: we have
> loops and conditionals, so it seems natural
> to write functions. Well - we don't HAVE
> functions, but we can fake them as scripts
> that we load with "call". Problem is that
> these scripts don't define local variables -
> any variable I use in my script will become
> a variable in the gnuplot session. To prevent
> clobbering existing variables, I therefore
> need to prepend a prefix to the name of each
> variable "MY_SCRIPT_i", "MY_SCRIPT_j", and so
> on. Very kludgy. Hence, it is reasonable to
> ask for functions with local variables.

I agree this would be one step too far, but you can import library
functions today, so there´s no real need for this. And i guess it would
be quite hard to find a (backward compatible) syntax for this, let alone
implementing it.

> I also think that it is a misdirection of effort: 
> do we really need to figure out how to design 
> functions with locally scoped variables? This
> has already been done, several times. Would it
> not be better to leverage other people's work?
> 
> If gnuplot needs to acquire programming features
> to stay competitive, then it should try to borrow
> them from somewhere else, where all these problems
> have already been solved - rather than inventing
> the wheel (and poorly, at that).

As long as "keep it backward compatible" stays the most important
paradigm in the development, i don´t quite see how the "programming
environment" features could get out of hand too badly. It makes sure the
learning curve will stay flat in the beginning.

Interfacing gnuplot with other programs is however an issue today, imo.
That would be, for example, much easier with an array variable that can
be read in from a file, see above, and also keep away further need for
new complex features.

  Karl