1. RE: Declaring a Function Before it is used
David Cuny wrote:
>
>
> Phil Russel wrote:
>
> > I don't understand why Rob insists on something so clunky when
> > there is no real need for it.
>
<snip>
> With routine_id, you could create a lookup table of event handlers.
<snip>
> So while it turns out to be an inelegant solution for forward
> references, it's a very flexible solution for callbacks.
And also for modular code. I've made a lot of use in, eg., matheval and
eusql for handling lots of different things using routine_id, where I
have a main loop, and then the actual code for each case is contained in
its own routine. To add new cases, I just add a new routine and add its
id and condition to a couple of sequences that are referenced in the
main loop.
Matt Lewis
2. RE: Declaring a Function Before it is used
> Can anyone tell me if there is a way to declare a function before it
> is used.
>
> If not, how do you handle things like:
> Run Function A, which calls Function B
> Function B calls Function C
> If statement then
> Function C calls Function D
> else
> Function C calls Function A
> end if
>
> This seems impossible to handle if you can't declare Function A ahead of
> time, because you can't move it ahead of Function C to solve the
> problem,
> since that causes a problem of not being able to call Functions B and C
> from
> Function A
If I need something like this, I use routine_id:
integer Callee_routine_id
procedure _Callee(int x)
call_proc(Callee_routine_id, {x})
end procedure
procedure Caller()
-- 'Caller' needs to call 'Callee'
_Callee(15) -- instead of calling Callee, you call _Callee
end procedure
procedure Callee(int x)
-- do something with x
end procedure
Callee_routine_id = routine_id("Callee")
3. RE: Declaring a Function Before it is used
Maybe you mean "use a function before it is declared"?
If your program really needs that, then it is not so simple. In fact, this
is necessary only when you have two (or more) mutually recursive functions.
Regards.
----- Original Message -----
From: Michelle Rogers <michellerogers at bellsouth.net>
To: <EUforum at topica.com>
Subject: Re: Declaring a Function Before it is used
>
>
> wait a sec...i thought this language was supposed to be EASIER to
use...then
> why would you have to go through all of this for a simple "declare a
> function before it's used"?
>
> ----- Original Message -----
> From: "Derek Parnell" <ddparnell at bigpond.com>
> To: <EUforum at topica.com>
> Sent: Tuesday, October 28, 2003 7:10 AM
> Subject: Re: Declaring a Function Before it is used
>
>
> > ----- Original Message -----
> > From: "Michelle Rogers" <michellerogers at bellsouth.net>
> > To: <EUforum at topica.com>
> > Sent: Tuesday, October 28, 2003 10:06 PM
> > Subject: Declaring a Function Before it is used
> >
> >
> > > Also, can anyone tell me if there is a way to declare a function
before
> it
> > > is used.
> >
> > You can't, damn it! This is the thing I most want in Euphoria, but the
> author is philosophically against it.
> >
> > > If not, how do you handle things like:
> > > Run Function A, which calls Function B
> > > Function B calls Function C
> > > If statement then
> > > Function C calls Function D
> > > else
> > > Function C calls Function A
> > > end if
> > >
> > > This seems impossible to handle if you can't declare Function A ahead
of
> > > time, because you can't move it ahead of Function C to solve the
> problem,
> > > since that causes a problem of not being able to call Functions B and
C
> from
> > > Function A
> > >
> >
> > Welcome to the wonderful world of 'routine_id()'.
> >
> > The function 'routine_id()' returns an index to a routine, and the
> routines 'call_proc()' and 'call_func()' can use this index to invoke the
> routine indirectly. Here is an example...
> >
> > -- This need to be near the front of the file.
> > integer r_FuncA, r_FuncB, r_FuncC, r_FuncD
> >
> > function FuncA()
> > x = call_func(r_FuncB,{})
> > end function
> >
> > function FuncB()
> > x = call_func(r_FuncC,{})
> > end function
> >
> > function FuncC()
> > if statement then
> > x = call_func(r_FuncD,{})
> > else
> > x = call_func(r)FuncA,{})
> > end if
> > end function
> >
> > function FuncD()
> > . . .
> > end function
> >
> > -- These need to be after the routines they are referring to.
> > r_FuncA = routine_id("FuncA") -- Notice the routine name is in a string.
> > r_FuncB = routine_id("FuncB")
> > r_FuncC = routine_id("FuncC")
> > r_FuncD = routine_id("FuncD")
> >
> >
> > --
> > Derek
> >
> >
> > TOPICA - Start your own email discussion group. FREE!
> >
> >
>
>
> TOPICA - Start your own email discussion group. FREE!
>
>
4. RE: Declaring a Function Before it is used
Thats right, Pete. In C and C++, you have to use prototypes to this end.
Regards.
----- Original Message -----
From: Pete Lomax <petelomax at blueyonder.co.uk>
To: <EUforum at topica.com>
Subject: Re: Declaring a Function Before it is used
>
>
> On Tue, 28 Oct 2003 18:09:05 -0500, Michelle Rogers
> <michellerogers at bellsouth.net> wrote:
>
> >wait a sec...i thought this language was supposed to be EASIER to
use...then
> >why would you have to go through all of this for a simple "declare a
> >function before it's used"?
>
> Actually it really is not so difficult:
>
> integer r_Even -- extra/instead
>
> integer i
>
> function Odd(integer o)
> if o=0 then return 0 end if
> if o=1 then return 1 end if
> -- return Even(o-1)
> return call_func(r_Even,{o-1}) -- extra/instead
> end function
>
> function Even(integer e)
> if e=0 then return 1 end if
> if e=1 then return 0 end if
> return Odd(e-1)
> end function
> r_Even=routine_id("Even") -- extra/instead
>
> ? Odd(3)
> ?Even(3)
> ? Odd(2)
> ?Even(2)
>
> Analysis
> =======
> You've had to replace the one line "return Even(o-1)" with three:
>
> integer r_Even -- extra/instead
> return call_func(r_Even,{o-1}) -- extra/instead
> r_Even=routine_id("Even") -- extra/instead
>
>
> YES, there is a (valid) beef about this in this forum.
> However, it works, and Eu is fast(er) because of it.
> Is it a major problem?
>
> You decide.
>
> Pete
> PS I would also sacrifice a little speed for ease of programming.
> However, I'm not walking away over this (minor) issue.
> PPS In other languages I believe you have to declare a "prototype", or
> worse independently define it in a .h file, sometimes anyway.
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
>
5. RE: Declaring a Function Before it is used
Derek Parnell wrote:
>
> From: "Mike Nelson"
<snip>
> > I would suggest "declare" as a new keyword, used as below:
> >
> > declare function foo(3) -- the digit is the number of parameters
> >
> > declare global procedure bar(0)
> >
IMO this isn't really much cleaner than the routine_id() way. And it
still matters where you put the declare.
<snip>
> So why bother? Either do the 'C' thing ...
>
> declare function foo(sequence , integer , integer)
>
> or don't have a 'declare' but have the interpreter keep a fix-up
> table during the (single) parse pass.
I like this idea better (the VB-ish, fix-up table).
<snip>
> One really annoying aspect of routine_id() is that it doesn't do
> forward referencing either. If it did, it would simplify libraries
> like Win32lib and Diamond. We could then test for the existance of
> user-written routines - in win32lib's case, I could test for
> routine names like "onPaint_MyWindow" etc.. so the user of the
> library didn't have to do a setHandler() at runtime.
This would be easier to implement (in fact, looking at the RDS source,
Rob has comments that make it clear that it was a conscious decision to
disallow run-time forward referencing, rather than a consequence of the
design), although I prefer having explicit event handling connections.
Of course, you'd have to keep setHandler() to allow for single handlers
for multiple events and controls.
Matt Lewis
6. RE: Declaring a Function Before it is used
Derek:
I agree. But I'd call this "convenient", not "necessary".
Regards.
----- Original Message -----
From: Derek Parnell <ddparnell at bigpond.com>
To: <EUforum at topica.com>
Subject: Re: Declaring a Function Before it is used
>
>
> ----- Original Message -----
> From: "Ricardo Forno" <rmforno at tutopia.com>
> To: <EUforum at topica.com>
> Sent: Wednesday, October 29, 2003 4:22 PM
> Subject: RE: Declaring a Function Before it is used
> >
> > If your program really needs that, then it is not so simple. In fact,
this
> > is necessary only when you have two (or more) mutually recursive
functions.
> > Regards.
>
> The other time it is 'necessary' is when the coder wishes to have the
source code structured in such a manner that it reflects the architecture of
the application. That's a fancy way of saying the I'd like to have related
routines physically close to each other in the source code.
>
> With the current restriction in Euphoria, I am frequently moving routines
around the source files so that they can used - this is one of the reasns
why Win32lib is such a dog's breakfast. For example, I sometimes will change
a routine so that it now calls another routine, only to find that the
routine I'm now calling is further down the in the source file. So I must
rearrange the code to accommodate RDS's philosophy. And in doing so, I might
suddenly find that I need to more more than one (often unrelated) routine to
get it 'just right'. In fact, I've gotten so sick and tired of doing this
that now I resort to routine_id() calls instead of rearranging source code.
Call me lazy, but it is not effective coding practice (IMNSHO) to
continually be concerned with juggling the physical layout of source code.
>
> The other language I deal with in a daily manner is Visual Basic, and that
language does not require either pre-declaration or restricted physical code
layouts. I can group my routines in a logical manner and not worry about
where in the source code a routine is physically coded in order for me to
use it.
>
> RDS is got this one wrong.
>
> --
> Derek
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
>
7. RE: Declaring a Function Before it is used
I'm with Derek on this one. The lack of forward referencing really
starts to hurt when you are writing/maintaining large libraries (like
EuGrid in my case).
I don't see the value in an imposed 'philosophy' which just ends up
wasting my time.
I don't know much about the interpreter's innards but perhaps a
compromise would be a new 'with forward references' declaration
statement?
If this were possible then those of us who don't mind a slight potential
performance penalty could write code the way *we* want to. The rest
could carry on as at present.
Regards,
Phil
Derek Parnell wrote:
>
>
> ----- Original Message -----
> From: "Ricardo Forno" <rmforno at tutopia.com>
> To: <EUforum at topica.com>
> Sent: Wednesday, October 29, 2003 4:22 PM
> Subject: RE: Declaring a Function Before it is used
> >
> > If your program really needs that, then it is not so simple. In fact,
> > this
> > is necessary only when you have two (or more) mutually recursive
> > functions.
> > Regards.
>
> The other time it is 'necessary' is when the coder wishes to have the
> source code structured in such a manner that it reflects the
> architecture of the application. That's a fancy way of saying the I'd
> like to have related routines physically close to each other in the
> source code.
>
> With the current restriction in Euphoria, I am frequently moving
> routines around the source files so that they can used - this is one of
> the reasns why Win32lib is such a dog's breakfast. For example, I
> sometimes will change a routine so that it now calls another routine,
> only to find that the routine I'm now calling is further down the in the
> source file. So I must rearrange the code to accommodate RDS's
> philosophy. And in doing so, I might suddenly find that I need to more
> more than one (often unrelated) routine to get it 'just right'. In fact,
> I've gotten so sick and tired of doing this that now I resort to
> routine_id() calls instead of rearranging source code. Call me lazy, but
> it is not effective coding practice (IMNSHO) to continually be concerned
> with juggling the physical layout of source code.
>
> The other language I deal with in a daily manner is Visual Basic, and
> that language does not require either pre-declaration or restricted
> physical code layouts. I can group my routines in a logical manner and
> not worry about where in the source code a routine is physically coded
> in order for me to use it.
>
> RDS is got this one wrong.
>
> --
> Derek
>
>
8. RE: Declaring a Function Before it is used
Robert Craig wrote:
>
>
> Irv Mullins wrote:
> > I understand the desirability of declaring a routine before referencing
> > it. But why couldn't something like:
> >
> > declare function foo(2)
> > or
> > declare function foo ( name, age )
> >
> > be used to declare a routine in advance? Seems that meets the
> > philosophical requirements as well as the practical ones.
>
> In practice, people would simply arrange their
> routines in random order, then keep adding
> declarations until the interpreter shuts up.
>
> I like having some kind of logical order imposed,
> and machine verified. You may have an even more
> logical way of arranging some of your routines,
> but what does it mean to me as the reader of your
> code? And is it machine verified?
>
> I still think the advantages of
> "define-it-before-you-use-it" outweigh
> the nuisance of occasionally having to copy/paste
> a routine to a new place. It may not be desirable
> in *every* program, but when people know there are
> no exceptions to this rule, it promotes the
> readability and maintainability of Euphoria
> programs in general.
>
Please explain to me how, in the example below, the called routine is
defined-before-use ...
integer r_ProcTwo
procedure ProcOne()
call_proc(r_ProcTwo,{})
end procedure
procedure ProcTwo()
. . .
end procedure
r_ProcTwo = routine_id("ProcTwo")
--
Derek
9. RE: Declaring a Function Before it is used
I'm trying to see both sides of the argument. While I think that having the
possibility of forward references may ease program writing, I'd like to talk
about two experiences I'm having.
At the moment, I'm not programming in Euphoria but in C, and I'm teaching C
at a University here in Buenos Aires.
1) I wrote two very large programs in C. Each one is contained in a *single*
file. I did not use prototypes at all. I do not have mutually recursive
routines in them, nor simply recursive ones, for that matter. So, I had to
arrange routines in their usage order, and I feel this helped me to better
organize and follow my programs.
2) I've found that one of the main problems that face beginner C programmers
is in using prototypes. As far as 30% or 40% of the errors I find in their
programs are due to inconsistencies between prototypes and actual function
definitions. So, I teach them to order functions in the souce file the same
way we have to do in Euphoria, unless they have mutually recursive functions
(which at the beginner level are seldom used).
As a conclusion, in a way I am with Rob in this subject, though I admit that
in certain cases forward referencing will alleviate program writing.
Regards.
----- Original Message -----
From: Pete Lomax <petelomax at blueyonder.co.uk>
To: <EUforum at topica.com>
Sent: Thursday, October 30, 2003 9:31 PM
Subject: Re: Declaring a Function Before it is used
>
>
> On Thu, 30 Oct 2003 13:51:40 -0500, Robert Craig
> <rds at RapidEuphoria.com> wrote:
>
> >In practice, people would simply arrange their
> >routines in random order, then keep adding
> >declarations until the interpreter shuts up.
>
> And if they had no need to add the declarations in the first place?
>
> You are actually admitting here, that this is a problem, and the
> second word of your answer is "off", the first being too rude to print
>
> >
> >I still think the advantages of
> >"define-it-before-you-use-it" outweigh
> >the nuisance of occasionally having to copy/paste
>
> OCCASIONALLY?!!!!
>
> Stop thinking about trivial programs.
>
> >a routine to a new place. It may not be desirable
> >in *every* program,
>
> This happens in EVERY program over a few thousand lines.
>
> >but when people know there are
> >no exceptions to this rule,
>
> If you are adamant on that, allow "forward func/proc xxx(whatever)".
> Personally, I believe you don't _have_ to do it that way, but as Irv
> said, it that's your philosophical requirement, so be it.
>
> What you have now does not make people happy.
>
> >it promotes the
> >readability and maintainability of Euphoria
> >programs in general.
>
> Don't believe you could show even one case where that last statement
> is true.
>
>
> Pete
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
>
10. RE: Declaring a Function Before it is used
Euphoria is easier than you think, believe me.
Regards.
----- Original Message -----
From: Michelle Rogers <michellerogers at bellsouth.net>
To: <EUforum at topica.com>
Subject: Re: Declaring a Function Before it is used
>
>
> wow..I didn't realize that I could join this list and so quickly caues
such
> a "stir" over a matter that I posted about. heh..
>
> although, honestly, I imagine the reason that this is causing such
> controversy is becaue this is the one major flaw that I can see that
> Euphoria has.
>
> I think that was someone suggested (although I forgot who and I've already
> deleted by now) was a good idea...to add a statement near the top to say
> whether you want this feature to be used in your programming, or not.
That
> way, at least everyone would have a choice. That way, the ones who wanted
> to work on small programs could leave this off and wouldn't have a
problem.
> But, those of us who wanted to make more complicated programs would be
able
> to do it with this language, as well. Otherwise, it looks like I have to
> finish teaching myself C/C++ to be able to do some of the things I'm going
> to need to do.
>
> But, maybe that's logical? Maybe you have to sacrifice some of the power
> (i.e forward referencing functions) when you use an easier language, like
> Euphoria? When you think about that, it makes sense. I guess we
shouldn't
> be expecting to be able to do as much with an easier language. Much
> like...you can find editors that will create tables and t hings for you in
> HTML, that are easier than figuring out the code. But, I never use them,
> because while, yes, they are easier...you have to only use what is
> prewritten into them. So, you can't have as much variation as when you
code
> it out, yourself. Maybe that's how we should be looking at this instead.
> If we don't expect as much from an easier language, like Euphoria, and
only
> use it for "easier" programming tasks, then we won't be as disappointed to
> discover things that are beyond its capability, like forward referencing
> structures.
>
>
> ----- Original Message -----
> From: "Pete Lomax" <petelomax at blueyonder.co.uk>
> To: <EUforum at topica.com>
> Sent: Thursday, October 30, 2003 9:30 PM
> Subject: Re: Declaring a Function Before it is used
>
>
> > On Thu, 30 Oct 2003 13:51:40 -0500, Robert Craig
> > <rds at RapidEuphoria.com> wrote:
> >
> > >In practice, people would simply arrange their
> > >routines in random order,
> >
> >
> > TOPICA - Start your own email discussion group. FREE!
> >
> >
>
>
> TOPICA - Start your own email discussion group. FREE!
>
>
11. RE: Declaring a Function Before it is used
Robert Craig wrote:
>
> I still think the advantages of
> "define-it-before-you-use-it" outweigh
> the nuisance of occasionally having to copy/paste
> a routine to a new place. It may not be desirable
> in *every* program, but when people know there are
> no exceptions to this rule, it promotes the
> readability and maintainability of Euphoria
> programs in general.
>
Of course, we've entered the realm of flame/holy war here, so I can't
possibly resist putting in my own comments.
I think that "define-it-before-you-use-it" is not as unequivocal as it
first looks. For instance, there is much confusion regarding
routine_id(), in that the function must be defined at compile time,
rather than run time. I'd say that Euphoria is really
"define-it-before-you-write-it," at least from a run-time, program flow
perspective.
I'd personally be happy if we could simply use run-time definitions. If
I get enough time, I'll try to put this into my interpreter this
weekend, but here's a rough sketch of my idea:
* At compile time, note any routine usage that isn't already defined
(probably using a linked list or a hash table or some combination)
* When required, do a symbol search on the *entire* visible scope, not
restricting to only previously defined in the source
* As each routine is encountered in the source, check the above list to
verify correct usage, etc
* Undefined routines become warnings at the end if not encountered, or
if encountered at run-time, are errors. This is because you'll never
know if the routine might be defined at the next line until you get to
the end, and shouldn't require a major overhaul of the parser, since
you're still doing it all in one pass.
This would also allow forward-in-scope routine_id() calls. The emphasis
on run-time seems appropriate for an interpreter to me (and somewhat
more intuitive).
I don't really see the benefit in prototypes. If you have prototypes,
you have to go look somewhere else for the declaration. If you have to
go look somewhere, why make two places to look instead of one?
Matt Lewis
12. RE: Declaring a Function Before it is used
I agree with Mike Nelson.
The reason I got hooked on Euphoria was that I really appreciated it's
combination of power/simplicity/elegance.
By contrast, routine_id seems to me to be a singularly inelegant
construct. I vividly remember the first time I saw it and thought 'Eh?
Why on earth would I want to use that?'. It seems from the list that
this is a fairly common experience.
I don't understand why Rob insists on something so clunky when there is
no real need for it.
Phil Russell
Michael Nelson wrote:
> Unlike many other proposals (structures, OOP, built-in Windows, etc.),
> allowing forward referencing does not complicate syntax or add overhead
> to
> the interpreter. It also can't be implemented in a library. So your
> objections in this matter are purely philosophical. OK, it's your
> language--but why make developers of major libraries unhappy for the
> sake of
> pure philosophy?
