Changing the way dispatch works for built-in functions

[John W. Eaton]

While looking at this bug report

  https://savannah.gnu.org/bugs/?49794

I started thinking about how to better handle dispatch for built-in 
functions.  Currently, built-in functions are found last.  The search is 
performed in symbol_table::fcn_info::fcn_info_rep::xfind:


http://hg.savannah.gnu.org/hgweb/octave/file/9b096bffc10d/libinterp/corefcn/symtab.cc#l647

As things are now, if you create a .m file function with the same name 
as a built-in function, the .m file function will always override the 
built-in function.  But, if we were to install built-in functions in the 
map from class name to function (the same one that is currently only 
used for user-defined classes) then we could limit the damage someone 
could do by installing a plain old function with the same name as a 
built-in.  For example, if we installed the current built-in svd 
function in the class map for double and single classes, then the 
built-in svd function would be found when svd is called with a double or 
single argument.  The only way for a user to accidentally override the 
built-in version would be to create a function @double/svd @single/svd.

Lookup of built-in functions would also be slightly faster because the 
ones that are installed for specific types would be found earlier than 
they are now, bypassing some extra logic that is must now be executed 
before finding a built-in function.

All that needs to change is to augment the map of types and functions 
with built-in functions and the types they handle, and modify the code 
that clears that table so that it doesn't remove built-in functions from 
the list.  It is not necessary to add all functions at once.  Any 
built-in functions that are not associated with specific types will be 
found the same as they are now.

This change could also be the start of simply translating operators (+, 
-, *, etc.) to function calls (plus, minus, times, etc.) which could be 
overloaded instead of having the dispatch for operators happen in a 
completely different way from function calls.  Some care would be needed 
to avoid slowing operators down, but I think it should be possible.

jwe