Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #54673 > unrolled thread

Really?

Back to article view | Back to comp.lang.forth

Contents

  Really? Mark Wills <markwills1970@gmail.com> - 2017-02-06 06:46 -0800
    Re: Really? foxaudioresearch@gmail.com - 2017-02-06 07:20 -0800
    Re: Really? polymorph self <jackvanc3@gmail.com> - 2017-02-06 08:58 -0800
    Re: Really? rickman <gnuarm@gmail.com> - 2017-02-06 13:06 -0500
    Re: Really? hughaguilar96@gmail.com - 2017-02-06 11:25 -0800
    Re: Really? "HAA" <someone@microsoft.com> - 2017-02-07 11:45 +1100
    Re: Really? "Elizabeth D. Rather" <erather@forth.com> - 2017-02-06 15:38 -1000
      Re: Really? hughaguilar96@gmail.com - 2017-02-07 09:50 -0800
    Re: Really? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-02-06 23:39 -0500
      Re: Really? Mark Wills <markwills1970@gmail.com> - 2017-02-07 08:04 -0800
      Re: Really? "HAA" <someone@microsoft.com> - 2017-02-08 11:04 +1100
        Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-07 23:42 -0800
          Re: Really? "HAA" <someone@microsoft.com> - 2017-02-08 20:12 +1100
            Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-08 02:44 -0800
            Re: Really? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-08 17:48 +0000
              Re: Really? Alex <alex@rivadpm.com> - 2017-02-08 18:43 +0000
                Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-08 15:24 -0800
              Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-08 16:26 -0800
      Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-07 22:45 -0800
        Re: Really? hughaguilar96@gmail.com - 2017-02-07 22:50 -0800
      Re: Really? clozaga@gmail.com - 2017-02-08 21:03 -0800
        Re: Really? clozaga@gmail.com - 2017-02-08 21:04 -0800
        Re: Really? hughaguilar96@gmail.com - 2017-02-11 20:01 -0800
          Re: Really? Alex <alex@rivadpm.com> - 2017-02-12 16:26 +0000
            Re: Really? hughaguilar96@gmail.com - 2017-02-12 16:52 -0800
              Re: Really? Alex <alex@rivadpm.com> - 2017-02-13 09:49 +0000
                Re: Really? minforth@arcor.de - 2017-02-13 07:03 -0800
                Re: Really? hughaguilar96@gmail.com - 2017-02-13 13:41 -0800
                  Re: Really? Alex <alex@rivadpm.com> - 2017-02-13 22:32 +0000
                    Re: Really? hughaguilar96@gmail.com - 2017-02-15 11:42 -0800
                      Re: Really? Alex <alex@rivadpm.com> - 2017-02-15 20:41 +0000
                        Re: Really? hughaguilar96@gmail.com - 2017-02-17 09:42 -0800
                          Re: Really? Alex <alex@rivadpm.com> - 2017-02-17 22:22 +0000
            Re: Really? "Elizabeth D. Rather" <erather@forth.com> - 2017-02-12 19:24 -1000
              Re: Really? Alex <alex@rivadpm.com> - 2017-02-13 08:49 +0000
    Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-07 11:01 +0000
      Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-07 03:06 -0800
        Re: Really? hughaguilar96@gmail.com - 2017-02-07 09:35 -0800
        Re: Really? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-07 17:35 +0000
          Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-07 23:24 -0800
            Re: Really? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-09 08:57 +0000
              Re: Really? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-09 13:24 +0100
                Re: Really? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-11 15:32 +0000
        Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-07 20:42 +0000
          Re: Really? "Elizabeth D. Rather" <erather@forth.com> - 2017-02-07 13:58 -1000
            Re: Really? hughaguilar96@gmail.com - 2017-02-07 21:51 -0800
              Re: Really? rickman <gnuarm@gmail.com> - 2017-02-08 01:47 -0500
                Re: Really? hughaguilar96@gmail.com - 2017-02-07 22:52 -0800
                  Re: Really? rickman <gnuarm@gmail.com> - 2017-02-08 03:34 -0500
                    Re: Really? Alex <alex@rivadpm.com> - 2017-02-08 13:43 +0000
                      Re: Really? "Elizabeth D. Rather" <erather@forth.com> - 2017-02-08 15:39 -1000
                        Re: Really? hughaguilar96@gmail.com - 2017-02-08 22:39 -0800
                          Re: Really? Alex <alex@rivadpm.com> - 2017-02-09 08:56 +0000
                            Re: Really? hughaguilar96@gmail.com - 2017-02-09 14:36 -0800
                              Re: Really? Alex <alex@rivadpm.com> - 2017-02-10 08:33 +0000
                        Re: Really? Alex <alex@rivadpm.com> - 2017-02-09 09:03 +0000
                          Re: Really? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-09 10:51 +0100
                            Re: Really? john <anon@example.com> - 2017-02-09 11:54 +0000
                              Re: Really? "Elizabeth D. Rather" <erather@forth.com> - 2017-02-09 09:30 -1000
                            Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-09 14:14 +0000
                              Re: Really? Alex <alex@rivadpm.com> - 2017-02-09 14:37 +0000
                                Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-09 15:24 +0000
                                  Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-09 12:01 -0800
                                    Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-10 01:09 +0000
                                      Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-09 18:19 -0800
                                        Re: Really? "Elizabeth D. Rather" <erather@forth.com> - 2017-02-09 16:30 -1000
                                      Re: Really? hughaguilar96@gmail.com - 2017-02-09 19:16 -0800
                                        Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-10 16:29 +0000
                                          OT: [ was re: Really?] Foreign aid Alex <alex@rivadpm.com> - 2017-02-10 17:30 +0000
                                            Re: OT: [ was re: Really?] Foreign aid Cecil Bayona <cbayona@cbayona.com> - 2017-02-10 11:46 -0600
                                              Re: OT: [ was re: Really?] Foreign aid Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-02-10 11:54 -0600
                                                Re: OT: [ was re: Really?] Foreign aid Alex <alex@rivadpm.com> - 2017-02-10 18:05 +0000
                                              Re: OT: [ was re: Really?] Foreign aid Alex <alex@rivadpm.com> - 2017-02-10 17:55 +0000
                                                Re: OT: [ was re: Really?] Foreign aid Cecil Bayona <cbayona@cbayona.com> - 2017-02-10 12:04 -0600
                                                  Re: OT: [ was re: Really?] Foreign aid Alex <alex@rivadpm.com> - 2017-02-10 18:07 +0000
                                                    Re: OT: [ was re: Really?] Foreign aid Cecil Bayona <cbayona@cbayona.com> - 2017-02-10 12:57 -0600
                                                      Re: OT: [ was re: Really?] Foreign aid Alex <alex@rivadpm.com> - 2017-02-10 19:26 +0000
                                                        Re: OT: [ was re: Really?] Foreign aid Cecil Bayona <cbayona@cbayona.com> - 2017-02-10 14:04 -0600
                                                          Re: OT: [ was re: Really?] Foreign aid Alex <alex@rivadpm.com> - 2017-02-11 09:35 +0000
                                          Re: Really? hughaguilar96@gmail.com - 2017-02-10 16:33 -0800
                                      Static type checking (was: Really?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-10 11:07 +0000
                                Re: Really? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-11 15:16 +0000
                                  Re: Really? Cecil Bayona <cbayona@cbayona.com> - 2017-02-11 10:20 -0600
                                  Re: Really? hughaguilar96@gmail.com - 2017-02-11 19:02 -0800
                              Re: Really? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-10 17:31 +0100
                    Re: Really? "Elizabeth D. Rather" <erather@forth.com> - 2017-02-08 15:34 -1000
                Re: Really? "Elizabeth D. Rather" <erather@forth.com> - 2017-02-07 21:15 -1000
                Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-07 23:46 -0800
          Re: Really? hughaguilar96@gmail.com - 2017-02-07 22:47 -0800
            Re: Really? Ron Aaron <rambamist@gmail.com> - 2017-02-08 08:52 +0200
      Re: Really? rickman <gnuarm@gmail.com> - 2017-02-07 06:29 -0500
        Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-07 20:47 +0000
          Re: Really? rickman <gnuarm@gmail.com> - 2017-02-07 16:23 -0500
            Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-08 09:47 +0000
              Re: Really? rickman <gnuarm@gmail.com> - 2017-02-08 05:13 -0500
                Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-08 11:23 +0000
      Re: Really? Cecil Bayona <cbayona@cbayona.com> - 2017-02-07 09:49 -0600
    Really? Mark Wills <markwills1970@gmail.com> - 2017-02-09 00:30 -0800
      Re: Really? "HAA" <someone@microsoft.com> - 2017-02-10 10:32 +1100
        Re: Really? hughaguilar96@gmail.com - 2017-02-09 17:22 -0800

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#54745

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>different development style than Forth or C, where you have to be
>>>careful to not give back hard-earned gains.
>> If you run into that problem, there probably is something wrong with
>> your basic architecture or your code, and the "gains" are actually a
>> burden.
>
>What I've seen with large C programs is that bugs are elusive--they lurk
>around for a long time before even being noticed, they they're hunted
>for a while before any pattern emerges, and then they're often quite
>hard to diagnose and fix.  So old C programs are valuable because
>they're "seasoned": much effort has been spent finding and chasing bugs
>over the years, that has to be re-done if you toss out the code.
>
>By comparison, the mantra with fancy typed languages like Ocaml is that
>once you fix all the compile-time type errors the code tends to work.
>With latently typed languages like Python, you avoid every sort of
>compile-time error, and in return you get a lot of early runtime errors
>that give exact stack traces and are easy to debug.  You don't invest
>nearly the debugging time as you do in C so the program doesn't gain as
>much value as it ages.

That's totally contrary to my perception (except that, yes, the static
typechecking believers have this mantra; that does not mean that it is
true).  The kind of bugs that compile-time type checking catches or
that run-time type checking catches tend to be the easy ones.  If you
catch such a bug after a long time (because you did not test for it,
and apparently the users did not exercise that case, either), it is
still an easy bug.  And aging does not make code more valuable.

