1. RE: Routine_ID Is No Doubt My Solution...
> >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?
>
The function/procedure has to be "visible" to the routine_id() function
and therefore can't be above (in the code) those functions. So the
routine_id assignment has to occur below the function it refers to.
You could just pass both the name & the id to add_command:
procedure add_command( sequence newcommand, integer rid )
command_list = append( command_list , newcommand )
command_id = append( command_id, rid )
end procedure
function delete_all_cards()
cards = {}
return {1,""}
end function
add_command("delete_all_cards",routine_id("delete_all_cards"))
or just create a constant with the routine names and then loop through
them to get the ids. Less typing.
2. RE: Routine_ID Is No Doubt My Solution...
- Posted by rforno at tutopia.com
Apr 15, 2003
Derek:
I can assure you that "Horses for Courses" is neither used in Argentina, not
even in English-speaking circles;)
Regarding the subject of programming in different languages, I in a certain
way agree with Mr. C. K. Lester. I think that every programming language has
its pros and cons, and you have to adapt you programming style to each
language you program in. Particularly, I find Euphoria very manageable and
akin to my programming style.
I think the its weak spots lie in the trace and debugging facility, even its
being better than most other languages.
I will welcome facilities to:
1) See expressions, not only variables, during trace.
2) Show only variables (expressions) that one selects, and not automatically
selected ones.
3) Allow changing variable values, and perhaps executing routines while in
trace.
4) Save the status of the program in order to continue execution later.
In addition, I would like to be able to execute strings read or created
during program execution, and I'd prefer passing all parameters as
references, excepting constants and expressions.
But as it is today, Euphoria is a very, very useful language (at least for
the tasks I am using it for). I only had to resort to C for a large program,
CPU intensive, for speed reasons.
Regards.
----- Original Message -----
From: Derek Parnell <ddparnell at bigpond.com>
To: EUforum <EUforum at topica.com>
Sent: Monday, April 14, 2003 1:09 AM
Subject: Re: Routine_ID Is No Doubt My Solution...
>
> 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
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
3. RE: Routine_ID Is No Doubt My Solution...
- Posted by rforno at tutopia.com
Apr 16, 2003
Derek:
Please see answer about in the middle of the text...
----- Original Message -----
From: Derek Parnell <ddparnell at bigpond.com>
Subject: Re: Routine_ID Is No Doubt My Solution...
>
> 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.
>
> > Regarding the subject of programming in different languages, I in a
> > certain
> > way agree with Mr. C. K. Lester. I think that every programming language
> > has
> > its pros and cons, and you have to adapt you programming style to each
> > language you program in.
>
> Yes, every language (human and programming) has pros and cons. However, I
> refuse to believe that anything is "as good as at can get". Euphoria can
be
> better than the current 'cons'.
>
> > Particularly, I find Euphoria very manageable and
> > akin to my programming style.
>
> That's fine then.
>
> > I think the its weak spots lie in the trace and debugging facility, even
> > its being better than most other languages.
>
> Of course, if some other area were 'improved' there would be less need for
> tracing and debugging.
>
> > I will welcome facilities to:
> > 1) See expressions, not only variables, during trace.
>
> Yes please.
>
> > 2) Show only variables (expressions) that one selects, and not
> > automatically
> > selected ones.
>
> Yes please (as an option).
>
> > 3) Allow changing variable values, and perhaps executing routines while
> > in
> > trace.
>
> Yes please.
>
> > 4) Save the status of the program in order to continue execution later.
>
> Hmmm. Never really needed to do this.
>
> > In addition, I would like to be able to execute strings read or created
> > during program execution,
>
> This would require a complete rewrite of the RDS interpreter as its
> internal architecture prevents it doing this.
>
> > 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?
>
> > But as it is today, Euphoria is a very, very useful language (at least
> > for the tasks I am using it for).
>
> This is the meaning of 'horses for courses'. One uses Euphoria for the
> purposes it is best suited to, just like one uses the right sort of horse
> for the specific course to be raced over.
>
> > I only had to resort to C for a large program,
> > CPU intensive, for speed reasons.
>
> Yes, C is a lot closer to the metal; the next level down is machine
> language (assembler). I've heard it said that 'C' is really the PDP-11's
> high-level assembler.
>
> --
>
> cheers,
> Derek Parnell
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
4. RE: Routine_ID Is No Doubt My Solution...
- Posted by rforno at tutopia.com
Apr 17, 2003
----- Original Message -----
From: Pete Lomax <petelomax at blueyonder.co.uk>
Subject: Re: Routine_ID Is No Doubt My Solution...
On Tue, 15 Apr 2003 15:30:21 +1000, Derek Parnell
<ddparnell at bigpond.com> wrote:
<snip>
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=1 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>"
I think the solution is simpler than that, Pete. I already proposed to Rob
that the trace window should show only the variables you select, insted of
trace() selecting them. The typing effort would be very small: only a ? and
the variable name. And it would work with the current way of doing things
with only a minimum modification.
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...
I agree, Pete.
Pete
==^^===============================================================
This email was sent to: rforno at tutopia.com
TOPICA - Start your own email discussion group. FREE!
5. RE: Routine_ID Is No Doubt My Solution...
- Posted by rforno at tutopia.com
Apr 17, 2003
Derek:
I am afraid I don't completely understand what you are saying.
When you speak about a "reader", are you referring to a human reader?
When you speak about code optimizations, are you referring to:
a = b (being b a sequence)
not really making a copy until some element of a or b is changed, or some
other optimization?
----- Original Message -----
From: Derek Parnell <ddparnell at bigpond.com>
Subject: Re: Routine_ID Is No Doubt My Solution...
>
> 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
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
