Why did you remove the octave devs from the cc? The whole point of my messages is to try to encourage them to implement a compiler. If it is possible to implement it would be a great thing for them. If the devs don't like my ideas, let me know and maybe I will stop :-). Just maybe.
Now it seems the problem is only with functions and not operators (from nrjank's message). Creating a database with returning types from functions is an immediate idea that only needs mechanical work. I don't know how many functions Octave have. And I don't think there are many functions that return different types for the same variable. It would be a really strange thing to do.
If the operators are not a problem this could be a straight forward solution. I estimate at least 98% of all functions don't have differing types.
Creating a JIT for this is not a preferred method, it's better to try to use the tools the octave devs have to minimize work. I want to keep it simple. You are too pro for my ideas :-), try to think like an amateur :-D.
From my other thread I learnt that the interpreter doesn't create C code but compiled data that is run. So my idea is to use the interpreter on every line and create compiled data segments that are put together to create a runnable program.
Giving the user responsibility of keeping the types static, but not
checking them, sounds like a good way to produce segfaults and corrupted
data. That's a pretty bad failure mode for a programming language.
If you're going to be re-examining the type dynamically at run time to
take care of this, maybe you'd be more interested in a JIT than a
separate compilation mechanism? That way all users could get the benefit
of the compiled code speed-up. This is kind of how _javascript_ and
similar JITs work: examine the types that you get on the first few
passes of a function, optimistically compile code to those types, and
put up guardrails that detect when the actual run-time types coming in
violate those assumptions, so you can switch away from the compiled code
and either recompile
> How hard can
> it be to check variable types?
Given that type systems are an active area of academic research, and
compilers are some of the more effort-intensive software projects we
have, I'm going to say "pretty hard".
> The other part you write about I don't understand, why should the m-code be
> turned into C? The idea is to use the interpreter on every line of the
> m-file and create compiled code segments. Putting these segments together
> would be the runnable program.
C is typically used as an intermediate language when compiling
high-level languages down to native code. C is basically portable
assembly language. That way you can just write a transpiler that
transforms your code to C, and call an existing C compiler on that,
instead of having to write a compiler that transforms your code all the
way down to native machine code.
Are you suggesting that Octave should generate machine code directly? Or
compile to something else...?
Cheers,
Andrew
P.S. Removed octave-maintainers from the Cc because I suspect they're
getting tired of this conversation.