OpenEuphoria

Re: Comments on ORAC

• Posted by CChris <christian.cuvier at agriculture.gouv?f?> Nov 12, 2007
• 638 views

Mike wrote:
> 
> Matt Lewis wrote:
> > 
> > Mike wrote:
> 
> > > Now, if the Euphoria internals were modified to have said mask, Orac could
> > > only
> > > take advantage of this for routines called as procedures since it'd have
> > > to
> > > emit
> > > some "if" statements. Therefore, routines called as functions (in an
> > > expression)
> > > just wouldn't work.
> > 
> > I think you're overcomplicating this.  Since you're writing a preprocessor,
> > you just need to create a global function and a global procedure, something
> > like:
> > }}}
<eucode>
> > global function call_indirect_function( integer func, sequence args )
> >     if and_bits( func, C_FUNC_INDIRECT ) then
> >         return c_func( and_bits( func, ROUTINE_MASK ), args )
> > 
> >     elsif and_bits( func, EU_FUNC_INDIRECT ) then
> >         return call_func( and_bits( func, ROUTINEMASK ), args )
> >     end if
> >     -- error handling here...
> > end function
> > </eucode>
{{{

> > 
> > Matt
> 
> 
> Hi Matt,
> 
> Now why didn't I think of that, :-o  Yes, that would work. However, routines
> called as procedures would need to be encapsulated in a function call since
> 
> it won't be known beforehand if a func or proc is being referenced. Orac 
> allows (normal) functions to act like procedures so, to be consistent, that
> should be possible for indirect functions too. To the programmer it'll all
> look the same so it had better act the same.
> 
> Therefore, the mask requires 2 pieces of info: indirect vs dll  and  func vs
> proc.
> 
> This throws up a subtle gotcha: Since indirect calls of both kinds could be
> treated as functions, what happens if a  procedure is inadvertently used in
> an expression? The code will work but be wrong. 
> 
> I think a bit mask would be a good idea if Euphoria were fully modified to
> *natively* support seamless calls. But if this  were done in conjunction with
> Orac the code analysis it does now would still need to be done in order to be
> able to optimize certain calls - as Pete suggested.
> 
> But since indirect calls will always be slower than direct ones, is there
> really
> any point to optimizing? If not, then, there is no point to analysing the code
> either. I have no qualms about suspending the code I've just written - it's
> a hack anyway.
> 
> If this mask were added to Euphoria, what (other than Orac) could take
> advantage of it? I would feel uncomfortable if Euphoria were modified just
> to suit Orac - particularly when I'm inclined to something else.
> 
> IMO, an easier solution is simply to add a specifier to a variable/constant
> declaration. I am going to do this shortly unless someone can convince me
> otherwise with very persuasive arguments.
> 
> 
> Mike

If there is a way - whichever it is - to tell from an id what it refers to -
function vs procedure, indirect Eu vs external - then there would be no need for
c_proc() vs call_proc(), since any of them would do the right thing. So the
change would simplify the language.
Having the index in the indirect call table being different from the id returned
to programmer isn't much of a problem, since the conversion would be fast -
either shifting or anding -.

CChris