On Wed, Jul 29, 2009 at 6:13 PM, Robert T. Short
<address@hidden> 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