Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #45489 > unrolled thread
| Started by | laheadle@gmail.com |
|---|---|
| First post | 2016-02-12 13:57 -0800 |
| Last post | 2016-02-22 01:46 -0800 |
| Articles | 20 on this page of 115 — 26 participants |
Back to article view | Back to comp.lang.forth
How do you remember the stack? laheadle@gmail.com - 2016-02-12 13:57 -0800
Re: How do you remember the stack? Paul Rubin <no.email@nospam.invalid> - 2016-02-12 14:08 -0800
Re: How do you remember the stack? "HAA" <someone@microsoft.com> - 2016-02-16 13:35 +1100
Re: How do you remember the stack? Julian Fondren <julian.fondren@gmail.com> - 2016-02-15 19:28 -0800
Re: How do you remember the stack? Whammo <sidciavic@gmail.com> - 2016-02-15 19:54 -0800
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-16 07:28 +0000
Re: How do you remember the stack? "Elizabeth D. Rather" <erather@forth.com> - 2016-02-15 22:03 -1000
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-16 13:30 +0000
Re: How do you remember the stack? "Elizabeth D. Rather" <erather@forth.com> - 2016-02-16 08:20 -1000
Re: How do you remember the stack? dunno <dunno@dunno.dunno> - 2016-02-16 20:48 +0000
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-17 15:42 +0000
Re: How do you remember the stack? "HAA" <someone@microsoft.com> - 2016-02-18 18:48 +1100
Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-02-18 12:27 -0800
Re: How do you remember the stack? Julian Fondren <julian.fondren@gmail.com> - 2016-02-18 14:53 -0800
Re: How do you remember the stack? Julian Fondren <julian.fondren@gmail.com> - 2016-02-18 15:18 -0800
Re: How do you remember the stack? "HAA" <someone@microsoft.com> - 2016-02-21 13:32 +1100
Re: How do you remember the stack? Chris Curl <ccurl609@gmail.com> - 2016-02-20 20:57 -0800
Re: How do you remember the stack? Ron Aaron <rambamist@gmail.com> - 2016-02-21 07:23 +0200
Re: How do you remember the stack? Chris Curl <ccurl609@gmail.com> - 2016-02-21 08:54 -0800
Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-02-21 22:05 -0800
Re: How do you remember the stack? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-02-22 16:20 +0100
Re: How do you remember the stack? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-02-22 09:47 -0600
Re: How do you remember the stack? Whammo <sidciavic@gmail.com> - 2016-02-23 16:51 -0800
Re: How do you remember the stack? "HAA" <someone@microsoft.com> - 2016-02-28 15:22 +1100
Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-02-27 21:30 -0800
Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-02-27 21:33 -0800
Re: How do you remember the stack? "Elizabeth D. Rather" <erather@forth.com> - 2016-02-27 21:39 -1000
Re: How do you remember the stack? "HAA" <someone@microsoft.com> - 2016-02-29 13:47 +1100
Re: How do you remember the stack? Paul Rubin <no.email@nospam.invalid> - 2016-02-28 19:02 -0800
Re: How do you remember the stack? Julian Fondren <julian.fondren@gmail.com> - 2016-02-28 22:26 -0800
Re: How do you remember the stack? Paul Rubin <no.email@nospam.invalid> - 2016-02-28 22:37 -0800
Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-02-28 19:11 -0800
Re: How do you remember the stack? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-02-29 11:55 -0600
Re: How do you remember the stack? "Elizabeth D. Rather" <erather@forth.com> - 2016-02-29 19:30 -1000
Re: How do you remember the stack? "HAA" <someone@microsoft.com> - 2016-03-02 00:49 +1100
Re: How do you remember the stack? "Elizabeth D. Rather" <erather@forth.com> - 2016-03-01 13:50 -1000
Re: How do you remember the stack? Paul Rubin <no.email@nospam.invalid> - 2016-03-01 16:49 -0800
Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-03-01 18:04 -0800
Re: How do you remember the stack? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-03-02 02:53 -0600
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-02 09:57 +0000
Re: How do you remember the stack? Pablo Hugo Reda <pabloreda@gmail.com> - 2016-03-02 03:21 -0800
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-02 11:49 +0000
Re: How do you remember the stack? Pablo Hugo Reda <pabloreda@gmail.com> - 2016-03-02 04:23 -0800
Re: How do you remember the stack? stephen@mpeforth.com (Stephen Pelc) - 2016-03-02 18:32 +0000
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-02 18:41 +0000
Re: How do you remember the stack? stephen@mpeforth.com (Stephen Pelc) - 2016-03-02 20:36 +0000
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-03 07:38 +0000
Re: How do you remember the stack? stephen@mpeforth.com (Stephen Pelc) - 2016-03-03 09:26 +0000
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-03 11:15 +0000
Re: How do you remember the stack? stephen@mpeforth.com (Stephen Pelc) - 2016-03-03 15:35 +0000
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-03 15:56 +0000
Re: How do you remember the stack? stephen@mpeforth.com (Stephen Pelc) - 2016-03-03 17:04 +0000
Re: How do you remember the stack? Whammo <sidciavic@gmail.com> - 2016-03-01 19:29 -0800
Re: How do you remember the stack? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-02-28 18:52 +0000
Re: How do you remember the stack? Whammo <sidciavic@gmail.com> - 2016-02-28 13:30 -0800
Re: How do you remember the stack? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-02-29 07:55 +0100
Re: How do you remember the stack? "Elizabeth D. Rather" <erather@forth.com> - 2016-02-29 19:34 -1000
Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-03-01 20:40 -0800
Re: How do you remember the stack? Unknown <dog@gmail.com> - 2016-06-02 05:46 +0000
Re: How do you remember the stack? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-06-02 08:48 +0200
Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-06-02 00:17 -0700
Re: How do you remember the stack? Michael Barry <barrym95838@yahoo.com> - 2016-06-02 19:48 -0700
Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-06-02 20:34 -0700
Re: How do you remember the stack? "WJ" <w_a_x_man@yahoo.com> - 2016-02-22 19:23 +0000
Re: How do you remember the stack? "HAA" <someone@microsoft.com> - 2016-02-25 20:31 +1100
Re: How do you remember the stack? Julian Fondren <julian.fondren@gmail.com> - 2016-02-25 07:44 -0800
Re: How do you remember the stack? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-02-25 20:22 +0100
Re: How do you remember the stack? "HAA" <someone@microsoft.com> - 2016-02-28 13:43 +1100
Re: How do you remember the stack? "Elizabeth D. Rather" <erather@forth.com> - 2016-02-27 21:43 -1000
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-28 14:53 +0000
Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-02-28 15:27 -0800
Re: How do you remember the stack? humptydumpty <ouatubi@gmail.com> - 2016-06-02 02:02 -0700
Re: How do you remember the stack? JennyB <jennybrien@googlemail.com> - 2016-06-03 05:57 -0700
Re: How do you remember the stack? Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-01 16:38 +0000
Re: How do you remember the stack? Chris Curl <ccurl609@gmail.com> - 2016-02-12 16:31 -0800
Re: How do you remember the stack? Whammo <sidciavic@gmail.com> - 2016-02-12 17:31 -0800
Re: How do you remember the stack? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-02-13 08:03 +0100
Re: How do you remember the stack? dunno <dunno@dunno.dunno> - 2016-02-13 08:06 +0000
Re: How do you remember the stack? minforth@arcor.de - 2016-02-13 01:50 -0800
Re: How do you remember the stack? mhx@iae.nl - 2016-02-13 03:22 -0800
Re: How do you remember the stack? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-02-13 17:09 +0000
Re: How do you remember the stack? mhx@iae.nl - 2016-02-13 03:39 -0800
Re: How do you remember the stack? mhx@iae.nl - 2016-02-13 03:42 -0800
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-13 11:27 +0000
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-13 12:33 +0000
Re: How do you remember the stack? minforth@arcor.de - 2016-02-15 01:05 -0800
Re: How do you remember the stack? dunno <dunno@dunno.dunno> - 2016-02-14 19:34 +0000
Re: How do you remember the stack? Julian Fondren <julian.fondren@gmail.com> - 2016-02-13 06:43 -0800
Re: How do you remember the stack? minforth@arcor.de - 2016-02-15 01:22 -0800
Re: How do you remember the stack? dunno <dunno@dunno.dunno> - 2016-02-15 09:48 +0000
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-15 09:53 +0000
Re: How do you remember the stack? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-02-15 11:26 +0000
Re: How do you remember the stack? minforth@arcor.de - 2016-02-15 04:53 -0800
Re: How do you remember the stack? dunno <dunno@dunno.dunno> - 2016-02-15 17:06 +0000
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-16 14:57 +0000
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-16 14:14 +0000
Re: How do you remember the stack? Ron Aaron <rambamist@gmail.com> - 2016-02-15 12:31 +0200
Re: How do you remember the stack? Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-02-18 22:53 +0000
Re: How do you remember the stack? Doug Hoffman <glidedog@gmail.com> - 2016-02-13 10:51 -0500
Re: How do you remember the stack? "HAA" <someone@microsoft.com> - 2016-02-14 10:18 +1100
Re: How do you remember the stack? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-02-14 04:21 -0600
Re: How do you remember the stack? Whammo <sidciavic@gmail.com> - 2016-02-20 14:36 -0800
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-21 16:35 +0000
Re: How do you remember the stack? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-02-21 18:34 +0000
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-22 09:52 +0000
Re: How do you remember the stack? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-02-22 13:07 +0000
Re: How do you remember the stack? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-22 15:41 +0000
Re: How do you remember the stack? "Elizabeth D. Rather" <erather@forth.com> - 2016-02-22 08:24 -1000
Re: How do you remember the stack? "Elizabeth D. Rather" <erather@forth.com> - 2016-02-22 08:21 -1000
Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-02-22 17:51 -0800
Re: How do you remember the stack? hughaguilar96@gmail.com - 2016-02-22 18:15 -0800
Re: How do you remember the stack? "WJ" <w_a_x_man@yahoo.com> - 2016-02-29 06:20 +0000
Re: How do you remember the stack? "WJ" <w_a_x_man@yahoo.com> - 2016-03-02 20:42 +0000
Re: How do you remember the stack? "WJ" <w_a_x_man@yahoo.com> - 2016-06-02 20:13 +0000
Re: How do you remember the stack? humptydumpty <ouatubi@gmail.com> - 2016-02-22 01:46 -0800
Page 1 of 6 [1] 2 3 4 5 6 Next page →
| From | laheadle@gmail.com |
|---|---|
| Date | 2016-02-12 13:57 -0800 |
| Subject | How do you remember the stack? |
| Message-ID | <07ab86b1-3681-47c0-80ea-d7bd908925e7@googlegroups.com> |
When I'm reading forth code, I have to work hard to remember the contents of the stack. Especially when a word is more than a few subwords long, or contains words whose stack effects I have to go and look up, I am likely to forget what the stack looks like at the point I was just at. So I have to backtrack to a previous known stack state, and recover the context by reading word by word. One thing I do is mentally "say" the contents of the stack after every word: "a b c...b c a...c a..." etc. This seems to help my memory. But I sometimes find I'm using so much attention remembering the stack that I don't have as much short-term memory left over as I would like for understanding the program itself. Part of this is that I'm still pretty new, but I am wondering if you have any similar experiences or strategies to share.
[toc] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-02-12 14:08 -0800 |
| Message-ID | <87fuwxd1js.fsf@nightsong.com> |
| In reply to | #45489 |
laheadle@gmail.com writes: > Part of this is that I'm still pretty new, but I am wondering if you > have any similar experiences or strategies to share. You get use to it after a while. Before that, it can help to write stack comments at relevant places in your code.
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-02-16 13:35 +1100 |
| Message-ID | <n9u1t3$bce$1@gioia.aioe.org> |
| In reply to | #45490 |
Paul Rubin wrote: > laheadle@gmail.com writes: > > Part of this is that I'm still pretty new, but I am wondering if you > > have any similar experiences or strategies to share. > > You get use to it after a while. Before that, it can help to write > stack comments at relevant places in your code. I agree. I'd also add that it never really goes away. There's a view that experienced forthers 'do it all in their head'. Perhaps that's because they rarely say how *they* do it - which conveniently adds to the mystique. It's a myth worth busting. Despite advice about factoring, experienced forthers continue to write multi-line definitions. Lots of them. Why? Because factoring does little to reduce memory load. They factor when there's something worth factoring. So how do they handle multi-line definitions? In the same way as raw beginners - by jotting down stack effects as they go. These working comments are removed when the definition is complete. The process is similar to a builder erecting scaffolding during construction and removing it afterwards. When the building needs renovating, the scaffolding goes back up. Forth works the same.
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-02-15 19:28 -0800 |
| Message-ID | <798174bf-a08e-45bd-96cd-6ddacdef9db9@googlegroups.com> |
| In reply to | #45556 |
On Monday, February 15, 2016 at 8:35:24 PM UTC-6, HAA wrote: > Paul Rubin wrote: > > laheadle@gmail.com writes: > > > Part of this is that I'm still pretty new, but I am wondering if you > > > have any similar experiences or strategies to share. > > > > You get use to it after a while. Before that, it can help to write > > stack comments at relevant places in your code. > > I agree. I'd also add that it never really goes away. There's a view that > experienced forthers 'do it all in their head'. Perhaps that's because > they rarely say how *they* do it - which conveniently adds to the mystique. > It's a myth worth busting. > > Despite advice about factoring, experienced forthers continue to write > multi-line definitions. Lots of them. Why? Because factoring does little > to reduce memory load. They factor when there's something worth > factoring. Factoring comes up in discussions about stack management because difficulty with the stack is one of the ways that Forth punishes bad factoring. And it is certainly easier to follow (and modify) [: A B C ;] knowing there's always a single item on the stack between these words, than to follow the stack trashing that may actually be happening within those words. But stack management isn't *the point* of factoring. And what does the number of lines in a definition have to do with any of this? Lines of code don't translate to deeper stacks. > So how do they handle multi-line definitions? In the same > way as raw beginners - by jotting down stack effects as they go. > These working comments are removed when the definition is complete. > The process is similar to a builder erecting scaffolding during construction > and removing it afterwards. When the building needs renovating, the > scaffolding goes back up. Forth works the same. Nonsense. If you can't do it in your head, how are you going to read the code after the 'scaffolding' goes away? When would you even want it to go away? When your program is ready to frame on the wall of a museum, never to be improved again? -- Julian
[toc] | [prev] | [next] | [standalone]
| From | Whammo <sidciavic@gmail.com> |
|---|---|
| Date | 2016-02-15 19:54 -0800 |
| Message-ID | <8e30b84e-38e6-40b6-82fd-ea1ab2eb572c@googlegroups.com> |
| In reply to | #45556 |
On Monday, February 15, 2016 at 6:35:24 PM UTC-8, HAA wrote: > Paul Rubin wrote: > > writes: > > > Part of this is that I'm still pretty new, but I am wondering if you > > > have any similar experiences or strategies to share. > > > > You get use to it after a while. Before that, it can help to write > > stack comments at relevant places in your code. > > I agree. I'd also add that it never really goes away. There's a view that > experienced forthers 'do it all in their head'. Perhaps that's because > they rarely say how *they* do it - which conveniently adds to the mystique. > It's a myth worth busting. > > Despite advice about factoring, experienced forthers continue to write > multi-line definitions. Lots of them. Why? Because factoring does little > to reduce memory load. They factor when there's something worth > factoring. So how do they handle multi-line definitions? In the same > way as raw beginners - by jotting down stack effects as they go. > These working comments are removed when the definition is complete. > The process is similar to a builder erecting scaffolding during construction > and removing it afterwards. When the building needs renovating, the > scaffolding goes back up. Forth works the same. This proves my point. Short one or two line definitions make it easier to understand what is happening on the stack. We factor because once you understand how the code works, and the stack effects, it can then be an abstraction, a black box. There are also advantages to structured code. Indentations help understand the logical sequence of the code, but obscure what is actually happening. Short, named words are the first clue to it's function. Limiting the stack depth to two or three per word will reduce memory load. This is how forth is initially written and tested. Nobody can keep multi-line definition, stack thrashing straight in their head. Not even the genius himself, Chuck Moore. Programmers obscure their code in this manner to avoid others understanding their code and then having to justify their algorithms.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-02-16 07:28 +0000 |
| Message-ID | <2016Feb16.082803@mips.complang.tuwien.ac.at> |
| In reply to | #45556 |
"HAA" <someone@microsoft.com> writes:
>Despite advice about factoring, experienced forthers continue to write
>multi-line definitions. Lots of them. Why?
Because I find line-broken and indented code easier to read than the
classical Forth filling style that tries to fit as much code into a
screen as possible, only grudgingly starting a new line for a new
definition.
>Because factoring does little
>to reduce memory load. They factor when there's something worth
>factoring.
You got the last sentence right.
> So how do they handle multi-line definitions? In the same
>way as raw beginners - by jotting down stack effects as they go.
>These working comments are removed when the definition is complete.
Maybe you work that way, I don't. When the stack work is complex
enough to write down stack pictures, I keep them. They then also help
in reading the code.
>The process is similar to a builder erecting scaffolding during construction
>and removing it afterwards. When the building needs renovating, the
>scaffolding goes back up. Forth works the same.
There is good reason to remove the scaffolding, but no reason to
remove the stack picture comments.
- 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 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-02-15 22:03 -1000 |
| Message-ID | <jaCdnRZNtdRaSl_LnZ2dnUU7-YH46u6z@supernews.com> |
| In reply to | #45563 |
On 2/15/16 9:28 PM, Anton Ertl wrote: > "HAA" <someone@microsoft.com> writes: >> Despite advice about factoring, experienced forthers continue to write >> multi-line definitions. Lots of them. Why? > > Because I find line-broken and indented code easier to read than the > classical Forth filling style that tries to fit as much code into a > screen as possible, only grudgingly starting a new line for a new > definition. I have never found trying to "fit as much code into a screen as possible" to be either a "classical" or even popular strategy, and the excellent Forth programmers I've been privileged to work with over the years find such an approach anathema. Back in the day when we used source blocks the practice at FORTH, Inc. and other successful shops was to think of a source block as being roughly equivalent to a paragraph of prose: sentences (definitions) related to a specific topic. Some topics are bigger than others: when we printed listings, a "triad" of 3 blocks fitted on a page, and could handle a slightly larger sub-topic. Blocks always had a "line 0" containing a brief description of the contents, and an "index" (list of line-0's from a range of blocks, up to 60/page, though some pages would have a bunch of empty blocks) could handle major components of a system or application. Each block of source had a paired "shadow block" of comments describing the use of each definition in its corresponding block. (old timers know this, but newbies don't) When we converted to files, we tried to maintain a similar discipline: a file may be logically equivalent to an "index page" and contain multiple sections of code interspersed with introductory comment sections describing the code to follow. >> Because factoring does little >> to reduce memory load. They factor when there's something worth >> factoring. > > You got the last sentence right. The objective of factoring is to isolate a specific function. Continuing with the analogy to prose, a definition should be equivalent to a sentence: a few words conveying a single thought. In well-written Forth, many definitions are reusable, which does reduce memory usage, but the primary purpose is isolation of the "thought" which makes the whole programming practice simpler and cleaner: stack management, testing, reusability, etc. >> So how do they handle multi-line definitions? In the same >> way as raw beginners - by jotting down stack effects as they go. >> These working comments are removed when the definition is complete. > > Maybe you work that way, I don't. When the stack work is complex > enough to write down stack pictures, I keep them. They then also help > in reading the code. Yes. Never remove any kind of documentation, unless it is inaccurate (in which case it should be replaced with the correct comments). >> The process is similar to a builder erecting scaffolding during construction >> and removing it afterwards. When the building needs renovating, the >> scaffolding goes back up. Forth works the same. > > There is good reason to remove the scaffolding, but no reason to > remove the stack picture comments. The only "scaffolding" that needs to be removed might be temporary stubs for simulation purposes until the code that actually performs those functions has been written. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-02-16 13:30 +0000 |
| Message-ID | <2016Feb16.143053@mips.complang.tuwien.ac.at> |
| In reply to | #45564 |
"Elizabeth D. Rather" <erather@forth.com> writes:
>I have never found trying to "fit as much code into a screen as
>possible" to be either a "classical" or even popular strategy,
Despite screens being pretty much a thing of the ancient past (before
1990), it still seems quite popular to fill lines with code. E.g.,
looking at thre "Rosetta code reverse a string" thread, I see
<87d1rx8t35.fsf@jester.gateway.pace.com>:
create buf 1000 chars allot
buf value pp
: tr ( caddr u -- ) dup >r pp swap cmove r> pp + to pp ;
: collect begin parse-name dup while tuck pp >r tr r> swap repeat ;
: >> buf to pp collect 2drop depth 2/ 0 ?do type bl emit loop cr ;
as well as <56c30c28$0$23786$e4fe514c@news.xs4all.nl>:
\ Split SC into SC1 ... SC2 . reverse order.
: split BEGIN BL $/ 2SWAP DUP 0= UNTIL ;
: print >R BEGIN TYPE SPACE DEPTH R@ = UNTIL RDROP ;
: reverse DEPTH 2 - >R split R> print ;
- 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 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-02-16 08:20 -1000 |
| Message-ID | <T_GdnSOrDqXh9V7LnZ2dnUU7-Yn46u6z@supernews.com> |
| In reply to | #45571 |
On 2/16/16 3:30 AM, Anton Ertl wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> I have never found trying to "fit as much code into a screen as >> possible" to be either a "classical" or even popular strategy, > > Despite screens being pretty much a thing of the ancient past (before > 1990), it still seems quite popular to fill lines with code. E.g., > looking at thre "Rosetta code reverse a string" thread, I see > <87d1rx8t35.fsf@jester.gateway.pace.com>: > > create buf 1000 chars allot > buf value pp > > : tr ( caddr u -- ) dup >r pp swap cmove r> pp + to pp ; > : collect begin parse-name dup while tuck pp >r tr r> swap repeat ; > : >> buf to pp collect 2drop depth 2/ 0 ?do type bl emit loop cr ; > > as well as <56c30c28$0$23786$e4fe514c@news.xs4all.nl>: > > \ Split SC into SC1 ... SC2 . reverse order. > : split BEGIN BL $/ 2SWAP DUP 0= UNTIL ; > : print >R BEGIN TYPE SPACE DEPTH R@ = UNTIL RDROP ; > : reverse DEPTH 2 - >R split R> print ; I'm not sure what kind of links those are (they generate meaningless email addresses when clicked), but I agree that these are pretty ugly code examples, mostly lacking stack comments or any kind of helpful spacing. But I'm sure it's possible to write ugly, unreadable code in most languages. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | dunno <dunno@dunno.dunno> |
|---|---|
| Date | 2016-02-16 20:48 +0000 |
| Message-ID | <1059542236.477348056.311902.dunno-dunno.dunno@news.mixmin.net> |
| In reply to | #45585 |
Elizabeth D. Rather <erather@forth.com> wrote: > On 2/16/16 3:30 AM, Anton Ertl wrote: >> "Elizabeth D. Rather" <erather@forth.com> writes: >>> I have never found trying to "fit as much code into a screen as >>> possible" to be either a "classical" or even popular strategy, >> >> Despite screens being pretty much a thing of the ancient past (before >> 1990), it still seems quite popular to fill lines with code. E.g., >> looking at thre "Rosetta code reverse a string" thread, I see >> <87d1rx8t35.fsf@jester.gateway.pace.com>: >> >> create buf 1000 chars allot >> buf value pp >> >>> tr ( caddr u -- ) dup >r pp swap cmove r> pp + to pp ; >>> collect begin parse-name dup while tuck pp >r tr r> swap repeat ; >>>>> buf to pp collect 2drop depth 2/ 0 ?do type bl emit loop cr ; >> >> as well as <56c30c28$0$23786$e4fe514c@news.xs4all.nl>: >> >> \ Split SC into SC1 ... SC2 . reverse order. >>> split BEGIN BL $/ 2SWAP DUP 0= UNTIL ; >>> print >R BEGIN TYPE SPACE DEPTH R@ = UNTIL RDROP ; >>> reverse DEPTH 2 - >R split R> print ; > > I'm not sure what kind of links those are (they generate meaningless > email addresses when clicked), Those are Message IDs of Usenet articles (both of which were posted to CLF). They are recognized as email addresses by some software, but they're not. They more like a permanent link to specific articles. Message ID of your article is <T_GdnSOrDqXh9V7LnZ2dnUU7-Yn46u6z@supernews.com>, and it can be found in the headers of your message. > but I agree that these are pretty ugly > code examples, mostly lacking stack comments or any kind of helpful > spacing. But I'm sure it's possible to write ugly, unreadable code in > most languages. > > Cheers, > Elizabeth > -- dunno
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-02-17 15:42 +0000 |
| Message-ID | <2016Feb17.164244@mips.complang.tuwien.ac.at> |
| In reply to | #45585 |
"Elizabeth D. Rather" <erather@forth.com> writes:
>On 2/16/16 3:30 AM, Anton Ertl wrote:
>> "Elizabeth D. Rather" <erather@forth.com> writes:
>>> I have never found trying to "fit as much code into a screen as
>>> possible" to be either a "classical" or even popular strategy,
>>
>> Despite screens being pretty much a thing of the ancient past (before
>> 1990), it still seems quite popular to fill lines with code. E.g.,
>> looking at thre "Rosetta code reverse a string" thread, I see
>> <87d1rx8t35.fsf@jester.gateway.pace.com>:
>>
>> create buf 1000 chars allot
>> buf value pp
>>
>> : tr ( caddr u -- ) dup >r pp swap cmove r> pp + to pp ;
>> : collect begin parse-name dup while tuck pp >r tr r> swap repeat ;
>> : >> buf to pp collect 2drop depth 2/ 0 ?do type bl emit loop cr ;
>>
>> as well as <56c30c28$0$23786$e4fe514c@news.xs4all.nl>:
>>
>> \ Split SC into SC1 ... SC2 . reverse order.
>> : split BEGIN BL $/ 2SWAP DUP 0= UNTIL ;
>> : print >R BEGIN TYPE SPACE DEPTH R@ = UNTIL RDROP ;
>> : reverse DEPTH 2 - >R split R> print ;
>
>I'm not sure what kind of links those are (they generate meaningless
>email addresses when clicked),
These are Usenet Message-Ids. Look at the header of any Usenet
message. These are from two postings from a recent thread: "Rosetta
code reverse a string".
>but I agree that these are pretty ugly
>code examples, mostly lacking stack comments or any kind of helpful
>spacing. But I'm sure it's possible to write ugly, unreadable code in
>most languages.
Sure it is possible in other languages, but it is actually done in
Forth, even when posting a program here on clf (where one would assume
that people want to show good examples); and by different posters in
that thread, so it's not just a singular aberration.
Filling screens may be a historical reason that spawned that culture;
a more recent incentive is the line-counting metric used by some,
e.g., the claim that factoring and multi-line definitions don't go
together in <n9u1t3$bce$1@gioia.aioe.org>. As in any over-simplified
metric, people start optimizing for the metric instead of for the
actual goal.
- 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 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-02-18 18:48 +1100 |
| Message-ID | <na3t17$anv$1@gioia.aioe.org> |
| In reply to | #45564 |
Elizabeth D. Rather wrote:
> On 2/15/16 9:28 PM, Anton Ertl wrote:
> > "HAA" <someone@microsoft.com> writes:
> ...
> >> So how do they handle multi-line definitions? In the same
> >> way as raw beginners - by jotting down stack effects as they go.
> >> These working comments are removed when the definition is complete.
> >
> > Maybe you work that way, I don't. When the stack work is complex
> > enough to write down stack pictures, I keep them. They then also help
> > in reading the code.
Very rarely do I see stack comments within the body of a definition.
> Yes. Never remove any kind of documentation, unless it is inaccurate (in
> which case it should be replaced with the correct comments).
Examples from a SwiftForth demo:
: G.WALL ( y x r c b -- y x' )
>R 2DUP R@ ?SQUARE IF
2DUP VISITED ?SQUARE IF
R@ ADJACENT VISITED ?SQUARE IF
BRUSH .BEEN @
ELSE BRUSH .OPEN @
THEN ELSE 2DROP BRUSH .OPEN @ THEN
ELSE 2DROP BRUSH .WALL @
THEN DRAW-ELEMENT R> DROP ;
: RELINK-MAZE ( a -- r c t | a f ) DUP >R FROM-BEGINNING
DUP >R CELL+ 2H@ DUP R@ 2 CELLS + 2+ H@ < NOT IF
DROP R@ 2 CELLS + H@ SWAP
1+ DUP R@ 3 CELLS + 2+ H@ < NOT IF
DROP R@ 3 CELLS + H@ SWAP R@ CELL+ 2H!
R> R> DROP FALSE EXIT
THEN SWAP THEN 2DUP 1+ R@ CELL+ 2H!
R> R> AT-END ! TRUE ;
Factors or not, writing such routines (I would think) requires more
than can easily be remembered yet there's nothing there to help the
programmer or reader. Either forth programmers have exceptional
memories - or they're taught by example any aids used during
writing should be removed afterwards.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-02-18 12:27 -0800 |
| Message-ID | <fdf5a94b-8d18-4560-b995-0002d90ea559@googlegroups.com> |
| In reply to | #45600 |
On Thursday, February 18, 2016 at 12:48:59 AM UTC-7, HAA wrote:
> Elizabeth D. Rather wrote:
> > On 2/15/16 9:28 PM, Anton Ertl wrote:
> > > "HAA" <someone@microsoft.com> writes:
> > ...
> > >> So how do they handle multi-line definitions? In the same
> > >> way as raw beginners - by jotting down stack effects as they go.
> > >> These working comments are removed when the definition is complete.
> > >
> > > Maybe you work that way, I don't. When the stack work is complex
> > > enough to write down stack pictures, I keep them. They then also help
> > > in reading the code.
>
> Very rarely do I see stack comments within the body of a definition.
I do that all the time.
As a rule, whenever I have a BEGIN WHILE REPEAT loop, I put the BEGIN WHILE on one line with a stack-picture after it.
> > Yes. Never remove any kind of documentation, unless it is inaccurate (in
> > which case it should be replaced with the correct comments).
>
> Examples from a SwiftForth demo:
>
> : G.WALL ( y x r c b -- y x' )
> >R 2DUP R@ ?SQUARE IF
> 2DUP VISITED ?SQUARE IF
> R@ ADJACENT VISITED ?SQUARE IF
> BRUSH .BEEN @
> ELSE BRUSH .OPEN @
> THEN ELSE 2DROP BRUSH .OPEN @ THEN
> ELSE 2DROP BRUSH .WALL @
> THEN DRAW-ELEMENT R> DROP ;
>
> : RELINK-MAZE ( a -- r c t | a f ) DUP >R FROM-BEGINNING
> DUP >R CELL+ 2H@ DUP R@ 2 CELLS + 2+ H@ < NOT IF
> DROP R@ 2 CELLS + H@ SWAP
> 1+ DUP R@ 3 CELLS + 2+ H@ < NOT IF
> DROP R@ 3 CELLS + H@ SWAP R@ CELL+ 2H!
> R> R> DROP FALSE EXIT
> THEN SWAP THEN 2DUP 1+ R@ CELL+ 2H!
> R> R> AT-END ! TRUE ;
>
> Factors or not, writing such routines (I would think) requires more
> than can easily be remembered yet there's nothing there to help the
> programmer or reader. Either forth programmers have exceptional
> memories - or they're taught by example any aids used during
> writing should be removed afterwards.
Yes, that is pretty horrible code!
Code like this can be simplified considerably by using structs. Here is some example code from my STUNDURD.TXT file:
0
w field .x
w field .y
constant point
0
point field .a
point field .b
constant line
: line.length \ ^line -- length
>r
r@ .a .x @ r@ .b .x @ - dup m*
r@ .a .y @ r@ .b .y @ - dup m* d+ msqrt
rdrop ;
This could arguably be improved by using local variables like this:
: line.length { ^line -- length }
^line .a .x @ ^line .b .x @ - dup m*
^line .a .y @ ^line .b .y @ - dup m* d+ msqrt ;
Whether you use local variables or not though, structs are a good way to package related data. Without structs, LINE.LENGTH would have 4 parameters on the data stack. Now, you either have to use local variables or do a lot of stack-juggling because you have more than 3 parameters on the stack which is typically considered to be the most that you want. Also, it is not clear that these 4 parameters represent a single line segment.
If you wrote a function to calculate the intersection of two line segments, you would have 8 parameters on the stack, which is way too many.
I have never seen any Forth Inc. book that provided a definition of FIELD (I have it in the novice package). I was programming in Forth immediately after high school and had only read Forth Inc. books ("Starting Forth" and "Thinking Forth"), and I didn't know what a struct was. It was only after I learned C that I learned about structs, and then I brought the knowledge back to Forth. Almost everything that I know about computer science was learned in non-Forth languages and then brought back to Forth.
Forth is a good language, but we have never had anybody to teach Forth --- the result is a lot of horrible Forth code floating around written by people who don't really know anything about computer science, and this tends to give Forth a bad reputation --- Forth is not an inherently bad language though, but it can be good if the programmer is knowledgeable in computer science concepts (knows what a struct is, for example).
Forth could have been successful if there had been any leadership in the Forth community in the 1980s, but there was a complete lack of leadership. Now, 30 years later, we still have a lack of leadership. The Forth-200x committee claim to be our leadership, but they are a purely negative contribution --- all of the committee members were appointed by Elizabeth Rather and all of them are mandated to make Forth-200x 100% compatible with ANS-Forth, which was Elizabeth Rather's marketing gimmick in 1994 designed to convince the world that Forth Inc. sets the standard for Forth --- nobody is making any effort to help novice Forth programmers learn Forth and become capable of writing non-trivial programs (very few people are writing non-trivial Forth programs themselves, so they can hardly teach other people how to do so).
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-02-18 14:53 -0800 |
| Message-ID | <1772e81c-f15d-4d7a-90db-badf4dab523d@googlegroups.com> |
| In reply to | #45607 |
On Thursday, February 18, 2016 at 2:27:38 PM UTC-6, hughag...@gmail.com wrote:
> On Thursday, February 18, 2016 at 12:48:59 AM UTC-7, HAA wrote:
> >
> > Examples from a SwiftForth demo:
> >
> > : G.WALL ( y x r c b -- y x' )
> > >R 2DUP R@ ?SQUARE IF
> > 2DUP VISITED ?SQUARE IF
> > R@ ADJACENT VISITED ?SQUARE IF
> > BRUSH .BEEN @
> > ELSE BRUSH .OPEN @
> > THEN ELSE 2DROP BRUSH .OPEN @ THEN
> > ELSE 2DROP BRUSH .WALL @
> > THEN DRAW-ELEMENT R> DROP ;
> >
> > : RELINK-MAZE ( a -- r c t | a f ) DUP >R FROM-BEGINNING
> > DUP >R CELL+ 2H@ DUP R@ 2 CELLS + 2+ H@ < NOT IF
> > DROP R@ 2 CELLS + H@ SWAP
> > 1+ DUP R@ 3 CELLS + 2+ H@ < NOT IF
> > DROP R@ 3 CELLS + H@ SWAP R@ CELL+ 2H!
> > R> R> DROP FALSE EXIT
> > THEN SWAP THEN 2DUP 1+ R@ CELL+ 2H!
> > R> R> AT-END ! TRUE ;
> >
> > Factors or not, writing such routines (I would think) requires more
> > than can easily be remembered yet there's nothing there to help the
> > programmer or reader. Either forth programmers have exceptional
> > memories - or they're taught by example any aids used during
> > writing should be removed afterwards.
I imagine that you think you should be able to place your finger on
a random word of code and be able to instantly know what exactly is
on the stack at that that point. But the stack is *state*. You
can't say this about any kind of state that gets modified constantly
in any program in any language. You always have to step through the
context. You always start with localized answers like "well this
part is clearly assuming this about the state".
Take a random line of that code:
> > DROP R@ 2 CELLS + H@ SWAP
( x1 x2 ) ( R: a1 )
DROP R@ 2 CELLS + H@ SWAP
( a1 x1 ) ( R: a1 )
Or read it word-for-word, with your inferences about the stack
following, and your developing knowledge about the overall effect of
the stack following:
DROP ( x -- ) ( x -- )
R@ ( R: x -- x ) ( x1 -- x2 ) ( R: x2 -- x2 )
2 ( -- 2 ) ( x1 -- x2 2 ) ( R: x2 -- x2 )
CELLS ( x -- x' ) ( x1 -- x2 2*CELLS ) ( R: x2 -- x2 )
+ ( x1 x2 -- x3 ) ( x -- a[2*cells] ) ( R: a -- a )
H@ ( a -- w ) ( x -- w ) ( R: a -- a )
SWAP ( a b -- b a ) ( x1 x2 -- w x1 ) ( R: a -- a )
Saying that you actually need to write code like this to understand
the Forth is like saying that the way people teach you to attack and
decipher Latin sentences is how the Romans did things. There's a
lot of poetry in Latin utterances that's rendered senseless when you
forget that Romans listened and understood each word as it was
uttered. You can inject similar 'poetry' in your Forth with
phrasing:
DROP R@ 2 CELLS + H@ SWAP
Which emphasizes subcomponents which each individually have a clear
stack effect. In this specific case, the stack effect instantly
obvious to anyone who's actually a Forth programmer, but in general
you'll have to also know about application words. Superhuman powers
or secretly disposed-of stack comments are not required.
>
> Yes, that is pretty horrible code!
>
"Is Forth readable?"
"I can't say myself, but I asked some Forth programmers and they all
agreed that anything written by another Forth programmer was awful
beyond belief."
>
> I was programming in Forth immediately after high school and had only read [...] "Starting Forth" and "Thinking Forth"[...], and I didn't know what a struct was. It was only after I learned C that I learned about structs, and then I brought the knowledge back to Forth. Almost everything that I know about computer science was learned in non-Forth languages and then brought back to Forth.
>
This explains a lot of your bitterness, but it's unusual for Forth
to be a first programming language. These days, gforth is likely to
be the first Forth anyone uses (it was for me, for the same reasons
I think it would be for others), and gforth clearly documents a
structures extension and several OO extensions. Personally I
learned C and several other languages before Forth and it was only
after learning Forth that I had any sense of how programs use memory
and what a 'pointer' is.
BTW, for decades now my dreams have had this trope where I can float
around as a normal form of locomotion. I'd just raise my feet off
the ground, bend my knees, and zip about. It feels completely
natural. Going down stairs? Just float down them, it's easier and
anyone can do it anyway. This has been in my dreams for decades.
It was only a few years ago that I realized that my dreamt
experiences had an exact waking analogue: bike riding. All this
time some primitive part of my brain didn't understand what was
really going on when I would get on a bike; while I was just having
fun, that part of me was having a magical experience.
I mention that because learning Forth, with gforth, and gforth's
documentation, was a magical experience for me. I can't explain
what was so great about it. The world, the interaction, just took
on a glamour. Somehow
: hi cr ." Hello, world!" ; ok
hi
Hello, world! ok
was just so much more amazing than
>>> def hi(): print "hello, world!"
...
>>> hi()
hello, world!
I started with the crash course, that began by having you type in
things that killed gforth. And I laughed at the footnote in the
structures documentation, which said that Wirth wrote a new compiler
for a new language for a feature that Forth added with a few lines
of code.
There's more advocacy for Forth in little comments like that, or in
fun pages like Anton's "how much do we have to break Forth before a
Quine becomes an interesting challenge for it?", than there is in
everything you've ever written about how awful Forth-as-it-is is.
-- Julian
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-02-18 15:18 -0800 |
| Message-ID | <70c71f48-2bfe-4092-8b91-0d8ecc4fdc92@googlegroups.com> |
| In reply to | #45610 |
On Thursday, February 18, 2016 at 4:53:57 PM UTC-6, Julian Fondren wrote: > > There's more advocacy for Forth in little comments like that, or in > fun pages like Anton's "how much do we have to break Forth before a > Quine becomes an interesting challenge for it?", than there is in > everything you've ever written about how awful Forth-as-it-is is. > I went on for a bit, and then cut all that out; the abrupt ends makes this sound harsher than I'd intended it to. -- Julian
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-02-21 13:32 +1100 |
| Message-ID | <nab7ko$1onb$1@gioia.aioe.org> |
| In reply to | #45607 |
hughaguilar96@gmail.com wrote:
> On Thursday, February 18, 2016 at 12:48:59 AM UTC-7, HAA wrote:
> > Elizabeth D. Rather wrote:
> > > On 2/15/16 9:28 PM, Anton Ertl wrote:
> > > > "HAA" <someone@microsoft.com> writes:
> > > ...
> > > >> So how do they handle multi-line definitions? In the same
> > > >> way as raw beginners - by jotting down stack effects as they go.
> > > >> These working comments are removed when the definition is complete.
> > > >
> > > > Maybe you work that way, I don't. When the stack work is complex
> > > > enough to write down stack pictures, I keep them. They then also help
> > > > in reading the code.
> >
> > Very rarely do I see stack comments within the body of a definition.
>
> I do that all the time.
>
> As a rule, whenever I have a BEGIN WHILE REPEAT loop, I put the BEGIN WHILE on one line
> with a stack-picture after it.
> ...
It makes perfect sense that a stack-based language needs stack-based
commentary to be readable. Take it out and the code becomes 'write only'
- a frequent complaint of Forth.
Forth primers are largely silent on this topic. The closest I found was the
Open Firmware guidelines published in FPH (section 8.2).
8.2.8 Stack Comments
Stack comments begin with (_ and end with ).
*** Use stack comments liberally within definitions. ***
Try to structure each definition so that, when you put stack
comments at the end of each line, the stack picture
makes a nice pattern.
OFW practice what they preach:
: do-buffer ( apf -- adr )
dup >user @ if ( apf )
>user @ ( adr )
else ( apf )
dup /user# + @ ( apf size )
dup alloc-mem ( apf size adr )
dup rot erase ( apf adr )
dup rot >user ! ( adr )
then
;
Which code would you prefer to work with - with or without the stack
comments? It's a 'no brainer'. Yet forthers persist writing them without.
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2016-02-20 20:57 -0800 |
| Message-ID | <06f08b00-e47e-4ead-b569-d5a83da39fd2@googlegroups.com> |
| In reply to | #45648 |
On Saturday, February 20, 2016 at 9:33:05 PM UTC-5, HAA wrote: > > Which code would you prefer to work with - with or without the stack > comments? It's a 'no brainer'. Yet forthers persist writing them without. I think you are over-generalizing a little. Everyone is different and has different levels of experience and understanding. Some programmers have enough experience that the stack comments are obvious and un-necessary. Others prefer more explicit stack frames. I use them sometimes, other times I don't feel there is a need for them. like C++ code as follows: int a = 0; // declare variable a with value of 0. int b = 1; // declare variable b with value of 1. int c = a+b; // declare variable c with sum of a and b. These comments are completely pointless because it is obvious what is going on. Stack frame comments are also stating the obvious. The more experience you have, the less you need them.
[toc] | [prev] | [next] | [standalone]
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2016-02-21 07:23 +0200 |
| Message-ID | <nabhec$i8l$1@dont-email.me> |
| In reply to | #45649 |
On 21/02/2016 06:57, Chris Curl wrote: > On Saturday, February 20, 2016 at 9:33:05 PM UTC-5, HAA wrote: > int a = 0; // declare variable a with value of 0. > int b = 1; // declare variable b with value of 1. > int c = a+b; // declare variable c with sum of a and b. > > These comments are completely pointless because it is obvious what is going on. Stack > frame comments are also stating the obvious. The more experience you have, the less > you need them. Perhaps, but if you work with others you need to make sure everyone in the group can follow the code as well as you can. What seems obvious to a more experienced programmer may very well not be so to a more junior one.
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2016-02-21 08:54 -0800 |
| Message-ID | <14cd6513-b92e-41ec-ae31-0b346760d208@googlegroups.com> |
| In reply to | #45650 |
On Sunday, February 21, 2016 at 12:23:12 AM UTC-5, Ron Aaron wrote: > > Perhaps, but if you work with others you need to make sure everyone in > the group can follow the code as well as you can. What seems obvious to > a more experienced programmer may very well not be so to a more junior one. Fair enough.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-02-21 22:05 -0800 |
| Message-ID | <fb300f0f-ad1c-4640-81b5-94405da90f75@googlegroups.com> |
| In reply to | #45648 |
On Saturday, February 20, 2016 at 7:33:05 PM UTC-7, HAA wrote:
> OFW practice what they preach:
>
> : do-buffer ( apf -- adr )
> dup >user @ if ( apf )
> >user @ ( adr )
> else ( apf )
> dup /user# + @ ( apf size )
> dup alloc-mem ( apf size adr )
> dup rot erase ( apf adr )
> dup rot >user ! ( adr )
> then
> ;
>
> Which code would you prefer to work with - with or without the stack
> comments? It's a 'no brainer'. Yet forthers persist writing them without.
That example has unnecessary comments, and it is too vertical. I would write it like this:
: do-buffer ( apf -- adr )
dup >user @ if
>user @ \ -- adr
else
dup /user# + @ dup alloc-mem \ -- apf size adr
dup rot erase \ -- apf adr
dup rot >user ! \ -- adr
then ;
Actually, I find ROT to be confusing. It is difficult to keep track of in my head because the data on the stack are swapping places in a complicated manner. I would write the code like this instead:
: do-buffer ( apf -- adr )
dup >user @ if
>user @ \ -- adr
else
dup /user# + @ dup alloc-mem \ -- apf size adr
tuck swap erase \ -- apf adr
tuck swap >user ! \ -- adr
then ;
I think that TUCK is easier to understand --- it is obvious that we are tucking a datum away because it will be kept on the stack for later use (the ADR is getting tucked away each time). Most likely those guys didn't have TUCK available --- Forth systems didn't have TUCK in the 1980s, but it was only in the 1990s that TUCK got invented (I don't know by whom).
Also, note how I use two spaces on the line with ALLOC-MEM to separate the code producing the two data.
Also, note how I use different indentation rules than the original code. I put the THEN on the same level as the code inside. Sometimes I put the THEN on the last line of code rather than give it a line of its own --- that just reduces the number of lines --- I didn't do that here though.
[toc] | [prev] | [next] | [standalone]
Page 1 of 6 [1] 2 3 4 5 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web