From octave-maintainers-request at bevo dot che dot wisc dot edu Sun Feb 22 12:52:00 2004
Subject: Re: Octave compiler
From: Paul Thomas <paulthomas2 at wanadoo dot fr>
To: Paul Kienzle <pkienzle at users dot sourceforge dot net>
Cc: Jens Ruecknagel <Jens dot Ruecknagel at stud dot tu-ilmenau dot de>,    octave-maintainers-list <octave-maintainers@bevo.che.wisc.edu>,    "JD Cole (OCTAVE)" <listguy@transientresearch.com>
Date: Sun, 22 Feb 2004 19:51:45 +0100

Yes, that is what I was getting at - or explicit type declaration.  I 
had more than once wondered if the language would benefit from optional 
type assertion in some shape or form.  This, however, brings to mind the 
discussion,a few months back, of passing arguments by reference or by 
value. Compatability with the other product makes them very undesirable. 
 Equally, to judge by the other products performance on basic 
interpretation/evaluation, intelligence must exist.....  I have started 
analysing typical .m functions to see how intelligence might be 
manifested in either interpreters or compilers.

Paul T

Paul Kienzle wrote:

> In lieu of intelligence, one can always use pragmas to identify types.
> E.g.,
>     %% int i
>     %% double t, x[]
>     t=0; for i=1:n, t += x(i); end
>
> You can even do this in octave code instead of special syntax:
>
>     x=double(x);
>     t=double(0); for i=int(1:n), t += x(i); end
>
> but you need some way to make sure that double, int, etc. always
> return values of the right type, even in the presence of dispatch, oct
> files, user defined types, etc.
>
> - Paul
>     
> On Feb 22, 2004, at 10:46 AM, Paul Thomas wrote:
>
>> JD and Jens,
>>
>> Have you given any thought yet as to how you will do the C++ generation?
>> I suppose that a first order approach would be, in essence, to output 
>> the octave evaluator code.  However, I suspect that the performance 
>> improvement over that of the interpreter/evaluator will not be as 
>> impressive as writing .oct files "by hand".  Therefore, the trick is 
>> going to be to improve on the evaluator, particularly where type 
>> identification, indirect referencing and bound checking is concerned. 
>> Once you do that, the strategy you have adopted should allow to 
>> similarly improve octave's evaluator, should it not?
>>
>> Paul Thomas
>>
>
>