OpenEuphoria

Re: Calling Func/Proc

• Posted by Robert Craig <rds at RapidEuph?ria.com> Jul 12, 2007
• 643 views

CChris wrote:
> c.k.lester wrote:
> > CChris wrote:
> > 
> > > I must look at this more carefully, but then there would be no performance
> > > issue
> > > in having a function return the last caller name/the whole list.
> > > 
> > > As I said, I'd use it too.
> > > Any objections? There must be some around <smile/>.
> > 
> > + No performance hit
> > + Enhancement is beneficial to programmers
> > 
> > There better be no objections! :P
> > 
> > Do it! Do it! Do it! :)
> 
> I had some eyestrain problems lately, keeping coding at a minimum this week.
> 
> 
> Things look better now. I'd like to plug once for all a probable DC leak in
> win32lib "Patch #67" so that I can send Derek (and the testers, remember?)what
> I can consider beta-stage code for him to merge into his code base, ultimately
> leading to a new public release of the lib. The consequence of the leak is the
> slowing down of all graphic rendering.
> 
> When this is done, I'll look into the 
> <prospective doc entry>
> s=function get_callers(i) 
> 
> Returns a sequence of pairs of strings if /i/ is greater than or equal to 0.
> The pairs are of the form {/routine name,file name/} and represent (part of)
> the current list of callers of the routine being executed.
> 
> The first pair in the returned list, if any, shows the routine that directly
> called the code being executed. The second pair shows the routine that called
> the latter, and so on. If the list is empty, it means that your routine was
> called from code outside of any routine, or that your statement is outside of
> any routine itself.
> 
> If /i/ is greater than zero, the /i/ first calling routines are returned, or
> less if there are less. If /i/ is 0, the whole list is returned. A value less
> than 0 will trigger a run time error.
> </prospective doc entry>
> 
> This introduces a new opcode in the IL spec, and causes many places to need
> small modificattions (just like find_from()). As a result, it would appear in
> v3.2 at the earliest if it ever does.
> 
> Any thoughts?

Be aware that these sorts of things are not easy to 
implement in the Translator. Translated code has no real
symbol table, except for a stripped-down (often empty) table that only
has entries for routines that might be referenced by a 
call to routine_id(). Also, the call stack (one per task) 
is just a bare hardware stack, not like the high-level 
software stacks controlled by the interpreter. 

Currently the Translator can handle any program that the 
interpreter can handle. I don't think we want to start 
adding features that are not supported by the Translator, 
unless there is a very good reason for it. It will create
confusion for people, when they try to remember the list
of features (and libraries) that they shouldn't use 
if they want to ever translate their code.

Is it that inconvenient to just add a parameter to the routine,
or set a global variable with the name of the calling routine?
Can we see some examples of where this would be useful. C.K.?

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com