1. 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.
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
Michelle
----- Original Message -----
From: "Michelle Rogers" <michellerogers at bellsouth.net>
To: <EUforum at topica.com>
Sent: Tuesday, October 28, 2003 5:36 AM
Subject: Re: Fastest Way to...
>
>
> Hello, can someone tell me what is wrong with this? I'm using the
hackserv
> as a basis for a mud. I've tried to change it to accomodate telnet, gmud,
> zmud, etc..(basically any client) where it only supported telnet in the
> beginning. I KNOW this is too much code..but i've just been adding stuff
in
> trying to make it work and nothing seems to work. I KNOW that I'm
> overlooking something really easy..but I can't figure it out. Can someone
> tell me if you know what is wrong with this?
>
> elsif action = FD_READ then -- The client said somethin'
> junk = ""
> owork = ""
> while not match({CRLF},junk) do
> owork = WsockReadData(sock,1)
> if atom(owork) then
> exit
> end if
> if length(owork)<1 then
> exit
> end if
> if atom(owork) then
> exit
> end if
> if length(owork)<1 then
> exit
> end if
> junk = junk & owork
>
> end while
> -- junk now contains the client's responce
>
> -- find this user in our list
> iwork = getUserFromSocket(sock)
>
>
> if length(players)>0 then
> for x=1 to length(players) do
> if players[x][1]=sock then
> charnum=x
> end if
> end for
> end if
>
> players[charnum][6]=players[charnum][6]&junk
>
> if compare({10},players[charnum][6][(length(players[charnum][6]))]) or
> compare({13},players[charnum][6][length(players[charnum][6])]) then
>
> if compare({10},players[charnum][6][length(players[charnum][6])]) then
>
>
players[charnum][6]=players[charnum][6][1..(length(players[charnum][6])-1)]
> end if
>
> if compare({13},players[charnum][6][length(players[charnum][6])]) then
>
>
players[charnum][6]=players[charnum][6][1..(length(players[charnum][6])-1)]
> end if
>
> if compare({10},players[charnum][6][length(players[charnum][6])]) then
>
>
players[charnum][6]=players[charnum][6][1..(length(players[charnum][6])-1)]
> end if
> junk=players[charnum][6]
>
> warnErr("junk:"&sprint(junk))
>
> players[charnum][6]=""
> call_proc(players[charnum][7],{sock,junk})
> junk=""
> end if
>
>
> Thank you in advance,
>
> Michelle
>
>
> ----- Original Message -----
> From: "C. K. Lester" <euphoric at cklester.com>
> To: <EUforum at topica.com>
> Sent: Monday, October 27, 2003 11:34 PM
> Subject: Re: Fastest Way to...
>
>
> > Pete Lomax wrote:
> >
> > >>Okay, here's my attempt:
> > >>
> > >>junk =3D pos <=3D 0
> > >>pos =3D pos * junk
> > >>pos +=3D not junk
> > >>
> > >>
> > >That's about 3 times slower.
> > >
> > >In your first post, you "unrolled the loop" which is a classic way to
> > >make something as fast as possible.
> > >
> > >Pete
> > >
> > >
> > hey, Pete, thanks for that info. I later realized that it won't be a
> > static size sequence, so I have to accommodate all sizes.
> >
> > I bet looping through the sequence when length() is more than ? would be
> > faster than the sequence operations... right?
> >
> >
> > TOPICA - Start your own email discussion group. FREE!
> >
> >
>
>
> TOPICA - Start your own email discussion group. FREE!
>
>
2. Re: Declaring a Function Before it is used
----- Original Message -----
From: "Michelle Rogers" <michellerogers at bellsouth.net>
To: <EUforum at topica.com>
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
3. 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>
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!
>
>
4. 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"?
it has to do with how the interpreter works on the internal level. from my
understanding, it parses the routines one-by-one, and checks the code as it
goes. if a routine is called before it is declared, it produces an error,
since the interpreter does not know where, if at all, that routine is
actually declared. this helps speed up error checking, since the whole
program doesn't need to be parsed twice, once for routines and code, and
again for errors.
the use of routine_id() may be somewhat complicated, but it is probably the
most ingenius method for working around undeclared routines. you'll find
that routine_id() is used extensively with Win32Lib for setting event
handlers for controls. once you get used to using routine_id() and
understand how your program flows, it does become a lot easier. and
sometimes using routine_id() may be avoided by re-thinking the flow of a
program.
~Greg
5. Re: Declaring a Function Before it is used
----- Original Message -----
From: "Michelle Rogers" <michellerogers at bellsouth.net>
To: <EUforum at topica.com>
Sent: Wednesday, October 29, 2003 10:09 AM
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"?
I 100% agree. I believe that the author of Euphoria regards forward referencing
as a bad programming practice and therefore will not support it.
> ----- 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!
>
>
6. 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.
7. Re: Declaring a Function Before it is used
that's a LOT more difficult and time-consuming than..
int procedure ProcedureToBeCalledLater()
unless i'm mistaken..that's ALL you have to do in C
and in my opinion this is a major issue that will cause a lot of programming
problems. I'm still looking for the error that I had from not being able to
declare a function/procedure ahead of time (it's hard to find, because i
simply changed the program to do something different than what I wanted it
to do, I had no choice)..But, the thing is that I got the error while using
routine_id. So, that isn't fool-proof, either. I can't show you the code,
because I've already changed it. That's what I mean...but I didn't see any
way around getting rid of that error, short of just going to a different
procedure than what I had originally intended. In this case, I wasn't as
happy doing that..but settled for it. But, I can see future cases where it
will be a major problem.
Michelle
----- Original Message -----
From: "Pete Lomax" <petelomax at blueyonder.co.uk>
To: <EUforum at topica.com>
Sent: Tuesday, October 28, 2003 7:33 PM
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!
>
>
8. Re: Declaring a Function Before it is used
Please remember to always top-post so no-one knows who you are
replying to.
Your problems are always much better received if you admit you can't
remember why they caused you a problem in the first place.
Introducing a problem that you can't remember and can't reproduce is
even better.
Being reasonable when asked a reasonable question is NOT an option
Pete
9. Re: Declaring a Function Before it is used
On Tue, 28 Oct 2003 20:38:42 -0500, Michelle Rogers
<michellerogers at bellsouth.net> wrote:
>int procedure ProcedureToBeCalledLater()
>
>unless i'm mistaken..that's ALL you have to do in C
BTW you could also get it right. It is:
int ProcedureToBeCalledLater();
Oh gosh, two lines of code, not three. I'll die of carpel tunnel
syndrome.
Pete
10. 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
11. Re: Declaring a Function Before it is used
> ----- Original Message -----
> From: Pete Lomax <petelomax at blueyonder.co.uk>
> To: <EUforum at topica.com>
> Sent: Tuesday, October 28, 2003 9:33 PM
> Subject: Re: Declaring a Function Before it is used
>
>
[snip]
> >
> > 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?
I would strongly argue for the value of routine_id(), but for reasons other than
a means to implement forward referencing.
And is forward referencing a real performance penalty? I would argue not.
Firstly, Eu is already checking for the existance of the named routine when it
parses routine call. To implement forward referencing (of routines) Eu only needs
to act differently when it finds a routine name that it hasn't come across yet.
Instead of crashing, Eu only needs to leave a place holder and add it to a
'fix-up' list. And when parsing a new routine definition, check the fix-up list
to back poke in the new routine reference as required. Only one pass of the
source code is required. The place holder could in fact be a reference to an
built-in routine that causes the program to crash due to undefined routine name!
Ok, so it might add a few milliseconds to the program start up - but who'd
notice in any program that runs for more than a second?
> > PS I would also sacrifice a little speed for ease of programming.
> > However, I'm not walking away over this (minor) issue.
Neither am I. Thankfully Euphoria got other things right enough for me to stick
with it for now.
--
Derek
12. Re: Declaring a Function Before it is used
I would like to see a C-style rule: you must declare a routine before using
it, but can define it later (must be in the same source file--this would
eliminate the proliferation of headers and be simpler for the interpreter).
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)
declare type blech -- digit not needed, as a type must have exactly one
parameter. But "declare type blech(1)" might be prefered for consistency.
While this is more involved than the VB approach, it would allow Eu to
remain a one-pass interpreter, but eliminate the need for routine_id for
this very common case.
I would also keep routine_id functioning as it does now, we need it for
other things: indirect calls, polymorphic calls, etc.
-- Mike Nelson
13. Re: Declaring a Function Before it is used
----- Original Message -----
From: "Mike Nelson" <MichaelANelson at WORLDNET.ATT.NET>
To: <EUforum at topica.com>
Sent: Wednesday, October 29, 2003 6:25 PM
Subject: Re: Declaring a Function Before it is used
>
>
> I would like to see a C-style rule: you must declare a routine before using
> it, but can define it later (must be in the same source file--this would
> eliminate the proliferation of headers and be simpler for the interpreter).
>
> 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)
>
> declare type blech -- digit not needed, as a type must have exactly one
> parameter. But "declare type blech(1)" might be prefered for consistency.
>
> While this is more involved than the VB approach, it would allow Eu to
> remain a one-pass interpreter, but eliminate the need for routine_id for
> this very common case.
This idea would not change the number of passes the interpreter would need to
make, because at the the time a routine call is parsed, all that would be
available to Eu is the routine's name and the number of parameters. It would
still need to parse the actual definition to know the exact signature of the
routine (assuming you are trying to catch mismatched parameter usage). For
example, it wouldn't catch this ...
declare function foo(3)
. . .
x = foo(1, 2.4, "abc")
. . .
function foo(sequence a, integer b, integer c)
. . .
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 would also keep routine_id functioning as it does now, we need it for
> other things: indirect calls, polymorphic calls, etc.
>
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.
--
Derek
14. Re: Declaring a Function Before it is used
On Wed, 29 Oct 2003 23:05:36 +1100, Derek Parnell
<ddparnell at bigpond.com> wrote:
> x = foo(1, 2.4, "abc")
> . . .
> function foo(sequence a, integer b, integer c)
You are aware that even if those lines are the other way round, RDS Eu
does not perform any type checking whatsoever at parse/compile time.
I don't think this is a problem, btw, I'm just saying that forward ref
wouldn' "lose" type-checking, since there is none done in the first
place. You can prove this with:
function foo(sequence a, integer b, integer c)
return 1
end function
function bar()
return foo(1, 2.4, "abc")
end function
puts(1,"no error yet\n")
if getc(0) then end if
?bar() -- this will still crash, of course
Theoretically, forward referencing need be no different to 'else'
handling, the only thing needed is new error messages:
fred(1,2,3,4)
...
procedure fred(integer a, integer b, integer c)
^
error: procedure previously used with 4 parameters
and an undefined routine message like the type check error above, if
you try to actually execute the call before the routine is defined, or
at the end of the program.
>One really annoying aspect of routine_id() is that it doesn't do forward
>referencing either.
Yup
>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 "onPaint_MyWindow" etc.
> so the user didn't have to do a setHandler() at runtime.
Have you tried:
include win32lib.ew
<user code>
include win32rtn.ew
WinMain(Main,Normal)
where win32rtn.ew is something like:
-- code starts --
function rid(sequence name)
return routine_id(name)
end function
w32Init(routine_id("rid"))
-- code ends --
You might want to allow daisy-chaining of several copies of such a
routine, to prevent all the "onPaint_MyWindow" having to be global.
(In which case function rid()'s would have to be hand-coded.)
Pete
15. Re: Declaring a Function Before it is used
After reading Derek's reply, I withdraw my suggestion. I had not realized
that it would still be possible to have a one pass interpreter. Given that
it is, I would call on Rob to allow forward referencing, both in routine
calls and in routine_id(). If he is convinced that it is bad programming
practice, let the interpreter issue a warning, if Rob insists.
-- Mike Nelson
16. Re: Declaring a Function Before it is used
On Thursday 30 October 2003 06:30 am, you wrote:
>
>
> 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).
Agreed. Recently I've been trying to write some database programs
in a neat, modular way, and the lack of forward declarations means
a lot of "routine juggling" (moving routines from an include file where
they _logically_ belong to some other include where they don't, but
where they are able to see the routines they depend upon).
> I don't see the value in an imposed 'philosophy' which just ends up
> wasting my time.
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.
As someone pointed out earlier, there's no point in putting
types in the parameter list, as no type checking is done until
run-time, but it might be nice to be able to give meaningful
or descriptive names to the parameters.
Rob?
Irv
17. Re: Declaring a Function Before it is used
On Thu, 30 Oct 2003 08:02:32 -0500, Irv Mullins <irvm at ellijay.com>
wrote:
>it might be nice to be able to give meaningful
>or descriptive names to the parameters.
Why? The actual routine definition does that.
All you need to know is whether it is a procedure or function, which
I'm assuming won't be difficult to deduce from the context (unless
someone has an example where it might be?) and the number of
parameters, which again I would imagine is just a matter of counting
them.
One thing I will say is that forward definition of types should NOT be
allowed, since by doing so they would actually be used before they
were defined, to allocate the right space for the variable, as opposed
to functions and procedures which can be referenced, but not actually
called until after the routine is properly defined.
Pete
PS As to performance issues, a program is only loaded once. Imagine it
takes an extra 20,000 instructions, say 1,000,000 machine cycles.
That's what? 0.004 seconds at 250MHz, 0.0005 seconds at 2GHz?
18. Re: Declaring a Function Before it is used
On Thursday 30 October 2003 09:17 am, you wrote:
>
>
> On Thu, 30 Oct 2003 08:02:32 -0500, Irv Mullins <irvm at ellijay.com>
>
> wrote:
> >it might be nice to be able to give meaningful
> >or descriptive names to the parameters.
>
> Why? The actual routine definition does that.
> All you need to know is whether it is a procedure or function, which
> I'm assuming won't be difficult to deduce from the context (unless
> someone has an example where it might be?) and the number of
> parameters, which again I would imagine is just a matter of counting
> them.
Documentation - it's a good thing.
Which is more meaningful:
function count (2)
or
function count (customers, transactions)
Note that there is no need for the words used to be valid
variables. Words are just more meaningful than (2) would be.
If you don't want them to have any meaning, just use
(a,b) or (param1, param2)
> One thing I will say is that forward definition of types should NOT be
> allowed, since by doing so they would actually be used before they
> were defined, to allocate the right space for the variable, as opposed
> to functions and procedures which can be referenced, but not actually
> called until after the routine is properly defined.
Yes, I don't see any purpose in forward type declarations.
Irv
19. Re: Declaring a Function Before it is used
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.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
20. Re: Declaring a Function Before it is used
On Thursday 30 October 2003 01:51 pm, you wrote:
>
> Irv Mullins wrote:
> > I understand the desirability of declaring a routine before referencing
> > it. But why couldn't something like:
> >
> > d> 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.
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.comeclare 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.
And who would be to blame for that?
> 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?
If I can arrange it more logically, that should mean to you,
as a reader of my code, that things would appear in a more logical
order, no?
And, just exactly what do you mean when you say "machine
verified"?
If I declare a function: foo ( integer x )
and then call it as foo("Hello"), there is NO machine verification
until the code runs. None, in fact, until conditions happen to be
right for a call to foo() to be executed.
This is a source of many problems.
How could a forward declaration cause even less verification than
what already (doesn't) exist?
Irv
21. 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
22. 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,
23. 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!
>
>
24. Re: Declaring a Function Before it is used
No, I did not notice that there was already forward referencing. I had to
completely change what I wanted to do with the program and do something
different (well, I could have done that or either had that function in the
program twice....although I actually realized t hat wouldn't work either,
because what I was wanting was an endless loop where you kept going back to
the same function if you hadn't entered something correctly, but if you had
entered correctly, you moved on to a different one). I was using routine_id
at the time...actually I wasn't too upset about not being able to forward
reference, because I had seen that you could use routine_id to do that. So,
that's what I was using. But I still got errors because I coudn't get the
functions in the right order. See, I had (and all of this has already been
deleted when I rewrote it completely) but I had about 3 to 4 functions
involved, actually. Something similiar to.... (and sorry, I ALWAYS say
functions, even though in this case I REALLY mean
procedures..but...something similiar to this..)
Run Procedure 1
Run Procedure 2
Run Procedure 3
If you entered correctly Goto Procedure 4 else return to Procedure 1
In this particular case..I heaved a heavy sigh and changed what I wanted to
do...instead of giving the person a chance to return to Procedure 1 and
correct what they had entered, I simply kicked them off the server and made
them start over by manually reconnecting (this is a socket server).
Because this is where they were being asked to create a user name and a
password, it was very early on in the program, and I COULD do that, even
though I didn"t WANT to do that. However, I'm afraid that when this issue
comes up again, later in the program (which it will, because the number of
lines are growing rapidly) I'll have to move back to C/C++ and start over.
But, yes, I was using routine_id the entire time. I use a call_proc to read
what they are entering so that I can change which function they go to with
routine_id. This way I can stop their input and wait for one specific
answer to my question (i.e. password) instead of allowing them to keep
typing any command (i.e. who, look, etc.)
Michelle
----- Original Message -----
From: "Al Getz" <Xaxo at aol.com>
To: <EUforum at topica.com>
Sent: Friday, October 31, 2003 2:11 AM
Subject: RE: Declaring a Function Before it is used
>
>
> Hello Michelle,
>
> Hee hee, believe it or not, this subject comes up every time
> someone else with more then a casual interest in Eu 'joins' the
> list 
> I think it's because they realize that there already is
> forward referencing but it's much harder to declare a
> function that will be forward referenced than a normal
> function.
>
> BTW, you did notice that there already is forward referencing
> didnt you?
>
> I use this all the time and so im quite used to it by now,
> but even an abbreviation 'rid' for 'routine_id' would
> be very nice to have.
>
> Take care,
> Al
>
> PS Dont ask any more questions ok? (just kidding)
>
>
> Michelle Rogers wrote:
> >
> >
> > 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!
>
<snip>
25. Re: Declaring a Function Before it is used
On Thursday 30 October 2003 10:23 pm, you wrote:
>
>
> 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.
Keep looking - you'll find more ;)
<snip>
> 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....
If it weren't just an arbitrary limitation based on some personal philosophy,
I would agree. If Euphoria were just a language invented for the sole use of
Rob, I would say "fine". However, once RDS decided to sell Euphoria, they
put themselves in a different situation. Any good business person listens to
customers' requests, and tries to satisfy them.
Irv
26. Re: Declaring a Function Before it is used
Hi the list!
I'm sorry to disagree with you, Rob, because I can read source files
only from start to end of file (and expect a plurality of people to do
so :) ).
Assume routineA() calls subroutineA1(), subroutineA2() and
sunbroutineA3(). In the current layout enforced by Euphoria, I have to
read through the code of all three suroutines (hopefully they don't call
anything else to be stacked berofre them) before understanding (at
last!) why they are here in the first place, what the arguments mean
etc, as the answer appear inside the code of routineA().
As a result, the general layout of the code is made positively more
obscure by disallowing forward referenceing, not clearer.
Regards
CChris
> Date: Thu, 30 Oct 2003 13:51:40 -0500
> From: Robert Craig <rds at RapidEuphoria.com>
> Subject: Re: Declaring a Function Before it is used
>
>
> 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.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
>
27. Re: Declaring a Function Before it is used
<unlurk>
1. Not uncommon for any large project, regardless of the arrangements
of routines.
2. Simple solution: press <CTRL><END> and start reading the routines
from the bottom up.
</unlurk>
>>> Christian.CUVIER at agriculture.gouv.fr 10/31/2003 8:45:54 AM >>>
In the current layout enforced by Euphoria, I have to
read through the code of all three subroutines before understanding why
they are here in the first place, what the arguments mean
etc, as the answer appear inside the code of routineA().
28. Re: Declaring a Function Before it is used
Rob,
I program professionally in Visual Basic, where forward references are
legal. I find most of my code structures itself as
use-it-before-you-define-it. For example, let's say that foo is a routine
and bar implements some detailed functionality for foo.
In Eu, I must code this as
procedure bar()
-- do highly technical stuff
end procedure
global procedure foo()
-- do stuff
bar()
-- do more stuff
end procedure
Admittedly on reading foo, I have already read bar and "know what it does".
On the other hand, as likely as not I can't really understand what bar does
until I see it in its context in foo. If forward referencing were allowed,
I would put the general routine foo first and the implementation routine
bar() after it.
I submit that ordering routines from general to specific (top-down) is at
least as logically coherent nad readable as specific to general (bottom-up)
as mandated by Eu.
I agree with Al Getz that forward referencing in top-lvel code should still
be prohibited. This is much less needed and would require a two-pass
interpreter.
If I am so inclined, I can write excellent, comprehenisble code in either
mode. I can also write unmaintainable garbage in either mode. Obfuscated Eu
code is perfectly possible, it just takes more creativity than in C.
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? If Derek says that forward refencing would simplify
Win32Lib and its absence makes his programming tasks more complicated, I am
certain he knows what he's talking about. In Diamond, this is not a
significant issue, but the routines are far less interdependent than in
Win32Lib.
By the way, Diamond allows forward referencing of methods (no problem to
implement as all methods are called via routine_id).
-- Mike Nelson
29. Re: Declaring a Function Before it is used
Mike Nelson wrote:
> ...=20
> In Eu, I must code this as
>=20
> procedure bar()
> -- do highly technical stuff
> end procedure
>=20
> global procedure foo()
> -- do stuff
> bar()
> -- do more stuff
> end procedure
>=20
> Admittedly on reading foo, I have already read bar and "know what it does=
".
> On the other hand, as likely as not I can't really understand what bar do=
es
> until I see it in its context in foo. If forward referencing were allowe=
d,
> I would put the general routine foo first and the implementation routine
> bar() after it.
> ...
Mike, would it be possible to write your example code like this:
global procedure foo()
-- do stuff
bar()
-- do more stuff
end procedure
So, you have not (or would not) read bar() in advance of foo().
Have a nice day, Rolf=20
| Earth |-------------------------------|
| Solar System | Earth Phone : +49-40-724-4650 |
| Milky Way | National Fax: 0721-151-577722 |
| Local Group | mailto:Rolf at RSchr.de |
| Known Universe | http://www.rschr.de |
30. Re: Declaring a Function Before it is used
Mike Nelson wrote:
> ...
> In Eu, I must code this as
>
> procedure bar()
> -- do highly technical stuff
> end procedure
>
> global procedure foo()
> -- do stuff
> bar()
> -- do more stuff
> end procedure
>
> Admittedly on reading foo, I have already read bar and "know what it does".
> On the other hand, as likely as not I can't really understand what bar does
> until I see it in its context in foo. If forward referencing were allowed,
> I would put the general routine foo first and the implementation routine
> bar() after it.
> ...
Mike, would it be possible to write your example code like this:
global procedure foo()
-- do stuff
bar()
-- do more stuff
end procedure
So, you have not (or would not) read bar() in advance of foo().
Have a nice day, Rolf
31. Re: Declaring a Function Before it is used
Mike Nelson wrote:
> ...=20
> In Eu, I must code this as
>=20
> procedure bar()
> -- do highly technical stuff
> end procedure
>=20
> global procedure foo()
> -- do stuff
> bar()
> -- do more stuff
> end procedure
>=20
> Admittedly on reading foo, I have already read bar and "know what it does=
".
> On the other hand, as likely as not I can't really understand what bar do=
es
> until I see it in its context in foo. If forward referencing were allowe=
d,
> I would put the general routine foo first and the implementation routine
> bar() after it.
> ...
Mike, would it be possible to write your example code like this:
include bar.e -- contains procedure bar()
global procedure foo()
-- do stuff
bar()
-- do more stuff
end procedure
So, you have not (or would not) read bar() in advance of foo().
Have a nice day, Rolf=20
| Earth |-------------------------------|
| Solar System | Earth Phone : +49-40-724-4650 |
| Milky Way | National Fax: 0721-151-577722 |
| Local Group | mailto:Rolf at RSchr.de |
| Known Universe | http://www.rschr.de |
