OpenEuphoria

2. Re: Routine_ID Is No Doubt My Solution...

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> Apr 12, 2003
• 450 views

On Thu, 10 Apr 2003 16:23:15 -0500, "C. K. Lester"
<cklester at yahoo.com> wrote:

>How come I get no valid routine_ids?
Yikes, now there is a nasty programming gotcha. Somehow at the point
where routine_id is called it appears to be searching a saved list of
routine names known at that point during parsing... rather than the
expected scan of the full symbol table at that point during execution!
Maybe an over-zealous optimisation, Rob?

Anyway, comment out the call to routine_id within add_command() and
insert the following code after all add_command()s have been issued.

command_id =3D repeat(-1,length(command_list))
for i =3D 1 to length(command_list) do
	command_id[i]=3Droutine_id(command_list[i])
end for

Pete

4. Re: Routine_ID Is No Doubt My Solution...

• Posted by Derek Parnell <ddparnell at bigpond.com> Apr 12, 2003
• 475 views

----- Original Message -----
>From: "Pete Lomax" <petelomax at blueyonder.co.uk>
>To: "EUforum" <EUforum at topica.com>
>Subject: Re: Routine_ID Is No Doubt My Solution...
>

>
>On Thu, 10 Apr 2003 16:23:15 -0500, "C. K. Lester"
><cklester at yahoo.com> wrote:
>
>>How come I get no valid routine_ids?
>Yikes, now there is a nasty programming gotcha. Somehow at the point
>where routine_id is called it appears to be searching a saved list of
>routine names known at that point during parsing... rather than the
>expected scan of the full symbol table at that point during execution!
>Maybe an over-zealous optimisation, Rob?
>
>Anyway, comment out the call to routine_id within add_command() and
>insert the following code after all add_command()s have been issued.
>
>command_id = repeat(-1,length(command_list))
>for i = 1 to length(command_list) do
>command_id[i]=routine_id(command_list[i])
>end for

Pete's solution is the right thing, but this behaviour of Euphoria is
designed. RDS explicitly wants Euphoria to be like this - it is NOT
"over-zealous optimisation". The design philosophy for Euphoria is "nothing
can be referenced until it has been 'seen' by the translator first".

<soapbox>
IMHO, this is a dumb decision and one of the most annoying things about this
great language. The lack of forward referencing makes things harder for the
coder. I can understand the excuse for it in the early days when computers
were slow, but with modern computers I really don't mind waiting the one or
two seconds it takes to parse the whole code before execution.
</soapbox>

----------------
cheers,
Derek Parnell

6. Re: Routine_ID Is No Doubt My Solution...

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> Apr 13, 2003
• 435 views

On Sun, 13 Apr 2003 08:30:28 +1000, Derek Parnell
<ddparnell at bigpond.com> wrote:

>Pete's solution is the right thing, but this behaviour of Euphoria is
>designed. RDS explicitly wants Euphoria to be like this - it is NOT
>"over-zealous optimisation". The design philosophy for Euphoria is =
"nothing
>can be referenced until it has been 'seen' by the translator first".

