1. RE: built in routine id's
- Posted by bensler at mail.com Mar 22, 2002
- 478 views
Carl R. White wrote: > Chris Bensler wrote: > > > Why can't I get the routine id of a built in? > > > > ? routine_id("sequence") > > I agree with you on this one, which I admit isn't really like me when it > comes to adding things to Euphoria. :) > > There is a workaround: > > global function s_(object o) return sequence(o) end if > global constant sequence_id = routine_id("s_") > -- now use 'sequence_id' instead of 'routine_id("sequence")' > > ...but using this means that call_func()'s are slower than they could > be. > > Also, you have to write your own wrapper func/procs for every built-in > you > want to get the routine_id of. > > > BTW: > > Did anyone else know they could get the routine_id() of a type? It is > > just a function after all, but it doesn't seem to be documented. > > I did know this. It's all down to experimentation (which, IMHO, too many > people don't do). It's also when I discovered that the built-in types > and > functions don't have their own routine_id's. > > Try this for madness. There's a quiz at the end so pay attention :) : > > type natural(object o) > if integer(o) then return o >= 0 end if > return 0 > end type > > with trace trace(1) > > integer beeble_id > type bobble(object o) > if not natural(o) then return 0 end if > return call_func(beeble_id, {o-1}) > end type > > type beeble(object o) > if not natural(o) then return 0 end if > if not o then return 1 end if > return bobble(o-1) > end type > beeble_id = routine_id("beeble") > > beeble a > bobble b > > a = 4 > b = 5 > b *= b > a = (b-1)/a > > ? a > > POP QUIZ: > > Do it on paper first before running it. > Do the same again starting with a = 8. > What happens in each case, and did it do what you expected? > What are better names for beeble and bobble? (Hint: The second letter of > each is a clue). > > beeble-bobble-beeble-bobble, ;) > Carl I've just discovered this problem, so it's just barely made it's way onto my wishlist. I wouldn't consider it a priority item, though it would be a simple and welcomed improvement for EU. That's a neat little snippet It's not what I had expected :) I won't answer the other question, so others can be intrigued as well :P Chris
2. RE: built in routine id's
- Posted by Bernie Ryan <xotron at localnet.com> Mar 22, 2002
- 459 views
Chris: Why would you need a routine_id of a built-in function when you can over-ride any built-in function and replace it or change something before or after calling it. Bernie
3. RE: built in routine id's
- Posted by Chris Bensler <bensler at mail.com> Mar 22, 2002
- 451 views
Bernie Ryan wrote: > > Chris: > Why would you need a routine_id of a built-in function > when you can over-ride any built-in function and replace > it or change something before or after calling it. > Bernie > > > It was a question, not a demand :) Just curious. The question arrived because I didn't know I could wrap the builtins. The only reason it dawned on me to try, is because I remember someone mentioning a LLOONNGG time ago that it's possible to override the builtins. Is that documented? More than anything, it seems odd not to support referencing of builtins. We can reference any other routine, and we can override the builtins, why not allow referencing them? I wouldn't mind seeing that, but it doesn't make it into my Euphorian Dream :) Chris Bensler ------------------ My Euphorian Dream: 1 : sequence subscripting in the trace facility 2 : function result indexing 3 : slicing shorthands 4 : relational operators for sequences 5 : assignment on declaration 6 : vertical slicing 7 : leading commas for assignments 8 : with/without short_circuit 9 : NULL value for unassigned variables
4. RE: built in routine id's
- Posted by Bernie Ryan <xotron at localnet.com> Mar 23, 2002
- 448 views
Rolf Schröder wrote: > Bernie, > > suppose you have a routine which needs a functions as parameter, i.e., a > general function for integration of functions. The parameter to pass for > the function to be integrated is the func_id parameter. So, how could > you use this kind of routine to integrate build in functions? Any idea? > > Have a nice day, Rolf Rolf: I do not understand your question. Can you give me a simple example then maybe I can come up with an idea. Thanks, Bernie
5. RE: built in routine id's
- Posted by Chris Bensler <bensler at mail.com> Mar 23, 2002
- 462 views
When I originally posted about this, it was just a question, because I had assumed that I would be able to do it, and was puzzled why it wasn't possible, or maybe it was and I was just doing something wrong. Now that I have looked and experimented I have 4 things to point out. 1. The inconvenince of wrapping the builtin routines. So what, I can live with that, the chance that I will have to wrap every routine is very slim. And then in that case, I would make an include file, and would never need to do it again. 2. The extra overhead needed to call the wrappers which call the builtins. Anything that helps to optimize my code is a good thing. 3. You can't wrap routine_id() If I wrap routine_id(), the wrapper must be found after any routines that I need the routine_id for. 4. You can't wrap the builtins with the same name. The MAIN reason that I would want to override the name of a function, would be to change the functionality of a particular routine. Not rewrite it. Even with routine_id() for builtins, this wouldn't be possible; see #5. 5. If someone overrides a builtin, how can I use the original? This would require a special case when calling routine_id(). Perhaps something like equal_rID = routine_id("!equal"). If the concept of #5 were implemented, I could do stuff like this: function gets(integer fn) object ret ret = gets(fn) if fn = 0 then if atom(ret) then return ret end if return ret[1..length(ret)-1] end if return ret end function Chris Rolf Schröder wrote: > Bernie Ryan wrote: > > > > Rolf: > > I do not understand your question. > > Can you give me a simple example then maybe I can come > > up with an idea. > > Bernie, > > enclosed an example. Each in build function has to be called via an > extra user defined function to make it for the function 'qgauss' > callable, like SIN instead sin. If you replace SIN by sin in the MAIN > section you will get an error. I think, the build in > functions/procedures should also freely be usable for routine_id() and > call_func()/call_proc(). > > Have a nice day, Rolf > > include misc.e -- PI > .9739065285} > constant W = { .2955242247, > .2692667193, > .2190863625, > .1494513491, > .0666713443} > > function SIN(atom x) -- equivalent of build in sin() > -- *** > return sin(x) > end function > > function quad(atom x) -- x^2 > -- **** > return x*x > end function > > function qgauss(sequence func, atom a, atom b) > -- ****** > atom xm, xr, ss, dx > integer id > > id = routine_id(func) > xm = (b+a)/2 > xr = (b-a)/2 > ss = 0.0 > for j = 1 to 5 do > dx = xr*X[j] > ss += W[j]*(call_func(id,{xm+dx})+call_func(id,{xm-dx})) > end for > return xr*ss > end function > -- > printf(1,"I(sin)[0,PI] = %15.10f (2 exactly)\n\n", > qgauss("SIN",0,PI)) > printf(1,"I(x*x)[0,3] = %15.10f (9 exactly)\n", > qgauss("quad",0,3)) > abort(0) > >