Re: Unintended consequences - things to think about

[Ethan A M. <sf...@us...>]

On Thursday, 13 November, 2014 09:20:52 Philipp K. Janert wrote:
> 
> 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?)

Beauty is in the eye of the beholder.
Gnuplot has 3 types of variables: integer, string, and complex

There is one simple iterator for integer variables:
  for [ i = min : max : step]

There is one simple iterator for string variables:
  for [s in "A B C D"]

Arguably there is room for an interator over complex values,
but so far no one has convinced me that it is needed.
 
> So, before too long, the loops will beget
> an array. That seems certain.

[shrug]
I can see reasons one might want to have arrays,
but the existence of loops is not a compelling one.

I'd be more inclined to think about adding support
for lists or unordered sets, with a corresponding 
iterator
  for [element in set]


> 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. 
> 
> 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? 
> 
> 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". 

"call" is a prime example of a gnuplot feature that I have ignored
for decades.  We continue to support the "call" mechanism
(there's that backwards compatibility promise)
but I honestly don't see a good use for it.
Version 5 provides a slightly more standard/familiar variant that
treats the call parameters like shell variables, with save+restore
of the values. But I doubt I'll ever want to use the new variant either.

> 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.

Now it seems you are not so much arguing for discussing
new features as you are implicitly arguing that we should
get rid of a feature that has been there for 25 years.
Isn't this the Python mistake?   To break old scripts as a 
consequence of removing an old feature just because
you thought of a better way to do something similar?

If you don't like "call", don't use it.

If you want to propose a syntax for defining fully-scoped function 
blocks, go right ahead (although maybe you are advocating against
this rather than for this; it's hard to tell).

> My point, in case this still isn't clear:
> 
> Once you have one programming feature (say:
> loops), there is a natural tendency for them 
> to require all other programming features 
> (data structures, functions, local scope).
> 
> Therefore, what starts like a local convenience 
> today will - invariably - grow until it has 
> acquired all the features that are already 
> provided by R, matlab, Octave, Perl, Python, Ruby.
> 
> And THAT I think is the wrong direction. If 
> somebody wants R, why would they use gnuplot? 

Because they find it easier to make nice plots?

Let's flip that question around.  If someone is happy with
gnuplot except for some hypothetical missing feature
provided by R, should we not consider adding that missing
feature to gnuplot?

> 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).

So how about instead of dragging in lots of bad examples,
you suggest what nice feature from some other language
or program we should consider adopting.

	Ethan (not actually finding this discussion very useful)