Bill Allombert on Wed, 21 Jan 2015 20:29:46 +0100

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: Undocumented prototype code "C" in eval()

On Tue, Jan 20, 2015 at 02:41:10PM +0100, Jeroen Demeyer wrote:
> The function eval() has a code C in the prototype which is not documented:
> Function: eval
> Section: polynomials
> C-Name: geval_gp
> Prototype: GC

Indeed, it is a private code for the GP compiler.
This allows the code run through eval() to reference lexical variables
declared with my() by the caller.
This is the magic used so that

The parameter C is a "pack", a data structure describing the list of 
lexical variables. This is used to preseed the GP compiler before 
compiling "z^2" so that z is known.

The file src/language/init.c has this:
 *  C  lexical context

This is a reference to develop.tex;
\subsec{Function related to the GP parser}

The GP parser can generate an opcode saving the current lexical context
(pairs made of a lexical variable name and its value) in a \kbd{GEN}, called
\kbd{pack} in the sequel. These can be used from debuggers (e.g. gp's break
loop) to track values of lexical variable. Indeed, lexical variables have
disappeared from the compiled code, only their values in a given scope exist
(on some value stack). Provided the parser generated the proper opcode, there
remains a trace of lexical variable names and everything can still be

\fun{GEN}{localvars_read_str}{const char *s, GEN pack} evaluate the string $s$
in the lexical context given by \kbd{pack}.  Used by \tet{geval_gp} in GP.

\fun{long}{localvars_find}{GEN pack, entree *ep} does \kbd{pack} contain
a pair whose variable corresponds to \kbd{ep}? If so, where is the
corresponding value? (returns an offset on the value stack).

The leading paragraph is not fully accurate. First there is no dedicated opcode,
and second, the GP debugger do not use these functions. However, it also uses
preseeding of lexical variable however.