New very simple methodology to create a m-file compiler.

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

New very simple methodology to create a m-file compiler.

GoSim
If the user wants to compile the code force the user to write code where the
variable types are static. The syntax is still m-code syntax. Use your
interpreter and check if any variable changes type and then display an error
message:

"Variable x changes type from ? to ? at line ?, please restructure your code
so that variables never change type to use the Octave compiler"

Now just take the compiled segments and put them after eachother, declare
the variables at the top or just before they are used in the m-file.

This is very user friendly, much easier than your current oct-file method
and would attract more users and it is also very simple to implement.
Restricting the m-file to not allow variable type changes is no challenge
for most scripters, and for the performance gain it's a nobrainer.

So with this method there is no need to automatically make the m-file only
have static types or to hack the compiled code. This effort is put on the
scripter and it is not much of an effort.

C code is considered to be 7 times faster than java. I consider java to be
5-20 faster than m-code.....you have to implement this.



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: New very simple methodology to create a m-file compiler.

GoSim
I want to add that the documentation for this functionality would not be more
than for a function like lsqlin(), lsim() etc.

Just write that types can't be changed and maybe add some examples. The
learning to do for m-scripters is close to zero.



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: New very simple methodology to create a m-file compiler.

apjanke-floss
In reply to this post by GoSim

On 5/5/19 12:15 PM, GoSim wrote:

> If the user wants to compile the code force the user to write code where the
> variable types are static. The syntax is still m-code syntax. Use your
> interpreter and check if any variable changes type and then display an error
> message:
>
> "Variable x changes type from ? to ? at line ?, please restructure your code
> so that variables never change type to use the Octave compiler"
>
> Now just take the compiled segments and put them after eachother, declare
> the variables at the top or just before they are used in the m-file.
>
> This is very user friendly, much easier than your current oct-file method
> and would attract more users and it is also very simple to implement.
> Restricting the m-file to not allow variable type changes is no challenge
> for most scripters, and for the performance gain it's a nobrainer.
>
> So with this method there is no need to automatically make the m-file only
> have static types or to hack the compiled code. This effort is put on the
> scripter and it is not much of an effort.
>
> C code is considered to be 7 times faster than java. I consider java to be
> 5-20 faster than m-code.....you have to implement this.
>

This probably wouldn't work, because the types of M-code expressions
can't be determined at "compile" time. You could do it for variables
that were initialized from literal expressions in the code. But function
calls (and due to operator overloading, most non-trivial M-code
expressions) can generally return any type they want, and that type is
not determined until run time. And what function actually gets called is
also not determined until run time, because that depends on the run time
types of the arguments to the function, and what's on the Octave path.
So the compiler doesn't generally have access to compile-time type
information for variables in M-code.

It's also probably not "simple to implement", because then you're still
left with the problem of how to translate M-code into more efficient C
code. Octave's runtime and data structures are _already written in C++_;
you'd need to find alternate faster ways of implementing their semantics
in C, and a way of generating that code automatically.

Cheers,
Andrew

Reply | Threaded
Open this post in threaded view
|

Re: New very simple methodology to create a m-file compiler.

GoSim
apjanke-floss wrote