Of course, if you have invested quite a bit of effort into the code,
that is one way to determine its value; a related one is the effort
that replacing it would cost.  Another is the value that the users of
the code (including programmers calling it) derive from it; If the
code restricts the usage, and causes complexity in the callers, it's
actually a burden.

>I had a significant change in perspective when I got involved in a
>Python project dealing with a large (terabytes) data corpus.  The motto
>there was basically that data is gold but code is crap.  I'd been used
>to hearing it the other way around.  We were constantly writing
>throwaway programs to munch the data one way or another, but replacing
>the data (collected over decades) would have been impossible.

What is valuable depends on the project.  And in a project where you
have to do lots of one-off data analyses, you are likely to use a
language that makes that easy, rather than writing assembly-language
programs with fine-tuning for maximum performance, expecially if your
programs are disk-bound anyway.

>> Concerning run-time checks, if you think that helps, put them into your
>> code.
>
>The trouble is that errors happen in exactly the places you don't expect
>them to, or else they wouldn't be errors ;).  Yes some asserts here and
>there are good, but pervasive checking catches a lot of stuff that could
>go unnoticed.  Think of all the subscript errors in Fortran and C
>programs over the years.  

The errors that run-time checking in languages like Python checks for
are errors that the Python implementors expected, otherwise they would
not have put them in; and if the checks catch something, it's obvious
that errors can occur in places where one expects errors.*

Anyway, if you want subscript checking, then go ahead, implement it,
and use it.  If you want to check that you are accessing the right
structure, put a magic number in the structure, and check it in the
field words.

*) Actually, I guess that most of the hard errors occur in places
where one expects them; this reminds me of an anecdote by Richard
Feinmann, where he inspected an Uranium enrichment facility.  They
showed him the plans, he asked about a specific part, and they
realized that there was an error there, and viewed him as a genius for
seeing that error right away, while he actually described it as just a
random inquiry.  My guess is that he asked about a particularly
complex part of the plan, and it's much more likely that there is an
error there than in the easy parts.

>> If you are used to garbage collection, you may find that hard, and
>> requiring you to think outside the box of your usual practices.
>> Programming like in a GC language and trying to put in FREEs where
>> necessary will not lead to good results.
>
>For lots of purposes, single-ownership pointers (std::unique_ptr) in C++
>can take the place of GC with almost no overhead and not too much
>programmer effort.  But they rely on the C++'s so-called RAII paradigm,
>where a value's type signature can tell the compiler to call
>user-supplied code when the value goes out of scope, and also operator
>overloading to track the movement of values from one place to another.
>It's much easier than manual alloc/free and I don't think it can be done
>in Forth.

Freeing memory (or other reseources) on leaving the definition where
it was ALLOCATEd (which is the limitation of RAII in C++) is certainly
possible in Forth:

: alloc-exec ( ... u xt -- ... )
  \ allocate u memory at addr and call xt ( ... addr -- ... ); 
  \ on leaving xt, free the memory.
  >r allocate throw dup {: addr :} r> catch addr free throw throw ; 

Usage:

  500 [: ( addr -- ) ... do some computation with the buffer ... ;] alloc-exec

