1. routine_id()
Hi all!
i'm now in vague on what the use of "routine_id()" is. i came to know
that it may be used to call the suroutines declared *after* the current call.
however, in this case, the global variables must be declared and are to be
set using "routine_id()" by the user, manually...
i guess there is some good reasons in why Rob made it as it is... since if the
main use of routine_id() is only for calling coming-later subs, Rob would
make ex.exe internally declare and set those variables.
Bye -- from Lee, woo seob...
2. Re: routine_id()
- Posted by Robert Craig <rds at EMAIL.MSN.COM>
Nov 12, 1997
-
Last edited Nov 13, 1997
Lee woo seob writes:
> i'm now in vague on what the use of "routine_id()" is. i came to know
> that it may be used to call the suroutines declared *after* the current
> call.
> however, in this case, the global variables must be declared and are > to
be
> set using "routine_id()" by the user, manually...
> i guess there is some good reasons in why Rob made it as it is...
> since if the
> main use of routine_id() is only for calling coming-later subs, Rob
> would
> make ex.exe internally declare and set those variables.
I expect that fewer than 10% of Euphoria programs will use
routine_id(). But it does have some interesting uses:
1. It lets you call routines that come later in the program.
This solves the "mutual recursion" recursion problem,
and allows you to write a recursive-descent parser.
2. You can create a sequence of routine ids and index into
it, rather than having a long chain of elsif's. Indexing will
be much faster than having a long chain. This is useful
in the inner loop of an interpreter. David Cuny has used
this technique already to speed up an interpreter he is
writing.
3. You can pass the routine id of a compare function to a general
sorting routine (see csort.ex demo), or
maybe a routine that "walks" through a data structure
applying a function to each node.
4. An object-oriented "object" is supposed to consist of data
plus the code needed to manipulate that data. Suppose you
stored the routine id of a routine that will manipulate the data
along with the data itself, in a sequence. You could set up
a very object-oriented system.
Version 2.0 alpha introduces the concept of a routine id
anyway as part of linking to WIN32 C routines, so it seemed
like a good time to add it for Euphoria routines.
Why does routine id("xxx") only search *earlier* in the program
for xxx? This was done to eliminate possible ambiguity and confusion.
It does not restrict you, since you can compute the routine id later
in your program, and assign it to a global variable that is declared at the
very beginning of your program.
Imagine if you write a .e file that wants to
use the routine id of your (non-global) function foo().
Suppose the user of your
.e file also has a routine named foo. If routine_id() were defined
to pick up the currently-defined routine foo, you might accidentally
pick up the routine id of *his* foo. After 3 days of debugging
he might figure out that you are sometimes calling *his* foo.
As routine_id is actually defined, if you really want to call his foo you
can do it, but he must explicitly call routine_id("foo") and pass you
the routine id himself. He will never fear that you are calling his
routines without his permission.
Regards,
Rob Craig
Rapid Deployment Software
3. Re: routine_id()
Lee woo seob wrote:
> i'm now in vague on what the use of "routine_id()" is. i came to know
> that it may be used to call the suroutines declared *after* the
> current call.
> however, in this case, the global variables must be declared and are
> to be
> set using "routine_id()" by the user, manually...
> i guess there is some good reasons in why Rob made it as it is...
> since if the
> main use of routine_id() is only for calling coming-later subs, Rob
> would
> make ex.exe internally declare and set those variables.
No, no, no..
The cool part now, is the new flexibility.
The type of mechanism that can be set up by this weren't possible
yet...
They were in for example C++
You can now have an euphoria object and save which routine you want
that object to handle, example:
------ AN example with two different custom compare routines...
function my_compare_1 (sequence s1, sequence s2)
return length(s1) > length(s2)
end function
function my_compare_2 (sequence s1, sequence s2)
s1 = s1 + s2
return find(0, s1)
end function
integer my_compare_id
procedure do_something (sequence s)
--- a lot of happy code
print (1, call_func( my_compare_id, {s,s-4} ))
--- more happy code
end procedure
my_compare_id = routine_id ("my_compare_1")
do_something ("Euphoria Rulezz")
my_compare_id = routine_id ("my_compare_2")
do_something ("Don't you know ??")
----------- end of example
What's the beauty ??
We can now assign any routine to do the comparisation, even ones
declared later on in the program.
But the best part is: We can save which routine should handle a
piece of data in the data itself.
Example: {routine_id_to_be_called, normal_data}
The one thing that made OOP more powerfull than Euphoria now and
then.
Althrough I still want that global routines can only be called
by other files, that have included it directly and not indirectly. I
really am in favour of this!!
Ralf N
nieuwen at xs4all.nl
4. Re: routine_id()
Robert Craig wrote:
> As routine_id is actually defined, if you really want to call his foo
> you
> can do it, but he must explicitly call routine_id("foo") and pass you
> the routine id himself. He will never fear that you are calling his
> routines without his permission.
So this means it contains the same rules as normal function calling
& definition ??
(private & global routines i mean)
And please, please, at least consider to make calling a routine
indirect illigal (each file must include the other file itself).
Simply add a new keyword for routine declaration: child
Example:
--
child function this_func ()
-- some happy code
end function
--
Routines defined with child in front of it, can only be called when
that file is directly included.
Same should apply to declaration of data objects:
child sequence my_sequence
child constant my_text = "Euphoria Rulez!"
I hope you finally consider this, Robert, i've asked you several
times, but never got a respons, and i know you have a lot to do and i
don't want to waste your time, but for me its clear that this will be a
very good thing for Euphoria and will increase Euphoria purity. I am
sometimes trying to do develop complex mechanisms, that certainly don't
make Euphoria look good. I can give you an example, but it will be a
very complex.
Ralf N
nieuwen at xs4all.nl
5. Re: routine_id()
>Imagine if you write a .e file that wants to
>use the routine id of your (non-global) function foo().
Sounds pretty useful. Will this feature also work in the new dos
version?? Thanks Art
Arthur P. Adamson, The Cincinnati Engine Man, euclid at isoc.net
6. Re: routine_id()
- Posted by Robert Craig <rds at EMAIL.MSN.COM>
Nov 13, 1997
-
Last edited Nov 14, 1997
Ralf writes:
> So this means it contains the same rules as normal function calling
> & definition ??
> (private & global routines i mean)
Consider:
x = routine_id("foo")
y = foo(999)
These both refer to the same foo().
routine_id() obeys the usual scope rules in
looking up "foo". The "foo" that it locates is the same one
that you would get if you tried to call foo *at this place* in the
source code. foo must occur earlier in the source, either in the
same file, or it must be global in some file that you have included.
non-global foo's in other source files are not visible.
> Routines defined with child in front of it, can only be called when
> that file is directly included.
> Same should apply to declaration of data objects:
I'm sorry, but I just don't see any compelling reason to
add this extra complexity to the language.
Regards,
Rob Craig
Rapid Deployment Software
7. routine_id()
A couple of trivial illustrations:
-- example 1:
function get_id(sequence routine_name)
return routine_id(routine_name)
end function
procedure hello()
puts(1, "hello, world!\n")
end procedure
? get_id("hello") -- prints -1 : named routine can't be found
-- example 2:
procedure hello()
puts(1, "hello, world!\n")
end procedure
function get_id(sequence routine_name)
return routine_id(routine_name)
end function
? get_id("hello") -- prints 0 : ok, routine found
I have been caught by this one so many times it's not funny! The book
says, roughly:
"... The named routine by must be visible, i.e. callable, at the
place where routine_id() is used to get the id number ..."
To restrict the search for the routine's name to the point where the
routine_id() is _located_ in the source code and not where it is
actually _invoked_ is probably very convenient for the interpreter,
but a bloody nuisance as far as I am concerned ;). Can anything be
done about it, Robert? You would not need two passes for that, would
you?
jiri
8. Re: routine_id()
- Posted by Robert Craig <rds at ATTCANADA.NET>
Jul 04, 2000
-
Last edited Jul 05, 2000
Jiri Babor writes:
> To restrict the search for the routine's name to the point where the
> routine_id() is _located_ in the source code and not where it is
> actually _invoked_ is probably very convenient for the interpreter,
> but a bloody nuisance as far as I am concerned ;). Can anything be
> done about it, Robert? You would not need two passes for that,
> would you?
David Cuny has requested the same thing on several
occasions. I may reconsider it at some point, but I still tend
to believe what I said in a posting in March 1998:
------------------
... I could have defined routine_id() so it would search
forwards and backwards to find routines *anywhere*
in the program (assuming they have been defined at
the time routine_id is called.)
I chose the current behavior for routine_id for the following
reasons:
* It matches the way routines are looked-up in the
symbol table when a normal call is performed. This
makes the language definition simpler.
* I could imagine a lot of very weird bugs happening
if a library .e file used routine_id *internally* and you
included this .e file in your program, and you accidentally
had a routine with the same name as routine_id() in the
.e file was looking for. You might have no idea why
your routine was getting called since you wouldn't
necessarily understand the workings of the .e file. I felt it
would be safer if it was your job to get the routine id of
your own routine and pass it to any library that
wants to call your routine. There would be no surprises.
* I am still clinging to the somewhat controversial belief,
that there is maintenance and readability value in having
the language force everyone to order variables
and routines such that they are defined before they are
used. (It also opens some possibilities for optimization
that I have already taken advantage of.)
routine_id gives you a mechanism for breaking that
order, but it's much less convenient than a normal call
(especially to call a "later" routine), and the reader of
your code can plainly see that you are doing something
unusual when he sees the routine_id() calls and the
explicit call_proc() and call_func() calls.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
9. Re: routine_id()
- Posted by David Cuny <dcuny at LANSET.COM>
Jul 04, 2000
-
Last edited Jul 05, 2000
Robert Craig wrote:
> I may reconsider it at some point, but I still tend
> to believe what I said in a posting in March 1998...
Amazing - something that Jiri and I actually agree on, and yet you remain
unconvinced. What will it take to turn your heart of stone? 
-- David Cuny
10. Re: routine_id()
- Posted by Hawke' <mikedeland at NETZERO.NET>
Jul 04, 2000
-
Last edited Jul 05, 2000
From: David Cuny <dcuny at LANSET.COM>
> Amazing - something that Jiri and I actually agree on, and yet you remain
> unconvinced. What will it take to turn your heart of stone?
heh, hopefully i dont sound like a brown nosing suckup to rob here ;)
but i gotta go with rob on this one...biggest reason is:
{rob}
* I am still clinging to the somewhat controversial belief,
that there is maintenance and readability value in having
the language force everyone to order variables and
routines such that they are defined before they are used.
and lest we forget function overloading? without a defined
ordering of function declarations, function overloading would
be an infinite mutual recursion nightmare as each function
vies for the title of:
"oh no, im the main function, you are overloading ME"
sure there are ways around that...if defined and all that...
at some point, readability would be thrown out the window tho...
and before u throw the arguement out, "well i dont like being dictated
as to how i order my programs and code my code", well...
neither do I...but i have been -thankfull- that rules are imposed
upon me more then once in my life, and that goes double
for coding...
i've been rereading a lot of coding i did a while
back for euphoria, to get back in the game here, and if it was
not for the small amounts of structuring euphoria imposes upon
us, i dunno that i could have re-read my old code and relate to
it like it was an old friend come to visit.
just my opines, YMMV --Hawke'
_______________________________________________
Why pay for something you could get for free?
NetZero provides FREE Internet Access and Email
http://www.netzero.net/download/index.html
11. Re: routine_id()
if you want readability of code then you need good editor, which lists
routines, and then you know for all where they are
