Re: [Fwd: Gnuplot: MAX_NUM_VAR in src/syscfg.h]

[Ethan A M. <merritt@u.washington.edu>]

On Friday 24 June 2005 12:11 pm, you wrote:
> >> How about changing these arrays to hold dynamically
> >> allocated pointers instead.  [[...]]
>
> - how are string literals in expressions represented?

If a literal string appears in-line on a single command line, then it
has no continuing existence.  It exists as part of the command line
being parsed.

String variables do have continuing existence, in dynamically-allocated
storage associated with the udv for that variable name.

A string literal that is part of a user-defined function is held in
a dynamically-allocated udv in the pre-built evaluation stack for
that function.

In any case, when the string is referenced during the course of evaluating
an expression, a copy of the string is made by allocating dynamic storage.
This temporary copy is pushed/popped/dereferenced using the stack during
the expression evaluation, and freed again at the end of evaluation.

> When I was 
>   deliberating over this area, I was tending towards having the notion
>   of a string pool associated with an exression. The pool would
>   survive for as long as the expression did, and if that meant the
>   expression was stored in a user-defined fn, then the string pool
>   would persist.

If I understand correctly, that is what it currently does.
But I don't quite follow the use of the word "pool", except insofar
as the strings exist in the heap managed by malloc() via gp_alloc().

>   If that approach was used, then the names of the dummy variables
>   could be stored in that string pool.

There you lost me.  The dummy variable names are independent of
any particular function, and must be available to the parser before
any user-defined functions have been defined.  Unless, as before,
by "stored in that pool" you mean "dynamically allocated by gp_alloc()"?

> - the other aspect of MAX_NUM_VAR is to actually have space for the
>   values during (recursive) expression parsing. My recollection is
>   that gnuplot used to have a fixed area for the parameter values, and
>   when recursing into a udf, would copy the old values into temporary
>   space, and put the new values into the globals. I don't know if this
>   is still how it works. But a much more elegant solution would be to
>   use an evaluation stack. (I work on java vm's these days, so it's
>   obvious where this idea comes from...)

It does use an evaluation stack.  Currently the stack is of fixed size
   eval.c:  static struct value stack[STACK_DEPTH];
but I think it would be straightforward to make it dynamically evaluated
instead. The push() routine would have to check whether the stack needs
to be expanded via realloc().


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742