>But, the Boehm GC works pretty well in C and sounds ok for
>Forth (you'd know better than me about that).

The funny thing is that, even though I wrote a conservative garbage
collector for Forth, I have not really used it; in those cases where
it would have been compatible with other requirements, it did not seem
necessary.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#54749

In article <2017Feb9.095708@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
<SNIP>
>
>That's totally contrary to my perception (except that, yes, the static
>typechecking believers have this mantra; that does not mean that it is
>true).  The kind of bugs that compile-time type checking catches or
>that run-time type checking catches tend to be the easy ones.  If you
>catch such a bug after a long time (because you did not test for it,
>and apparently the users did not exercise that case, either), it is
>still an easy bug.  And aging does not make code more valuable.

Of course it does. Industrial and corporate IT-users know that
very well. They are extremely reluctant to abandon working
systems. It is not so much that the bugs are out, but the bugs
are known, and what is more important the larger misconceptions
are caught, like the idea that a train has at least three carriages,
a locomotive on each side and the payload. (An example from
my practice with incidious consequences.)

Then there is statistics. If a large system has run for 365
days without maior faults, The chance is about less than one
in 365 that it will fail this day.

>- anton
>--
>M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
>comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
>     New standard: http://www.forth200x.org/forth200x.html
>   EuroForth 2016: http://www.euroforth.org/ef16/
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#54792

albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <2017Feb9.095708@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
><SNIP>
>>
>>That's totally contrary to my perception (except that, yes, the static
>>typechecking believers have this mantra; that does not mean that it is
>>true).  The kind of bugs that compile-time type checking catches or
>>that run-time type checking catches tend to be the easy ones.  If you
>>catch such a bug after a long time (because you did not test for it,
>>and apparently the users did not exercise that case, either), it is
>>still an easy bug.  And aging does not make code more valuable.
>
>Of course it does. Industrial and corporate IT-users know that
>very well. They are extremely reluctant to abandon working
>systems. It is not so much that the bugs are out, but the bugs
>are known, and what is more important the larger misconceptions
>are caught, like the idea that a train has at least three carriages,
>a locomotive on each side and the payload. (An example from
>my practice with incidious consequences.)
>
>Then there is statistics. If a large system has run for 365
>days without maior faults, The chance is about less than one
>in 365 that it will fail this day.

The context of the discussion was *not* the value of the code to end
users who only use the code, and can only assess it through use, and
cannot improve it themselves in any way.  In any case, the value
according to the end-user metric you describe is completely
independent of the programming language, because the programming
language does not come into play here, and the end users don't deal
with the source code anyway.

The context of the discussion was the value of the code to the
developers and their organization.

There is one aspect where the value rises with age: It becomes more
expensive over time to rewrite the code, because the knowledge about
the code vanishes from memory (or the people with the memory leave the
organization), so that knowledge has to be reacquired from the
documentation, from the source code, or (if that has been lost)
through various reverse engineering techniques.  That, too is
independent of the programming language, except that languages where
programs are distributed in source are immune to the "lost source
code" problem. OTOH, the requirements may change, reducing the value
of the existing code.

For a case where bugs are found after exercising the code a lot, I
read something along the lines of that you need to process 10 million
lines of code to find all bugs in a register allocator.  These kinds
of bugs are not caught by sophisticated static type checkers (I talked
to (IIRC) Lal George, the guy who did the register allocator for
SML/NJ, and when I talked to him he said he really had big problems
debugging it), and certainly not by dynamic type checking (which tends
to be much less sophisticated), so the value added by fixing these
kinds of bugs is added "late" in any language (of course, if you do
extensive testing from the start, the "late" will be earlier than if
not).

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#54691

On Tue, 07 Feb 2017 03:06:46 -0800, Paul Rubin
<no.email@nospam.invalid> wrote:

>stephen@mpeforth.com (Stephen Pelc) writes:
>> Success or failure of projects is mostly down to project management.
>
>Got any advice about how to manage Forth projects?

1) Hire good programmers (applies to any language),
2) Apply the surgical team aproach from the Mythical Man Month.
3) Be prepared to be brutal - do not waste time getting rid
   of bad people. You may have to get rid of a guru, they tend
   to be destructive in teams.
4) Keep the team small.

None of this is specific to Forth, it's just software.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#54697

On 2/7/17 10:42 AM, Stephen Pelc wrote:
> On Tue, 07 Feb 2017 03:06:46 -0800, Paul Rubin
> <no.email@nospam.invalid> wrote:
>
>> stephen@mpeforth.com (Stephen Pelc) writes:
>>> Success or failure of projects is mostly down to project management.
>>
>> Got any advice about how to manage Forth projects?
>
> 1) Hire good programmers (applies to any language),
> 2) Apply the surgical team aproach from the Mythical Man Month.
> 3) Be prepared to be brutal - do not waste time getting rid
>    of bad people. You may have to get rid of a guru, they tend
>    to be destructive in teams.
> 4) Keep the team small.
>
> None of this is specific to Forth, it's just software.

I agree with all of that, but can add few observations peculiar to Forth 
projects in my experience.

* A key factor in Forth projects is that development will go very fast, 
so it's possible to get too far down a wrong path if there aren't some 
clear specifications and priorities.

* It's important for the team members to agree on common coding styles. 
This makes it much easier for them to read each others' code, and feel 
comfortable about sharing code. This agreement should be codified at the 
beginning of the project.

* The members of the small team need very specific task descriptions, 
and they need to agree on the interaction between their tasks.

* It's important to facilitate communication between team members. If 
common needs arise, for example, they should be able to agree on a 
common solution, rather than separate incompatible approaches. Back in 
the day, it was effective to get everyone in the same room. Nowadays 
it's possible to work on a shared code base in the cloud.

Cheers,
Elizabeth


-- 
Elizabeth R. Conklin
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA  90045
USA

[toc] | [prev] | [next] | [standalone]

#54700

This is what I said:

On Tuesday, February 7, 2017 at 10:35:16 AM UTC-7, hughag...@gmail.com wrote:
> The way that this worked, was that the team members had very distinct responsibilities. 
> ...
> The important point is that everybody stays out of each other's turf --- this way, instead of one big project developed by a team, there are three small projects each developed by a single person --- all three parts have to work together, of course, so there has to be good communication.

This is what Elizabeth Rather said:

On Tuesday, February 7, 2017 at 4:58:49 PM UTC-7, Elizabeth D. Rather wrote:
> * It's important for the team members to agree on common coding styles. 
> This makes it much easier for them to read each others' code, and feel 
> comfortable about sharing code. This agreement should be codified at the 
> beginning of the project.

Why are the team members reading each others' code? Why are they sharing code?

AFAIK, when I wrote MFX nobody at Testra read my code. If they did, they never commented on it to me. It was really all about the code doing what it was supposed to do --- I don't think anybody cared about the internal workings.

