[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ian McCallion
Subject: Re: New very simple methodology to create a m-file compiler.
Date: Tue, 7 May 2019 14:01:57 +0100

On Tue, 7 May 2019 at 12:33, Nicholas Jankowski <address@hidden> wrote:

On Mon, May 6, 2019 at 23:34 Andrew Janke <address@hidden> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]