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 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-02-08 20:21 +0000 |
| Message-ID | <mb8gem$ev7$1@dont-email.me> |
| In reply to | #36390 |
on 08/02/2015 18:13:40, wrote: > On Saturday, February 7, 2015 at 6:35:37 PM UTC-7, Elizabeth D. Rather > wrot e: >> The term "control flow stack" was coined in Forth94 to allow it to >> describe the functions of these control structure words without >> *mandating* an implementation using the data stack, although that is the > >> most common strategy. > > By allowing the data-stack to be used as the control-flow stack, > ANS-Forth requires programmers to assume that the data-stack is the > control-flow stac k in order for their programs to work on all > ANS-Forth systems --- this is effectively the same as mandating that > the data-stack be used as the contro l-flow stack. It isn't. > > The standard needs to require that the control-flow stack behave as a > disti nct stack (not to have its data intermingled with the user's > data on the da ta-stack) --- this is necessary for anybody to write a > standard program tha t assumes that the control-flow stack is > distinct. Only when compiling. Is there a consistently used metaphor in Forth that requires user data on the stack while compiling? Can you provide one? > > This is obvious [snip ad hominem whine] a standard has to > standardize. > What you are really saying is that you don't like the standard, since the standard did standardize.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-02-09 22:49 -0800 |
| Message-ID | <5bbc76d4-6847-4e8d-8e55-68a4d5ffa118@googlegroups.com> |
| In reply to | #36395 |
On Sunday, February 8, 2015 at 1:21:15 PM UTC-7, Alex McDonald wrote: > on 08/02/2015 18:13:40, wrote: > > On Saturday, February 7, 2015 at 6:35:37 PM UTC-7, Elizabeth D. Rather > > wrot e: > >> The term "control flow stack" was coined in Forth94 to allow it to > >> describe the functions of these control structure words without > >> *mandating* an implementation using the data stack, although that is the > >> most common strategy. > > > > By allowing the data-stack to be used as the control-flow stack, > > ANS-Forth requires programmers to assume that the data-stack is the > > control-flow stack in order for their programs to work on all > > ANS-Forth systems --- this is effectively the same as mandating that > > the data-stack be used as the control-flow stack. > > It isn't. > > > > > The standard needs to require that the control-flow stack behave as a > > distinct stack (not to have its data intermingled with the user's > > data on the data-stack) --- this is necessary for anybody to write a > > standard program tha t assumes that the control-flow stack is > > distinct. > > Only when compiling. Is there a consistently used metaphor in Forth that > requires user data on the stack while compiling? Can you provide one? LITERAL
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-02-10 12:12 +0000 |
| Message-ID | <mbcshk$nri$1@dont-email.me> |
| In reply to | #36425 |
on 10/02/2015 06:49:14, wrote: > On Sunday, February 8, 2015 at 1:21:15 PM UTC-7, Alex McDonald wrote: >> on 08/02/2015 18:13:40, wrote: >> > On Saturday, February 7, 2015 at 6:35:37 PM UTC-7, Elizabeth D. Rather >> > wrot e: >> >> The term "control flow stack" was coined in Forth94 to allow it to >> >> describe the functions of these control structure words without >> >> *mandating* an implementation using the data stack, although that is the >> >> most common strategy. >> > >> > By allowing the data-stack to be used as the control-flow stack, >> > ANS-Forth requires programmers to assume that the data-stack is the >> > control-flow stack in order for their programs to work on all >> > ANS-Forth systems --- this is effectively the same as mandating that >> > the data-stack be used as the control-flow stack. >> >> It isn't. >> >> > >> > The standard needs to require that the control-flow stack behave as a >> > distinct stack (not to have its data intermingled with the user's >> > data on the data-stack) --- this is necessary for anybody to write a >> > standard program tha t assumes that the control-flow stack is >> > distinct. >> >> Only when compiling. Is there a consistently used metaphor in Forth that >> requires user data on the stack while compiling? Can you provide one? > > LITERAL > (I meant idiomatic, not metaphorical, but you got what I meant.) The commonest idiom I've seen for LITERAL is : foo ... [ buf-size maxbuffer - ] literal ... ; The compile is suspended so we can optimise away sets of constants to a single constant that we then compile with LITERAL. It doesn't matter what's on the data stack at this point, whether it be control flow values or not. Where this wouldn't work is : foo ... [ buf-size maxbuffer - dup 1+ ] if literal else literal then .. ; Here the control flow, if on the data stack, has pushed down the literals and we can't get at them. Are you claiming this is idiomatic, with use of LITERAL inside a control flow where the literal value is put on the stack before it?
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-02-10 12:54 +0000 |
| Message-ID | <54d9ff6a$0$3895$e4fe514c@dreader34.news.xs4all.nl> |
| In reply to | #36426 |
In article <mbcshk$nri$1@dont-email.me>, Alex McDonald <blog@rivadpm.com> wrote: >on 10/02/2015 06:49:14, wrote: >> On Sunday, February 8, 2015 at 1:21:15 PM UTC-7, Alex McDonald wrote: >>> on 08/02/2015 18:13:40, wrote: >>> > On Saturday, February 7, 2015 at 6:35:37 PM UTC-7, Elizabeth D. Rather >>> > wrot e: >>> >> The term "control flow stack" was coined in Forth94 to allow it to >>> >> describe the functions of these control structure words without >>> >> *mandating* an implementation using the data stack, although that is the >>> >> most common strategy. >>> > >>> > By allowing the data-stack to be used as the control-flow stack, >>> > ANS-Forth requires programmers to assume that the data-stack is the >>> > control-flow stack in order for their programs to work on all >>> > ANS-Forth systems --- this is effectively the same as mandating that >>> > the data-stack be used as the control-flow stack. >>> >>> It isn't. >>> >>> > >>> > The standard needs to require that the control-flow stack behave as a >>> > distinct stack (not to have its data intermingled with the user's >>> > data on the data-stack) --- this is necessary for anybody to write a >>> > standard program tha t assumes that the control-flow stack is >>> > distinct. >>> >>> Only when compiling. Is there a consistently used metaphor in Forth that >>> requires user data on the stack while compiling? Can you provide one? >> >> LITERAL >> > >(I meant idiomatic, not metaphorical, but you got what I meant.) > >The commonest idiom I've seen for LITERAL is > >: foo ... [ buf-size maxbuffer - ] literal ... ; > >The compile is suspended so we can optimise away sets of constants to a >single constant that we then compile with LITERAL. It doesn't matter >what's on the data stack at this point, whether it be control flow values >or not. > >Where this wouldn't work is > >: foo ... [ buf-size maxbuffer - dup 1+ ] if literal else literal then >.. ; > >Here the control flow, if on the data stack, has pushed down the literals >and we can't get at them. Are you claiming this is idiomatic, with use of >LITERAL inside a control flow where the literal value is put on the stack >before it? > If Hugh isn't, I am. And it is a pitfall because one needs to read the standard very carefully to realize that : might leave something on the control stack. 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 | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-02-10 06:30 -0800 |
| Message-ID | <85348184-ca41-46e6-9c94-b8c7f1c6ef6a@googlegroups.com> |
| In reply to | #36427 |
On Tuesday, 10 February 2015 12:54:04 UTC, Albert van der Horst wrote: > >Where this wouldn't work is > > > >: foo ... [ buf-size maxbuffer - dup 1+ ] if literal else literal then > >.. ; > > > >Here the control flow, if on the data stack, has pushed down the literals > >and we can't get at them. Are you claiming this is idiomatic, with use of > >LITERAL inside a control flow where the literal value is put on the stack > >before it? > > > > If Hugh isn't, I am. And it is a pitfall because one needs to read the > standard very carefully to realize that : might leave something > on the control stack. > > 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 It might not be idiomatic, but it's another gotcha. Hugh is right. This *might* (or, to use ANS parlance, *may*) work: [ calculation ] : foo ... ... literal ; This might work: : foo [ calculation ] 100 0 do literal loop ; Then again, it might not. They're not great examples, I admit, because you could simply move the calculation next to the literal.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-02-10 14:53 +0000 |
| Message-ID | <mbd5vj$vbo$1@dont-email.me> |
| In reply to | #36428 |
on 10/02/2015 14:30:11, Mark Wills wrote: On Tuesday, 10 February 2015 12:54:04 UTC, Albert van der Horst wrote: [requoted] > >Where this wouldn't work is > > > >: foo ... [ buf-size maxbuffer - dup 1+ ] if literal else literal then > >.. ; > > > >Here the control flow, if on the data stack, has pushed down the literals > >and we can't get at them. Are you claiming this is idiomatic, with use of > >LITERAL inside a control flow where the literal value is put on the stack > >before it? > > > > If Hugh isn't, I am. And it is a pitfall because one needs to read the > standard very carefully to realize that : might leave something > on the control stack. > > 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 [ end requote] For some reason the quoting is all messed up, so Albert's reply to me is pasted above. > > It might not be idiomatic, but it's another gotcha. Hugh is right. > > This *might* (or, to use ANS parlance, *may*) work: Words like MAY are (in some standards) very closely defined. See https://www.ietf.org/rfc/rfc2119.txt for the IETF meanings. 5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) A committee sat down and wrote that definition because languages like English are not well specified, and specifications (not surprisingly) need to be as unambiguous as possible. There's an equivalent ISO specification ISO/IEC TR 10176:2003 that ANSI now conforms to; I suspect that were the ANS Forth standard to be presented again today, it would require significant revision to clean up the language, since ISO generally recognises shall, will and should. Other words like may or might are discouraged. Your examples aren't ANS Forth, so they won't work in all cases. They certainly won't work with gforth, Win32Forth and (I think) VFX. > [ calculation ] : foo ... ... literal ; You mean calculation : foo ... ... literal ; It probably won't work. 6.1.0450 : “colon” CORE ( C: “<spaces>name” -- colon-sys ) > > This might work: >: foo [ calculation ] 100 0 do literal loop ; > > Then again, it might not. Same problem. 6.1.1240 DO CORE Compilation: ( C: -- do-sys ) Place do-sys onto the control-flow stack. > > They're not great examples, I admit, because you could simply move > the calculation next to the literal. > That's what I would like to see. Is there something we're missing out on? If so, what is it?
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-02-10 08:20 -1000 |
| Message-ID | <xsidnYT1EoNz1kfJnZ2dnUU7-U-dnZ2d@supernews.com> |
| In reply to | #36428 |
On 2/10/15 4:30 AM, Mark Wills wrote: > On Tuesday, 10 February 2015 12:54:04 UTC, Albert van der Horst wrote: >>> Where this wouldn't work is >>> >>> : foo ... [ buf-size maxbuffer - dup 1+ ] if literal else literal then >>> .. ; >>> >>> Here the control flow, if on the data stack, has pushed down the literals >>> and we can't get at them. Are you claiming this is idiomatic, with use of >>> LITERAL inside a control flow where the literal value is put on the stack >>> before it? >>> >> >> If Hugh isn't, I am. And it is a pitfall because one needs to read the >> standard very carefully to realize that : might leave something >> on the control stack. >> >> 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 > > It might not be idiomatic, but it's another gotcha. Hugh is right. > > This *might* (or, to use ANS parlance, *may*) work: > [ calculation ] : foo ... ... literal ; > > This might work: > : foo [ calculation ] 100 0 do literal loop ; > > Then again, it might not. > > They're not great examples, I admit, because you could simply move > the calculation next to the literal. > ...which should be done anyway, for readability. 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 | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-02-10 14:33 +0000 |
| Message-ID | <mbd4qk$q04$1@dont-email.me> |
| In reply to | #36427 |
on 10/02/2015 12:54:00, wrote: > In article <mbcshk$nri$1@dont-email.me>, > Alex McDonald <blog@rivadpm.com> wrote: >>on 10/02/2015 06:49:14, wrote: >>> On Sunday, February 8, 2015 at 1:21:15 PM UTC-7, Alex McDonald wrote: >>>> on 08/02/2015 18:13:40, wrote: >>>> > On Saturday, February 7, 2015 at 6:35:37 PM UTC-7, Elizabeth D. Rather >>>> > wrot e: >>>> >> The term "control flow stack" was coined in Forth94 to allow it to >>>> >> describe the functions of these control structure words without >>>> >> *mandating* an implementation using the data stack, although that is the >>>> >> most common strategy. >>>> > >>>> > By allowing the data-stack to be used as the control-flow stack, >>>> > ANS-Forth requires programmers to assume that the data-stack is the >>>> > control-flow stack in order for their programs to work on all >>>> > ANS-Forth systems --- this is effectively the same as mandating that >>>> > the data-stack be used as the control-flow stack. >>>> >>>> It isn't. >>>> >>>> > >>>> > The standard needs to require that the control-flow stack behave as a >>>> > distinct stack (not to have its data intermingled with the user's >>>> > data on the data-stack) --- this is necessary for anybody to write a >>>> > standard program tha t assumes that the control-flow stack is >>>> > distinct. >>>> >>>> Only when compiling. Is there a consistently used metaphor in Forth that >>>> requires user data on the stack while compiling? Can you provide one? >>> >>> LITERAL >>> >> >>(I meant idiomatic, not metaphorical, but you got what I meant.) >> >>The commonest idiom I've seen for LITERAL is >> >>: foo ... [ buf-size maxbuffer - ] literal ... ; >> >>The compile is suspended so we can optimise away sets of constants to a >>single constant that we then compile with LITERAL. It doesn't matter >>what's on the data stack at this point, whether it be control flow values >>or not. >> >>Where this wouldn't work is >> >>: foo ... [ buf-size maxbuffer - dup 1+ ] if literal else literal then >>.. ; >> >>Here the control flow, if on the data stack, has pushed down the literals >>and we can't get at them. Are you claiming this is idiomatic, with use of >>LITERAL inside a control flow where the literal value is put on the stack >>before it? >> > > If Hugh isn't, I am. And it is a pitfall because one needs to read the > standard very carefully to realize that : might leave something on the > control stack. > > Groetjes Albert There isn't any extant code that makes use of data on the stack at compile time the way I suggested, and for the following fairly obvious reason. The standard makes it clear that there are certain features of compile time where the data stack may be used as a control flow stack. So there is no code that can take advantage of control flow stack not being data stack, since most popular ANS Forth compilers use the data stack for control flow, and no-one normally writes code that won't run. What Hugh and you need to do is demonstrate that there's a requirement or use case, or some cool idiom that we're all missing out on, due to this feature of the language. It applies only to LITERAL and COMPILE, (and possibly EXECUTE), since there's not a lot else you can do with a value on the stack at compile time; it's either a number or it's an XT. Standards get modified & developed over time by demonstrating a need for change. Not by claiming pitfalls because you didn't read the doc. It clearly marks control stack use as C: in stack diagrams. 6.1.0450 : “colon” CORE ( C: “<spaces>name” -- colon-sys ) I read the standard pretty regularly. I don't always get it right or understand it correctly, but I don't then claim that the standard is stupid or negligent or some homosexual conspiracy because it wasn't written how I wanted it to read. Frankly, I can't see the use case that would give us significant advantages if the current restriction were changed.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-02-10 19:09 +0000 |
| Message-ID | <54da5772$0$3899$e4fe514c@dreader34.news.xs4all.nl> |
| In reply to | #36429 |
In article <mbd4qk$q04$1@dont-email.me>, Alex McDonald <blog@rivadpm.com> wrote: <SNIP> >There isn't any extant code that makes use of data on the stack at >compile time the way I suggested, and for the following fairly obvious >reason. The standard makes it clear that there are certain features of >compile time where the data stack may be used as a control flow stack. So >there is no code that can take advantage of control flow stack not being >data stack, since most popular ANS Forth compilers use the data stack for >control flow, and no-one normally writes code that won't run. > >What Hugh and you need to do is demonstrate that there's a requirement or >use case, or some cool idiom that we're all missing out on, due to this >feature of the language. It applies only to LITERAL and COMPILE, (and >possibly EXECUTE), since there's not a lot else you can do with a value >on the stack at compile time; it's either a number or it's an XT. You raise a general point. and you present the standpoint of a normal Forth programmer well. But what I see here is not a brick wall but a thicket that holds me back as a programmer. In a few years I may be fully converted to LISP where similar concerns are considered valid. 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-02-10 14:29 +0000 |
| Subject | Control-flow stack (was: Static Single Assignment ...) |
| Message-ID | <2015Feb10.152916@mips.complang.tuwien.ac.at> |
| In reply to | #36427 |
albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <mbcshk$nri$1@dont-email.me>,
>Alex McDonald <blog@rivadpm.com> wrote:
>>Where this wouldn't work is
>>
>>: foo ... [ buf-size maxbuffer - dup 1+ ] if literal else literal then
>>.. ;
>>
>>Here the control flow, if on the data stack, has pushed down the literals
>>and we can't get at them. Are you claiming this is idiomatic, with use of
>>LITERAL inside a control flow where the literal value is put on the stack
>>before it?
>>
>
>If Hugh isn't, I am. And it is a pitfall because one needs to read the
>standard very carefully to realize that : might leave something
>on the control stack.
You mean the data stack, and the case you are thinking of is not the
one Alex McDonald presented as example. What you are thinking of is
simething like
buf-size maxbuffer - : foo literal + ;
Here Forth-94 says:
|6.1.0450 : colon CORE\
| ( C: "<spaces>name" -- colon-sys )
2.2.2 "Stack notation" explains that C: stands for the control-flow
stack, and 3.2.3.2 "Control-flow stack" explains that the control-flow
stack may be implemented using the data stack.
I don't think this needs more careful reading than other aspects of
the standard.
It seems to me that using the data stack as control-flow stack is
common practice (are there any exceptions?). Tightening the standard
to disallow a separate control-flow stack would not give progammers a
lot of additional freedom, because all the control-flow stack items
are opaque and the number of cells they contain is not standardized;
but it would have the following effects:
* No need to document the possibility of a separate control-flow
stack. The standard becomes easier to understand.
* 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. This is probably ok for many compilers,
but other compilers might have been written with the assumption that
only the standard control-flow stack manipulation words are used for
dealing with control-flow stack items, and would not work with the
programmer-written ones. Are there such compilers?
- 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-10 15:49 +0000 |
| Subject | Re: Control-flow stack (was: Static Single Assignment ...) |
| Message-ID | <mbd98q$eml$1@dont-email.me> |
| In reply to | #36431 |
on 10/02/2015 14:29:19, wrote: > albert@spenarnc.xs4all.nl (Albert van der Horst) writes: >>In article <mbcshk$nri$1@dont-email.me>, >>Alex McDonald <blog@rivadpm.com> wrote: >>>Where this wouldn't work is >>> >>>: foo ... [ buf-size maxbuffer - dup 1+ ] if literal else literal then >>>.. ; >>> >>>Here the control flow, if on the data stack, has pushed down the literals >>>and we can't get at them. Are you claiming this is idiomatic, with use of >>>LITERAL inside a control flow where the literal value is put on the stack >>>before it? >>> >> >>If Hugh isn't, I am. And it is a pitfall because one needs to read the >>standard very carefully to realize that : might leave something >>on the control stack. > > You mean the data stack, and the case you are thinking of is not the > one Alex McDonald presented as example. What you are thinking of is > simething like > > buf-size maxbuffer - : foo literal + ; > > Here Forth-94 says: > >|6.1.0450 : colon CORE\ >| ( C: "<spaces>name" -- colon-sys ) > > 2.2.2 "Stack notation" explains that C: stands for the control-flow > stack, and 3.2.3.2 "Control-flow stack" explains that the control-flow > stack may be implemented using the data stack. > > I don't think this needs more careful reading than other aspects of > the standard. > > It seems to me that using the data stack as control-flow stack is > common practice (are there any exceptions?). Tightening the standard > to disallow a separate control-flow stack would not give progammers a > lot of additional freedom, because all the control-flow stack items > are opaque and the number of cells they contain is not standardized; > but it would have the following effects: Category A. Hugh (and possibly Albert) wants the control flow stack to *not* be the data stack. B. There may be others with a similar opinion, but they appear to be confused about when it is used and what it is used for. > > * No need to document the possibility of a separate control-flow > stack. The standard becomes easier to understand. That fixes category B. > > * 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. It's not so easy for : colon-sys and perhaps others regardless of unified or separate, since they may have other side effects beyond wasting some code space. ( stack empty ) ] if [ depth constant orig-cells : clear orig-cells 0 ?do drop loop ; clear cr ." the orig/dest cell count is " orig-cells . ORIG-CELLS is zero for a separate control flow stack. > This is probably ok for many compilers, > but other compilers might have been written with the assumption that > only the standard control-flow stack manipulation words are used for > dealing with control-flow stack items, and would not work with the > programmer-written ones. Are there such compilers? > > - anton
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-02-10 17:56 +0000 |
| Subject | Re: Control-flow stack (was: Static Single Assignment ...) |
| Message-ID | <54da465e$0$3854$e4fe514c@dreader34.news.xs4all.nl> |
| In reply to | #36432 |
In article <mbd98q$eml$1@dont-email.me>, Alex McDonald <blog@rivadpm.com> wrote: >on 10/02/2015 14:29:19, wrote: >> albert@spenarnc.xs4all.nl (Albert van der Horst) writes: >>>In article <mbcshk$nri$1@dont-email.me>, >>>Alex McDonald <blog@rivadpm.com> wrote: >>>>Where this wouldn't work is >>>> >>>>: foo ... [ buf-size maxbuffer - dup 1+ ] if literal else literal then >>>>.. ; >>>> >>>>Here the control flow, if on the data stack, has pushed down the literals >>>>and we can't get at them. Are you claiming this is idiomatic, with use of >>>>LITERAL inside a control flow where the literal value is put on the stack >>>>before it? >>>> >>> >>>If Hugh isn't, I am. And it is a pitfall because one needs to read the >>>standard very carefully to realize that : might leave something >>>on the control stack. >> >> You mean the data stack, and the case you are thinking of is not the >> one Alex McDonald presented as example. What you are thinking of is >> simething like >> >> buf-size maxbuffer - : foo literal + ; >> >> Here Forth-94 says: >> >>|6.1.0450 : colon CORE\ >>| ( C: "<spaces>name" -- colon-sys ) >> >> 2.2.2 "Stack notation" explains that C: stands for the control-flow >> stack, and 3.2.3.2 "Control-flow stack" explains that the control-flow >> stack may be implemented using the data stack. >> >> I don't think this needs more careful reading than other aspects of >> the standard. >> >> It seems to me that using the data stack as control-flow stack is >> common practice (are there any exceptions?). Tightening the standard >> to disallow a separate control-flow stack would not give progammers a >> lot of additional freedom, because all the control-flow stack items >> are opaque and the number of cells they contain is not standardized; >> but it would have the following effects: > >Category A. Hugh (and possibly Albert) wants the control flow stack to >*not* be the data stack. B. There may be others with a similar opinion, >but they appear to be confused about when it is used and what it is used >for. I don't want a separate control stack. I just said that wanting to pass parameters at compile time to a colon definition is idiomatic, and that it is one of those pitfalls. At least I've fallen into it. It was a Forth I implemented myself and indeed while implementing `` : '' I checked that using the data stack was allowed by the standard. It is the price to pay for simplicity. I was once involved in a big fat Forth: transputer Forth. There we had separate stacks for everything. For temporary storage we had >S S> S@ instead of >R R> R@ that could be used with impunity within loops and intermixed with locals that had their own stack too. Probably good decisions to make for a fat Forth. (I wanted to have the S system and R return stacks interchanged. The system stack would then indicate non-portability, while the use of R anything would be upwards compatible.) Bottom line, I think it is a design decision that is worth thinking about. 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 | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-02-10 20:53 +0000 |
| Subject | Re: Control-flow stack (was: Static Single Assignment ...) |
| Message-ID | <mbdr3v$5vo$1@dont-email.me> |
| In reply to | #36434 |
on 10/02/2015 17:56:49, wrote: > In article <mbd98q$eml$1@dont-email.me>, > Alex McDonald <blog@rivadpm.com> wrote: >>on 10/02/2015 14:29:19, wrote: >>> albert@spenarnc.xs4all.nl (Albert van der Horst) writes: >>>>In article <mbcshk$nri$1@dont-email.me>, >>>>Alex McDonald <blog@rivadpm.com> wrote: >>>>>Where this wouldn't work is >>>>> >>>>>: foo ... [ buf-size maxbuffer - dup 1+ ] if literal else literal then >>>>>.. ; >>>>> >>>>>Here the control flow, if on the data stack, has pushed down the literals >>>>>and we can't get at them. Are you claiming this is idiomatic, with use of >>>>>LITERAL inside a control flow where the literal value is put on the stack >>>>>before it? >>>>> >>>> >>>>If Hugh isn't, I am. And it is a pitfall because one needs to read the >>>>standard very carefully to realize that : might leave something >>>>on the control stack. >>> >>> You mean the data stack, and the case you are thinking of is not the >>> one Alex McDonald presented as example. What you are thinking of is >>> simething like >>> >>> buf-size maxbuffer - : foo literal + ; >>> >>> Here Forth-94 says: >>> >>>|6.1.0450 : colon CORE\ >>>| ( C: "<spaces>name" -- colon-sys ) >>> >>> 2.2.2 "Stack notation" explains that C: stands for the control-flow >>> stack, and 3.2.3.2 "Control-flow stack" explains that the control-flow >>> stack may be implemented using the data stack. >>> >>> I don't think this needs more careful reading than other aspects of >>> the standard. >>> >>> It seems to me that using the data stack as control-flow stack is >>> common practice (are there any exceptions?). Tightening the standard >>> to disallow a separate control-flow stack would not give progammers a >>> lot of additional freedom, because all the control-flow stack items >>> are opaque and the number of cells they contain is not standardized; >>> but it would have the following effects: >> >>Category A. Hugh (and possibly Albert) wants the control flow stack to >>*not* be the data stack. B. There may be others with a similar opinion, >>but they appear to be confused about when it is used and what it is used >>for. > > I don't want a separate control stack. I just said that wanting > to pass parameters at compile time to a colon definition is idiomatic, It's pretty easily addressed without re-engineering an entire set of compilers. Declare named literals. 10 constant bar : foo [ bar ] literal + ; Alternatively, define a parameterized colon definition. : :1 >r : r> ; 20 :1 foo literal + ; [snip]
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-02-10 13:08 -1000 |
| Subject | Re: Control-flow stack |
| Message-ID | <MqSdnbKgN87HEkfJnZ2dnUU7-QmdnZ2d@supernews.com> |
| In reply to | #36438 |
On 2/10/15 10:53 AM, Alex McDonald wrote: > on 10/02/2015 17:56:49, wrote: >> In article <mbd98q$eml$1@dont-email.me>, >> Alex McDonald <blog@rivadpm.com> wrote: >>> on 10/02/2015 14:29:19, wrote: >>>> albert@spenarnc.xs4all.nl (Albert van der Horst) writes: >>>>> In article <mbcshk$nri$1@dont-email.me>, >>>>> Alex McDonald <blog@rivadpm.com> wrote: >>>>>> Where this wouldn't work is >>>>>> >>>>>> : foo ... [ buf-size maxbuffer - dup 1+ ] if literal else literal then >>>>>> .. ; >>>>>> >>>>>> Here the control flow, if on the data stack, has pushed down the literals >>>>>> and we can't get at them. Are you claiming this is idiomatic, with use of >>>>>> LITERAL inside a control flow where the literal value is put on the stack >>>>>> before it? >>>>>> >>>>> >>>>> If Hugh isn't, I am. And it is a pitfall because one needs to read the >>>>> standard very carefully to realize that : might leave something >>>>> on the control stack. >>>> >>>> You mean the data stack, and the case you are thinking of is not the >>>> one Alex McDonald presented as example. What you are thinking of is >>>> simething like >>>> >>>> buf-size maxbuffer - : foo literal + ; >>>> >>>> Here Forth-94 says: >>>> >>>> |6.1.0450 : colon CORE\ >>>> | ( C: "<spaces>name" -- colon-sys ) >>>> >>>> 2.2.2 "Stack notation" explains that C: stands for the control-flow >>>> stack, and 3.2.3.2 "Control-flow stack" explains that the control-flow >>>> stack may be implemented using the data stack. >>>> >>>> I don't think this needs more careful reading than other aspects of >>>> the standard. >>>> >>>> It seems to me that using the data stack as control-flow stack is >>>> common practice (are there any exceptions?). Tightening the standard >>>> to disallow a separate control-flow stack would not give progammers a >>>> lot of additional freedom, because all the control-flow stack items >>>> are opaque and the number of cells they contain is not standardized; >>>> but it would have the following effects: >>> >>> Category A. Hugh (and possibly Albert) wants the control flow stack to >>> *not* be the data stack. B. There may be others with a similar opinion, >>> but they appear to be confused about when it is used and what it is used >>> for. >> >> I don't want a separate control stack. I just said that wanting >> to pass parameters at compile time to a colon definition is idiomatic, > > It's pretty easily addressed without re-engineering an entire set of > compilers. Declare named literals. > > 10 constant bar > : foo [ bar ] literal + ; > > Alternatively, define a parameterized colon definition. > > : :1 >r : r> ; > 20 :1 foo literal + ; > > [snip] > The latter depends on colon-sys being a single cell, which is not guaranteed. On many systems, it's zero cells, for example, since not everyone is as keen on this kind of compiler security, and it isn't required by any standard. And I really don't see any advantage of naming the thing you want to make a literal; if it's defined and has a name you don't need a literal. Most instances of needing to define a literal involve some sort of variable data. Really, the best practice is to specify your value right before the LITERAL; safer and more readable. Or, if you really want to be able to pass values into a colon definition, declare a dependency on being able to do that and forge ahead. 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 | awegel@arcor.de (Alexander Wegel) |
|---|---|
| Date | 2015-02-11 03:15 +0100 |
| Subject | Re: Control-flow stack |
| Message-ID | <1lznrxy.1hprxw414lwjngN%awegel@arcor.de> |
| In reply to | #36443 |
Elizabeth D. Rather <erather@forth.com> wrote: > > Alternatively, define a parameterized colon definition. > > > > : :1 >r : r> ; > > 20 :1 foo literal + ; > > > > [snip] > > > > The latter depends on colon-sys being a single cell, which is not > guaranteed. No, it doesn't depend on that.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-02-10 18:47 -0800 |
| Subject | Re: Control-flow stack |
| Message-ID | <4d6802f6-d56e-488b-92f7-def75fd8ba0e@googlegroups.com> |
| In reply to | #36443 |
On Tuesday, February 10, 2015 at 4:08:12 PM UTC-7, Elizabeth D. Rather wrote: > On 2/10/15 10:53 AM, Alex McDonald wrote: > > Alternatively, define a parameterized colon definition. > > > > : :1 >r : r> ; > > 20 :1 foo literal + ; > > > > The latter depends on colon-sys being a single cell, which is not > guaranteed. On many systems, it's zero cells, for example, since not > everyone is as keen on this kind of compiler security, and it isn't > required by any standard. No it doesn't. His :1 is for situations in which there is 1 parameter being passed into the colon word --- the 1 doesn't have anything to do with how much control-flow data the colon may put on the data stack --- I don't think you really understand Forth code (I mean, any Forth code other than the example programs in "Starting Forth"). Anyway, this is typical quality for Alex McDonald. His :1 only works if there is 1 parameter, but he will have to write a :2 :3 etc. for every possible number of parameters, and he will require the programmer to make sure to use the correct one. His :1 doesn't work if there are any control structures inside of the colon word and the LITERAL is inside of them. By "typical quality for Alex McDonald" I mean, a complete failure. > And I really don't see any advantage of naming the thing you want to > make a literal; if it's defined and has a name you don't need a literal. > Most instances of needing to define a literal involve some sort of > variable data. Really, the best practice is to specify your value right > before the LITERAL; safer and more readable. Total failure to understand the concept of meta-compiling. > Or, if you really want to be able to pass values into a colon > definition, declare a dependency on being able to do that and forge ahead. This is from the chairperson of the ANS-Forth committee!!! Maybe this is why ANS-Forth failed as a standard, do you think?
[toc] | [prev] | [next] | [standalone]
| From | Unknown <dog@gmail.com> |
|---|---|
| Date | 2015-02-17 07:13 +0000 |
| Subject | Re: Control-flow stack |
| Message-ID | <pan.2015.02.17.07.21.37@gmail.com> |
| In reply to | #36458 |
On Tue, 10 Feb 2015 18:47:25 -0800, hughaguilar96 wrote: > Anyway, this is typical quality for Alex McDonald. His :1 only works if > there is 1 parameter, but he will have to write a :2 :3 etc. for every > possible number of parameters, and he will require the programmer to > make sure to use the correct one. His :1 doesn't work if there are any > control structures inside of the colon word and the LITERAL is inside of > them. By "typical quality for Alex McDonald" I mean, a complete failure. > How many parameters do you want to be able to handle? I can only visualise up to 1, 2, 3. Acknowledging(?sp) to the <compiler: how many pars there are> is like strong typing, which instead of shooting-from-the hip, reduces problems.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-02-11 17:59 +0000 |
| Subject | Re: Control-flow stack |
| Message-ID | <2015Feb11.185901@mips.complang.tuwien.ac.at> |
| In reply to | #36443 |
"Elizabeth D. Rather" <erather@forth.com> writes:
>> Alternatively, define a parameterized colon definition.
>>
>> : :1 >r : r> ;
>> 20 :1 foo literal + ;
>>
>> [snip]
>>
>
>The latter depends on colon-sys being a single cell, which is not
>guaranteed.
No, it passes one cell in, irrespective of the size of colon-sys.
> On many systems, it's zero cells, for example, since not
>everyone is as keen on this kind of compiler security, and it isn't
>required by any standard.
Try it on SwiftForth, where colon-sys has zero cells. It works.
Try it on Gforth, where colon-sys has four cells. It works.
- 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 | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-02-11 01:30 -0800 |
| Subject | Re: Control-flow stack (was: Static Single Assignment ...) |
| Message-ID | <82110f2c-9940-462e-b212-9f65e07ed351@googlegroups.com> |
| In reply to | #36434 |
> I was once involved in a big fat Forth: transputer Forth. > There we had separate stacks for everything. > For temporary storage we had >S S> S@ instead of >R R> R@ > that could be used with impunity within loops and intermixed > with locals that had their own stack too. Probably good decisions > to make for a fat Forth. (I wanted to have the S system and R > return stacks interchanged. The system stack would then indicate > non-portability, while the use of R anything would be upwards > compatible.) > This seems quite a good and modern forth to me. Except that >S etc, which probably were to replace the >R etc. These should be obsoleted anyway and replaced with plain locals. It's the job of the compiler to generate the most efficient code when using a local variable, you don't need a >R, R@ etc. ANS forth should standardize this kind of forth, not trying to standardize the simplest forth system posible. And I don't think that this kind of forth is fat. I have a forth cross compiler with a lot of stacks (data, locals, more than one control flow stack...) and it is in fact simpler than an all-in-one solution using the data stack for all needs.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <buzz@notnotnontnooatno.cmm> |
|---|---|
| Date | 2015-02-10 18:43 -0500 |
| Subject | Re: Control-flow stack (was: Static Single Assignment ...) |
| Message-ID | <op.xtu76h0nv6dtjm@localhost> |
| In reply to | #36432 |
On Tue, 10 Feb 2015 10:49:19 -0500, Alex McDonald <blog@rivadpm.com> wrote: > on 10/02/2015 14:29:19, wrote: >> albert@spenarnc.xs4all.nl (Albert van der Horst) writes: >>> In article <mbcshk$nri$1@dont-email.me>, >>> Alex McDonald <blog@rivadpm.com> wrote: >>>> Where this wouldn't work is >>>> >>>> : foo ... [ buf-size maxbuffer - dup 1+ ] if literal >>>> else literal then .. ; >>>> >>>> Here the control flow, if on the data stack, has pushed down the >>>> literals and we can't get at them. Are you claiming this is >>>> idiomatic, with use of LITERAL inside a control flow where the >>>> literal value is put on the stack before it? >>>> >>> >>> If Hugh isn't, I am. >> >> It seems to me that using the data stack as control-flow stack is >> common practice (are there any exceptions?). > > Category A. Hugh (and possibly Albert) wants the control flow stack > to *not* be the data stack. And, it can't be the return stack either because that would break threading. So ... They want a dedicated third stack. Yes? Rod Pemberton
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web