Moving on, here is a quote from Elizabeth Rather:
------------------------------------------------------------------------------------
Truly, I don't see the point of all this paranoia about reentrancy, particularly in systems without a multitasker. VARIABLE was *designed* for things that would be used in multiple definitions. I remember the horror of (*gasp*) global variables back in the 1960's in Fortran. But, frankly, in 30+ years of programming in Forth I never found them a problem. I think this is all about mythical dragons.
------------------------------------------------------------------------------------

Maybe the Valdocs team got bit by a mythical dragon! If Elizabeth Rather taught them Forth, then she most certainly taught them that if any string needed to be held for any period of time, then PAD was where it should be stored. What could go wrong?

Here is another Elizabeth Rather quote:
------------------------------------------------------------------------------------
People are much too phobic about [global] variables. The cry, "They aren't re-entrant" simply means you have to look at the whole application and how it is organized.
------------------------------------------------------------------------------------

The idea that you "simply ... have to look at the whole application" works well in Elizabeth Rather's novice class because the "program" is less than 20 lines long and consists of maybe 3 or 4 functions --- it is easy to look at the whole application and make sure that there are no clashes in the commonly used global variables. 

Looking at the whole application is going to be difficult when there is 16MB of source-code --- the programmers need to understand the concept of re-entrancy --- they can't pass data between functions in global variables.

[toc] | [prev] | [next] | [standalone]

#54703

On 2/8/2017 12:51 AM, hughaguilar96@gmail.com wrote:
> This is what I said:
>
> On Tuesday, February 7, 2017 at 10:35:16 AM UTC-7, hughag...@gmail.com wrote:
>> The way that this worked, was that the team members had very distinct responsibilities.
>> ...
>> The important point is that everybody stays out of each other's turf --- this way, instead of one big project developed by a team, there are three small projects each developed by a single person --- all three parts have to work together, of course, so there has to be good communication.
>
> This is what Elizabeth Rather said:
>
> On Tuesday, February 7, 2017 at 4:58:49 PM UTC-7, Elizabeth D. Rather wrote:
>> * It's important for the team members to agree on common coding styles.
>> This makes it much easier for them to read each others' code, and feel
>> comfortable about sharing code. This agreement should be codified at the
>> beginning of the project.
>
> Why are the team members reading each others' code? Why are they sharing code?
>
> AFAIK, when I wrote MFX nobody at Testra read my code. If they did, they never commented on it to me. It was really all about the code doing what it was supposed to do --- I don't think anybody cared about the internal workings.
>
> Moving on, here is a quote from Elizabeth Rather:
> ------------------------------------------------------------------------------------
> Truly, I don't see the point of all this paranoia about reentrancy, particularly in systems without a multitasker. VARIABLE was *designed* for things that would be used in multiple definitions. I remember the horror of (*gasp*) global variables back in the 1960's in Fortran. But, frankly, in 30+ years of programming in Forth I never found them a problem. I think this is all about mythical dragons.
> ------------------------------------------------------------------------------------
>
> Maybe the Valdocs team got bit by a mythical dragon! If Elizabeth Rather taught them Forth, then she most certainly taught them that if any string needed to be held for any period of time, then PAD was where it should be stored. What could go wrong?
>
> Here is another Elizabeth Rather quote:
> ------------------------------------------------------------------------------------
> People are much too phobic about [global] variables. The cry, "They aren't re-entrant" simply means you have to look at the whole application and how it is organized.
> ------------------------------------------------------------------------------------
>
> The idea that you "simply ... have to look at the whole application" works well in Elizabeth Rather's novice class because the "program" is less than 20 lines long and consists of maybe 3 or 4 functions --- it is easy to look at the whole application and make sure that there are no clashes in the commonly used global variables.
>
> Looking at the whole application is going to be difficult when there is 16MB of source-code --- the programmers need to understand the concept of re-entrancy --- they can't pass data between functions in global variables.

You are aware that re-entrancy is only an issue with multitasking, 
right?  Was this OS multitasking?

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#54705

On Tuesday, February 7, 2017 at 11:47:26 PM UTC-7, rickman wrote:
> On 2/8/2017 12:51 AM, hughaguilar96@gmail.com wrote:
> > This is what I said:
> >
> > On Tuesday, February 7, 2017 at 10:35:16 AM UTC-7, hughag...@gmail.com wrote:
> >> The way that this worked, was that the team members had very distinct responsibilities.
> >> ...
> >> The important point is that everybody stays out of each other's turf --- this way, instead of one big project developed by a team, there are three small projects each developed by a single person --- all three parts have to work together, of course, so there has to be good communication.
> >
> > This is what Elizabeth Rather said:
> >
> > On Tuesday, February 7, 2017 at 4:58:49 PM UTC-7, Elizabeth D. Rather wrote:
> >> * It's important for the team members to agree on common coding styles.
> >> This makes it much easier for them to read each others' code, and feel
> >> comfortable about sharing code. This agreement should be codified at the
> >> beginning of the project.
> >
> > Why are the team members reading each others' code? Why are they sharing code?
> >
> > AFAIK, when I wrote MFX nobody at Testra read my code. If they did, they never commented on it to me. It was really all about the code doing what it was supposed to do --- I don't think anybody cared about the internal workings.
> >
> > Moving on, here is a quote from Elizabeth Rather:
> > ------------------------------------------------------------------------------------
> > Truly, I don't see the point of all this paranoia about reentrancy, particularly in systems without a multitasker. VARIABLE was *designed* for things that would be used in multiple definitions. I remember the horror of (*gasp*) global variables back in the 1960's in Fortran. But, frankly, in 30+ years of programming in Forth I never found them a problem. I think this is all about mythical dragons.
> > ------------------------------------------------------------------------------------
> >
> > Maybe the Valdocs team got bit by a mythical dragon! If Elizabeth Rather taught them Forth, then she most certainly taught them that if any string needed to be held for any period of time, then PAD was where it should be stored. What could go wrong?
> >
> > Here is another Elizabeth Rather quote:
> > ------------------------------------------------------------------------------------
> > People are much too phobic about [global] variables. The cry, "They aren't re-entrant" simply means you have to look at the whole application and how it is organized.
> > ------------------------------------------------------------------------------------
> >
> > The idea that you "simply ... have to look at the whole application" works well in Elizabeth Rather's novice class because the "program" is less than 20 lines long and consists of maybe 3 or 4 functions --- it is easy to look at the whole application and make sure that there are no clashes in the commonly used global variables.
> >
> > Looking at the whole application is going to be difficult when there is 16MB of source-code --- the programmers need to understand the concept of re-entrancy --- they can't pass data between functions in global variables.
 
> You are aware that re-entrancy is only an issue with multitasking, 
> right?  Was this OS multitasking?

Re-entrancy is not just an issue with multi-tasking.

If a function uses PAD internally and calls another function that uses PAD internally, then chaos will result.

This should be obvious to anybody!

