Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: rickman Newsgroups: comp.lang.forth Subject: Re: Really? Date: Wed, 8 Feb 2017 03:34:50 -0500 Organization: A noiseless patient Spider Lines: 73 Message-ID: References: <1239a88b-a574-401b-9454-50ac7e000049@googlegroups.com> <5899a408.386236853@news.eternal-september.org> <87shnqw989.fsf@nightsong.com> <589a303c.422128955@news.eternal-september.org> <01fb25bd-7975-4ca5-b9e6-1024cb772c7a@googlegroups.com> <1207313c-ffcd-4640-a619-f1424dcf75cc@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Wed, 8 Feb 2017 08:33:04 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="cd6920b229c8b78398c4bdf504224a30"; logging-data="14094"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+ERgX6G9a5redJWz5iqiBG" User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 In-Reply-To: <1207313c-ffcd-4640-a619-f1424dcf75cc@googlegroups.com> Cancel-Lock: sha1:U6ncCP73jwotIA5LVP3HdDbRO1o= Xref: csiph.com comp.lang.forth: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