Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #36318 > unrolled thread
| Started by | Aliaksei Chapyzhenka <alex.drom@gmail.com> |
|---|---|
| First post | 2015-02-05 20:01 -0800 |
| Last post | 2015-02-08 10:51 +0000 |
| Articles | 20 on this page of 111 — 18 participants |
Back to article view | Back to comp.lang.forth
Static Single Assignment form to Stack allocation Aliaksei Chapyzhenka <alex.drom@gmail.com> - 2015-02-05 20:01 -0800
Re: Static Single Assignment form to Stack allocation Paul Rubin <no.email@nospam.invalid> - 2015-02-05 21:00 -0800
Re: Static Single Assignment form to Stack allocation "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-02-06 02:15 -0500
Re: Static Single Assignment form to Stack allocation Paul Rubin <no.email@nospam.invalid> - 2015-02-06 12:07 -0800
Re: Static Single Assignment form to Stack allocation Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-02-08 22:38 +0000
Re: Static Single Assignment form to Stack allocation Paul Rubin <no.email@nospam.invalid> - 2015-02-08 14:55 -0800
Re: Static Single Assignment form to Stack allocation Aliaksei Chapyzhenka <alex.drom@gmail.com> - 2015-02-08 19:59 -0800
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-06 13:15 +0000
Re: Static Single Assignment form to Stack allocation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-02-06 13:22 +0000
Re: Static Single Assignment form to Stack allocation Aliaksei Chapyzhenka <alex.drom@gmail.com> - 2015-02-06 11:16 -0800
Re: Static Single Assignment form to Stack allocation Paul Rubin <no.email@nospam.invalid> - 2015-02-06 12:05 -0800
Re: Static Single Assignment form to Stack allocation hughaguilar96@gmail.com - 2015-02-06 16:44 -0800
Re: Static Single Assignment form to Stack allocation "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-02-06 23:41 -0500
Re: Static Single Assignment form to Stack allocation "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-02-06 23:41 -0500
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-07 19:22 +0000
Re: Static Single Assignment form to Stack allocation Aliaksei Chapyzhenka <alex.drom@gmail.com> - 2015-02-07 13:09 -0800
Re: Static Single Assignment form to Stack allocation "Elizabeth D. Rather" <erather@forth.com> - 2015-02-07 11:25 -1000
Re: Static Single Assignment form to Stack allocation Aliaksei Chapyzhenka <alex.drom@gmail.com> - 2015-02-07 14:09 -0800
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-07 22:32 +0000
Re: Static Single Assignment form to Stack allocation Aliaksei Chapyzhenka <alex.drom@gmail.com> - 2015-02-07 14:51 -0800
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-08 00:04 +0000
Re: Static Single Assignment form to Stack allocation Aliaksei Chapyzhenka <alex.drom@gmail.com> - 2015-02-07 17:03 -0800
Re: Static Single Assignment form to Stack allocation "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-02-07 21:04 -0500
Re: Static Single Assignment form to Stack allocation "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-02-07 21:10 -0500
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-08 10:57 +0000
Re: Static Single Assignment form to Stack allocation "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-02-07 21:05 -0500
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-07 22:24 +0000
Re: Static Single Assignment form to Stack allocation "Elizabeth D. Rather" <erather@forth.com> - 2015-02-07 11:21 -1000
Re: Static Single Assignment form to Stack allocation "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-02-07 20:11 -0500
Re: Static Single Assignment form to Stack allocation "Elizabeth D. Rather" <erather@forth.com> - 2015-02-07 15:35 -1000
Re: Static Single Assignment form to Stack allocation "Elizabeth D. Rather" <erather@forth.com> - 2015-02-07 16:52 -1000
Re: Static Single Assignment form to Stack allocation hughaguilar96@gmail.com - 2015-02-08 10:21 -0800
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-08 20:09 +0000
Re: Static Single Assignment form to Stack allocation "Elizabeth D. Rather" <erather@forth.com> - 2015-02-08 17:15 -1000
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-09 12:00 +0000
Re: Static Single Assignment form to Stack allocation albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-02-09 13:05 +0000
Re: Static Single Assignment form to Stack allocation "HAA" <someone@microsoft.com> - 2015-02-10 16:01 +1100
Re: Static Single Assignment form to Stack allocation "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-02-09 02:35 -0500
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-09 12:03 +0000
Re: Static Single Assignment form to Stack allocation hughaguilar96@gmail.com - 2015-02-08 10:13 -0800
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-08 20:21 +0000
Re: Static Single Assignment form to Stack allocation hughaguilar96@gmail.com - 2015-02-09 22:49 -0800
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-10 12:12 +0000
Re: Static Single Assignment form to Stack allocation albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-02-10 12:54 +0000
Re: Static Single Assignment form to Stack allocation Mark Wills <markwills1970@gmail.com> - 2015-02-10 06:30 -0800
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-10 14:53 +0000
Re: Static Single Assignment form to Stack allocation "Elizabeth D. Rather" <erather@forth.com> - 2015-02-10 08:20 -1000
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-10 14:33 +0000
Re: Static Single Assignment form to Stack allocation albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-02-10 19:09 +0000
Control-flow stack (was: Static Single Assignment ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-02-10 14:29 +0000
Re: Control-flow stack (was: Static Single Assignment ...) "Alex McDonald" <blog@rivadpm.com> - 2015-02-10 15:49 +0000
Re: Control-flow stack (was: Static Single Assignment ...) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-02-10 17:56 +0000
Re: Control-flow stack (was: Static Single Assignment ...) "Alex McDonald" <blog@rivadpm.com> - 2015-02-10 20:53 +0000
Re: Control-flow stack "Elizabeth D. Rather" <erather@forth.com> - 2015-02-10 13:08 -1000
Re: Control-flow stack awegel@arcor.de (Alexander Wegel) - 2015-02-11 03:15 +0100
Re: Control-flow stack hughaguilar96@gmail.com - 2015-02-10 18:47 -0800
Re: Control-flow stack Unknown <dog@gmail.com> - 2015-02-17 07:13 +0000
Re: Control-flow stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-02-11 17:59 +0000
Re: Control-flow stack (was: Static Single Assignment ...) Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-02-11 01:30 -0800
Re: Control-flow stack (was: Static Single Assignment ...) "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-02-10 18:43 -0500
Re: Control-flow stack (was: Static Single Assignment ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-02-11 17:46 +0000
Re: Control-flow stack (was: Static Single Assignment ...) "Alex McDonald" <blog@rivadpm.com> - 2015-02-11 22:39 +0000
Re: Control-flow stack (was: Static Single Assignment ...) "Alex McDonald" <blog@rivadpm.com> - 2015-02-11 22:42 +0000
Re: Control-flow stack (was: Static Single Assignment ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-02-12 09:52 +0000
Re: Control-flow stack (was: Static Single Assignment ...) "Alex McDonald" <blog@rivadpm.com> - 2015-02-12 10:28 +0000
Re: Control-flow stack (was: Static Single Assignment ...) hughaguilar96@gmail.com - 2015-02-11 20:23 -0800
Re: Control-flow stack (was: Static Single Assignment ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-02-12 07:21 +0000
Re: Control-flow stack (was: Static Single Assignment ...) hughaguilar96@gmail.com - 2015-02-12 18:33 -0800
Re: Control-flow stack awegel@arcor.de (Alexander Wegel) - 2015-02-13 04:46 +0100
Re: Control-flow stack "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-02-13 06:48 -0500
Re: Control-flow stack awegel@arcor.de (Alexander Wegel) - 2015-02-13 13:40 +0100
Re: Control-flow stack albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-02-13 15:49 +0000
Re: Control-flow stack awegel@arcor.de (Alexander Wegel) - 2015-02-14 03:47 +0100
Re: Control-flow stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-02-13 16:09 +0000
Re: Control-flow stack (was: Static Single Assignment ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-02-13 15:20 +0000
Re: Control-flow stack (was: Static Single Assignment ...) hughaguilar96@gmail.com - 2015-02-13 21:31 -0800
Re: Control-flow stack awegel@arcor.de (Alexander Wegel) - 2015-02-14 03:47 +0100
Re: Control-flow stack (was: Static Single Assignment ...) hughaguilar96@gmail.com - 2015-02-14 19:22 -0800
Re: Control-flow stack (was: Static Single Assignment ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-02-15 11:09 +0000
Re: Control-flow stack (was: Static Single Assignment ...) hughaguilar96@gmail.com - 2015-02-15 16:57 -0800
Re: Control-flow stack (was: Static Single Assignment ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-02-16 14:41 +0000
Re: Control-flow stack (was: Static Single Assignment ...) hughaguilar96@gmail.com - 2015-02-16 18:43 -0800
Re: Control-flow stack Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-02-10 22:04 +0000
Re: Control-flow stack Harold <hzrabbie@gmail.com> - 2015-02-10 16:58 -0800
Re: Control-flow stack Bernd Paysan <bernd.paysan@gmx.de> - 2015-02-11 02:51 +0100
Re: Control-flow stack albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-02-11 11:34 +0000
Re: Control-flow stack Harold <hzrabbie@gmail.com> - 2015-02-11 08:17 -0800
Re: Control-flow stack "Elizabeth D. Rather" <erather@forth.com> - 2015-02-10 16:37 -1000
Re: Control-flow stack hughaguilar96@gmail.com - 2015-02-10 18:57 -0800
Re: Static Single Assignment form to Stack allocation "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-02-10 18:44 -0500
Re: Static Single Assignment form to Stack allocation "Elizabeth D. Rather" <erather@forth.com> - 2015-02-10 14:49 -1000
Re: Static Single Assignment form to Stack allocation hughaguilar96@gmail.com - 2015-02-10 18:16 -0800
Re: Static Single Assignment form to Stack allocation Mark Wills <markwills1970@gmail.com> - 2015-02-11 00:35 -0800
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-11 09:35 +0000
Re: Static Single Assignment form to Stack allocation Mark Wills <markwills1970@gmail.com> - 2015-02-11 03:06 -0800
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-11 14:27 +0000
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-11 14:40 +0000
Re: Static Single Assignment form to Stack allocation "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-02-12 20:02 -0500
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-13 11:42 +0000
Re: Static Single Assignment form to Stack allocation "Rod Pemberton" <buzz@notnotnontnooatno.cmm> - 2015-02-13 07:44 -0500
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-13 14:20 +0000
Re: Static Single Assignment form to Stack allocation "Elizabeth D. Rather" <erather@forth.com> - 2015-02-13 10:32 -1000
Re: Static Single Assignment form to Stack allocation "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-03-29 16:27 -0400
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-03-29 22:46 +0100
Re: Static Single Assignment form to Stack allocation "Elizabeth D. Rather" <erather@forth.com> - 2015-03-29 15:24 -1000
Re: Static Single Assignment form to Stack allocation hughaguilar96@gmail.com - 2015-03-30 04:44 -0700
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-03-30 15:33 +0100
Re: Static Single Assignment form to Stack allocation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-02-11 18:03 +0000
Re: Static Single Assignment form to Stack allocation Bernd Paysan <bernd.paysan@gmx.de> - 2015-02-12 00:16 +0100
Re: Static Single Assignment form to Stack allocation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-02-12 07:08 +0000
Re: Static Single Assignment form to Stack allocation "Alex McDonald" <blog@rivadpm.com> - 2015-02-08 10:51 +0000
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-02-11 17:46 +0000 |
| Subject | Re: Control-flow stack (was: Static Single Assignment ...) |
| Message-ID | <2015Feb11.184639@mips.complang.tuwien.ac.at> |
| In reply to | #36432 |
"Alex McDonald" <blog@rivadpm.com> writes:
>Category A. Hugh (and possibly Albert) wants the control flow stack to
>*not* be the data stack.
I have done more metaprogramming in Forth than most other Forth
programmers (e.g., the Gray parser generator generates executable
Forth code, including control structures); a separate control-flow
stack would have helped relatively little. Requiring it would be a
burden for implementors, especially on small systems. I certainly
don't see that being standardized in the foreseeable future (I tend to
weigh programmer convenience over implementor convenience more than
most Forth committee members and implementors).
>> * Programmers could use DEPTH to find out the size of an individual
>> control-flow stack item, and then copy it, store it to memory, or
>> otherwise manipulate it.
>
>Ouch. They can do that anyway for words with orig and dest.
They cannot store these items to memory, and load them later or
something (e.g., for implementing labels and gotos).
But the things you might do with that are probably more than we want
to guarantee; e.g., a programmer might store an orig or dest in one
definition and use it in another. On some compilers this might work,
on others maybe not. We probably don't want to specify the things
that you can do in that way (I don't see any common practice for doing
such things), so the standard looks good to me in this area as it is.
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-02-11 22:39 +0000 |
| Subject | Re: Control-flow stack (was: Static Single Assignment ...) |
| Message-ID | <mbglmo$7rs$1@dont-email.me> |
| In reply to | #36479 |
on 11/02/2015 17:46:36, wrote: > "Alex McDonald" <blog@rivadpm.com> writes: >>Category A. Hugh (and possibly Albert) wants the control flow stack to >>*not* be the data stack. > > I have done more metaprogramming in Forth than most other Forth > programmers (e.g., the Gray parser generator generates executable > Forth code, including control structures); a separate control-flow > stack would have helped relatively little. That's also been my experience while supporting the Win32Forth meta-compiler. > >>> * Programmers could use DEPTH to find out the size of an individual >>> control-flow stack item, and then copy it, store it to memory, or >>> otherwise manipulate it. >> >>Ouch. They can do that anyway for words with orig and dest. > > They cannot store these items to memory, and load them later or > something (e.g., for implementing labels and gotos). > Why not? Removing an IFs orig should effectively remove the IF from the compile stream, since there is no code generated (at least on the CPU architecures I know where there's no requirement to identify a branch target) and the orig is the only evidence of the IF.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-02-11 22:42 +0000 |
| Subject | Re: Control-flow stack (was: Static Single Assignment ...) |
| Message-ID | <mbglr9$8mi$1@dont-email.me> |
| In reply to | #36485 |
on 11/02/2015 22:39:56, "Alex McDonald" wrote: > on 11/02/2015 17:46:36, wrote: >> "Alex McDonald" <blog@rivadpm.com> writes: >>>Category A. Hugh (and possibly Albert) wants the control flow stack to >>>*not* be the data stack. >> >> I have done more metaprogramming in Forth than most other Forth >> programmers (e.g., the Gray parser generator generates executable >> Forth code, including control structures); a separate control-flow >> stack would have helped relatively little. > > That's also been my experience while supporting the Win32Forth > meta-compiler. > >> >>>> * Programmers could use DEPTH to find out the size of an individual >>>> control-flow stack item, and then copy it, store it to memory, or >>>> otherwise manipulate it. >>> >>>Ouch. They can do that anyway for words with orig and dest. >> >> They cannot store these items to memory, and load them later or >> something (e.g., for implementing labels and gotos). >> > > Why not? Removing an IFs orig should effectively remove the IF from > the compile stream, since there is no code generated (at least on the > CPU architecures I know where there's no requirement to identify a > branch target) and the orig is the only evidence of the IF. Belay that and delete, this newsreader I'm using has a send but no save draft button, and I prematurely fired this off. It's obvious that THEN is the target of the branch at IF.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-02-12 09:52 +0000 |
| Subject | Re: Control-flow stack (was: Static Single Assignment ...) |
| Message-ID | <2015Feb12.105235@mips.complang.tuwien.ac.at> |
| In reply to | #36485 |
"Alex McDonald" <blog@rivadpm.com> writes:
>>>> * Programmers could use DEPTH to find out the size of an individual
>>>> control-flow stack item, and then copy it, store it to memory, or
>>>> otherwise manipulate it.
>>>
>>>Ouch. They can do that anyway for words with orig and dest.
>>
>> They cannot store these items to memory, and load them later or
>> something (e.g., for implementing labels and gotos).
>>
>
>Why not?
The data might be on a separate control-flow stack, and in a standard
program we cannot use ! on that data, or get its address or
something.
> Removing an IFs orig should effectively remove the IF from the
>compile stream, since there is no code generated (at least on the CPU
>architecures I know where there's no requirement to identify a branch
>target) and the orig is the only evidence of the IF.
The IF typically generates an unresolved branch, so on most (all?)
systems just removing the orig and never resolving the IF would result
in code that does not work.
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-02-12 10:28 +0000 |
| Subject | Re: Control-flow stack (was: Static Single Assignment ...) |
| Message-ID | <mbhv6j$7h2$1@dont-email.me> |
| In reply to | #36497 |
on 12/02/2015 09:52:33, wrote: > "Alex McDonald" <blog@rivadpm.com> writes: >>>>> * Programmers could use DEPTH to find out the size of an individual >>>>> control-flow stack item, and then copy it, store it to memory, or >>>>> otherwise manipulate it. >>>> >>>>Ouch. They can do that anyway for words with orig and dest. >>> >>> They cannot store these items to memory, and load them later or >>> something (e.g., for implementing labels and gotos). >>> >> >>Why not? Ah > > The data might be on a separate control-flow stack, and in a standard > program we cannot use ! on that data, or get its address or > something. > >> Removing an IFs orig should effectively remove the IF from the >>compile stream, since there is no code generated (at least on the CPU >>architecures I know where there's no requirement to identify a branch >>target) and the orig is the only evidence of the IF. > > The IF typically generates an unresolved branch, so on most (all?) > systems just removing the orig and never resolving the IF would result > in code that does not work. > Yes, I corrected myself about 20ms after I sent this. Newsreaders on Windows (or specifically NewsMan, the clunkiest piece of software I've used in a long time) suck, and I sent by mistake. ((Belay that and delete, this newsreader I'm using has a send but no save draft button, and I prematurely fired this off. It's obvious that THEN is the target of the branch at IF.)) > - anton
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-02-11 20:23 -0800 |
| Subject | Re: Control-flow stack (was: Static Single Assignment ...) |
| Message-ID | <587613c2-2804-4ee0-9c41-5503306ff33a@googlegroups.com> |
| In reply to | #36479 |
On Wednesday, February 11, 2015 at 10:58:03 AM UTC-7, Anton Ertl wrote: > I have done more metaprogramming in Forth than most other Forth > programmers (e.g., the Gray parser generator generates executable > Forth code, including control structures); Apparently you didn't have a LITERAL inside of any of these control structures that you generated --- or you would have noticed that getting the literal value to the LITERAL is a problem because the control-structures' control-flow data is on the data stack getting in the way. In this thread I did some meta-programming: https://groups.google.com/forum/#!searchin/comp.lang.forth/codejam/comp.lang.forth/3Y4w_MdYl0k/IMCaSNvF864J I found a bug in Gforth that limited the length of colon words. This isn't generally a problem with hand-written colon words, because Forth style is to write short colon words. It is more likely to be a problem in meta-programming, because unwinding loops is pretty common. The fact that this bug existed in Gforth indicates to me that none of the Gforth programmers (including yourself) had ever done any meta-programming in Gforth (at least, nothing that involved unwinding a loop) --- otherwise you would have found the bug --- the fact that I found the bug, indicates that I was one of the first people ever to do any meta-programming in Gforth. > a separate control-flow > stack would have helped relatively little. Requiring it would be a > burden for implementors, especially on small systems. I certainly > don't see that being standardized in the foreseeable future (I tend to > weigh programmer convenience over implementor convenience more than > most Forth committee members and implementors). Implementing a stack is a "burden for implementers"??? I would really expect anybody to be able to do this in one weekend --- we have already spent an order of magnitude more time discussing the problem, then would have been required to fix the problem. You aren't being consistent when you say that you weigh programmer convenience over implementer convenience, after complaining that implementing a stack is an onerous burden for implementers. If you cared about programmer convenience, you would allow the programmer to pass data into colon words on the data-stack at compile-time for use by LITERAL --- rather than force the programmer to use a work-around like I did in the many novice-package meta-programming words. Even though there is a work-around (use local variables) for the problem, the problem should still be fixed. ANS-Forth is gratuitously complicated. This is primarily due to the features clashing with each other. The student has to not only learn how the features work, but learn when they clash with each other (usually because some resource is being used for multiple unrelated features, and their data gets in each other's way) and avoid using the features together --- these kinds of pointless restrictions make ANS-Forth difficult to learn --- this is why nobody wants to become an ANS-Forth programmer (if I were 18 today, I wouldn't want to learn ANS-Forth).
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-02-12 07:21 +0000 |
| Subject | Re: Control-flow stack (was: Static Single Assignment ...) |
| Message-ID | <2015Feb12.082133@mips.complang.tuwien.ac.at> |
| In reply to | #36491 |
hughaguilar96@gmail.com writes:
>On Wednesday, February 11, 2015 at 10:58:03 AM UTC-7, Anton Ertl wrote:
>> I have done more metaprogramming in Forth than most other Forth
>> programmers (e.g., the Gray parser generator generates executable
>> Forth code, including control structures);=20
>
>Apparently you didn't have a LITERAL inside of any of these control structu=
>res that you generated
Let's see:
1 max-member ok
0 singleton ' abort terminal t ok
t ?? parser test ok
see test
: test
140737329163752 abort
IF 140737329163752 abort abort
THEN ; ok
The 140737329163752 was generated with LITERAL, and one of them is
inside the IF.
> --- or you would have noticed that getting the liter=
>al value to the LITERAL is a problem because the control-structures' contro=
>l-flow data is on the data stack getting in the way.
In this program they did not get in the way. Let's look at the source
code for the code generation for the terminal T and for "??":
: compile-test ( set -- )
postpone literal
test-vector @ compile, ;
: generate-terminal ( -- )
this get-first compile-test
check&next compile, ;
: generate-option ( -- )
operand get-first compile-test
postpone if
operand generate
postpone endif ;
What's happening here is that Gray uses an object-oriented approach
akin to mini-oof2. I think it's the great-grandfather of mini-oof2;
like mini-oof2, but unlike the intermediate mini-oof it already has
the current object (THIS) and can access fields of THIS such as
OPERAND. In Gray a separate stack is used for that, but a VALUE and
the return stack would have been good enough (and is used in
objects.fs and I think mini-oof2). When calling GENERATE, the object
is removed from the data stack and put on the separate stack.
PARSER generates code for a "??" node and calls GENERATE which calls
GENERATE-OPTION, and that generates the IF, and then accesses THIS
(via OPERAND) to tell another instance of GENERATE what to generate
code for; so the control-flow stack item of the IF does not get in the
way. That GENERATE then calls GENERATE-TERMINAL, which calls LITERAL.
>In this thread I did some meta-programming:
>https://groups.google.com/forum/#!searchin/comp.lang.forth/codejam/comp.lang.forth/3Y4w_MdYl0k/IMCaSNvF864J
>I found a bug in Gforth that limited the length of colon words. This isn't =
>generally a problem with hand-written colon words, because Forth style is t=
>o write short colon words. It is more likely to be a problem in meta-progra=
>mming, because unwinding loops is pretty common. The fact that this bug exi=
>sted in Gforth indicates to me that none of the Gforth programmers (includi=
>ng yourself) had ever done any meta-programming in Gforth (at least, nothin=
>g that involved unwinding a loop) --- otherwise you would have found the bu=
>g --- the fact that I found the bug, indicates that I was one of the first =
>people ever to do any meta-programming in Gforth.
Here's the answer <2012Apr25.153938@mips.complang.tuwien.ac.at> to
your posting:
|That's a limitation in Gforth 0.6.*. Gforth 0.7.* does not have that
|limitation. BTW, this means that your program has a sequence of 128
|primitives without intervening control flow (no call to a colon
|definition or somesuch). Not many people complained about that
|limitation while 0.6.* was current, but I came across (IIRC) one
|program where it caused a problem, so I removed the limitation.
BTW, I just looked up when this limitation was removed in the
development version of Gforth, and it was in November 2003, 6 months
after it was introduced, and more than 8 years before you first
complained about it.
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-02-12 18:33 -0800 |
| Subject | Re: Control-flow stack (was: Static Single Assignment ...) |
| Message-ID | <756ccb89-2068-4d5a-84ef-5484a66e8778@googlegroups.com> |
| In reply to | #36496 |
On Thursday, February 12, 2015 at 1:34:30 AM UTC-7, Anton Ertl wrote: > hughaguilar96@gmail.com writes: > >On Wednesday, February 11, 2015 at 10:58:03 AM UTC-7, Anton Ertl wrote: > >> I have done more metaprogramming in Forth than most other Forth > >> programmers (e.g., the Gray parser generator generates executable > >> Forth code, including control structures);=20 > > > >Apparently you didn't have a LITERAL inside of any of these control structu= > >res that you generated > > Let's see: > > 1 max-member ok > 0 singleton ' abort terminal t ok > t ?? parser test ok > see test > : test > 140737329163752 abort > IF 140737329163752 abort abort > THEN ; ok > > The 140737329163752 was generated with LITERAL, and one of them is > inside the IF. > > > --- or you would have noticed that getting the liter= > >al value to the LITERAL is a problem because the control-structures' contro= > >l-flow data is on the data stack getting in the way. > > In this program they did not get in the way. Let's look at the source > code for the code generation for the terminal T and for "??": > > : compile-test ( set -- ) > postpone literal > test-vector @ compile, ; > > : generate-terminal ( -- ) > this get-first compile-test > check&next compile, ; > > : generate-option ( -- ) > operand get-first compile-test > postpone if > operand generate > postpone endif ; > > What's happening here is that Gray uses an object-oriented approach > akin to mini-oof2. I think it's the great-grandfather of mini-oof2; > like mini-oof2, but unlike the intermediate mini-oof it already has > the current object (THIS) and can access fields of THIS such as > OPERAND. In Gray a separate stack is used for that, but a VALUE and > the return stack would have been good enough (and is used in > objects.fs and I think mini-oof2). When calling GENERATE, the object > is removed from the data stack and put on the separate stack. > > PARSER generates code for a "??" node and calls GENERATE which calls > GENERATE-OPTION, and that generates the IF, and then accesses THIS > (via OPERAND) to tell another instance of GENERATE what to generate > code for; so the control-flow stack item of the IF does not get in the > way. That GENERATE then calls GENERATE-TERMINAL, which calls LITERAL. This is just a work-around for the bug in ANS-Forth --- are you really recommending that I use mini-OOF2 to do meta-compiling??? --- I'm not going to use mini-OOF2 for anything, and certainly not for meta-compiling (I have a lot of meta-compiling throughout the novice-package, and using mini-OOF2 would grossly over-complicate the novice-package for no purpose). ANS-Forth is over-complicated. We have a data-stack that is for passing data to functions --- but the data-stack fails to work at compile-time for a colon word --- and there is no explanation for why it fails to work under this circumstance, but this is just something that the student has to discover on his own and work around. It would obviously be better if the data-stack just worked consistently everywhere --- certainly easier to explain! Another example is that ANS-Forth fails to require code and data to be separate. It would obviously be better if the ANS-Forth document could just say that only comma, c-comma and ALLOT affect the data dictionary at HERE --- this way the programmer could use comma, c-comma and ALLOT and feel confident that nothing is going to clash with his data --- but instead, there are a wide variety of words that affect the data dictionary (colon, CONSTANT, etc.) and clash with the programmer's use of the dictionary, and there is no list in the ANS-Forth document that says which words will clash. ANS-Forth is a mish-mash of features that clash with each other --- there is no coherent design --- ANS-Forth was published without a reference compiler being written, so nobody had the opportunity to test ANS-Forth and notice that the features can't be used together. Nobody will ever take Forth seriously until ANS-Forth is abandoned --- you have to start over! --- there is nothing in ANS-Forth worth saving! > >In this thread I did some meta-programming: > >https://groups.google.com/forum/#!searchin/comp.lang.forth/codejam/comp.lang.forth/3Y4w_MdYl0k/IMCaSNvF864J > >I found a bug in Gforth that limited the length of colon words. This isn't = > >generally a problem with hand-written colon words, because Forth style is t= > >o write short colon words. It is more likely to be a problem in meta-progra= > >mming, because unwinding loops is pretty common. The fact that this bug exi= > >sted in Gforth indicates to me that none of the Gforth programmers (includi= > >ng yourself) had ever done any meta-programming in Gforth (at least, nothin= > >g that involved unwinding a loop) --- otherwise you would have found the bu= > >g --- the fact that I found the bug, indicates that I was one of the first = > >people ever to do any meta-programming in Gforth. > > Here's the answer <2012Apr25.153938@mips.complang.tuwien.ac.at> to > your posting: > > |That's a limitation in Gforth 0.6.*. Gforth 0.7.* does not have that > |limitation. BTW, this means that your program has a sequence of 128 > |primitives without intervening control flow (no call to a colon > |definition or somesuch). Not many people complained about that > |limitation while 0.6.* was current, but I came across (IIRC) one > |program where it caused a problem, so I removed the limitation. > > BTW, I just looked up when this limitation was removed in the > development version of Gforth, and it was in November 2003, 6 months > after it was introduced, and more than 8 years before you first > complained about it. You say: "Not many people complained about that limitation while 0.6.* was current, but I came across (IIRC) one program where it caused a problem, so I removed the limitation." This tells me that not many of the Gforth programmers (including yourself) had ever done any meta-programming in Gforth (at least, nothing that involved unwinding a loop) --- exactly what I just said in my last post. Also, I wasn't the one who complained about it. When I posted my program, I got this complaint (from the thread mentioned above): On Tuesday, April 24, 2012 at 4:59:20 PM UTC-7, Alex Wegel wrote: > It didn't work here (on gforth/powerpc) even for the small set, and i > didn't feel like debugging either of these packages (novice, list). > ... > It seems to me that the novice package was more an obstacle, rather than > a helpful tool (at least in this case). This was actually your Gforth bug that I was getting blamed for --- there are no bugs in novice.4th or list.4th. Here is another example (https://groups.google.com/forum/#!searchin/comp.lang.forth/lc53/comp.lang.forth/wP5nw1ClzsM/E-TV9v2y9RoJ) of a complaint directed at me: On Tuesday, November 24, 2009 at 11:37:04 PM UTC-7, ron wrote: > On Nov 25, 7:38 am, Hugh Aguilar <hugoagui...@rosycrew.com> wrote: > > I really > > need ANS-Forth in order to be able to run programs such as this. > > I suppose "gforth" is not an ANS-Forth? Your version of the program > does not compile under gforth 0.7.0: > > lc53.f:27: Cannot tick compile-only word (try COMP' ... DROP) > over ['] >>>;<<< = if 2drop postpone ; immediate exit > then This was actually your Gforth bug that I was getting blamed for --- some words in Gforth, such as semicolon, don't have an xt value and will cause tick to abort with a baffling error-message --- actually, this is a bug in the ANS-Forth design that says some words don't have an "execution semantics" (at least, this is what you claim that the ANS-Forth document says; I read 6.1.0460 and didn't see anything to indicate that I couldn't tick semicolon and get an xt, and the concept of a function without "execution semantics" is total nonsense that I did not predict based upon my 25 years of experience in Forth). Almost every time that I write a program, it fails under Gforth and I get blamed --- eventually it gets shown to be a bug in Gforth, not my code, but nobody ever apologizes for blaming me and saying that I write bug-ridden Forth code and don't know Forth --- this makes me want to avoid Gforth. I consider ANS-Forth to be a cult --- Alex Wegel is a cult member; he is entirely focused on claiming that I write bug-ridden Forth code and don't know Forth, and that there are no flaws in ANS-Forth --- your post here was also cult-behavior, no different from what Alex Wegel was saying. I think that you know perfectly well that ANS-Forth has serious design flaws (you're not an idiot) --- you just never admit that the flaws exist, or make any effort to fix the flaws in Forth-200x --- because you lack courage. You know that Elizabeth Rather will replace you on the committee if you show any disloyalty to ANS-Forth. There are many on comp.lang.forth, such as Alex Wegel and Alex McDonald, who would be happy to take your job and who would be totally loyal to ANS-Forth if you can't be. If necessary, Elizabeth Rather will go to the lunatic asylum and slip a hacksaw through the bars on the window --- two days later Elizabeth Rather will announce that Anton Ertl will no longer be on the Forth-200x committee because he wasn't a team player, and that John Passaniti will be the new chairperson of the Forth-200x committee --- the point I'm making, is that if your loyalty wavers, you will be replaced immediately with somebody who's loyalty won't waver, and so you have to defend the myriad gross flaws in ANS-Forth as long as you want to keep your job.
[toc] | [prev] | [next] | [standalone]
| From | awegel@arcor.de (Alexander Wegel) |
|---|---|
| Date | 2015-02-13 04:46 +0100 |
| Subject | Re: Control-flow stack |
| Message-ID | <1lzrmku.1fv6cmw1y8lgwkN%awegel@arcor.de> |
| In reply to | #36526 |
Liar.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <buzz@notnotnontnooatno.cmm> |
|---|---|
| Date | 2015-02-13 06:48 -0500 |
| Subject | Re: Control-flow stack |
| Message-ID | <op.xtzu3ecfv6dtjm@localhost> |
| In reply to | #36528 |
On Thu, 12 Feb 2015 22:46:25 -0500, Alexander Wegel <awegel@arcor.de> wrote: > Liar. You snipped all context and the header for the name of the person you replied to. When you do that, some Usenet newsreaders display your reply as a new thread, since they can't determine where to index the post without the replied to names, i.e., "wrote" lines. I have no idea whose post this was in reply to. I.e., did you just call me a "liar" or someone else? Fortunately, Google Groups, which has nothing to do with this Usenet group, shows the correct indexing based on message IDs. It was in reply to Hugh's post mentioning "mini-OOF2", which has replies to multiple people ... Please, stop snipping the replied to lines at the top of the post. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | awegel@arcor.de (Alexander Wegel) |
|---|---|
| Date | 2015-02-13 13:40 +0100 |
| Subject | Re: Control-flow stack |
| Message-ID | <1lzsa6n.kvj8lyp5o874N%awegel@arcor.de> |
| In reply to | #36532 |
Rod Pemberton <buzz@notnotnontnooatno.cmm> wrote: > On Thu, 12 Feb 2015 22:46:25 -0500, Alexander Wegel <awegel@arcor.de> > wrote: > > > Liar. > > You snipped all context and the header for the name of > the person you replied to. When you do that, some Usenet > newsreaders display your reply as a new thread, since > they can't determine where to index the post without > the replied to names, i.e., "wrote" lines. I'd propose using a usenet reader that isn't broken (i.e. one that isn't ignoring essential characteristics/features of usenet, such as the threading by message-ids that you mentioned). But ok, i might try to quote a little more in the future.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-02-13 15:49 +0000 |
| Subject | Re: Control-flow stack |
| Message-ID | <54de1cf7$0$14896$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #36533 |
In article <1lzsa6n.kvj8lyp5o874N%awegel@arcor.de>, Alexander Wegel <awegel@arcor.de> wrote: >Rod Pemberton <buzz@notnotnontnooatno.cmm> wrote: > >> On Thu, 12 Feb 2015 22:46:25 -0500, Alexander Wegel <awegel@arcor.de> >> wrote: >> >> > Liar. >> >> You snipped all context and the header for the name of >> the person you replied to. When you do that, some Usenet >> newsreaders display your reply as a new thread, since >> they can't determine where to index the post without >> the replied to names, i.e., "wrote" lines. > >I'd propose using a usenet reader that isn't broken (i.e. one that isn't >ignoring essential characteristics/features of usenet, such as the >threading by message-ids that you mentioned). You don't seem to appreciate how Usenet works. On a typical server message may expire in e.g. two weeks. That google has unlimited storage is neither here nor there. > >But ok, i might try to quote a little more in the future. A usenet article should be self contained. If I store an article, because I think it useful, then I should not be obliged to store a chain of articles, and make a note how they are linked. (Of course I won't even try, so the articles of A. Wegel will not be kept for posterity.) You could take Hugh as an example. He writes essays, he's not using Usenet as a chat room. His recent post of butchers and cattle is brilliant and coherent. (Not that I kept it.) 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]
| From | awegel@arcor.de (Alexander Wegel) |
|---|---|
| Date | 2015-02-14 03:47 +0100 |
| Subject | Re: Control-flow stack |
| Message-ID | <1lzt7my.l3mgjm1o50neoN%awegel@arcor.de> |
| In reply to | #36538 |
Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: > In article <1lzsa6n.kvj8lyp5o874N%awegel@arcor.de>, > Alexander Wegel <awegel@arcor.de> wrote: > >Rod Pemberton <buzz@notnotnontnooatno.cmm> wrote: > > > >> On Thu, 12 Feb 2015 22:46:25 -0500, Alexander Wegel <awegel@arcor.de> > >> wrote: > >> > >> > Liar. > >> > >> You snipped all context and the header for the name of > >> the person you replied to. When you do that, some Usenet > >> newsreaders display your reply as a new thread, since > >> they can't determine where to index the post without > >> the replied to names, i.e., "wrote" lines. > > > >I'd propose using a usenet reader that isn't broken (i.e. one that isn't > >ignoring essential characteristics/features of usenet, such as the > >threading by message-ids that you mentioned). > > You don't seem to appreciate how Usenet works. On a typical server > message may expire in e.g. two weeks. Irrelevant, because then my answer disappears with it ;-) (And: Is 2 weeks really typical? Sounds like totally low-end to me, especially for a comp.* text-only group) > >But ok, i might try to quote a little more in the future. > > A usenet article should be self contained. If I store an article, > because I think it useful, then I should not be obliged to store a > chain of articles, and make a note how they are linked. (Of course I > won't even try, so the articles of A. Wegel will not be kept for > posterity.) Well - i obviously didn't want to write an "article", i didn't even plan on participating in this particular sub-thread, but was getting annoyed by Hughs fact bending, so never mind: there's not really anything to be stored anyway (so far). Actually i started out by quoting it, but after my newsreader started complaining about Hughs overlong lines, i decided to not give this any more time than neccessary and completely stripped it (because this IS usenet, where discussions ARE threaded by message-ids). Looks like i have to give it some more..
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-02-13 16:09 +0000 |
| Subject | Re: Control-flow stack |
| Message-ID | <2015Feb13.170957@mips.complang.tuwien.ac.at> |
| In reply to | #36533 |
awegel@arcor.de (Alexander Wegel) writes:
>Rod Pemberton <buzz@notnotnontnooatno.cmm> wrote:
>
>> On Thu, 12 Feb 2015 22:46:25 -0500, Alexander Wegel <awegel@arcor.de>
>> wrote:
>>
>> > Liar.
>>
>> You snipped all context and the header for the name of
>> the person you replied to. When you do that, some Usenet
>> newsreaders display your reply as a new thread, since
>> they can't determine where to index the post without
>> the replied to names, i.e., "wrote" lines.
>
>I'd propose using a usenet reader that isn't broken (i.e. one that isn't
>ignoring essential characteristics/features of usenet, such as the
>threading by message-ids that you mentioned).
My news reader allows a threaded display, but I usually use the
chronological view, so I had no idea to what posting you were replying
to, either. And even if I use the threaded view, it shows me only the
unread postings. If a had read the posting you replied to earlier, I
won't see the posting you replied to when seeing your posting. And
then there is the classic Usenet issue of your posting appearing
before the one you replied to; maybe not as frequent as in earlier
times, but it still happens occasionally. Finally, and maybe most
importantly, even if one does know what posting you are replying to,
it does not tell us what particular statement you disagree with. All
good reasons for quoting the part you reply to.
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-02-13 15:20 +0000 |
| Subject | Re: Control-flow stack (was: Static Single Assignment ...) |
| Message-ID | <2015Feb13.162020@mips.complang.tuwien.ac.at> |
| In reply to | #36526 |
hughaguilar96@gmail.com writes:
>On Thursday, February 12, 2015 at 1:34:30 AM UTC-7, Anton Ertl wrote:
>> In this program they did not get in the way. Let's look at the source
>> code for the code generation for the terminal T and for "??":
>>=20
>> : compile-test ( set -- )
>> postpone literal
>> test-vector @ compile, ;
>>=20
>> : generate-terminal ( -- )
>> this get-first compile-test
>> check&next compile, ;
>>=20
>> : generate-option ( -- )
>> operand get-first compile-test
>> postpone if
>> operand generate
>> postpone endif ;
>>=20
>> What's happening here is that Gray uses an object-oriented approach
>> akin to mini-oof2. I think it's the great-grandfather of mini-oof2;
>> like mini-oof2, but unlike the intermediate mini-oof it already has
>> the current object (THIS) and can access fields of THIS such as
>> OPERAND. In Gray a separate stack is used for that, but a VALUE and
>> the return stack would have been good enough (and is used in
>> objects.fs and I think mini-oof2). When calling GENERATE, the object
>> is removed from the data stack and put on the separate stack.
>>=20
>> PARSER generates code for a "??" node and calls GENERATE which calls
>> GENERATE-OPTION, and that generates the IF, and then accesses THIS
>> (via OPERAND) to tell another instance of GENERATE what to generate
>> code for; so the control-flow stack item of the IF does not get in the
>> way. That GENERATE then calls GENERATE-TERMINAL, which calls LITERAL.
>
>This is just a work-around for the bug in ANS-Forth
That's ahistorical. Gray was first written in 1989 in fig-Forth and
then ported to TILE (Forth-83-inspired), and eventually ported to ANS
Forth. Already the first version had THIS and a separate stack for
the values of THIS.
It has been a long time, but I am pretty sure that I chose to use THIS
and a separate stack not primarily because IF etc. put stuff on the
data stack. The control flow words are also not the reason why
Mini-oof2 does not keep the current object on the data stack; the
reason is that because everything puts stuff on the data stack, and
keeping the current object on the data stack, like mini-oof does, just
results in lots of stack juggling.
So, the control-flow stack items on the data stack were not the reason
for this design; I guess if it was only control-flow items, I would
have just used >R R> around POSTPONE IF etc.
> --- are you really reco=
>mmending that I use mini-OOF2 to do meta-compiling???
As mentioned above, the most straightforward way to deal with passing
data from before POSTPONE IF to afterwards is to use >R and R>. But
other solutions may lead to better programs. For Gray the
mini-oof2-like stuff led to a good structure and as a side-effect
control-flow stack items were not in the way.
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-02-13 21:31 -0800 |
| Subject | Re: Control-flow stack (was: Static Single Assignment ...) |
| Message-ID | <914c5217-156c-4083-b3ae-b8d3094c11f4@googlegroups.com> |
| In reply to | #36539 |
On Friday, February 13, 2015 at 9:08:38 AM UTC-7, Anton Ertl wrote: > hughaguilar96@gmail.com writes: > >This is just a work-around for the bug in ANS-Forth > > That's ahistorical. Gray was first written in 1989 in fig-Forth and > then ported to TILE (Forth-83-inspired), and eventually ported to ANS > Forth. Already the first version had THIS and a separate stack for > the values of THIS. I agree that the bug (using the data-stack as the control-flow stack) existed in FIG-Forth, Forth-83, etc.. The fact that the bug has a long history doesn't make it any less of a bug. Obviously, somebody on the ANS-Forth committee knew that it was a bug, which is why the concept of a control-flow stack was introduced into ANS-Forth --- but this was a "may" feature, meaning that it can't be used without abandoning portability. Elizabeth Rather says: "just declare a dependency and forge ahead!" --- she has totally undermined the bug-fix --- doing it right is not portable but doing it wrong is portable. There were actually a lot of bad design decisions in the early Forths. My impression of the history of this period, is that Charles Moore was writing commercial software under deadline, so he did what was convenient at the time. For example, PAD was most likely a quick hack to give him some very rudimentary string-handling capability for a particular application (something that only worked with one string at a time). Using the data-stack as the control-flow stack was another quick hack that saved him the day's effort needed to implement a separate stack and also saved some memory for an extremely memory-limited 1970s computer (most likely the PDP-11). The problem is that after Charles Moore got kicked out of Forth Inc., there was nobody left at Forth Inc. who had any programming skill. All the code that Charles Moore wrote was considered to be the work of a genius and was held onto forever, somewhat like the stone tablets that Moses brought down from the mountain --- this is despite the fact that a lot of that stuff was disposable application-specific code. Most of Charles Moore's code from that period was for the PDP-11 and it reflects the limitations of the PDP-11; this is not worth keeping for decades. For example, when Forth Inc. came out with PolyForth for the 8086, PolyForth was limited to 64K total (application code, application data, compiler, dictionary and editor) --- it was most likely a direct port of the PDP-11 PolyForth that was limited to 64K because 64K was an inherent limitation of the PDP-11 --- I think that if Charles Moore had written a Forth for the 8086 he would have figured out how the segment registers worked and used them in a similar manner to UR/Forth. > It has been a long time, but I am pretty sure that I chose to use THIS > and a separate stack not primarily because IF etc. put stuff on the > data stack. The control flow words are also not the reason why > Mini-oof2 does not keep the current object on the data stack; the > reason is that because everything puts stuff on the data stack, and > keeping the current object on the data stack, like mini-oof does, just > results in lots of stack juggling. > > So, the control-flow stack items on the data stack were not the reason > for this design; I guess if it was only control-flow items, I would > have just used >R R> around POSTPONE IF etc. > > > --- are you really reco= > >mmending that I use mini-OOF2 to do meta-compiling??? > > As mentioned above, the most straightforward way to deal with passing > data from before POSTPONE IF to afterwards is to use >R and R>. But > other solutions may lead to better programs. For Gray the > mini-oof2-like stuff led to a good structure and as a side-effect > control-flow stack items were not in the way. I don't know what Gray is, so I can't comment on whether mini-OOF2 was a good choice or not (I've never used mini-OOF2 either, as I consider OOP to be a bad fit for Forth). I think that you tend to write code that is gratuitously complicated and that this makes you a bad choice for leading the Forth-200x effort (my language is maybe 1/10 as fat, and yet I have lambda functions that you don't have), but that is just a general observation and not very meaningful outside of the context of any particular application. Wasn't there a book about this? "The Fifty Shades of Gray" Previously I said: "Almost every time that I write a program, it fails under Gforth and I get blamed --- eventually it gets shown to be a bug in Gforth, not my code, but nobody ever apologizes for blaming me and saying that I write bug-ridden Forth code and don't know Forth --- this makes me want to avoid Gforth." Actually, Gforth isn't that bad for bugs (although it is very bad for speed). I should have said: Almost every time that I write a program, it fails under one of the ANS-Forth compilers (Gforth, SwiftForth, Win32Forth or VFX) and I get blamed --- eventually it gets shown to be a bug in the ANS-Forth compiler, not my code, but nobody ever apologizes for blaming me and saying that I write bug-ridden Forth code and don't know Forth --- this makes me want to avoid ANS-Forth. I can't think of any ANS-Forth program that I've written that didn't expose a bug in one of the above-mentioned ANS-Forth compilers, and need to be tweaked to work around the bug --- this is why I think that ANS-Forth is not ready for prime-time --- employers don't have time for compilers with bugs, or for a standard that doesn't provide portability between compilers (they are not going to: "just declare a dependency and forge ahead!"). It has been 20 years since ANS-Forth came out, and ANS-Forth has not proven useful for writing commercial software --- ANS-Forth could be scrapped (or maybe just scraped).
[toc] | [prev] | [next] | [standalone]
| From | awegel@arcor.de (Alexander Wegel) |
|---|---|
| Date | 2015-02-14 03:47 +0100 |
| Subject | Re: Control-flow stack |
| Message-ID | <1lzt4ds.d9u7c214g7us0N%awegel@arcor.de> |
| In reply to | #36526 |
Well - because some people mentioned the lack of context in my rather unwordy post (content="Liar") to this subthread, i try again with some more quoted text. <hughaguilar96@gmail.com> wrote (discussing with Anton Ertl about a GForth 0.6 limitation): > Also, I wasn't the one who complained about it. When I posted my program, > I got this complaint (from the thread mentioned above): > > On Tuesday, April 24, 2012 at 4:59:20 PM UTC-7, Alex Wegel wrote: > > It didn't work here (on gforth/powerpc) even for the small set, and i > > didn't feel like debugging either of these packages (novice, list). > > ... > > It seems to me that the novice package was more an obstacle, rather than > > a helpful tool (at least in this case). > > This was actually your Gforth bug that I was getting blamed for > --- there are no bugs in novice.4th or list.4th. Here (at the "...") you conveniently snipped away the context, in order to change my argument. Here's a quote of the original passage from the "codejam" thread: On Apr 24, 5:59 pm, awe...@arcor.de (Alex Wegel> ) wrote: > Hugh Aguilar <hughaguilar96@yahoo.com> wrote: > > > BTW, isn't anybody going to criticize my program because it fails to > > work at all on the large input set? > > It didn't work here (on gforth/powerpc) even for the small set, and i > didn't feel like debugging either of these packages (novice, list). > > > This is due to the fact that I > > used my SEQ lists from LIST.4TH, and they are limited to 255 char > > strings, whereas most of the pattern strings in the large input file > > are upwards of 1K in size. > > The patterns can't be larger than (26+2)*15 = 420 characters, > and actually the longest one has 382 chars. > > > This is easy to fix --- all I have to do is > > write a new version of SEQ that allows big strings (I'll do this in > > the next novice-package upgrade). When I was speed-programming > > however, I just used my existing SEQ rather than write all of that low- > > level stuff from scratch. I didn't realize this was a problem until > > after the program was written and I noticed that it worked fine on the > > small input file but not the large input file (I hadn't even visually > > inspected the large file at that time, but had just vaguely assumed > > that it was the same as the small input file just with more patterns > > and more words). > > It seems to me that the novice package was more an obstacle, rather than > a helpful tool (at least in this case). Go figure. (Does this need further explanation?) > I consider ANS-Forth to be a cult --- Alex Wegel is a cult member; he is > entirely focused on claiming that I write bug-ridden Forth code and don't > know Forth, and that there are no flaws in ANS-Forth --- your post here > was also cult-behavior, no different from what Alex Wegel was saying. I never stated (or thought), that there are no flaws in ANS-Forth. (But don't turn this around to say that i acknowledged flaws in ans-forth or sth.) So - now i spent more than enough time on this. PS: As long as you (routinely) try to push your almost-correct-points and boasts by using violence (bullying, insults and lies), we probably can't have a normal technical discussion, because this really spoils it (for me anyway).
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-02-14 19:22 -0800 |
| Subject | Re: Control-flow stack (was: Static Single Assignment ...) |
| Message-ID | <8f22f747-e820-4679-9bc3-dc9a4c2858a0@googlegroups.com> |
| In reply to | #36496 |
On Thursday, February 12, 2015 at 1:34:30 AM UTC-7, Anton Ertl wrote: > hughaguilar96@gmail.com writes: > >On Wednesday, February 11, 2015 at 10:58:03 AM UTC-7, Anton Ertl wrote: > >> I have done more metaprogramming in Forth than most other Forth > >> programmers (e.g., the Gray parser generator generates executable > >> Forth code, including control structures);=20 > > > >Apparently you didn't have a LITERAL inside of any of these control structu= > >res that you generated > > Let's see: > > 1 max-member ok > 0 singleton ' abort terminal t ok > t ?? parser test ok > see test > : test > 140737329163752 abort > IF 140737329163752 abort abort > THEN ; ok > > The 140737329163752 was generated with LITERAL, and one of them is > inside the IF. > > > --- or you would have noticed that getting the liter= > >al value to the LITERAL is a problem because the control-structures' contro= > >l-flow data is on the data stack getting in the way. > > In this program they did not get in the way. Let's look at the source > code for the code generation for the terminal T and for "??": > > : compile-test ( set -- ) > postpone literal > test-vector @ compile, ; > > : generate-terminal ( -- ) > this get-first compile-test > check&next compile, ; > > : generate-option ( -- ) > operand get-first compile-test > postpone if > operand generate > postpone endif ; > > What's happening here is that Gray uses an object-oriented approach > akin to mini-oof2. I think it's the great-grandfather of mini-oof2; > like mini-oof2, but unlike the intermediate mini-oof it already has > the current object (THIS) and can access fields of THIS such as > OPERAND. In Gray a separate stack is used for that, but a VALUE and > the return stack would have been good enough (and is used in > objects.fs and I think mini-oof2). When calling GENERATE, the object > is removed from the data stack and put on the separate stack. > > PARSER generates code for a "??" node and calls GENERATE which calls > GENERATE-OPTION, and that generates the IF, and then accesses THIS > (via OPERAND) to tell another instance of GENERATE what to generate > code for; so the control-flow stack item of the IF does not get in the > way. That GENERATE then calls GENERATE-TERMINAL, which calls LITERAL. How is this different from using global variables to hold the values that will be given to LITERAL? Isn't THIS a global variable? Isn't it true that there can only be one current object in use at a time? What happens when you have a function that is accessing two objects? Implementing a complex-number class in most OOP systems is difficult, because most of the functions (plus, minus, times, divide, etc.) have two parameters --- how would you do this in your mini-OOF2 system? All in all, I don't like OOP very much, as it can get complicated. I know C++, but I prefer Forth --- if I had an application that really needed OOP though, then I would switch to C++ rather than use mini-OOF2 or any other OOP add-on to Forth --- maybe if I got hired to write the code for the baggage-handling system for the Denver Airport (lol). OTOH, I think that lambda functions are very useful and a good fit for Forth.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-02-15 11:09 +0000 |
| Subject | Re: Control-flow stack (was: Static Single Assignment ...) |
| Message-ID | <2015Feb15.120902@mips.complang.tuwien.ac.at> |
| In reply to | #36578 |
hughaguilar96@gmail.com writes:
>On Thursday, February 12, 2015 at 1:34:30 AM UTC-7, Anton Ertl wrote:
>> hughaguilar96@gmail.com writes:
>> : compile-test ( set -- )
>> postpone literal
>> test-vector @ compile, ;
>>=20
>> : generate-terminal ( -- )
>> this get-first compile-test
>> check&next compile, ;
>>=20
>> : generate-option ( -- )
>> operand get-first compile-test
>> postpone if
>> operand generate
>> postpone endif ;
>>=20
>> What's happening here is that Gray uses an object-oriented approach
>> akin to mini-oof2. I think it's the great-grandfather of mini-oof2;
>> like mini-oof2, but unlike the intermediate mini-oof it already has
>> the current object (THIS) and can access fields of THIS such as
>> OPERAND. In Gray a separate stack is used for that, but a VALUE and
>> the return stack would have been good enough (and is used in
>> objects.fs and I think mini-oof2). When calling GENERATE, the object
>> is removed from the data stack and put on the separate stack.
>>=20
>> PARSER generates code for a "??" node and calls GENERATE which calls
>> GENERATE-OPTION, and that generates the IF, and then accesses THIS
>> (via OPERAND) to tell another instance of GENERATE what to generate
>> code for; so the control-flow stack item of the IF does not get in the
>> way. That GENERATE then calls GENERATE-TERMINAL, which calls LITERAL.
>
>How is this different from using global variables to hold the values that w=
>ill be given to LITERAL?
Global variables are messy, especially in a recursive program like a
parser generator. You typically have to save and restore them when
you change them in a definition.
> Isn't THIS a global variable?=20
No. In Gray THIS is the top of the extra stack.
>Isn't it true that there can only be one current object in use at a time? W=
>hat happens when you have a function that is accessing two objects?
In Gray there is only one node under consideration at a time, that's
why the object-oriented part is designed as it is. However, when
dealing with a node, one has to deal with it's children, so in some
sence there are more objects being accessed; this works by passing the
addresses of the other nodes to words that expect a node address,
e.g.:
: generate-concatenation ( -- )
operand1 generate
operand2 generate ;
> Impleme=
>nting a complex-number class in most OOP systems is difficult, because most=
> of the functions (plus, minus, times, divide, etc.) have two parameters --=
>- how would you do this in your mini-OOF2 system?
Why should I use an OO system for complex numbers?
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-02-15 16:57 -0800 |
| Subject | Re: Control-flow stack (was: Static Single Assignment ...) |
| Message-ID | <a0248452-ed3f-4b48-84fb-d3ae168d0314@googlegroups.com> |
| In reply to | #36583 |
On Sunday, February 15, 2015 at 4:28:42 AM UTC-7, Anton Ertl wrote:
> hughaguilar96@gmail.com writes:
> >How is this different from using global variables to hold the values that w=
> >ill be given to LITERAL?
>
> Global variables are messy, especially in a recursive program like a
> parser generator. You typically have to save and restore them when
> you change them in a definition.
>
> > Isn't THIS a global variable?=20
>
> No. In Gray THIS is the top of the extra stack.
Well, in all OOP systems there is a stack of objects, with THIS being the top element --- so you get a mechanism for saving and restoring --- it is still essentially a global variable though.
As I said before, this is a work-around for the problem in ANS-Forth that the data-stack can't be used for data during compile-time of colon words.
> >Isn't it true that there can only be one current object in use at a time? W=
> >hat happens when you have a function that is accessing two objects?
>
> In Gray there is only one node under consideration at a time, that's
> why the object-oriented part is designed as it is. However, when
> dealing with a node, one has to deal with it's children, so in some
> sence there are more objects being accessed; this works by passing the
> addresses of the other nodes to words that expect a node address,
> e.g.:
>
> : generate-concatenation ( -- )
> operand1 generate
> operand2 generate ;
I had never heard of GRAY before this discussion. I can't comment further on it without examining it --- can I download it somewhere?
I'm writing an assembler right now, so your GRAY might be useful --- it is an assembler, right?
> > Impleme=
> >nting a complex-number class in most OOP systems is difficult, because most=
> > of the functions (plus, minus, times, divide, etc.) have two parameters --=
> >- how would you do this in your mini-OOF2 system?
>
> Why should I use an OO system for complex numbers?
You shouldn't --- I just offer the complex-number challenge whenever OOP enthusiasts are promoting OOP as the solution-to-everything --- that usually causes them to fall flat on their faces.
In general, OOP works okay when the member functions ("methods") work only on THIS object's data --- but problems arise when they need access to the internal data of another object (even if it is of the same class).
OOP was originally developed for use in simulation software (Simula67), and this later got incorporated into C++ where it was hailed as a solution-to-everything in the 1990s, but in most cases it over-complicated programs for no real purpose. OOP isn't a bad thing, and I will use it when appropriate, but trying to apply it across the board as done in the 1990s will make things worse rather than better more often than not.
Dynamic-OOP as used in Lisp and all of the scripting languages is something completely different --- it is very confusing that these two ideas are both called OOP, as they are not even similar.
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web