[toc] | [prev] | [next] | [standalone]

#54711

On 2/8/2017 1:52 AM, hughaguilar96@gmail.com wrote:
> On Tuesday, February 7, 2017 at 11:47:26 PM UTC-7, rickman wrote:
>> On 2/8/2017 12:51 AM, hughaguilar96@gmail.com wrote:
>>> This is what I said:
>>>
>>> On Tuesday, February 7, 2017 at 10:35:16 AM UTC-7, hughag...@gmail.com wrote:
>>>> The way that this worked, was that the team members had very distinct responsibilities.
>>>> ...
>>>> The important point is that everybody stays out of each other's turf --- this way, instead of one big project developed by a team, there are three small projects each developed by a single person --- all three parts have to work together, of course, so there has to be good communication.
>>>
>>> This is what Elizabeth Rather said:
>>>
>>> On Tuesday, February 7, 2017 at 4:58:49 PM UTC-7, Elizabeth D. Rather wrote:
>>>> * It's important for the team members to agree on common coding styles.
>>>> This makes it much easier for them to read each others' code, and feel
>>>> comfortable about sharing code. This agreement should be codified at the
>>>> beginning of the project.
>>>
>>> Why are the team members reading each others' code? Why are they sharing code?
>>>
>>> AFAIK, when I wrote MFX nobody at Testra read my code. If they did, they never commented on it to me. It was really all about the code doing what it was supposed to do --- I don't think anybody cared about the internal workings.
>>>
>>> Moving on, here is a quote from Elizabeth Rather:
>>> ------------------------------------------------------------------------------------
>>> Truly, I don't see the point of all this paranoia about reentrancy, particularly in systems without a multitasker. VARIABLE was *designed* for things that would be used in multiple definitions. I remember the horror of (*gasp*) global variables back in the 1960's in Fortran. But, frankly, in 30+ years of programming in Forth I never found them a problem. I think this is all about mythical dragons.
>>> ------------------------------------------------------------------------------------
>>>
>>> Maybe the Valdocs team got bit by a mythical dragon! If Elizabeth Rather taught them Forth, then she most certainly taught them that if any string needed to be held for any period of time, then PAD was where it should be stored. What could go wrong?
>>>
>>> Here is another Elizabeth Rather quote:
>>> ------------------------------------------------------------------------------------
>>> People are much too phobic about [global] variables. The cry, "They aren't re-entrant" simply means you have to look at the whole application and how it is organized.
>>> ------------------------------------------------------------------------------------
>>>
>>> The idea that you "simply ... have to look at the whole application" works well in Elizabeth Rather's novice class because the "program" is less than 20 lines long and consists of maybe 3 or 4 functions --- it is easy to look at the whole application and make sure that there are no clashes in the commonly used global variables.
>>>
>>> Looking at the whole application is going to be difficult when there is 16MB of source-code --- the programmers need to understand the concept of re-entrancy --- they can't pass data between functions in global variables.
>
>> You are aware that re-entrancy is only an issue with multitasking,
>> right?  Was this OS multitasking?
>
> Re-entrancy is not just an issue with multi-tasking.
>
> If a function uses PAD internally and calls another function that uses PAD internally, then chaos will result.
>
> This should be obvious to anybody!

I don't know I've ever seen this referred to as reentrancy.  Looking on 
the web it's hard to find authoritative sources about reentrancy... but 
here is wikipedia, not that I consider wikipedia to necessarily be 
authoritative.

********************************
In computing, a computer program or subroutine is called reentrant if it 
can be interrupted in the middle of its execution, and then be safely 
called again ("re-entered") before its previous invocations complete 
execution. The interruption could be caused by an internal action such 
as a jump or call, or by an external action such as a hardware interrupt 
or signal. Once the reentered invocation completes, the previous 
invocations will resume correct execution.
********************************

So they do allow for the case of a routine calling another and ending up 
calling itself.  But what you describe is one routine calling another 
that shares a common data structure.  That's not technically reentrancy. 
  Still, I suppose I get your point.  Recursion is a form of reentrancy. 
  But that simply means you need to be aware when routines can be called 
recursively which is very infrequent.  Otherwise, you simply have to be 
aware when you are sharing data structures.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#54720

On 2/8/2017 08:34, rickman wrote:
>>>> Looking at the whole application is going to be difficult when there
>>>> is 16MB of source-code --- the programmers need to understand the
>>>> concept of re-entrancy --- they can't pass data between functions in
>>>> global variables.
>>
>>> You are aware that re-entrancy is only an issue with multitasking,
>>> right?  Was this OS multitasking?
>>
>> Re-entrancy is not just an issue with multi-tasking.
>>
>> If a function uses PAD internally and calls another function that uses
>> PAD internally, then chaos will result.
>>
>> This should be obvious to anybody!

Function A setting PAD and calling B that sets PAD is a simple case of 
the side effect of using global variables, specifically when they are 
modified. (No-one objects to constants as globals, because they are only 
ever read and not set.)

For this kind of problem, only rewriting the code will fix it, but it 
definitely does not need to be reentrant.

>
> I don't know I've ever seen this referred to as reentrancy.  Looking on
> the web it's hard to find authoritative sources about reentrancy... but
> here is wikipedia, not that I consider wikipedia to necessarily be
> authoritative.
>
> ********************************
> In computing, a computer program or subroutine is called reentrant if it
> can be interrupted in the middle of its execution, and then be safely
> called again ("re-entered") before its previous invocations complete
> execution. The interruption could be caused by an internal action such
> as a jump or call, or by an external action such as a hardware interrupt
> or signal. Once the reentered invocation completes, the previous
> invocations will resume correct execution.
> ********************************

It's not very good.

>
> So they do allow for the case of a routine calling another and ending up
> calling itself.  But what you describe is one routine calling another
> that shares a common data structure.  That's not technically reentrancy.
>  Still, I suppose I get your point.  Recursion is a form of reentrancy.
>  But that simply means you need to be aware when routines can be called
> recursively which is very infrequent.  Otherwise, you simply have to be
> aware when you are sharing data structures.

That's exactly the point. Excuse my lecture, but...

External hardware interrupts may cause key components of the OS or 
application to be entered while they are executing on behalf of another 
task. When multiprogramming (more than one processor), even the software 
can interfere with itself. There are a few solutions.

1. Suspend interrupts while dealing with interrupts. Doesn't really 
provide a solution when multiple processors are involved, since the same 
code can be executed by several processors.

2. Make sure that the routines do not refer to global areas, so that 
each incomplete execution is not interfered with by a new execution of 
the same code. This can be problematic (we may have only 1 of a given 
resource, but several tasks sharing it for example), so another 
technique is used;

