Re: Digest for EUforum at topica.com, issue 3041
> From: Peter Lynch <plynch49 at hotmail.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.
> Gosub vs Goto is the equivalent of
> Perform vs Goto in COBOL
> RTJ vs JMP in assembler
>
> 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'.
> 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.
>
>
Concurred. You can get rid of GOSUB, since Pascal can implement this as
nested routines - no special syntax and optimal readibility. I really
wish Euphoria had these.
CChris
>
>
> Derek Parnell wrote:
>
>>
>>----- Original Message -----
>>From: "Peter Lynch" <plynch49 at hotmail.com>
>>To: "EUforum" <EUforum at topica.com>
>>Sent: Monday, October 06, 2003 1:00 AM
>>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
>>
>
|
Not Categorized, Please Help
|
|
