Re: Local variables controversial?

bobjaffray@xxxxxxxx <bobjaffray@xxxxxxxx> wrote:


>> 4 of 6
>>Date: Sun 24 Jul 2005 18:16
>>From: Andrew Haley

>>bobjaffray@xxxxxxxx <bobjaffray@xxxxxxxx> wrote:

>>> Local variables controversial?

>>>>Date: Fri 22 Jul 2005 16:14
>>>>From: Andrew Haley

>>Forth is designed so that calling a word has a very low overhead.
>>That's the idea: provide a langauge with a tiny subroutine overhead
>>in order to encourage programmers to use subroutines.

> bj: Right. But high-level Forth has considerably more
> overhead than inlined subroutines.

I guess you're assuming that the overhead of inlining a subroutine is
zero. That may be so, but inlining is an implementation technique that
Forth can use too, so it's irrelevant to this particular point.

> Yes, compared to other languages calling a subroutine has
> considerably less overhead.

Right. This is the *essential thing* about learning Forth: don't worry
about calling words. Factor, factor, factor.

>>No, no, that's not it _at all_.

> bj: Well it is sometimes, though perhaps not all that often
> the way Forth is usually written.

>>Forth is supposed to be composed of a bunch of small words, each of
>>which expresses a single idea.

> bj: That is _supposed_ to be it. But in F83 I find "single ideas"
> often broken down into fragments of ideas. (I am still open to
> suggestions about a modern public domain ANS Forth.)

Perhaps: I have no real idea of the codebase you're looking at.

>>That doesn't make it wordy: usually quite the reverse.

> bj: If you are referring to the artificial names often given in
> other languages I agree. However, because of the small size of words
> in Forth compared to other languages there inherently is a larger
> number of names.

Not absolutely, because you don't have lots of local variable names.
Also, and this is harder to quantify, Forth style tends not to produce
a blizzard of names. But yes, you do have a lot of words.

> (Of course, right choice of names for words helps to make Forth more
> readable, and _vice versa_ - poor choice makes can make it almost
> impossible.

>>> It often does not really improve the structure of the code, but is
>>> done to work-around the limitations of traditional code
>>> constructs.

>>I strongly disagree.

> bj: I have in mind the words EXIT and LEAVE in F83, which I take it
> are pretty much standard words. I always find myself wanting to
> EXIT to the end of a looping construct (other than DO ... LOOP)
> rather than exiting a word.

Well, you'd have to explain further, but if you really do want to
leave a loop in the middle you can always use WHILE. But complex
looping structures are an ANS thing that you don't have in F83.

> bj: Maybe you can suggest a practical way for me to approach my mind
> block.

>>It is sometimes possible to factor too far, when a single idea is
>>split into parts, but that is far less common than overlong
>>definitions.

> bj: I don't see overlong definitions in F83 source.

Glad to hear it. It's been a long while since I looked at F83, but
from what I remember it was pretty clean.

Andrew.
.

Relevant Pages

  • Managed vs Unmanaged Bare Bones Performance Test
    ... just the basic stuff inside the CLR i.e. function calling ... Here are the results (for release mode running from console, ... //record the overhead for calling the performance counter API ...
    (microsoft.public.dotnet.framework.clr)
  • Managed vs Unmanaged Bare Bones Performance Test
    ... just the basic stuff inside the CLR i.e. function calling ... Here are the results (for release mode running from console, ... //record the overhead for calling the performance counter API ...
    (microsoft.public.dotnet.framework)
  • Re: Postback from javascript
    ... overhead of calling the iterator on the 'forms' object (although its not ... >> hidden text fields are used to notify the processing page what control ... >> accomplish what you are trying to accomplish with minimal effort. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: sendfile(2) SF_NOPUSH flag proposal
    ... >> 2) The new feature provides significant performance benefit. ... >I think the calling setsockoptsyscall has huge overhead ... is negligible compared to the total overhead of accept, ...
    (freebsd-arch)
  • Re: how to write a reference clock driver
    ... Juergen Kosel writes: ... And I also don't understand what you mean by "computing time is a concern". ... Is the overhead of a subroutine call that significant in your application? ...
    (comp.protocols.time.ntp)