octave-maintainers
[Top][All Lists]
Advanced

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

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


From: Andrew Janke
Subject: Re: New very simple methodology to create a m-file compiler.
Date: Mon, 6 May 2019 23:34:18 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

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 via email to

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