1. procedures calling procedure calling procedure...
- Posted by rubis at fem.unicamp.br Oct 14, 2002
- 402 views
Hi people ! How do I call a procedure that is after the call ? for example: --begin procedure a() ?1 end procedure procedure b() a() c() end procedure procedure c() ?3 end procedure --end I'm doing this using call_proc(c(), {}), but something tells me that there is a more easy or intellignet way to do this... thanks Rubens
2. Re: procedures calling procedure calling procedure...
- Posted by Derek Parnell <ddparnell at bigpond.com> Oct 14, 2002
- 378 views
Sorry but there isn't. RDS believes this is the best way to do it. I strongly disagree with RDS on that issue. The RDS philosophy seems to be that good programming practice is to only refer to things that have already been "seen" by the one-pass interpreter. Thus you cannot refer to any identifier that is defined lower down in the file. So yes, the physical layout of indentifier definitions in a source code file has been deemed to be vitally significant by RDS. This means that you as a programmer have to invent cunning ways to get around this limitation in the language (as implemented by RDS). Of course, RDS has also recognised that there are legitimate reasons for coders to do this, so Euphoria has been provided with routine_id(), call_proc/func() routines. My suspicions are that it is now too hard for RDS to change the way the interpreter works to allow for forward referencing, so we are stuck with this limitation for now. Whenever I get a spare 12-months, I'll write a new implementation of the interpreter ------------- Derek. 15/10/2002 7:21:59 AM, rubis at fem.unicamp.br wrote: > >Hi people ! > >How do I call a procedure that is after the call ? > >for example: > >--begin >procedure a() >?1 >end procedure > >procedure b() >a() >c() >end procedure > >procedure c() >?3 >end procedure > >--end > >I'm doing this using call_proc(c(), {}), but something tells me that there >is a more easy or intellignet way to do this... > >thanks >Rubens > > > > --------- Cheers, Derek Parnell ICQ# 7647806
3. Re: procedures calling procedure calling procedure...
- Posted by francis at gmx.co.uk Oct 14, 2002
- 370 views
Cunning? Well, you can define routine ID constants/variables at the top of the file, reference them in the middle and set them at the end. Even in C, it is ordinary programming practice to "#define function(parameters);" if it is called before it is instantiated. It would be slightly more convenient to be able to call *before* it is defined, ut we are talking about an interpreted language! In terms of coding, I think is is not too much work around at all. >Sorry but there isn't. RDS believes this is the best way to do it. I strongly disagree with RDS on >that issue. > >The RDS philosophy seems to be that good programming practice is to only refer to things that have >already been "seen" by the one-pass interpreter. Thus you cannot refer to any identifier that is >defined lower down in the file. So yes, the physical layout of indentifier definitions in a source >code file has been deemed to be vitally significant by RDS. > >This means that you as a programmer have to invent cunning ways to get around this limitation in the >language (as implemented by RDS). Of course, RDS has also recognised that there > are legitimate >reasons for coders to do this, so Euphoria has been provided with routine_id(), > call_proc/func() >routines. > >My suspicions are that it is now too hard for RDS to change the way the interpreter works to allow >for forward referencing, so we are stuck with this limitation for now. > >Whenever I get a spare 12-months, I'll write a new implementation of the interpreter > >------------- >Derek. > >15/10/2002 7:21:59 AM, rubis at fem.unicamp.br wrote: > >> >>Hi people ! >> >>How do I call a procedure that is after the call ? >> >>for example: >> >>--begin >>procedure a() >>?1 >>end procedure >> >>procedure b() >>a() >>c() >>end procedure >> >>procedure c() >>?3 >>end procedure >> >>--end >> >>I'm doing this using call_proc(c(), {}), but something tells me that there >>is a more easy or intellignet way to do this... >> >>thanks >>Rubens >> >> >--------- >Cheers, >Derek Parnell >ICQ# 7647806 > > > >
4. Re: procedures calling procedure calling procedure...
- Posted by jbrown105 at speedymail.org Oct 14, 2002
- 369 views
I agree. It'd be nice if routine_id() wasn't scoped, but that probably can't be helped for the same reasons RDS can't add forward referencing directly. (I wrote a program which would allow you to access any function before it was declared via the name in a string, but this used routine_id() as the underlying system.) jbrown On 0, francis at gmx.co.uk wrote: > > Cunning? Well, you can define routine ID constants/variables at the top of the > > file, reference them in the middle and set them at the end. Even in C, it is > ordinary programming practice to "#define function(parameters);" if it is > called > before it is instantiated. It would be slightly more convenient to be able to > call *before* it is defined, ut we are talking about an interpreted language! > In > terms of coding, I think is is not too much work around at all. > > >Sorry but there isn't. RDS believes this is the best way to do it. I strongly > > > disagree with RDS on > >that issue. > > > >The RDS philosophy seems to be that good programming practice is to only > >refer > to things that have > >already been "seen" by the one-pass interpreter. Thus you cannot refer to any > > > identifier that is > >defined lower down in the file. So yes, the physical layout of indentifier > definitions in a source > >code file has been deemed to be vitally significant by RDS. > > > >This means that you as a programmer have to invent cunning ways to get around > > > this limitation in the > >language (as implemented by RDS). Of course, RDS has also recognised that > >there > are legitimate > >reasons for coders to do this, so Euphoria has been provided with > >routine_id(), > call_proc/func() > >routines. > > > >My suspicions are that it is now too hard for RDS to change the way the > interpreter works to allow > >for forward referencing, so we are stuck with this limitation for now. > > > >Whenever I get a spare 12-months, I'll write a new implementation of the > interpreter > > > >------------- > >Derek. > > > >15/10/2002 7:21:59 AM, rubis at fem.unicamp.br wrote: > > > >> > >>Hi people ! > >> > >>How do I call a procedure that is after the call ? > >> > >>for example: > >> > >>--begin > >>procedure a() > >>?1 > >>end procedure > >> > >>procedure b() > >>a() > >>c() > >>end procedure > >> > >>procedure c() > >>?3 > >>end procedure > >> > >>--end > >> > >>I'm doing this using call_proc(c(), {}), but something tells me that there > >>is a more easy or intellignet way to do this... > >> > >>thanks > >>Rubens > >> > >> > >--------- > >Cheers, > >Derek Parnell > >ICQ# 7647806 > > > >
5. Re: procedures calling procedure calling procedure...
- Posted by "Carl W." <euphoria at cyreksoft.yorks.com> Oct 15, 2002
- 372 views
<rubis at fem.unicamp.br> wrote: > How do I call a procedure that is after the call ? > > for example: > > --begin > procedure a() > ?1 > end procedure > > procedure b() > a() > c() > end procedure > > procedure c() > ?3 > end procedure > > --end > > I'm doing this using call_proc(c(), {}), but something tells me that there > is a more easy or intellignet way to do this... Hi. Like others have said, there's no predeclaration syntax in Euphoria, so you're stuck with using call_proc(), call_func(), and routine_id(). This doesn;t mean you can't make your code look tidy though: procedure a() puts(1,"a()\n") end procedure integer c_id -- predeclare c() procedure b() a() call_proc(c_id,{}) end procedure procedure c() puts(1,"c()\n") end procedure c_id = routine_id("c") -- assign something to the predeclaration var You can even have consitent style if you don't mind being a bit more verbose: type predeclare(object sub) -- Using a verb as a type name :) if integer(sub) and sub >= 0 then return 1 end if return 0 end type predeclare a_ -- Using underscores to distinguish the routine_id from predeclare c_ -- the actual routine name. Eu will complain otherwise. procedure a() puts(1,"a()\n") end procedure a_ = routine_id("a") procedure b() call_proc(a_,{}) -- Consistent syntax in b() call_proc(c_,{}) end procedure procedure c() puts(1,"c()\n") end procedure c_ = routine_id("c") HTH, Carl
6. Re: procedures calling procedure calling procedure...
- Posted by Derek Parnell <ddparnell at bigpond.com> Oct 15, 2002
- 380 views
----- Original Message ----- From: <francis at gmx.co.uk> To: "EUforum" <EUforum at topica.com> Subject: Re: procedures calling procedure calling procedure... > > Cunning? Well, you can define routine ID constants/variables at the top of the > file, reference them in the middle and set them at the end. I guess my main issue is that it is not so much that "you can define..." but that you *must* do that. We don't have freedom of choice on this issue. The current design of Euphoria forces us to do that that way. In this sense, Euphoria (like many others) is not a general programming language. It is an expression of a programming philosophy. I just wish Euphoria was not quite so doctrinal because it is such a great language. I'm probably in the camp of users that also believe that it can be even greater yet. For example, even though I actively campaign against the use of GOTO, I would allow it in a language so that people could choose NOT to use it. Of course many would use it, but that is a problem of their own making. Personal Responsibility. > Even in C, it is ordinary programming practice to > "#define function(parameters);" if it is called > before it is instantiated. But it is not mandatory. Its main purpose in C/C++ is to allow the compiler to perform some validation, at compile time, of the usage of routines and to allow it to generate the correct code for return values (without having to do an extra pass). >It would be slightly more convenient to be able to > call *before* it is defined, but we are talking about an interpreted language! In > terms of coding, I think is is not too much work around at all. There are other interpreted languages that all forward referencing. The reason for Euphoria's inability to do this is not because it is an interpreted language, but because either RDS thinks that it is good for us, or that it was easier not put it in. Of course this is speculation and may very well be wrong. Robert, why is forward referencing not included in Euphoria? ---------------- cheers, Derek Parnell
7. Re: procedures calling procedure calling procedure...
- Posted by petelomax at blueyonder.co.uk Oct 15, 2002
- 375 views
{{{ On Wed, 16 Oct 2002 07:28:55 +1000, Derek Parnell <ddparnell at bigpond.com> wrote:
that you *must* do that. We don't have freedom of choice on this issue. <snip>
I just wish Euphoria was not quite
so doctrinal because it is such a great language. I'm probably in the camp
of users that also believe that it can be even greater yet.
I've bit my tongue on this, apparently too long.
Just what, exactly, is *SO* hard about
global integer closeCompareRID ... call_proc(closeCompareRID, {) ... procedure closeCOMPARE() closeCompareRID routine_id("closeCOMPARE")
over & above:
closeCOMPARE() ... procedure closeCOMPARE()
????? Yeah, two extra lines and some syntax, SO? Just how often do you actually use forward references anyway?
I, for one, possibly lone voice, appreciate that the former clearly signals to me, the human reader, that closeCOMPARE() has not yet been defined; I haven't missed it; it may not even be in this source. (which is true anyway for global routines of include files)
Derek, I am frankly amazed that you bear such a grudge on this issue as surely if this had been in the language from the get-go then routine_id() would not exist and your work on win32lib would basically be nigh impossible?!
Pete
PS Rob, routine_id("rubbish") currently returns -1 (assuming of course that no procedure or function rubbish has been defined).
What chances of an error/warning message instead?
I feel a minor spelling mistake can cause major headaches in this case.
8. Re: procedures calling procedure calling procedure...
- Posted by Derek Parnell <ddparnell at bigpond.com> Oct 15, 2002
- 385 views
16/10/2002 9:34:51 AM, petelomax at blueyonder.co.uk wrote: >I've bit my tongue on this, apparently too long. >Just what, exactly, is *SO* hard about > >global integer closeCompareRID >... > call_proc(closeCompareRID, {}) >... >procedure closeCOMPARE() >closeCompareRID = routine_id("closeCOMPARE") > > >over & above: > > closeCOMPARE() >... >procedure closeCOMPARE() > >????? >Yeah, two extra lines and some syntax, SO? Just how often do you >actually use forward references anyway? Hi Pete, there is nothing hard about using routine_id. My issue is not that routine_id is hard to use or even is a poor work-around. In fact, routine_id is an excellent addition to the language and I would be very sad if it ever went away. It is also an excellent work around for the lack of forward referencing. It adheres to the feel of Euphoria well (except that it uses zero-based indexing whereas Euphoria generally uses one-based indexing). My problem is that the physical location of the routines in a source file has no relation to their functional grouping, thus I should be able to physically group together routines that are logically related. However, this is not always possible with Euphoria. Euphoria can force logically related routines to be physically seperated due to the need of the interpreter to parse a routine's source code before that routine can be referenced. In small programs this is not a big deal. But when dealing with large source files, I am often having to rearrange the location of routines when adding new calls. Well I used to. I've given up doing this now and resorting to routine_id() calls instead, thus increasing the calling overhead of the routine. I'm not arguing that it is difficult to use routine_id. I'm arguing against the need to rearrange existing source code just because I've added a new call reference. >I, for one, possibly lone voice, appreciate that the former clearly >signals to me, the human reader, that closeCOMPARE() has not yet been >defined; I haven't missed it; it may not even be in this source. >(which is true anyway for global routines of include files) I can appreciate this point of view, Pete. With the current Euphoria, you always know that a routine being referred to is somewhere earlier in the source file. It doesn't mean that it actually exists! But if it does, it's line number is less than the current line. However, just because you might see "call_proc(closeCompareRID, {})", does not mean that closeCompare is definitely not yet defined, nor does it mean that closeCompareRID is initialized, nor does it mean that closeCompareRID has been initialized with routine_id of "closeCompare". >Derek, I am frankly amazed that you bear such a grudge on this issue Frankly Pete, so am I! I'm not normally given over to passionate opinionating. And I'm very sorry if this is a waste of bandwidth. However, I refuse to believe that Euphoria is as good as it can be. It is only with public debate that this community can weigh the merits (or lack thereof) of individual's opinions. >as surely if this had been in the language from the get-go then >routine_id() would not exist and your work on win32lib would basically >be nigh impossible?! Again, I'm not complaining about routine_id. I truely believe that routine_id() is one of Euphoria's great strengths. Not only does win32lib depend on this functionality, but many, many Euphoria programs do. I just wish I could freely add new calls to Win32lib without having to worry about rearranging the code to stop Euphoria complaining. It really wouldn't take much more smarts in the interpreter to automatically insert call_proc/func() in cases where the called routine exists and it is defined starting on a line number greater than the "call" line. >Pete >PS Rob, routine_id("rubbish") currently returns -1 (assuming of course >that no procedure or function rubbish has been defined). > >What chances of an error/warning message instead? > >I feel a minor spelling mistake can cause major headaches in this >case. Not a bad idea, so long as this can be turned on and off using a "with" directive. Win32lib and some O-O schemes rely on a -1 being returned sometimes. --------- Cheers, Derek Parnell
9. Re: procedures calling procedure calling procedure...
- Posted by Robert Craig <rds at RapidEuphoria.com> Oct 15, 2002
- 373 views
Derek Parnell writes: > For example, even though I actively campaign > against the use of GOTO, I would allow it in a language > so that people could choose NOT to use it. Of > course many would use it, but that is a problem of their own making. I'd rather live in a world in which cigarettes don't exist, than a world where they are introduced and then actively campaigned against. With GOTO's in the language, you'd have to be more careful when reading someone else's code. An apparently familiar control-flow structure, could in fact be something hideous. To be sure, you'd have to scan every line of code looking for GOTO's. > Robert, why is forward referencing not included in Euphoria? Define-it-before-you-use-it is slightly easier to implement. Otherwise, you might have to fill in dummy information and "back patch" it when you find the real information. But this is a relatively minor issue. At first (many years ago, pre-1.0) I was prepared to allow define-it-anywhere, and I had a workable design for it, but then I started to think about a couple of languages I had used previously that imposed define-it-before-you-use-it, and I remembered that after a bit of initial frustration, I grew to like the imposed, machine-checked discipline. I'm happy the way Euphoria is, in this regard. I like the fact that when I'm scrolling around in an editor, I know which direction to move in to find the definition of a routine. I like the fact that I can pick up anyone's program, and see the structure, at least in terms of the ordering of high-level versus low-level routines. I can also be assured that the routines in a file included at the top of the main file, are used by the main file, but cannot call routines in the main file. (except via obvious uses of call_func/call_proc, and only by permission of the author of the main file who has to pass in a routine_id) This gives me some confidence in understanding the overall structure of the program. If people could lay out their routines in random order you'd lose all this. Of course people would arrange their routines in some way that means something to them, but probably not to anyone else, and their arrangement would not be machine verified, so it would not be trustworthy. Also, over the years I've added code that assumes define-it-before-you-use-it. I can think of various optimizations in the interpreter and the translator. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
10. Re: procedures calling procedure calling procedure...
- Posted by Robert Craig <rds at RapidEuphoria.com> Oct 15, 2002
- 403 views
Pete Lomax writes: > PS Rob, routine_id("rubbish") currently returns -1 > (assuming of course that no procedure or function > rubbish has been defined). > > What chances of an error/warning message instead? > > I feel a minor spelling mistake can cause major headaches in this > case. By returning -1, I give you the chance to test for the existence of a routine, and take some action if it doesn't exist. You can at least issue your own error message and shut down gracefully. Maybe most people would prefer to just fail on the spot. In any case, if you continue, and use the -1 in a call_proc or call_func, you'll get an error message. I think it's too late to change this now, and I don't think there are really "major headaches" in most cases. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
11. Re: procedures calling procedure calling procedure...
- Posted by Derek Parnell <ddparnell at bigpond.com> Oct 15, 2002
- 378 views
Thanks Robert. >> Robert, why is forward referencing not included in Euphoria? > >Define-it-before-you-use-it is ...[BIG SNIP] --------- Cheers, Derek Parnell
12. Re: procedures calling procedure calling procedure...
- Posted by rubis at fem.unicamp.br Oct 16, 2002
- 412 views
Thanks all for the answers and discussion about calling procedures. One interesting thing about euphoria is the possibility of making= =20 clear and structured codes, very diferent from BASIC, for example, where I= =20 started learning programming 20 years ago... I think it would be nice if euphoria had the option of calling a=20 procedure independently of its position in the program. Actually I was=20 expecting this feature to be "natural" in euphoria due to the=20 caracteristics of the language, so this is the reason why I asked about=20 other options to do this without using call_proc( ) and started this thread. Calling a procedure that is not before the call wouldn't turn the= =20 code into "basic with gosubs/gotos" because it is very easy to find the=20 procedures anywhere and the position of the procedure wouldn't change=20 anything in the code, except that you have to use call_proc( ). This is just the opinion of an Euphoria beginner, and perhaps it=20 would be good only for small codes( the codes I write :>) ), and not so=20 good for big codes. Abra=E7os, Rubens At 00:07 16/10/2002, you wrote: > >Thanks Robert. > > >> Robert, why is forward referencing not included in Euphoria? > > > >Define-it-before-you-use-it is ...[BIG SNIP] >--------- >Cheers, >Derek Parnell > > >