Derek is right again   I now fully understand and accept this (but
I'll beat it to death anyway)  eg:

a=3Droutine_id("b")
...
procedure b()

will not work, because when routine_id is executed, b() has not yet
been defined; it is not yet in the symbol table. But:

constant name=3D"b"
procedure a()
	?routine_id(name)		-- line 3
end procedure
procedure b()
end procedure
?routine_id(name)			-- line 7
a()						-- line 8

In this case, line 7 passes the same constant to the same built-in
function as line 3, which is actually executed after line 7, but it
gives a different result(!!). Hence somewhere for line 3 it must be
deliberately storing an index of some sort specifically to force this
behaviour. So Derek is right, this is not an optimisation, in fact it
is an (admittedly insignificant) overhead! And as usual the
documentation is spot-on, I just assumed it was using "after" in an
execution sense rather than a dogmatic absolute line number sense.
 You live and learn.

><soapbox>
>IMHO, this is a dumb decision and one of the most annoying things about =
this
>great language. The lack of forward referencing makes things harder for =
the
>coder. I can understand the excuse for it in the early days when =
computers
>were slow, but with modern computers I really don't mind waiting the one=
 or
>two seconds it takes to parse the whole code before execution.
></soapbox>

Agreed.

Pete

8. Re: Routine_ID Is No Doubt My Solution...

• Posted by euman at bellsouth.net Apr 13, 2003
• 434 views

{{{

Yeah, thats the problem with those Circular-List, always chasing their tails.

hehe Euman

10. Re: Routine_ID Is No Doubt My Solution...

• Posted by Derek Parnell <ddparnell at bigpond.com> Apr 14, 2003
• 449 views

On Sun, 13 Apr 2003 22:50:51 -0500, C. K. Lester <cklester at yahoo.com> 
wrote:

>
> On Sunday 13 April 2003 10:23 am, Derek wrote:
>>
>> ----- Original Message -----
>> From: "C. K. Lester" <cklester at yahoo.com>
>>
>> > I still have yet
>> > to find something lacking in EUPHORIA, or something I
>> > consider to be a detriment to programmers.
>>
>> Horses for Courses.
>
> What in all of creation does that mean? I could Google it, but it's close 
> to bedtime.

Sorry - I didn't realize this expression is not used in the U.S. It 
generally means that each situation is best suited to some solutions rather 
than others. In the context of my usage, I was trying to say your view of 
Euphoria, "I still have yet to find something lacking in EUPHORIA..." and 
mine, "I have to use workarounds" are obviously different but we are both 
still able to use it for the tasks we have chosen.

>> I have a host of coding paradigms that I enjoy using,
>> (because they increase *my* efficiency) that I have to use workarounds 
>> for
>> when coding in Euphoria. In other words, using Euphoria, I'm not as
>> efficient as I know I could be. I'm just lucky that that is still better
>> than using C/C++.
>
> Here's how I see it: you are as efficient as you can be in EUPHORIA. So 
> far, that's good enough.

I have a different set of expecations - just as valid as yours, of course.


-- 

cheers,
Derek Parnell

12. Re: Routine_ID Is No Doubt My Solution...

• Posted by gertie at visionsix.com Apr 15, 2003
• 440 views

On 15 Apr 2003, at 15:30, Derek Parnell wrote:

> 
> On Tue, 15 Apr 2003 00:13:28 -0300, <rforno at tutopia.com> wrote:
> 
> >
> > Derek:
> > I can assure you that "Horses for Courses" is neither used in Argentina, not
> > even in English-speaking circles;)
> 
> Must be an Australianism - ain't diversity a wonderful thing.

The only thing i can think of is the line from the Mr Ed tv show of the 50's "A 
horse is a horse, of course, of course, and no one can talk to a horse of 
course....", which could have been mangled to what you said.

Kat

14. Re: Routine_ID Is No Doubt My Solution...

• Posted by Derek Parnell <ddparnell at bigpond.com> Apr 16, 2003
• 460 views

On Wed, 16 Apr 2003 00:10:00 -0300, <rforno at tutopia.com> wrote:

[snip]
>>
>> > and I'd prefer passing all parameters as
>> > references, excepting constants and expressions.
>>
>> Now I can see why you want better tracing and debugging features - you
> need
>> them when passing by reference. Too many opportunitites for things to 
>> get
>> 'accidently' updated. 
> But Derek, now I'm not passing variables a references (not possible in
> current Euphoria), and I still think I need better tracing (this is so
> because I am not doing commercial programming, some special kind of CPU
> intensive programs).
> Moreover, now you have
> a = foo(b, c) and of course have 'a' updated.
> Is it so big the difference with:
> foo(a, b) where you can have 'a' and 'b' updated?
>>

The difference is that, using the current Euphoria functionality, the code 
reader (and thus the interpreter) can at this very point know if 'a' is 
being updated or not. When using pass-by-reference (PBR) the reader is 
*never* sure if the parameters being passed will also be updated, unless 
they also examine the code in the routine being called. By being sure at 
the time of the routine call, the interpreter can make some optimisations, 
and the code reader can focus on the immediately visible code rather than 
track any *potential* updating code that is not necessarily next to the 
code being read.

A further complication occurs with sequences. Currently we always know that 
the whole sequence is being replaced by a new one, but with a PBR scheme, 
we are never sure which elements may or may not be being updated by the 
called routine. This just adds uncertainty, which needs to have extra 
effort to resolve when inspecting code.

So in summary, there is nothing intrinsically wrong with PBR, its just that 
it increases the degree of difficulty in reading the code and increases the 
probability of mistakes being made. This is exactly the same effect with 
using GOTO. So my rule-of-thumb is that both PBR and GOTO should only be 
used if its the only way to gain the **NECESSARY** performance improvement 
for a specific algorithm or piece of code. The costs of maintaining code 
that uses these two techniques is larger than not using them, so this needs 
to be taken into consideration.

We need to take a look at what problems the PBR technique is trying to 
solve.

One of the main reasons for using PBR is to avoid the overheads of passing 
large 'stuctures' to routines and receiving large structures back again. 
So, an early recommendation for Euphoria was to introduce a simpler syntax 
for multiple return values. Something along the lines of ...

   $(a, b) = foo(a,b)
or

   $(s[Name], s[Telephone]) = UpdateCust(s)

and the special circumstance that current takes the form "x = func(x)" 
could be replaced by ...

   func( $x )

Another common use for PBR is in situation where the routine called only 
knows at runtime (rather than at the time the code was written) if the 
parameter needs updating or not, or which elements of a structure might 
need updating. Currently we usually perform the tests for updating outside 
of the called routine.

  if length(s[Addr]) = 0 then
      s[Addr] = NewAddress()
  else
      s[MailAddr] = NewAddress()
  end if

But in the interests of putting all the 'smarts' in one place, this test 
would be better placed inside the routine.

    function NewAddress(sequence s)
       . . . if length(s[Addr] = 0 then
           return {newaddr, s[MailAddr]}
       else
           return {s[Addr], newaddr}
       end if
    end function
    $(s[Addr], s[MailAddr]) = NewAddress(s)

And another PBR usage occurs when there are common data items shared by 
many routines, such as Stack or List structures.

   function Push(s, newitem)
     s = append(s, newitem)
     return s
   end function

   function Pop(s)
    object item
    if length(s) > 0 then
        item = s[length(s)]
        s = s[1..length(s)-1]
        return {item, s}
    else
        abend("Stack Empty")
    end if
   end function

Currently we code like this...

   ParameterStack = Push(ParameterStack, item)
   OperationStack = Push(OperationStack, op)

   x = Pop(ParameterStack)
   item = x[1]
   ParameterStack = x[2]

But with a syntax change we can get...

   Push($ParameterStack, item)
   Push($OperationStack, op)

   Pop($item, $ParameterStack)

With this syntax idea, we emulate PBR and still tell the reader exactly 
what we are doing. Note that PBR is not actually happening, its just that 
we are using a coding shorthand to assign returned sequence elements to 
multiple items UPON return.


-- 

cheers,
Derek Parnell

16. Re: Routine_ID Is No Doubt My Solution...

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> Apr 16, 2003
• 434 views

On Tue, 15 Apr 2003 15:30:21 +1000, Derek Parnell
<ddparnell at bigpond.com> wrote:

>> 4) Save the status of the program in order to continue execution =
later.
>
>Hmmm. Never really needed to do this.

Possibly badly worded. Resume the status of a debug session
definitely. I want to start the next debug session with result,
params, local var x etc showing their current values.
I'll not be the first dumb numbskull that needs more than one debug
session to solve a thorny problem & I freely admit that.

The debugger should allow a "permanent view" to be defined - not as it
stands overwrite randomly/sequentially those variables you are
interested in tracking with "fluff";  eg for i=3D1 to 10; you *know*
what i is, cause you're single-stepping the loop; when it blats the
current value of i over a value you are waiting to see go wrong, it's
a pain, 'cos you have to "?" it again to get it back on the screen.

Some kind of ini file, only read when the debug/trace window opens?
The debugger is smart enough to cope if I define some variable such as
"result" which is not in scope at the trap point & say "<undefined>"=20

The other one I'd vote for is viewing the *end* of a large sequence in
the permitted 80-char view. I know 2.4 allows you to see the whole
thing, but when you are single-stepping through, waiting for it to go
wrong...

Pete