> On 5/5/19 12:15 PM, GoSim wrote:
>> If the user wants to compile the code force the user to write code where
>> the
>> variable types are static. The syntax is still m-code syntax. Use your
>> interpreter and check if any variable changes type and then display an
>> error
>> message:
>>
>> "Variable x changes type from ? to ? at line ?, please restructure your
>> code
>> so that variables never change type to use the Octave compiler"
>>
>> Now just take the compiled segments and put them after eachother, declare
>> the variables at the top or just before they are used in the m-file.
>>
>> This is very user friendly, much easier than your current oct-file method
>> and would attract more users and it is also very simple to implement.
>> Restricting the m-file to not allow variable type changes is no challenge
>> for most scripters, and for the performance gain it's a nobrainer.
>>
>> So with this method there is no need to automatically make the m-file
>> only
>> have static types or to hack the compiled code. This effort is put on the
>> scripter and it is not much of an effort.
>>
>> C code is considered to be 7 times faster than java. I consider java to
>> be
>> 5-20 faster than m-code.....you have to implement this.
>>
>
> This probably wouldn't work, because the types of M-code expressions
> can't be determined at "compile" time. You could do it for variables
> that were initialized from literal expressions in the code. But function
> calls (and due to operator overloading, most non-trivial M-code
> expressions) can generally return any type they want, and that type is
> not determined until run time. And what function actually gets called is
> also not determined until run time, because that depends on the run time
> types of the arguments to the function, and what's on the Octave path.
> So the compiler doesn't generally have access to compile-time type
> information for variables in M-code.
>
> It's also probably not "simple to implement", because then you're still
> left with the problem of how to translate M-code into more efficient C
> code. Octave's runtime and data structures are _already written in C++_;
> you'd need to find alternate faster ways of implementing their semantics
> in C, and a way of generating that code automatically.
>
> Cheers,
> Andrew


Functions giving any type will affect the error messages when checking the
static type code but assuming the types are static it still works (give the
user the responsibility of static types). Maybe try to give error messages
when the compiled code is running somehow if there is a type error. Maybe
there are compile code analyzers that can give error messages? How hard can
it be to check variable types?

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.



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: New very simple methodology to create a m-file compiler.

nrjank
On Sun, May 5, 2019 at 3:12 PM GoSim <[hidden email]> wrote:
>apjanke-floss wrote
>> On 5/5/19 12:15 PM, GoSim wrote:
>>> If the user wants to compile the code force the user to write code where
>>> the variable types are static.
 
>> But function
>> calls (and due to operator overloading, most non-trivial M-code
>> expressions) can generally return any type they want, and that type is
>> not determined until run time. 

> Functions giving any type will affect the error messages when checking the
> static type code but assuming the types are static it still works 

Ok, so now we are restricting the user in type reassignments.  Regarding functions, must the return type be able to be declared at 'compile time'? Or is it simply sufficient to somehow determine that whatever type it is never changes? 

Can anyone give examples of a common function that could return a number of different classes depending on how it's called, especially if that can't be determined trivially by just reading and not running the code? Would we have to make an exclusion list of all functions capable of returning multiple classes and have the compiler throw an error any time one of those functions appears in a loop if it's not trivial to tell what class will be returned each time?


Reply | Threaded
Open this post in threaded view
|

Re: New very simple methodology to create a m-file compiler.

GoSim
That the type doesn't change is enough to know, I don't know how to determine
that without knowing what type/s the function gives though.

I can't recall ever have encountered a function that gives a variable that
can change type. It would be a very unuser-friendly way of writing a
function and I can't imagine there are too many of those.



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: New very simple methodology to create a m-file compiler.

GoSim
In reply to this post by nrjank
regarding type from function:

if it is a new variable the type is needed to declare it, if it is an
already used variable it is enough to know it doesn't change type.



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: New very simple methodology to create a m-file compiler.

GoSim
In reply to this post by GoSim
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.
 
 
Reply | Threaded
Open this post in threaded view
|

Re: New very simple methodology to create a m-file compiler.

nrjank
In reply to this post by GoSim

On Mon, May 6, 2019 at 10:40 AM GoSim <[hidden email]> wrote:
regarding type from function:

if it is a new variable the type is needed to declare it, if it is an
already used variable it is enough to know it doesn't change type.

 

A similar question was asked on StackOverflow about polymorphic functions, and they gave a very simple example of a function that could return multiple types, even non-predictably.

I also found an EETimes article talking about the difficulty in writing a Matlab-to-C translator, and polymorphism came up, among other things, as a particularly challenging translation problem.

I haven't identified any non-custom function that produces highly polymorphic output yet, maybe someone else can think of one.  but a simple:

a = 1;
b = 'foo';
[b, a] = deal(a, b)
b = 1
a = foo

