1. Internal suroutines
I intend to generate a considerable amount of code from a Pick
environment.
The code in the Pick environment has been written with the intention of
being exported to another language. There are many issues, one of which
i am considering at present.
In Pick, there is a language element called GOSUB. This executes a
named sub-procedure within the procedure, subroutine or function.
It takes no arguments, and uses the current program element's namespace.
This named procedure is elsewhere within the procedure - with its
detail coded as normal.
E.g.
Start:
Gosub Hello_World
Stop
Hello_World:
Notify_Msg("Hello World")
Return
This encapsulates inline code in a programmer defined semantic context.
Of course, if this structure existed in Euphoria, my conversion would
be easy because i dont need to investigate within the namespace in my
conversion code.
I am wondering if it may be a useful thing to add anyway. It does allow
clarification by the decomposition of long sequences of code, without
the overhead of argument passing.
Regards,
Peter
2. Re: Internal suroutines
----- Original Message -----
From: "Peter Lynch" <plynch49 at hotmail.com>
To: "EUforum" <EUforum at topica.com>
Subject: Internal suroutines
>
>
> I intend to generate a considerable amount of code from a Pick
> environment.
> The code in the Pick environment has been written with the intention of
> being exported to another language. There are many issues, one of which
> i am considering at present.
> In Pick, there is a language element called GOSUB. This executes a
> named sub-procedure within the procedure, subroutine or function.
> It takes no arguments, and uses the current program element's namespace.
> This named procedure is elsewhere within the procedure - with its
> detail coded as normal.
> E.g.
> Start:
> Gosub Hello_World
> Stop
> Hello_World:
> Notify_Msg("Hello World")
> Return
> This encapsulates inline code in a programmer defined semantic context.
> Of course, if this structure existed in Euphoria, my conversion would
> be easy because i dont need to investigate within the namespace in my
> conversion code.
> I am wondering if it may be a useful thing to add anyway. It does allow
> clarification by the decomposition of long sequences of code, without
> the overhead of argument passing.
As used in most Basic's, including Pick and its variants, the GOSUB has the same
issues as the GOTO. The main ones being that it obscures the logic flow, and that
more work is required by the code reader to find all the potential ways that the
program can get to the labelled statement.
The closest equivalent in Euphoria is, of course, ...
procedure Hello_World()
Notify_Msg("Hello World")
return
end procedure
Hello_World()
The differences are that the labelled code must occur before any reference to
it, and that the only way the program can get to the labelled statement is by
calling the procedure which must return to the statement afer the call.
In effect, almost all BASIC programs need to be hand-translated to Euphoria,
primarily because of Euphoria's lack of forward referencing. However one
technique is to (ob)use the routine_id facility...
integer r_Hello_World
integer r_Notify_msg
procedure Main()
call_proc(r_Hello_World,{})
end procedure
procedure Hello_World()
call_proc(r_Notify_Msg,{"Hello World"})
return
end procedure
r_Hello_World = routine_id("Hello_World")
procedure Notify_Msg(sequence pText)
. . .
end procedure
r_Notify_Msg = routine_id("Notify_Msg")
Main()
--
Derek
3. Re: Internal suroutines
----- Original Message -----
From: "Peter Lynch" <plynch49 at hotmail.com>
To: "EUforum" <EUforum at topica.com>
Subject: RE: Internal suroutines
>
>
> If your premise is that clarity is reduced by the use of an internal or
> sub-procedure, then i have to disagree.
No, this is not what I meant. Using a sub-procedure is generally a good thing,
but its the ability to fall-thru to a labelled statement that causes some
concerns.
> Gosub vs Goto is the equivalent of
> Perform vs Goto in COBOL
> RTJ vs JMP in assembler
Agreed. And Gosub is equivalent to Euphoria's call statement when used without
parameters.
>
> There are difficult issues of scope in implementing sub-procedures, but
> at present if i want to encapsulate anything i need to put it in a
> separate 'process'.
Good. This is a useful thing to do.
> I dont want to see the particular element GOSUB, but i wonder if
> anybody else sees the value of allowing arbitrary decomposition of
> functional primitives - sometimes they can be quite long, and are
> obscured simply by the number of levels of logic in them.
> Sub-procedures allow a further refinement of the decomposition process,
> which is i believe the basis of software implementation.
My premise is that Euphoria already has such a facility, only with three
differences - You can't fall-thru to Eu procedures (a good thing) and you can't
refer to a procedure that occurs further down in the source code (a not-so-good
thing), and you can pass the routine parameters (a good thing).
--
Derek
