Re: Unintended consequences - things to think about

[<pl...@pi...>]

On 11/13/14 19:14, Karl Ratzsch wrote:
> 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
>
>

There have been a number of times when I've regretted the lack of an 
index array structure in gnuplot.

Sometimes I've been able to hack something to do what I want using some 
kind of iteration but this often involves changing something else to 
shoehorn it into a form where it can be done with an iteration.

I do think this would be a useful addition.

Peter.