could be a problem i guess. this example might be easy to catch, and maybe even correct for, but only if you include 'deal' on a compiler blacklist of functions that can change variable type.


Reply | Threaded
Open this post in threaded view
|

Re: New very simple methodology to create a m-file compiler.

apjanke-floss

On 5/6/19 11:13 PM, Nicholas Jankowski wrote:
>
> I haven't identified any non-custom function that produces highly
> polymorphic output yet, maybe someone else can think of one.

I've got a few.

fread() jumps out at me. Pretty basic I/O function, but it can return
any of the primitive types, depending on the value (not type) of its
PRECISION argument.

textscan() is similarly polymorphic, depending in an even more complex
way on the value of its FORMAT string. tableread() will be too, once
implemented.

load() is a common function, and it can return just about anything.
jsondecode() and webread() will work similarly once they are implemented.

And, as usual, eval(), feval(), evalin(), and str2num() defeat any
attempt at static analysis: they can return *anything*, depending on
their inputs in a way that is probably not determinable at parse time.

subsref() on a cell or struct can return anything, because cell elements
and struct fields can hold anything.

arrayfun(), cellfun(), and structfun() can return anything, because
their output type is dependent on the output type of the function handle
they are passed as an argument at run time.

If Octave implemented the Database Toolbox, the return type of fetch()
varies in a complex way dependent on its input query string, the value
of its input FORMAT argument, _and_ the state of some global pref settings.

javaMethod() may return either a Java object or Octave arrays of various
primitive types, depending on the run-time type of the return value of
the method it calls.

And we're kind of ignoring the inherent polymorphism of most of Octave's
arithmetic operations: the ouput of +, -, /, and * (aka plus(), minus(),
divide(), and times()) depends on the type of their inputs, though not
their values. So if your compiler knew the input types at parse time, it
could deduce the output types: *if* it knew the mixed-arithmetic
promotion rules. E.g. "double + uint16" produces a "uint16"; "double +
char" produces a double. But that would only cover the primitives that
could be enumerated ahead of time; wouldn't tell you anything about
promotion rules for user-defined classes.

Cheers,
Andrew

Reply | Threaded
Open this post in threaded view
|

Re: New very simple methodology to create a m-file compiler.

nrjank


On Mon, May 6, 2019 at 23:34 Andrew Janke <[hidden email]> wrote:

On 5/6/19 11:13 PM, Nicholas Jankowski wrote:
>
> I haven't identified any non-custom function that produces highly
> polymorphic output yet, maybe someone else can think of one.

I've got a few.

 I guess what this boils down to is if you are going to require the user to avoid polymorphism on outputs, and you are going to throw an Error when they don’t , how will you be able to tell when they don’t? And if you’ve gone through the problem of detecting all of the cases where they Might not,  at that point wouldn’t it be better to just deal with the polymorphism somehow  rather than require them to avoid one of the more useful aspects of the programming language? 

Reply | Threaded
Open this post in threaded view
|

Re: New very simple methodology to create a m-file compiler.

Carlo de Falco-2


> Il giorno 07 mag 2019, alle ore 13:32, Nicholas Jankowski <[hidden email]> ha scritto:
>
>
>
> On Mon, May 6, 2019 at 23:34 Andrew Janke <[hidden email]> wrote:
>
> On 5/6/19 11:13 PM, Nicholas Jankowski wrote:
> >
> > I haven't identified any non-custom function that produces highly
> > polymorphic output yet, maybe someone else can think of one.
>
> I've got a few.
>
>  I guess what this boils down to is if you are going to require the user to avoid polymorphism on outputs, and you are going to throw an Error when they don’t , how will you be able to tell when they don’t? And if you’ve gone through the problem of detecting all of the cases where they Might not,  at that point wouldn’t it be better to just deal with the polymorphism somehow  rather than require them to avoid one of the more useful aspects of the programming language?

also, what is the actual purpose of this thread in the first place?
is the OP poster proposing to change the grammar of the language in order to make it easier to compile?
if you are looking for a language symilar to (but not compatible with) matlab that is faster to parse and compile then why not just look at https://julialang.org/ ?
c.


