overloaded function handles

[Judd Storrs]

On Wed, Jul 29, 2009 at 1:34 AM, Jaroslav Hajek <highegg at gmail.com> wrote:

> No, probably not. I was a little confused about what you were trying
> to say. Were you suggesting to change the implementation?


Let me preface this by saying that I have no idea how handles are
implemented in Octave and it may well be that you've already implemented it
this way. What I am trying to do is outline an implementation that I belive
works differently from what is described in the patent but that I feel gets
very close to Matlab's behavior.

To my understanding of the patent, the core claims revolve around:

1) Function handles are data structures that contain a dispatch list of
overloaded function implementations.

2) When evaluated each handle's data list is searched for the appropriate
overloaded function implementation instead of searching the implementations
available in the current environment.

3) The handles are somewhat isolated from changes in the environment that
add or remove overloaded implementations.

So first lets say what this is not. It is not about managing a central
database/cache of overloaded function definitions.

My suggestion is that perhaps a lot of this may be unnecessary in real code
because in many cases it is obvious which of the overloaded functions is
meant by the programmer. In those cases no dispatch list is needed and the
handle can refer always to that one specific implementation. i.e. no data
structure. These cases are immune to changes in environment by definition
because they have already been fully resolved.

That leaves the remaining cases where it isn't necessarily obvious which
implementation is desired. My question is how much real, working code would
it break if instead of searching the scope that the handle was created in,
we instead search the handle is applied in.

If the function can be found via the regular path mechanism, then a central
cache of available functions is sufficient and that can be created/querried
any time. So we just need to identify those cases where the central cache
doesn't apply.

So when you create a handle to an overloaded function if the implementation
is "immediate" based on some simple rules/heuristics (i.e. anonymous
functions, functions defined in the same file) the handle is fully resolved
at creation and refers to that specific implementation. Because there is no
list created and attached to the handle at creation the claims of the patent
shouldn't apply.

Class methods are a little trickier but could be handled by type matching of
the first argument at the time of evaluation. This should allow derived
classes to override parent methods, I think.

On the otherhand, if you create a handle and the implementation is not
"immediate" then a list of overloaded implementations would not be created
and no dispatch list is attached to the handle--instead the handle just
holds the function name. Because a dispatch list is not attached to the
handle at the time of creation, the patent doesn't apply. At evaluation
instead of searching the creation scope we search the calling scope. This
would differ from the described behavior in the patent. From my reading, the
core octave dispatch engine would be free to cache whatever it wants at the
time handle application as long as it does not attach multiple
implementations to the handle at the time of handle creation.

Because the dispatch tree is created at the time of evaluation instead of at
the time of creation it can conceivably result in different behavior between
Matlab and Octave because the scopes are different. The hope would be that
the "immediacy" rules can be designed to cover most if not all of the useful
cases where functions disappear.

What I'm having trouble thinking of are examples where someone could make
good use of the difference between what Matlab does and what I'm describing.

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