1. procedures calling procedure calling procedure...

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

new topic     » topic index » view message » categorize

2. Re: procedures calling procedure calling procedure...

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 blink

-------------
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

new topic     » goto parent     » topic index » view message » categorize

3. 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. 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 blink
>
>-------------
>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
>
>
>
>

new topic     » goto parent     » topic index » view message » categorize

4. Re: procedures calling procedure calling procedure...

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 blink
> >
> >-------------
> >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
> >
> >

new topic     » goto parent     » topic index » view message » categorize

5. Re: procedures calling procedure calling procedure...

<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

new topic     » goto parent     » topic index » view message » categorize

6. Re: procedures calling procedure calling procedure...

----- 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

new topic     » goto parent     » topic index » view message » categorize

7. Re: procedures calling procedure calling procedure...

{{{ On Wed, 16 Oct 2002 07:28:55 +1000, Derek Parnell <ddparnell at bigpond.com> wrote:

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. <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.

new topic     » goto parent     » topic index » view message » categorize

8. Re: procedures calling procedure calling procedure...

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

new topic     » goto parent     » topic index » view message » categorize

9. Re: procedures calling procedure calling procedure...

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

new topic     » goto parent     » topic index » view message » categorize

10. Re: procedures calling procedure calling procedure...

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

new topic     » goto parent     » topic index » view message » categorize

11. Re: procedures calling procedure calling procedure...

Thanks Robert.

>> Robert, why is forward referencing not included in Euphoria?
>
>Define-it-before-you-use-it is ...[BIG SNIP]
---------
Cheers,
Derek Parnell

new topic     » goto parent     » topic index » view message » categorize

12. Re: procedures calling procedure calling procedure...

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
>
>
>

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu