Re: Octave compiler

[Rob Vermaas]

Hi,

Sorry for the late response, but I've been quite busy in the meanwhile, 
as I found some of your remarks a good excuse to do some cleaning up and 
rewriting of the code of the compiler.

> What are the problems you face when supporting built-in functions?
> The code for those functions already exists, so shouldn't you be able
> to link to liboctinterp/liboctave and have nearly all of them work?
>  
You are right that nearly all builtin function work. So mainly builtin 
functions that depend on the interpreter related things do not work 
completely.

> I looked at the parser, and it seems you have adapted Octave's lexer
> and parser.  I think this is a good idea, as it makes little sense to
> develop a separate parser from scratch.  However, the code in Octave
> is likely to change, so if you fork your own version, you are likely
> to have a maintenance problem in the future.  Would you like to help
> introduce changes to Octave's parser so that it would be easier to
> generate what you need without having to rewrite the actions part of
> the paresr?  It migth be possible to do that now, without any changes
> to Octave, by writing a new new class based on Octave's tree_walker
> class (in src/pt-walk.h) that can take Octave's tree representation of
> the input and emit whatever you need for your front end.  That way,
> any changes to Octave's language in the parser/lexer would require
> fewer changes to your code.
>  
I have followed your advise on writing a tree_walker implementation. It 
is nearly finished and works well.

> The front end appears to have a list of built-in functions and
> variables.  How do you generate this list?  Would you like to
> contribute or help write patches to Octave's build system so that you
> can generate this information automatically for new versions of Octave?
>  
As I changed to using more of the internals of Octave, these lists have 
become redundant, therefore it is not necessary for us to generate them.


greetings,
Rob Vermaas