3. For small shared resources like counters or addresses, get the 
processors to help by using atmoic operations that most provide. For 
instance, the Intel x86 LOCK prefix and CMPXCHG instructions do this.

4. For larger shared resources, employ software locking or enqueuing, 
where tasks will wait for shared resources to be free. Tasks that can 
get the lock proceed and then release it; tasks that can't, wait until 
the lock is released. This generally requires atomic operations to 
accomplish.

Back to Hugh's comments about passing data via global variables making 
code non-reentrant.

: increment ( addr -- ) dup @ 1+ swap ! ; \ increment value at address

Even though INCREMENT does not itself refer to global variables and 
appears at first sight to be reentrant, two tasks using the shared area 
SHARED invoking SHARED INCREMENT will give inconsistent results when 
SHARED is fetched.

-- 
Alex

[toc] | [prev] | [next] | [standalone]

#54732

On 2/8/17 3:43 AM, Alex wrote:
> On 2/8/2017 08:34, rickman wrote:
>>>>> Looking at the whole application is going to be difficult when there
>>>>> is 16MB of source-code --- the programmers need to understand the
>>>>> concept of re-entrancy --- they can't pass data between functions in
>>>>> global variables.
>>>
>>>> You are aware that re-entrancy is only an issue with multitasking,
>>>> right?  Was this OS multitasking?
>>>
>>> Re-entrancy is not just an issue with multi-tasking.
>>>
>>> If a function uses PAD internally and calls another function that uses
>>> PAD internally, then chaos will result.
>>>
>>> This should be obvious to anybody!
>
> Function A setting PAD and calling B that sets PAD is a simple case of
> the side effect of using global variables, specifically when they are
> modified. (No-one objects to constants as globals, because they are only
> ever read and not set.)
>
> For this kind of problem, only rewriting the code will fix it, but it
> definitely does not need to be reentrant.
>
>>
>> I don't know I've ever seen this referred to as reentrancy.  Looking on
>> the web it's hard to find authoritative sources about reentrancy... but
>> here is wikipedia, not that I consider wikipedia to necessarily be
>> authoritative.
>>
>> ********************************
>> In computing, a computer program or subroutine is called reentrant if it
>> can be interrupted in the middle of its execution, and then be safely
>> called again ("re-entered") before its previous invocations complete
>> execution. The interruption could be caused by an internal action such
>> as a jump or call, or by an external action such as a hardware interrupt
>> or signal. Once the reentered invocation completes, the previous
>> invocations will resume correct execution.
>> ********************************
>
> It's not very good.
>
>>
>> So they do allow for the case of a routine calling another and ending up
>> calling itself.  But what you describe is one routine calling another
>> that shares a common data structure.  That's not technically reentrancy.
>>  Still, I suppose I get your point.  Recursion is a form of reentrancy.
>>  But that simply means you need to be aware when routines can be called
>> recursively which is very infrequent.  Otherwise, you simply have to be
>> aware when you are sharing data structures.
>
> That's exactly the point. Excuse my lecture, but...
>
> External hardware interrupts may cause key components of the OS or
> application to be entered while they are executing on behalf of another
> task. When multiprogramming (more than one processor), even the software
> can interfere with itself. There are a few solutions.
>
> 1. Suspend interrupts while dealing with interrupts. Doesn't really
> provide a solution when multiple processors are involved, since the same
> code can be executed by several processors.
>
> 2. Make sure that the routines do not refer to global areas, so that
> each incomplete execution is not interfered with by a new execution of
> the same code. This can be problematic (we may have only 1 of a given
> resource, but several tasks sharing it for example), so another
> technique is used;
>
> 3. For small shared resources like counters or addresses, get the
> processors to help by using atmoic operations that most provide. For
> instance, the Intel x86 LOCK prefix and CMPXCHG instructions do this.
>
> 4. For larger shared resources, employ software locking or enqueuing,
> where tasks will wait for shared resources to be free. Tasks that can
> get the lock proceed and then release it; tasks that can't, wait until
> the lock is released. This generally requires atomic operations to
> accomplish.
>
> Back to Hugh's comments about passing data via global variables making
> code non-reentrant.
>
> : increment ( addr -- ) dup @ 1+ swap ! ; \ increment value at address
>
> Even though INCREMENT does not itself refer to global variables and
> appears at first sight to be reentrant, two tasks using the shared area
> SHARED invoking SHARED INCREMENT will give inconsistent results when
> SHARED is fetched.

Managing that sort of situation is an elementary application design. If 
you have shared memory space in your application, you need very specific 
rules as to who may change which variables in that space and under what 
circumstances.

Cheers,
Elizabeth

-- 
Elizabeth R. Conklin
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA  90045
USA

[toc] | [prev] | [next] | [standalone]

#54736

On Wednesday, February 8, 2017 at 6:39:17 PM UTC-7, Elizabeth D. Rather wrote:
> On 2/8/17 3:43 AM, Alex wrote:
> > Back to Hugh's comments about passing data via global variables making
> > code non-reentrant.
> >
> > : increment ( addr -- ) dup @ 1+ swap ! ; \ increment value at address
> >
> > Even though INCREMENT does not itself refer to global variables and
> > appears at first sight to be reentrant, two tasks using the shared area
> > SHARED invoking SHARED INCREMENT will give inconsistent results when
> > SHARED is fetched.
 
> Managing that sort of situation is an elementary application design. If 
> you have shared memory space in your application, you need very specific 
> rules as to who may change which variables in that space and under what 
> circumstances.

This is the "very specific rule" regarding PAD that Elizabeth Rather provided in the ANS-Forth document:

"...is the address of a transient region that can be used to hold data for intermediate processing."

ANS-Forth actually has several problems that come from using the same memory for different things. This has been discussed before:
https://groups.google.com/forum/#!topic/comp.lang.forth/uGAKvs8baQk%5B26-50%5D

