1. routine_id evaluation
Robert,
I don't suppose you'd consider allowing routine_id to be evaluated at
run-time rather than at "compile" time?
eg.
in foo.e I have ...
sequence handles handles = {}
global function setHandle(atom handletype, sequence procname)
integer p
if handletype >1 and handletype < 10 then
p = routine_id(procname)
handles &= {handletype, procname, p}
return p
else
return -1
end if
end function
and in bar.e I have ...
include foo.e
X = setHandle(1, "routineX")
Y = setHandle(2, "routineY")
procedure routineX()
end procedure
procedure routineY()
end procedure
etc....
------
Derek Parnell
Melbourne, Australia
(Vote [1] The Cheshire Cat for Internet Mascot)
2. Re: routine_id evaluation
- Posted by Robert Craig <rds at RAPIDEUPHORIA.COM>
Dec 01, 2000
-
Last edited Dec 02, 2000
Derek Parnell writes:
> I don't suppose you'd consider allowing routine_id
> to be evaluated at run-time rather than at "compile" time?
It *is* evaluated at run-time.
However, it will only find routines that are defined
earlier than the place where you call routine_id().
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: routine_id evaluation
----- Original Message -----
From: "Robert Craig" <rds at RAPIDEUPHORIA.COM>
> Derek Parnell writes:
> > I don't suppose you'd consider allowing routine_id
> > to be evaluated at run-time rather than at "compile" time?
>
> It *is* evaluated at run-time.
> However, it will only find routines that are defined
> earlier than the place where you call routine_id().
Robert, did you get out of the wrong side of bed this morning. Please don't
play semantic games. You know that I already know how it works now, and you
know perfectly well what it is that I'm asking for!
Of course its currently done at run-time because its an interpreted
language. With an interpreted language, everything is run-time! It seems
that what you are implying is the Euphoria evaluates the parameter during
the syntax checking stage of the interpretation rather than the execution
stage of the interpretation.
If I have a procedure such as ...
procedure abc()
q = def(xyz)
end procedure
I don't expect def() to evaluate its parameter until the abc() procedure is
executing.
but it seems that Euphoria treats routine_id differently than other
functions. In this case ...
procedure abc()
q = routine_id(xyz)
end procedure
it would seem that routine_id() does evaluate its parameter even when abc()
is not being executed.
However, it seems to me that *if* Euphoria internally stores the location
and names of all its routines during the initial syntax pass, then at the
time that routine_id() actually executes, it could look up the internal
table and determine when in blazes the referenced routine (in the parameter)
is.
I'd rather that the function's parameter was evaluated at the time that the
routine_id function was executed rather than at the time that the
interpreter finds the refernce to the routine_id function in the code.
In other words, what I'd like is the following pseudo-code behaviour...
When the interpeter finds a routine_id() in the code,
if in syntax parsing state (or whatever you call it)
tokenize the function call and its parameter
elsif in executing state (or whatever you call it)
if the parameter has not been resolved yet
look up the name of the routine being referenced
add to the array of internal routine_ids
store the resolved reference if found (-1 otherwise)
else
get the location of the routine from the internal
routine_ids table
end if
attempt to call the referenced routine
end if
------
Derek Parnell
Melbourne, Australia
(Vote [1] The Cheshire Cat for Internet Mascot)
4. Re: routine_id evaluation
On 2 Dec 2000, at 16:10, Derek Parnell wrote:
> ----- Original Message -----
> From: "Robert Craig" <rds at RAPIDEUPHORIA.COM>
>
> > Derek Parnell writes:
> > > I don't suppose you'd consider allowing routine_id
> > > to be evaluated at run-time rather than at "compile" time?
> >
> > It *is* evaluated at run-time.
> > However, it will only find routines that are defined
> > earlier than the place where you call routine_id().
>
> Robert, did you get out of the wrong side of bed this morning. Please don't
> play semantic games. You know that I already know how it works now, and you
> know perfectly well what it is that I'm asking for!
>
> Of course its currently done at run-time because its an interpreted
> language. With an interpreted language, everything is run-time! It seems
> that what you are implying is the Euphoria evaluates the parameter during the
> syntax checking stage of the interpretation rather than the execution stage of
> the interpretation.
`cuse me, but if Eu is doing a pass on the script before executing, why is
there a need for routine_id() at all? Simply do not abort the pass that finds
unknown routine calls untill the end of the pass, where you can see if any
calls are still unknown. This would solve the problem Derek demonstrates,
no?
Kat
5. Re: routine_id evaluation
Derek Parnell writes:
> Robert, did you get out of the wrong side of bed this morning.
> Please don't play semantic games. You know that
> I already know how it works now, and you
> know perfectly well what it is that I'm asking for!
1. I'm not playing games.
2. Apparently you don't understand how it works.
3. I'm really not sure what you are asking for.
I was simply trying to explain how routine_id() works
as simply and clearly as I can.
> Of course its currently done at run-time
> because its an interpreted language.
> With an interpreted language, everything is run-time!
No. I really and truely mean it's evaluated at run-time,
while your program is executing statements.
Try this piece of code to convince yourself:
procedure foo1()
puts(1, "foo1 called\n")
end procedure
procedure foo2()
puts(1, "foo2 called\n")
end procedure
integer r
for i = 1 to 5 do
r = rand(2)
call_proc(routine_id(sprintf("foo%d", r)), {})
end for
> However, it seems to me that *if* Euphoria
> internally stores the location and names of all its routines
> during the initial syntax pass, then at the time that
> routine_id() actually executes, it could look up
> the internal table
That's what it does - even with the Translator where
you can actually see the table (if one is necessary) in init_.c.
But it won't search for routines that are defined after
the point of the call to routine id. This was a
deliberate, albeit somewhat strange and controversial
design decision made in the interests
of avoiding ambiguity, and promoting
the "define-it-before-you-use-it" philosophy.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
6. Re: routine_id evaluation
- Posted by David Cuny <dcuny at LANSET.COM>
Dec 01, 2000
-
Last edited Dec 02, 2000
Derek Parnell wrote:
> I'd rather that [routine_id's] parameter was
> evaluated at the time that the routine_id function
> was executed rather than at the time that the
> interpreter finds the reference to the routine_id
> function in the code.
This has been on my wish list forever.
-- David Cuny
7. Re: routine_id evaluation
- Posted by Derek Parnell <dparnell at BIGPOND.NET.AU>
Dec 02, 2000
-
Last edited Dec 03, 2000
----- Original Message -----
From: "Robert Craig" <rds at RAPIDEUPHORIA.COM>
I'm taking my end of this discussion offline. What I have to say next is not
for the list.
------
Derek
8. Re: routine_id evaluation
--
Rob:
The problem is that when you try to call foreward before a routine
has been define. The interpter evaluates the call and reports an error
that you are using a bad routine id in your call. If you waited
until run time then the id would be known and be valid so this would
allow for foreward calls. This is the purpose for prototypes in "C"
and Euphoria should allow for this same thing.
Bernie
9. Re: routine_id evaluation
People,
The controlling philosophy (for better or worse) is "define it before you
use it."
Interestingly, I used to arrange my C code in exactly the OPPOSITE order, on
the theory that placing the highest-level code (and comments) at the top of
a file, and carefully choosing meaningful names for subroutines, would give
a visiting reader the quickest and best idea of what the code was doing,
overall.
I tend to agree that it is a silly, stupid bother to have to arrange your
code in a particular order just to suit the philosophy of the language
designer, when other philosophies of arguably equal validity are extant, and
IT MAKES NO DIFFERENCE in the execution of the program!
Those who disagree strongly enough with Rob's philosophy are free to create
their own "uforia sect." (And hey, you has a choice between "uforia" as a
colloquial reference to the language, or the consistently misspelled
"Euhporia." I'd rather be colloquial with ease of typing than to make it
look like I'm trying to type the name correctly and failing. Sort of like,
I'd rather be called "geo" than "Goerge," on a regular basis. You may call
me "geo" if you finds "George" a difficult type. But I digress.) Uforia
sectarians can cobble up their own translators with whatever variant
behaviors they please.
geo
_____________________________________________________________________________________
Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com
10. Re: routine_id evaluation
Suppose you manufacture hammers, and your hammers are quite good, with many
innovative features that hammer users find appealing and useful.
You are devoted to the idea, for whatever reason, that hammer heads should
be square. Studies comparing your line of hammers to the competitions' show
that a hammer's having a square head has minimal, in any, effect on the
quantity or quality of nail hits; however, it substantially increases the
incidence of users hammering their thumbs. Then, will you remain devoted to
square heads as a matter of principle, or bow to the will of the users
(their philosophy that smacking their thumbs more than absolutely necessary
causes discomfort) and start making your hammer heads round, like normal?
Analogy by George, a free service.
_____________________________________________________________________________________
Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com
11. Re: routine_id evaluation
--
It is evident from your comments that you have not written any
complex or large programs in Euphoria.
It is not easy without a complete rewrite or removing of code methods
to over come a simple foreward reference.
12. Re: routine_id evaluation
On 2 Dec 2000, at 14:28, Bernie wrote:
> --
> It is evident from your comments that you have not written any
> complex or large programs in Euphoria.
> It is not easy without a complete rewrite or removing of code methods
> to over come a simple foreward reference.
>
Who are you addressing?
Kat
13. Re: routine_id evaluation
On Sat, 2 Dec 2000 14:06:17 -0600, Kat <gertie at PELL.NET> wrote:
>On 2 Dec 2000, at 14:28, Bernie wrote:
>
>Who are you addressing?
Mr Henry
14. Re: routine_id evaluation
--- Derek Parnell <dparnell at BIGPOND.NET.AU> wrote:
> Robert,
> I don't suppose you'd consider allowing routine_id to be evaluated at
> run-time rather than at "compile" time?
(I know you took this off list, but...)
I guess I finally understand what you're talking about: forward referencing
(although that's not how you're phrasing it). As with most stumpers like this
IMHO, you should be able to get around it with a little bit of indirection:
-- begin code
sequence handles
handles = { {}, {} } -- you could also use Jiri's associative lists :)
procedure do_proc( sequence name )
call_proc( find(name, handles[1]), {})
end procedure
procedure main()
do_proc( "foo1")
end procedure
procedure foo1()
-- stuff
end procedure
handles[1] &= { "foo1" }
procedure foo2()
-- more stuff
end procedure
handles[1] &= {"foo2"}
for i = 1 to length(handles[1]) do
handles[2] &= routine_id(handles[1][i])
end for
-- end code
Of course, you couldn't do exactly what you were asking, but with some slight
modifications, it should work.
=====
Matt Lewis
http://www.realftp.com/matthewlewis
__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/
15. Re: routine_id evaluation
Matt Lewis wrote:
> I guess I finally understand what
> you're talking about: forward referencing
> (although that's not how you're phrasing it).
Consider the following examples:
-- example 1: fails
function get_id( sequence s )
? routine_id(s)
end function
procedure bar()
end procedure
if get_id("bar") != routine_id("bar") then
puts( 1, "failed" )
end if
-- example 2: doesn't fail
procedure bar()
end procedure
function get_id( sequence s )
? routine_id(s)
end function
if get_id("bar") != routine_id("bar") then
puts( 1, "failed" )
end if
I respectfully submit that to claim that get_id is performing a "forward
reference" here while routine_id is not is simply absurd. And Robert doesn't
even make that claim. He's explained that the only reason it behaves this
was to is to make it inconvenient for people to use that feature.
-- David Cuny
16. Re: routine_id evaluation
> -----Original Message-----
> From: David Cuny
> Matt Lewis wrote:
>
> > I guess I finally understand what
> > you're talking about: forward referencing
> > (although that's not how you're phrasing it).
> -- example 2: doesn't fail
>
> procedure bar()
> end procedure
>
> function get_id( sequence s )
> ? routine_id(s)
> end function
>
> if get_id("bar") != routine_id("bar") then
> puts( 1, "failed" )
> end if
>
> I respectfully submit that to claim that get_id is performing
> a "forward
> reference" here while routine_id is not is simply absurd. And
> Robert doesn't
> even make that claim. He's explained that the only reason it
> behaves this
> was to is to make it inconvenient for people to use that feature.
Well, since you mention it, I'd say that routine_id() was *not* using a
forward reference. Only call_proc()/call_func() actually do that. :P
Sorry.
Although I didn't [want to] go into it, I agree that it might be nice to
have the 2 pass interpreter that's been talked about in the past (which
should do what Derek wants), but, as with many things on various wish lists
floating around, I wouldn't count on this being implemented. In the
meantime, a scheme like what I proposed can be a work around.
I probably wouldn't use routine_id() much less than now if we did have a two
pass interpreter. Although I encounter a few times where I need a simple
forward referenced function call, I typically use routine_id() for dynamic
function calling (ie, no way to know which routine needs to be called next),
as I did in matheval.
Matt Lewis
17. Re: routine_id evaluation
On 4 Dec 2000, at 8:55, Matthew Lewis wrote:
>
> Well, since you mention it, I'd say that routine_id() was *not* using a
> forward reference. Only call_proc()/call_func() actually do that. :P
> Sorry.
>
> Although I didn't [want to] go into it, I agree that it might be nice to
> have the 2 pass interpreter that's been talked about in the past (which
> should do what Derek wants), but, as with many things on various wish lists
> floating around, I wouldn't count on this being implemented. In the meantime,
> a scheme like what I proposed can be a work around.
>
> I probably wouldn't use routine_id() much less than now if we did have a two
> pass interpreter. Although I encounter a few times where I need a simple
> forward referenced function call, I typically use routine_id() for dynamic
> function calling (ie, no way to know which routine needs to be called next),
> as I did in matheval.
Ok, what about a bat file that calls a preprocessor before the interpreter
file, and it adds a "_" to proc/func names, and at the top of the program, it
adds a routine_id() by the original name for *every* func/proc? Then you
can call any function or procedure willy-nilly, no need to keep track of what
is declared first in the program. Will that solve it?
Kat
