Unexpected behavior with built-in

[Joel LeBlanc]

I think we need some community input on this one, but here are some
thoughts.
1)  Builtin is (as far as I know) the only way to call a function outside
the order of precedence
2)  This is an essential feature in the language, with a common use
case being the extension of a "builtin"
function via overloading
3)  What one considers "builtin" is really not essential, what is essential
is the ability to call functions out of precedence
4)  Visibility into the precedence chain is important, and thus "which"
needs to be extended to accept a "-all" flag and return a cell array of
paths to function.  This is almost a separate issue, but I think,
sufficiently related to mention here.

Thus I propose the following
solution.  Have builtin call the "lowest" function in the precedence chain.
 If a builtin exists, this will surely be it under any reasonable
definition.  Furthermore, builtin should throw an error when the "lowest"
function is also the caller.  This is because had the programmer intended
recursion, they wouldn't use builtin.

Finally, I suggest a flag along the lines of "-next", which causes builtin
to call the next lowest function in the precedence chain.  To see why this
could be important, consider altering a function to add a capability but not
knowing if someone else (some other package) also wanted to do the same.
 You want your code to run, but after that you'd like additional such
extensions to run as well.

Cheers,

~Joel

On Thu, Jul 9, 2009 at 7:02 PM, Joel LeBlanc <jwleblan at gmail.com> wrote:

> I need to think about it (and eat!).
> I think there are two issues here.  One is about what should be done (as
> you have said), and the other is about what is happening.
>
> For example, run this one instead
> *****************************************
>
> function builtinFailure
>
>
>
> builtin('fopen','noFile');
>
>
>
> end
>
>
>
> function fopen(varargin)
>
> disp('Calling overloaded load function: Test Failed!');
>
> end
>
> *****************************************
> I get:
> >> which fopen
> `fopen' is a built-in function
> >> builtinFailure
> Calling overloaded load function: Test Failed!
>
> So I maintain that builtin is not working, and I'll think about the other
> issue.
>
> Thanks John!
>
> ~Joel
>
> On Thu, Jul 9, 2009 at 4:22 PM, John W. Eaton <jwe at octave.org> wrote:
>
>> On  9-Jul-2009, Joel LeBlanc wrote:
>>
>> | The current tip (9423:f284e2a26ff9) gives unexpected behavior when I run
>> | built-in.  I am running on OSX (Darwin Kernel Version 9.7.0: Tue Mar 31
>> | 22:52:17 PDT 2009; root:xnu-1228.12.14~1/RELEASE_I386 i386 i386
>> | MacBookPro2,2 Darwin).
>> | Sorry about not having the
>> | standard debug format, but bug_report gives (octave-bug-3.1.55: command
>> not
>> | found).
>> |
>> | So here is a simple function to replicate my concern:
>> | ************************
>> |
>> | function builtinFailure
>> |
>> |
>> |
>> | builtin('beep');
>> |
>> |
>> |
>> | end
>> |
>> |
>> |
>> | function beep
>> |
>> | disp('Calling overloaded load function: Test Failed!');
>> |
>> | end
>>
>> In Octave, beep is not a built-in function.  I'm not sure what should
>> happen here.  Should we have builtin only look up built-in functions
>> (I think that is what Matlab does)?
>>
>> Or maybe we should have builtin only look up built-in functions and
>> functions on the default path?  But if we do that, then how do we
>> decide what is the default path?
>>
>> I'm really not sure what is best here.  I lean toward the first
>> solution, but then it seems likely that we will get complaints that
>> the list of built-in functions in Octave and Matlab are different.
>> And I don't really want to have to be compatible at that level, so I
>> don't expect that situation to change.
>>
>> jwe
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090709/77b5ef14/attachment.html