Reply | Threaded
Open this post in threaded view
|

Re: New very simple methodology to create a m-file compiler.

Ian McCallion
In reply to this post by nrjank
On Tue, 7 May 2019 at 12:33, Nicholas Jankowski <[hidden email]> wrote:


On Mon, May 6, 2019 at 23:34 Andrew Janke <[hidden email]> wrote:

On 5/6/19 11:13 PM, Nicholas Jankowski wrote:
>
> I haven't identified any non-custom function that produces highly
> polymorphic output yet, maybe someone else can think of one.

I've got a few.

 I guess what this boils down to is if you are going to require the user to avoid polymorphism on outputs, and you are going to throw an Error when they don’t , how will you be able to tell when they don’t? And if you’ve gone through the problem of detecting all of the cases where they Might not,  at that point wouldn’t it be better to just deal with the polymorphism somehow  rather than require them to avoid one of the more useful aspects of the programming language? 

Apologies for giving my opinions unasked, but it seems to me as an outsider that this boils down to why someone might want to compile m-code in the first place. I can think of two reasons:

A. For packaging and/or obfuscation. If this is the problem compiling is NOT the solution and a much preferable solution would be more targeted, involving compression, encryption, and the creating of a run-time-only version of Octave.

2. For performance. Most m-code does not involve a high degree of looping hence will not gain significant performance benefit from compilation. However there are cases where well-designed and well-written m-code utilising octave's extensive libraries wherever possible still has a significant performance problem. Providing ability to compile the performance-critical sections would be orders of magnitude easier to use for most Octave users than requiring them to write it in another programming language using another IDE, then integrating the result into the original application.

As has been shown already during this discussion compiling m-code is hard and there are necessary restrictions. A way around this would be to enable the user to give hints to the compiler. These hints could be by way of language extensions, but this would prevent the m-code working on Octave releases or environments not supporting compilation, so a better way might be by specialised comments. To illustrate this the comment:

   ###V integer count_things

could be used to assert that a particular variable is of a particular datatype.

Cheers... Ian 
Reply | Threaded
Open this post in threaded view
|

Re: New very simple methodology to create a m-file compiler.

GoSim
Ian McCallion wrote

>
> As has been shown already during this discussion compiling m-code is hard
> and there are necessary restrictions. A way around this would be to enable
> the user to give hints to the compiler. These hints could be by way of
> language extensions, but this would prevent the m-code working on Octave
> releases or environments not supporting compilation, so a better way might
> be by specialised comments. To illustrate this the comment:
>
>    ###V integer count_things
>
> could be used to assert that a particular variable is of a particular
> datatype.
>
> Cheers... Ian

This is a nice and simple solution.




--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: New very simple methodology to create a m-file compiler.

GoSim
In reply to this post by Carlo de Falco-2
Carlo de Falco-2 wrote
>> Il giorno 07 mag 2019, alle ore 13:32, Nicholas Jankowski &lt;

> jankowskin@

> &gt; ha scritto:
>>
>>
>>
>> On Mon, May 6, 2019 at 23:34 Andrew Janke &lt;

> floss@

> &gt; wrote:
>>
>> On 5/6/19 11:13 PM, Nicholas Jankowski wrote:
>> >
>> > I haven't identified any non-custom function that produces highly
>> > polymorphic output yet, maybe someone else can think of one.
>>
>> I've got a few.
>>
>>  I guess what this boils down to is if you are going to require the user
>> to avoid polymorphism on outputs, and you are going to throw an Error
>> when they don’t , how will you be able to tell when they don’t? And if
>> you’ve gone through the problem of detecting all of the cases where they
>> Might not,  at that point wouldn’t it be better to just deal with the
>> polymorphism somehow  rather than require them to avoid one of the more
>> useful aspects of the programming language?
>
> also, what is the actual purpose of this thread in the first place?
> is the OP poster proposing to change the grammar of the language in order
> to make it easier to compile?
> if you are looking for a language symilar to (but not compatible with)
> matlab that is faster to parse and compile then why not just look at
> https://julialang.org/ ?
> c.