On Friday, December 9, 2016 at 8:11:08 AM UTC-7, hughag...@gmail.com wrote:
> On Thursday, December 8, 2016 at 11:23:05 PM UTC-7, hughag...@gmail.com wrote:
> > ANS-Forth is confusing! I was testing my words under VFX just now and came to this:
> > 
> > 12345.6789e engineering  ok-2 
> > type 12.345679e32 ok
> > 
> > WTF??? Does my code have a bug??? Then I tried this:
> > 
> > 12345.6789e engineering type 12.345679e3  ok
> > 
> > This works. I realized then that the problem was not in my code, it was in ANS-Forth --- the outer-interpreter uses the same memory location for multiple purposes --- my <SCIENTIFIC> is using the buffer that <# #> uses, and this buffer gets clobbered by the outer-interpreter before the TYPE gets done on the next line.
> > ...
> > In Straight Forth I am going to get rid of all this confusing nonsense. My <SCIENTIFIC> used above should work in any context. It should be easy to make the system work in a consistent way. 
> 
> Straight Forth has a string-stack (the same as STRING-STACK.4TH that I wrote in ANS-Forth). It doesn't have TYPE so the above problem would never occur. All strings are worked with on the string-stack and it is very rare to remove a string from the string-stack. In Straight Forth, <# #> would push a string onto the string-stack --- to print it out, .$ would be used. You can push multiple strings onto the string-stack (it is a stack, you know), and they don't over-write each other.
> 
> It is utterly retarded that ANS-Forth uses one memory block for all of its strings, so if you have more than one string the latest string over-writes the previous strings. That is stupid! Even line-number BASIC on the old 8-bit computers of the 1980s had better string-handling than that!
> 
> I can easily imagine an ANS-Forth student running into a problem like this:
> 
> 12345.6789e engineering  ok-2 
> type 12.345679e32 ok
> 
> Then the student asks on comp.lang.forth what is wrong. He gets these responses:
> 
> John Passaniti: "You suck!"
> Elizabeth Rather: "You're homophobic!"
> Bernd Paysan: "You're stupid!"
> Alex McDonald: "You have a serious misunderstanding of how pointers work!"
> Stephen Pelc: "RTFM!"
> Andrew Haley: "You're jealous of me!"
> 
> This might be why nobody is volunteering to be an ANS-Forth student, do you think?
> 
> Actually, what the student will think is that there is a bug in my novice-package --- he will abandon the novice-package --- he will become a typical ANS-Forth programmer who spends all of his time on comp.lang.forth posting code copied directly out of the "Starting Forth" book and flinging insults at me.

[toc] | [prev] | [next] | [standalone]

#54738

On 2/9/2017 06:39, hughaguilar96@gmail.com wrote:
> On Wednesday, February 8, 2017 at 6:39:17 PM UTC-7, Elizabeth D.
> Rather wrote:
>> On 2/8/17 3:43 AM, Alex wrote:
>>> Back to Hugh's comments about passing data via global variables
>>> making code non-reentrant.
>>>
>>> : increment ( addr -- ) dup @ 1+ swap ! ; \ increment value at
>>> address
>>>
>>> Even though INCREMENT does not itself refer to global variables
>>> and appears at first sight to be reentrant, two tasks using the
>>> shared area SHARED invoking SHARED INCREMENT will give
>>> inconsistent results when SHARED is fetched.
>
>> Managing that sort of situation is an elementary application
>> design. If you have shared memory space in your application, you
>> need very specific rules as to who may change which variables in
>> that space and under what circumstances.
>
> This is the "very specific rule" regarding PAD that Elizabeth Rather
> provided in the ANS-Forth document:
>
> "...is the address of a transient region that can be used to hold
> data for intermediate processing."
>
> ANS-Forth actually has several problems that come from using the same
> memory for different things. This has been discussed before:
> https://groups.google.com/forum/#!topic/comp.lang.forth/uGAKvs8baQk%5B26-50%5D
>
>  On Friday, December 9, 2016 at 8:11:08 AM UTC-7, hughag...@gmail.com
> wrote:
>> On Thursday, December 8, 2016 at 11:23:05 PM UTC-7,
>> hughag...@gmail.com wrote:
>>> ANS-Forth is confusing! I was testing my words under VFX just now
>>> and came to this:
>>>
>>> 12345.6789e engineering  ok-2 type 12.345679e32 ok
>>>
>>> WTF??? Does my code have a bug??? Then I tried this:
>>>
>>> 12345.6789e engineering type 12.345679e3  ok
>>>
>>> This works. I realized then that the problem was not in my code,
>>> it was in ANS-Forth --- the outer-interpreter uses the same
>>> memory location for multiple purposes --- my <SCIENTIFIC> is
>>> using the buffer that <# #> uses, and this buffer gets clobbered
>>> by the outer-interpreter before the TYPE gets done on the next
>>> line.

Yes, your code has a bug, since the behaviour you're describing is 
covered by the standard.

Now, I think the standard is deficient in this area, and that some 
remedial work is appropriate; but I suspect that it would possibly fall 
on stony ground and get voted down because of its increased resource 
requirements.

>>
>> Actually, what the student will think is that there is a bug in my
>> novice-package --- he will abandon the novice-package --- he will
>> become a typical ANS-Forth programmer who spends all of his time on
>> comp.lang.forth posting code copied directly out of the "Starting
>> Forth" book and flinging insults at me.

It's a bug, since your <SCIENTIFIC> word doesn't work.

If you had a better software development model for your Forth, like 
github, you would be able to cope better with bugs and changes to the 
source; and also count downloads and do issue management. I picked up 
your novice package recently (What version? Was it the latest? Who 
knows) where you ship sort source code that you no longer support or 
maintain. That's not a reputation enhancing move.

-- 
Alex

[toc] | [prev] | [next] | [standalone]

#54757

On Thursday, February 9, 2017 at 1:56:25 AM UTC-7, Alex wrote:
> On 2/9/2017 06:39, hughaguilar96@gmail.com wrote:
> > ANS-Forth actually has several problems that come from using the same
> > memory for different things. This has been discussed before:
> > https://groups.google.com/forum/#!topic/comp.lang.forth/uGAKvs8baQk%5B26-50%5D
> >
> >  On Friday, December 9, 2016 at 8:11:08 AM UTC-7, hughag...@gmail.com
> > wrote:
> >> On Thursday, December 8, 2016 at 11:23:05 PM UTC-7,
> >> hughag...@gmail.com wrote:
> >>> ANS-Forth is confusing! I was testing my words under VFX just now
> >>> and came to this:
> >>>
> >>> 12345.6789e engineering  ok-2 type 12.345679e32 ok
> >>>
> >>> WTF??? Does my code have a bug??? Then I tried this:
> >>>
> >>> 12345.6789e engineering type 12.345679e3  ok
> >>>
> >>> This works. I realized then that the problem was not in my code,
> >>> it was in ANS-Forth --- the outer-interpreter uses the same
> >>> memory location for multiple purposes --- my <SCIENTIFIC> is
> >>> using the buffer that <# #> uses, and this buffer gets clobbered
> >>> by the outer-interpreter before the TYPE gets done on the next
> >>> line.
> 
> Yes, your code has a bug, since the behaviour you're describing is 
> covered by the standard.
> ...
> It's a bug, since your <SCIENTIFIC> word doesn't work.

There is no bug in my <SCIENTIFIC> --- the ANS-Forth cult's strategy seems to be repeatedly to denounce my novice package as having bugs without offering any evidence --- this is so ANS-Forth programmers won't use my STRING-STACK.4TH etc. because they believe that the whole package is full of bugs, and they continue using PAD etc. instead because that is "standard."

[toc] | [prev] | [next] | [standalone]

