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 my(z=2);eval("z^2") works. 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 unravelled. \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. Cheers, Bill.