Re: Should gnuplot become a programming environment?

[Philipp K. J. <ja...@ie...>]

On Wed, 29 Oct 2014 23:29:45 -0700
sfeam <sf...@us...> wrote:

> On Wednesday, 29 October 2014 04:52:54 PM Philipp K. Janert wrote:
> > 
> > (This started as a discussion on heredocs, but
> > is really about a bigger-picture-issue. So, I'll
> > try to restart this thread again.)
> > 
> > Recently, gnuplot has begun to acquire features
> > that are typical of a programming language:
> > 
> > - loops and conditionals
> 
>   Yes, loops are new.
> 
>   The only thing new about conditionals is that the
>   introduction of bracketed clauses means that you
>   no longer have to stuff the entire content on a
>   single input line.
> 
>   IHMO both of these are significant improvements
>   in usability.
> 
> > - structured data types
> 
>   There are no structured data types in gnuplot that I can think of
>   other than complex numbers {R, I}, and they were in gnuplot from
>   Day One.

Heredocs are a structured data type - they
are not scalars!

An iterable data type will surely follow:
otherwise the loop construct is living in
a vacuum.

> 
> > - statefulness and persistence.

Heredocs, again. You now maintain state (=data)
in the session. 

And as my (naive!) questioning shows, people
will want to persist that state (now that it
is there).

> 
>   You said this before but I do not understand what you are
>   referring to.  Could you give an example?
> 
> You don't mention the one programming-language feature added a
> while back that I do regret:  macros.

I have no problem with macros. They may be a
bad idea (I am not even sure they are), but
they are harmless - because the don't beget
more and more features.

Did you see my implementation of Newton's
method in gnuplot? Which I can do, given 
that I now have a proper looping construct?

But it relies on global variables, doesn't
it? Wouldn't it make sense to introduce 
variables that are local to the body of a
loop, a conditional (both now have bodies!)
or a function? By the way - shouldn't we
have multi-line functions?

And once we will have that array data
structure, it's only a matter of time
before someone implements an FFT in 
gnuplot.

> Since you raise the issue of backing out bad ideas, 
> could we start by deprecating macros?  

I am less concerned about killing off bad
ideas that are going to whither and die by 
themselves. I am concerned about features
that have heavy long-term effects. Again,
I come back to loops: once you have loops,
it is natural to have an iterable data 
type. Once you have loops AND an iterable
data type, you basically have a complete
programming environment, so now it makes
sense to ask for things like local scope.

Each idea by itself is useful and even
harmless - but I suggest that we also
take their long-term costs into account.

Best,

		Ph.