overloaded function handles

[Judd Storrs]

On Wed, Jul 29, 2009 at 6:13 PM, Robert T. Short <
octave at phaselockedsystems.com> wrote:

>  Judd, the problem with your argument is that the *CLAIMS* don't include
> the quotes you have below.  The invention is defined by the claims, not the
> patent body.  The patent body provides scope and a dictionary, but does not
> define the invention.  If the claims refer to an technique or term that is
> not clearly defined by standard practice or is intended to be used
> differently from standard practice, the body is used to interpret the
> claim.  So, breaking claim 1 down:
>
> *1. A method comprising: at a first point in a program in a computer
> programming language having dynamic types and overloaded functions,*
>
> octave is a computer language having dynamic types and overloaded functions
>
> *constructing, using a function name, a function data structure; *
>
> do we derive a data structure from a function name?
>
> *the function data structure comprising information leading to a set of
> functions visible at the first point; *
>
> Is the data structure comprised of information leading to a set of
> functions visible at the first point?
>


Obligatory: I am not a patent attourney.

You're right that my interpretation caries no weight at all, and "visible at
the first point" could mean just about anything, I suppose. But under too
broad of a reading type-aware computer algebra systems like Axiom and
Mathematica become obvious examples of prior art along with typed functional
languages like Haskell and OCAML. I have yet to find prior art for claim 1
under under the stricter reading.


*at a second point, applying the function data structure to an argument
> list, the applying comprising selecting a function using the function data
> structure and calling the selected function.
> *
> At the second point in the program, do we apply the function data structure
> to an argument list, that is do we call the selected function using an
> argument list?
>

> The wording of this last claim element is awkward and may leave a hole.
> Furthermore, it seems that any object-oriented language would infringe this
> claim.
>


I agree in part. But the problem with looking to object-oriented language
precedent is that most of the object-oriented languages follow the
"object->method()" syntax which unfortunately changes the problem
significantly. That approach leads naturally to a class-centric data
structure instead of a function-centric data structure.

For example, in C++ I believe a class ultimately boils down to a pointer to
a static structure that contains a pile of function pointers. At evaluation
because of the use of object->method syntax you know exactly where to find
the function because each object "type" information is a pointer to it's
class structure.

Initially I had hoped that IDL had already done something similar (generally
I prefer IDL's OOP style to Matlab's). The problem is that IDL, perl,
python, Ruby etc. all use some variant of the object->method() style.

I have tried to find object oriented languages that have taken the
method(...,object,...) route for dispatch. S+/R comes close. R's
implementation may actually have function data structures but as far as
something like a function handle goes, in R it seems that all the language
offers are strings and an feval equivalent.

I suspect that just about all (dare I say sane?) object-oriented prior art
uses a class-based data structure.

If we look beyond object-oriented languages the next stop is typed-aware
computer algebra systems like Mathematica, Axiom, OCAML, Haskell which make
heavy use of function name overloading. Mathematica and Axiom (like C++)
have very sophisticated and clever function dispatch based on the type
signatures of the input arguments. In Mathematica (and supposedly in Axiom)
you can do things like define different functions with the same name for
even integers, odd integers, rationals, quaternions, etc.

Matlab seems somewhat unique because the language doesn't allow it to
express any of these things well at all. It doesn't allow you to specify the
types of the arguements to a function and it also forces you to use the
ambiguous method(...,object,...) syntax that is sensitive to the current
search path (ick). But that's what we have to work with.

Maybe a class-organized data structure could work in octave? That seems the
safest way to stay completely away from the the claims altogether because
there is not function data structure and plenty of prior art but I'll have
to think about how to keep Jaroslav happy with the performance ;)


--judd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090729/eee4ec79/attachment-0001.html