Re: Is there a command that shows the C-code the interpreter creates?

[Andrew Janke]

On 4/16/19 6:38 PM, GoSim wrote:
> apjanke-floss wrote
>> On 4/16/19 4:56 PM, GoSim wrote:
>>> Ok, I misunderstood, Bison doesn't parse the m-code but creates a parser.
>>> So
>>> Bison is a general interpreter. And the parser creates a parse tree. 
>>
>> Pretty much. Bison generates a C program which is a parser, and the
>> execution of that parser procedurally processes the parse tree, though
>> the parse tree itself may not be represented explicitly in a data
>> structure.
>>
>>> And you run this parser on every line in the m-file. I thought the m-code
>>> was converted to C-code somewhere...
>>
>> Nope.
>>
>>> How does your parser know if it is a int or double?
>>
>> All numerics in Octave are doubles unless you explicitly convert them to
>> ints using int32() or similar conversion functions. All numeric literals
>> in Octave produce doubles. So if you see a number in Octave code, it's a
>> double.
>>
>> Cheers,
>> Andrew
> 
> How does your parser know if it is a string or int or matrix or imaginary
> number?
> thanks for clearing stuff up btw.

You're welcome!

See the Octave docs for how strings, ints, imaginaries, and so on are
represented in M-code source: https://octave.org/doc/interpreter/

>From the parser's point of view:

> a string

Strings are represented with single-quoted or double-quoted string
literals ('...' or "...").

> or int

Ints are only created with conversion functions, like "int32(42)".

> or matrix

In Octave, *every* value is a matrix. There is no such thing as a scalar
value, like there is in most every other programming language.
*Everything* is a matrix. (Or, rather, everything is an N-dimensional
array, and we call specifically 2-D arrays "matrixes".) Let *that* sink
in. :)

> imaginary number

Imaginary numbers are produced by suffixing a numeric literal with "i"
or "j". E.g. "1.23i". To create a complex number, you add a real and an
imaginary number with the regular addition operator, e.g. "1.23 + 4.56i".

And variables have no type; it's all dynamically typed. (In fact,
because Octave is so dynamic, and function calls & array indexing use
the same syntax, you don't necessarily know at parse time whether a
given identifier is a variable or a function.)

As for how the *interpreter* knows this stuff about live objects after
the parsing stage, it's all done dynamically with data structures.
(Almost) every Octave value is represented by a C++ object of class
Array or one of its subclasses, and that object contains fields that
indicate the length/size/dimensionality, imaginariness, and data type
(int32/double/char/MCOS-object) of the array, along with a pointer to
the C array containing the raw underlying data and some
reference-counting/bookkeeping data. Variables are all untyped; type and
size information is only contained in values. So there's nothing like
the C notion of a primitive scalar int or char or double. It's more like
every value in Octave is like a Java java.lang.Object, where there's a
heap-allocated interpreter data structure holding run-time type info for
it, and every Octave variable is like a Java variable of type
java.lang.Object, that just holds a reference to a structure whose type
you can query dynamically.

This stuff is Octave internals, so there's not much doco for it, but you
can see the source code and all the details in the "liboctave"
subdirectory of the octave source code. https://www.octave.org/hg/octave
The "libinterp" subdir holds most of the interpreter/parser stuff; with
"libinterp/octave-value" hodling the stuff for variables. There's also
Appendix A: External Code Interface in the Octave manual that describes
how oct-files (Octave functions written in C++) interact with the Octave
internals, which could be relevant here.

Cheers,
Andrew