>I don't have a function count, but Octave is about 500,000 lines of
>code: 375,000 lines of C++ and 170,000 lines of M-code. A quick `grep
>'^function' **/*.m | wc -l | tail -1` turns up 1,750 function
>declarations in the M-code. Dunno how many ore are in the C++ code.
>When you say "the same variable", do you mean "the same variable type
>for its arguments", or "the same variable value"? There are several core
>functions that can return different variable types depending on the
>value, not type, of their input variables. E.g. eval(), feval(),
>fread(), textscan(), load(), cellfun(), subsref(), javaMethod(),
>database.fetch().
I mean "the same variable type for its arguments". Those you list are still few.
>The fraction of functions that don't have differing return types is
>probably less relevant than how frequently those functions are called in
>practice. And since, as stated above, you don't know how many functions
>Octave has, it seems excessive to claim a precise figure like "98%" when
>guessing at how many of Octave's functions are polymorphic in their
>return types.
Guessing about things I know little is one of my expert areas :-D
So I will make my guess even more precise just to annoy you. My new guess is 98.117%
:-DDDDD
>From what I've seen, most M-code functions operate in terms of function
>calls primarily on their input arguments, and not on literal expressions
>defined in the function. That would make most M-code functions
>potentially polymorphic, unless your compiler could do an exhaustive
>analysis on all the code paths which potentially call them, and trace
>those code paths back to literal expressions which could narrow down the
>potential inputs.
The compiler should of course go through all m-files.
>But the Octave devs already have a start at a JIT; it's an established
>project, and there's some code for it in the Octave repo.
Didn't know that.
>The things you are proposing – creating new compiler functionality, with
>something like static type inference or a typed dialect of Octave – are
>not simple. Have you ever implemented a compiler or interpreter before?
No. I'm not even a software engineer. Just ignore my posts if they are stupid.
>I don't even understand what you're talking about here any more. Could
>you elaborate? What do you mean by "compiling" and "compiled data
>segments" here, if it's not about creating C code which can be compiled
>down to native machine code? And is "compiled data" different from
>"compiled code"?
>Cheers,
>Andrew
The interpreter runs the m-files somehow, how does it run them? It creates compiled data
segments with the interpreter and runs these segments , one after the other and inbetween
the octave variable handling is run. So this requires an analysis of every line repeatedly in e.g.
a loop. The idea is to have the interpreter go through every line of the m-file and create the runnable
segments and puzzle them together. This would only require analysis of every line once and would
be much faster.
please keep the octave maintainers as the recipient