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

[Andrew Janke]

On 4/16/19 7:00 PM, GoSim wrote:
> Do you have access to the compiled structures that Bison creates?
> 
> If yes, then changing the name of the variables in the m-file (instead of
> the c-file that doesn't exist) by adding a suffix everytime the type changes
> should be sufficient. Put the structures after eachother and that's the
> compiled code. Without loops there is no performance difference, but with
> loops if it is not needed to run the parser more than once for every line it
> could be a big difference.
> 
> I need to know how you detect if it is a string, int, imaginary number etc.
> 
> 
> If I create a program that changes the m-code according to my idea will you
> take care of the Bison thing and put its compiled structures after eachother
> and run it?
> In the future though, busy atm.

I think you're a little optimistic about how hard a project this would
be. One big issue is that *variables* in Octave are essentially untyped.
Only *values* (arrays) have types. And that type is not known until run
time, when you execute the individual line of code that is referencing
the value. In general, you can't know what the type of the value in a
particular variable is at parse time, because function calls and most
Octave expressions are untyped. You could only deduce the type for
variables which are initialized with literals inside a given function.
And thanks to the existence of evalin() and assignin(), that value and
its type can change at any time during program execution, _even when_ no
assignment or reference to the variable holding it is made. So that type
deduction is only valid for the line where initialization occurs.

All the Bison stuff is in the Octave source code repo in the "libinterp"
subdirectory. (I think.)

Cheers,
Andrew