#54766

On 2/9/2017 22:36, hughaguilar96@gmail.com wrote:
> On Thursday, February 9, 2017 at 1:56:25 AM UTC-7, Alex wrote:
>> On 2/9/2017 06:39, hughaguilar96@gmail.com wrote:
>>> ANS-Forth actually has several problems that come from using the
>>> same memory for different things. This has been discussed
>>> before:
>>> https://groups.google.com/forum/#!topic/comp.lang.forth/uGAKvs8baQk%5B26-50%5D
>>>
>>>
>>>
On Friday, December 9, 2016 at 8:11:08 AM UTC-7, hughag...@gmail.com
>>> wrote:
>>>> On Thursday, December 8, 2016 at 11:23:05 PM UTC-7,
>>>> hughag...@gmail.com wrote:
>>>>> ANS-Forth is confusing! I was testing my words under VFX just
>>>>> now and came to this:
>>>>>
>>>>> 12345.6789e engineering  ok-2 type 12.345679e32 ok
>>>>>
>>>>> WTF??? Does my code have a bug??? Then I tried this:
>>>>>
>>>>> 12345.6789e engineering type 12.345679e3  ok
>>>>>
>>>>> This works. I realized then that the problem was not in my
>>>>> code, it was in ANS-Forth --- the outer-interpreter uses the
>>>>> same memory location for multiple purposes --- my
>>>>> <SCIENTIFIC> is using the buffer that <# #> uses, and this
>>>>> buffer gets clobbered by the outer-interpreter before the
>>>>> TYPE gets done on the next line.
>>
>> Yes, your code has a bug, since the behaviour you're describing is
>>  covered by the standard. ... It's a bug, since your <SCIENTIFIC>
>> word doesn't work.
>
> There is no bug in my <SCIENTIFIC> --- the ANS-Forth cult's strategy
> seems to be repeatedly to denounce my novice package as having bugs
> without offering any evidence --- this is so ANS-Forth programmers
> won't use my STRING-STACK.4TH etc. because they believe that the
> whole package is full of bugs, and they continue using PAD etc.
> instead because that is "standard."
>

Am I to assume that all your code is bug-free, even when its author says 
it doesn't work?

-- 
Alex

[toc] | [prev] | [next] | [standalone]

#54739

On 2/9/2017 01:39, Elizabeth D. Rather wrote:
> On 2/8/17 3:43 AM, Alex wrote:

>>
>> Back to Hugh's comments about passing data via global variables making
>> code non-reentrant.
>>
>> : increment ( addr -- ) dup @ 1+ swap ! ; \ increment value at address
>>
>> Even though INCREMENT does not itself refer to global variables and
>> appears at first sight to be reentrant, two tasks using the shared area
>> SHARED invoking SHARED INCREMENT will give inconsistent results when
>> SHARED is fetched.
>
> Managing that sort of situation is an elementary application design. If
> you have shared memory space in your application, you need very specific
> rules as to who may change which variables in that space and under what
> circumstances.
>
> Cheers,
> Elizabeth
>

It's non-trivial in a large project, since the use of a shared area may 
not be apparent if it is referred to without its name (ie by address) 
some distance from its original specification. An address in memory is 
bare; it comes with no warnings or properties. Some programming 
languages may have the ability to track addresses across and through 
function invocations, but Forth can't.

-- 
Alex

[toc] | [prev] | [next] | [standalone]

#54742

In article <o7hb55$u0u$1@dont-email.me>, Alex  <alex@rivadpm.com> wrote:
>On 2/9/2017 01:39, Elizabeth D. Rather wrote:
>> On 2/8/17 3:43 AM, Alex wrote:
<SNIP>
>It's non-trivial in a large project, since the use of a shared area may
>not be apparent if it is referred to without its name (ie by address)
>some distance from its original specification. An address in memory is
>bare; it comes with no warnings or properties. Some programming
>languages may have the ability to track addresses across and through
>function invocations, but Forth can't.

It should be apparent by its descriptive comment for internal words
and by the API documentation for external words.

That's why ( addr len -- fl ) "comments" are harmful. There must be a
narrative, (a sequence of proper sentences that are statements, i.e.
can be true or false) that tells *everything* one must know about
this word (that is not defined in the context of the project already).

Yes the code tells everything. If you go that road largish programs
will fail.

>
>--
>Alex

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#54748

In article <o7he3k$sno$1@cherry.spenarnc.xs4all.nl>, 
albert@cherry.spenarnc.xs4all.nl says...
> That's why ( addr len -- fl ) "comments" are harmful. There must be a
> narrative, (a sequence of proper sentences that are statements, i.e.
> can be true or false) that tells *everything* one must know about
> this word (that is not defined in the context of the project already).
> 

Hence the use of predicate logic - and other technologies.
I wonder how many forth programmers will be allowed to release
commercial forth code 5 years from now?
Winter - as they say - is coming.

-- 

john

=========================
http://johntech.co.uk

"Bleeding Edge Forum"
http://johntech.co.uk/forum/ 

=========================

[toc] | [prev] | [next] | [standalone]

#54754

On 2/9/17 1:54 AM, john wrote:
> In article <o7he3k$sno$1@cherry.spenarnc.xs4all.nl>,
> albert@cherry.spenarnc.xs4all.nl says...
>> That's why ( addr len -- fl ) "comments" are harmful. There must be a
>> narrative, (a sequence of proper sentences that are statements, i.e.
>> can be true or false) that tells *everything* one must know about
>> this word (that is not defined in the context of the project already).
>>
>
> Hence the use of predicate logic - and other technologies.
> I wonder how many forth programmers will be allowed to release
> commercial forth code 5 years from now?
> Winter - as they say - is coming.
>

Stack comments aren't harmful, they're necessary but not sufficient. 
There should *also* be a description of what the words does, either in 
the source or associated documentation or (ideally) both.

Cheers,
Elizabeth

-- 
Elizabeth R. Conklin
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA  90045
USA

[toc] | [prev] | [next] | [standalone]

#54750

On Thu, 9 Feb 2017 10:51:48 +0100 (CET),
albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) wrote:

>That's why ( addr len -- fl ) "comments" are harmful. There must be a
>narrative, (a sequence of proper sentences that are statements, i.e.
>can be true or false) that tells *everything* one must know about
>this word (that is not defined in the context of the project already).

Stack comments are essential. People who do not provide a stack
comment for every word do not work for MPE. However, each word
*must* also have a description. In MPE world, this is the
  \ *G What this word does and why.
comment provided for each word.

In order to write code that is maintainable beyond the time
frame of the original programmer, his memory and her availability,
both the stack comment and the description/narrative must be
present.

Note that this discipline applies to all programming languages.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | comp.lang.forth

csiph-web