The purpose is to make it possible to compile m-files for speed.



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: New very simple methodology to create a m-file compiler.

Richard Crozier


On 07/05/2019 17:06, GoSim wrote:
> Carlo de Falco-2 wrote

>>
>> also, what is the actual purpose of this thread in the first place?
>> is the OP poster proposing to change the grammar of the language in order
>> to make it easier to compile?
>> if you are looking for a language symilar to (but not compatible with)
>> matlab that is faster to parse and compile then why not just look at
>> https://julialang.org/ ?
>> c.
>
> The purpose is to make it possible to compile m-files for speed.
>
>

I think his point is that making it work for a large part of the code
base is pretty hard (otherwise a good JIT would also be easy), and if
you make it so that there are many many things which a user must
remember to make it work safely, then it might be just as easy for them
to write it in another language in the first place.

Richard
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
Reply | Threaded
Open this post in threaded view
|

Re: New very simple methodology to create a m-file compiler.

Carlo de Falco-2
In reply to this post by GoSim


> Il giorno 07 mag 2019, alle ore 18:06, GoSim <[hidden email]> ha scritto:
>
> The purpose is to make it possible to compile m-files for speed.

just compiling m-code will not necessarily make it faster.
to make compiled code faster you need to avoid all the overhead related to dynamic typing.
if you force users to write sections of code that need to be faster without dynamic typing you are essentially asking them to use a different language.
but if you need to use a language different from the standard Octave language in sections that are to be compiled, why not write them in C++ as .oct files then?

c.
Reply | Threaded
Open this post in threaded view
|

Re: New very simple methodology to create a m-file compiler.

GoSim
In reply to this post by GoSim
 
 


>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

 
Reply | Threaded
Open this post in threaded view
|

Re: New very simple methodology to create a m-file compiler.

GoSim
In reply to this post by Carlo de Falco-2
Carlo de Falco-2 wrote
>> Il giorno 07 mag 2019, alle ore 18:06, GoSim &lt;

> GoSim@

> &gt; ha scritto:
>>
>> The purpose is to make it possible to compile m-files for speed.
>
> just compiling m-code will not necessarily make it faster.
> to make compiled code faster you need to avoid all the overhead related to
> dynamic typing.
> if you force users to write sections of code that need to be faster
> without dynamic typing you are essentially asking them to use a different
> language.
> but if you need to use a language different from the standard Octave
> language in sections that are to be compiled, why not write them in C++ as
> .oct files then?
>
> c.

No, it's not another language. Just a few differences, and also I don't
agree that dynamic types are used often and removing it would equal a new
language. I never use it.
I think it would be much more user friendly and would attract more users.
M-script is a very nice language. I only program high level languages like
java and don't know C++. I don't think I am the only m-scripter like this.



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: New very simple methodology to create a m-file compiler.

GoSim
In reply to this post by Richard Crozier
Richard Crozier wrote

> On 07/05/2019 17:06, GoSim wrote:
>> Carlo de Falco-2 wrote
>
>>>
>>> also, what is the actual purpose of this thread in the first place?
>>> is the OP poster proposing to change the grammar of the language in
>>> order
>>> to make it easier to compile?
>>> if you are looking for a language symilar to (but not compatible with)
>>> matlab that is faster to parse and compile then why not just look at
>>> https://julialang.org/ ?
>>> c.
>>
>> The purpose is to make it possible to compile m-files for speed.
>>
>>
>
> I think his point is that making it work for a large part of the code
> base is pretty hard (otherwise a good JIT would also be easy), and if
> you make it so that there are many many things which a user must
> remember to make it work safely, then it might be just as easy for them
> to write it in another language in the first place.
>
> Richard
> The University of Edinburgh is a charitable body, registered in Scotland,
> with registration number SC005336.

Learning a few new things in a language you are used to is much easier than
learning a new language.




--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

12