Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #48085 > unrolled thread
| Started by | Marek Brunda <marekb@phoenics.org> |
|---|---|
| First post | 2016-06-13 13:41 -0700 |
| Last post | 2016-06-26 22:41 -1000 |
| Articles | 20 on this page of 116 — 28 participants |
Back to article view | Back to comp.lang.forth
Is it sill FORTH ? Marek Brunda <marekb@phoenics.org> - 2016-06-13 13:41 -0700
Re: Is it sill FORTH ? crc <charles.childers@gmail.com> - 2016-06-13 13:57 -0700
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-13 15:18 -0700
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-13 15:34 -0700
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-13 15:37 -0700
Re: Is it sill FORTH ? Paul Rubin <no.email@nospam.invalid> - 2016-06-13 15:45 -0700
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-13 15:54 -0700
Re: Is it sill FORTH ? Coos Haak <chforth@hccnet.nl> - 2016-06-14 01:41 +0200
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-13 16:48 -0700
Re: Is it sill FORTH ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-14 03:24 -0500
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-14 02:53 -0700
Re: Is it sill FORTH ? Coos Haak <chforth@hccnet.nl> - 2016-06-14 01:53 +0200
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-13 17:25 -0700
Re: Is it sill FORTH ? Marek Brunda <marekb@phoenics.org> - 2016-06-13 22:23 -0700
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-14 03:13 -0400
VALUE Lars Brinkhoff <lars.spam@nocrew.org> - 2016-06-14 09:17 +0200
Re: Is it sill FORTH ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-14 03:51 -0500
Re: Is it sill FORTH ? Marek Brunda <marekb@phoenics.org> - 2016-06-14 02:45 -0700
Re: Is it sill FORTH ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-15 04:21 -0500
Re: Is it sill FORTH ? Brad Eckert <hwfwguy@gmail.com> - 2016-08-05 21:02 -0700
Re: Is it sill FORTH ? "Elizabeth D. Rather" <erather@forth.com> - 2016-08-05 21:48 -1000
Re: Is it sill FORTH ? missycurl@gmail.com - 2016-08-06 05:37 -0700
Re: Is it sill FORTH ? humptydumpty <ouatubi@gmail.com> - 2016-08-06 06:37 -0700
Re: Is it sill FORTH ? Cecil Bayona <cbayona@cbayona.com> - 2016-08-06 08:53 -0500
Re: Is it sill FORTH ? humptydumpty <ouatubi@gmail.com> - 2016-08-06 07:18 -0700
Re: Is it sill FORTH ? humptydumpty <ouatubi@gmail.com> - 2016-08-06 07:40 -0700
Re: Is it sill FORTH ? "Elizabeth D. Rather" <erather@forth.com> - 2016-08-06 15:07 -1000
Re: Is it sill FORTH ? hughaguilar96@gmail.com - 2016-08-06 19:14 -0700
Re: Is it sill FORTH ? Chris Curl <ccurl609@gmail.com> - 2016-08-07 10:38 -0700
Re: Is it sill FORTH ? "Elizabeth D. Rather" <erather@forth.com> - 2016-08-07 20:57 -1000
Re: Is it sill FORTH ? Roelf Toxopeus <rt4all@nothishetnet.nl> - 2016-08-08 22:20 +0200
Re: Is it sill FORTH ? "Elizabeth D. Rather" <erather@forth.com> - 2016-08-08 12:14 -1000
Re: Is it sill FORTH ? hughaguilar96@gmail.com - 2016-08-09 00:29 -0700
Re: Is it sill FORTH ? hughaguilar96@gmail.com - 2016-08-06 19:30 -0700
Re: Is it sill FORTH ? Chris Curl <ccurl609@gmail.com> - 2016-08-07 07:42 -0700
Re: Is it sill FORTH ? hughaguilar96@gmail.com - 2016-08-07 13:34 -0700
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-08-08 16:13 -0400
Re: Is it sill FORTH ? Cecil Bayona <cbayona@cbayona.com> - 2016-08-08 15:36 -0500
Re: Is it sill FORTH ? jim.brakefield@ieee.org - 2016-08-06 06:28 -0700
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-08-08 16:42 -0400
Re: Is it sill FORTH ? "Elizabeth D. Rather" <erather@forth.com> - 2016-08-08 12:31 -1000
Re: Is it sill FORTH ? Paul Rubin <no.email@nospam.invalid> - 2016-08-08 16:38 -0700
Re: Is it sill FORTH ? mhx@iae.nl - 2016-08-08 22:49 -0700
Re: Is it sill FORTH ? Paul Rubin <no.email@nospam.invalid> - 2016-08-08 23:43 -0700
Re: Is it sill FORTH ? "Elizabeth D. Rather" <erather@forth.com> - 2016-08-08 22:16 -1000
Re: Is it sill FORTH ? JUERGEN <epldfpga@aol.com> - 2016-08-09 03:54 -0700
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-14 03:42 -0700
Re: Is it sill FORTH ? Marek Brunda <marekb@phoenics.org> - 2016-06-14 04:58 -0700
Re: Is it sill FORTH ? Mark Wills <markwills1970@gmail.com> - 2016-06-14 05:04 -0700
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-13 19:22 -0400
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-14 05:22 -0700
Re: Is it sill FORTH ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-14 12:41 +0000
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-14 06:30 -0700
Re: Is it sill FORTH ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-14 14:21 +0000
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-14 13:21 -0400
Re: Is it sill FORTH ? Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-06-14 17:45 -0400
Re: Is it sill FORTH ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-14 10:55 -0500
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-13 16:38 -0700
Re: Is it sill FORTH ? Paul Rubin <no.email@nospam.invalid> - 2016-06-13 16:41 -0700
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-14 03:54 -0700
Re: Is it sill FORTH ? Paul Rubin <no.email@nospam.invalid> - 2016-06-14 08:14 -0700
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-14 13:24 -0400
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-14 11:03 -0700
Re: Is it sill FORTH ? Paul Rubin <no.email@nospam.invalid> - 2016-06-14 12:42 -0700
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-14 13:28 -0700
Re: Is it sill FORTH ? Paul Rubin <no.email@nospam.invalid> - 2016-06-14 13:42 -0700
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-14 14:47 -0700
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-14 19:37 -0400
Re: Is it sill FORTH ? Marek Brunda <marekb@phoenics.org> - 2016-06-14 17:01 -0700
Re: Is it sill FORTH ? Marek Brunda <marekb@phoenics.org> - 2016-06-14 17:06 -0700
Re: Is it sill FORTH ? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-06-15 07:57 +0200
Re: Is it sill FORTH ? "Elizabeth D. Rather" <erather@forth.com> - 2016-06-15 16:12 +0200
Re: Is it sill FORTH ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-15 03:20 -0500
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-14 20:20 -0400
Re: Is it sill FORTH ? Marek Brunda <marekb@phoenics.org> - 2016-06-14 17:33 -0700
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-14 21:21 -0400
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-14 19:57 -0700
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-14 23:03 -0400
Re: Is it sill FORTH ? Paul Rubin <no.email@nospam.invalid> - 2016-06-14 20:31 -0700
Re: Is it sill FORTH ? pahihu <pahihu@gmail.com> - 2016-06-15 01:36 -0700
Re: Is it sill FORTH ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-18 12:54 +0000
Re: Is it sill FORTH ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-18 13:28 +0000
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-18 07:17 -0700
Re: Is it sill FORTH ? lawrencedo99@gmail.com - 2016-06-18 18:31 -0700
Re: Is it sill FORTH ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-25 14:55 +0000
Re: Is it sill FORTH ? lawrencedo99@gmail.com - 2016-06-25 19:58 -0700
Re: Is it sill FORTH ? hughaguilar96@gmail.com - 2016-06-18 21:14 -0700
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-14 19:32 -0400
Re: Is it sill FORTH ? Paul Rubin <no.email@nospam.invalid> - 2016-06-14 17:13 -0700
Re: Is it sill FORTH ? Marek Brunda <marekb@phoenics.org> - 2016-06-14 17:21 -0700
Re: Is it sill FORTH ? Paul Rubin <no.email@nospam.invalid> - 2016-06-14 18:36 -0700
Re: Is it sill FORTH ? "Elizabeth D. Rather" <erather@forth.com> - 2016-06-15 16:06 +0200
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-15 06:36 -0700
Re: Is it sill FORTH ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-15 09:20 -0500
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-15 10:55 -0700
Re: Is it sill FORTH ? Paul Rubin <no.email@nospam.invalid> - 2016-06-15 11:07 -0700
Re: Is it sill FORTH ? "Elizabeth D. Rather" <erather@forth.com> - 2016-06-15 16:20 +0200
Re: Is it sill FORTH ? mhx@iae.nl - 2016-06-15 11:19 -0700
Re: Is it sill FORTH ? hughaguilar96@gmail.com - 2016-06-14 22:10 -0700
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-15 01:33 -0400
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-14 19:31 -0400
Re: Is it sill FORTH ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-14 11:15 +0000
Re: Is it sill FORTH ? Mark Wills <markwills1970@gmail.com> - 2016-06-14 05:02 -0700
Re: Is it sill FORTH ? Julian Fondren <julian.fondren@gmail.com> - 2016-06-15 01:44 -0700
Re: Is it sill FORTH ? Julian Fondren <ayrnieu@gmail.com> - 2016-06-15 08:31 -0700
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-15 17:10 -0700
Re: Is it sill FORTH ? Bernd Paysan <bernd.paysan@gmx.de> - 2016-08-05 01:09 +0000
Re: Is it sill FORTH ? hughaguilar96@gmail.com - 2016-06-14 00:55 -0700
Re: Is it sill FORTH ? "Elizabeth D. Rather" <erather@forth.com> - 2016-06-14 16:15 +0200
Re: Is it sill FORTH ? hughaguilar96@gmail.com - 2016-06-15 15:43 -0700
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-15 17:03 -0700
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-15 22:36 -0400
Re: Is it sill FORTH ? Mat <dambere@web.de> - 2016-06-26 04:14 -0700
Re: Is it sill FORTH ? Coos Haak <chforth@hccnet.nl> - 2016-06-26 14:50 +0200
Re: Is it sill FORTH ? lawrencedo99@gmail.com - 2016-06-26 18:58 -0700
Re: Is it sill FORTH ? "Elizabeth D. Rather" <erather@forth.com> - 2016-06-26 22:41 -1000
Page 1 of 6 [1] 2 3 4 5 6 Next page →
| From | Marek Brunda <marekb@phoenics.org> |
|---|---|
| Date | 2016-06-13 13:41 -0700 |
| Subject | Is it sill FORTH ? |
| Message-ID | <0c6bffa3-2fc9-4dfb-876a-cc6319545406@googlegroups.com> |
Gforth example session: 0 constant foo ok foo . 0 ok : bar foo ; ok bar . 0 ok 1234 ' foo >body ! ok foo . 1234 ok bar . 0 ok ( WTF? ) see bar : bar 0 ; ok ( OMG! ) Can anybody explain this?
[toc] | [next] | [standalone]
| From | crc <charles.childers@gmail.com> |
|---|---|
| Date | 2016-06-13 13:57 -0700 |
| Message-ID | <867bd587-389a-40de-8bc4-f3af2a3b248d@googlegroups.com> |
| In reply to | #48085 |
On Monday, June 13, 2016 at 4:41:08 PM UTC-4, Marek Brunda wrote: > Gforth example session: > > 0 constant foo ok > > foo . 0 ok > > : bar foo ; ok > > bar . 0 ok > > 1234 ' foo >body ! ok > > foo . 1234 ok > > bar . 0 ok ( WTF? ) > > see bar > > : bar > 0 ; ok ( OMG! ) > > Can anybody explain this? gforth is inlining the constant: 0 constant foo ok see foo 0 Constant foo ok : bar foo ; ok see bar : bar 0 ; ok When you change foo, it doesn't affect the words defined using it since the constant value was inlined.
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2016-06-13 15:18 -0700 |
| Message-ID | <f5ab7223-ba01-47a1-a72e-b43156c04a98@googlegroups.com> |
| In reply to | #48086 |
I find this behavior disturbing, unless there was a specific word/directive to switch on inlining of constants or other specific compilation behavior. Not sure if the behavior is consistent with ANS Forth, but it looks like it could lead to portability problems. Krishna Myneni
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2016-06-13 15:34 -0700 |
| Message-ID | <17873d92-657f-494a-8c0f-6bd2ad5d212a@googlegroups.com> |
| In reply to | #48087 |
On Monday, June 13, 2016 at 5:18:26 PM UTC-5, krishna...@ccreweb.org wrote: > I find this behavior disturbing, unless there was a specific word/directive to switch on inlining of constants or other specific compilation behavior. Not sure if the behavior is consistent with ANS Forth, but it looks like it could lead to portability problems. > > Krishna Myneni To be clear, I meant Gforth's behavior could lead to portability problems, not the OP's example. KM
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2016-06-13 15:37 -0700 |
| Message-ID | <5cc3e283-5530-45f7-90cc-fe5275076464@googlegroups.com> |
| In reply to | #48088 |
On Monday, June 13, 2016 at 5:34:58 PM UTC-5, krishna...@ccreweb.org wrote: > On Monday, June 13, 2016 at 5:18:26 PM UTC-5, krishna...@ccreweb.org wrote: > > I find this behavior disturbing, unless there was a specific word/directive to switch on inlining of constants or other specific compilation behavior. Not sure if the behavior is consistent with ANS Forth, but it looks like it could lead to portability problems. > > > > Krishna Myneni > > To be clear, I meant Gforth's behavior could lead to portability problems, not the OP's example. > > KM And, it turns out I have the same issue with kForth! KM
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-06-13 15:45 -0700 |
| Message-ID | <874m8wpv2l.fsf@nightsong.com> |
| In reply to | #48088 |
krishna.myneni@ccreweb.org writes: > To be clear, I meant Gforth's behavior could lead to portability > problems, not the OP's example. I don't think it's reasonable to expect OP's example to be portable. What if it's a native code compiler? In fact even in the most obvious types of interpreters it's hard to understand why it should work.
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2016-06-13 15:54 -0700 |
| Message-ID | <4ed94f31-82fb-4a31-a56a-cd55dae94b61@googlegroups.com> |
| In reply to | #48090 |
I guess the point is, when you write n CONSTANT FOO do you really mean it? Since Forth permits such low-level manipulations of built-in data structures, either the standard should state explicitly that inlining constants is allowed, or there should be an explicit directive telling the compiler to inline constants. Note the word >BODY is a core word and one would assume it may be used in all allowed situations and work as expected. Krishna
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2016-06-14 01:41 +0200 |
| Message-ID | <152j583se85l8.mblwlmwe4hph$.dlg@40tude.net> |
| In reply to | #48091 |
Op Mon, 13 Jun 2016 15:54:34 -0700 (PDT) schreef krishna.myneni@ccreweb.org: > I guess the point is, when you write > > n CONSTANT FOO > > do you really mean it? Since Forth permits such low-level manipulations of built-in data structures, either the standard should state explicitly that inlining constants is allowed, or there should be an explicit directive telling the compiler to inline constants. Note the word >BODY is a core word and one would assume it may be used in all allowed situations and work as expected. > > Krishna Why would you want to change a constant. The name says: I am a CONSTANT. You should use VALUE for this kind of manipulation. Or use Figforth ;-) groet Coos
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2016-06-13 16:48 -0700 |
| Message-ID | <2aeb9301-6073-4e19-9593-1778b5259f8f@googlegroups.com> |
| In reply to | #48097 |
We seem to be imposing arbitrary restrictions on what may be done with Forth, in an undocumented way. Perhaps the standard does not guarantee the use of >BODY with constants, but it is certainly not obvious to me. Krishna
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-06-14 03:24 -0500 |
| Message-ID | <D5KdndwRIO-5IsLKnZ2dnUU7-aednZ2d@supernews.com> |
| In reply to | #48099 |
krishna.myneni@ccreweb.org wrote:
> We seem to be imposing arbitrary restrictions on what may be done
> with Forth, in an undocumented way. Perhaps the standard does not
> guarantee the use of >BODY with constants, but it is certainly not
> obvious to me.
6.1.0550 >BODY
to-body CORE
( xt -- a-addr )
a-addr is the data-field address corresponding to xt. An ambiguous
condition exists if xt is not for a word defined via CREATE.
This looks like it qualifies as "obvious". Did you even look?
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2016-06-14 02:53 -0700 |
| Message-ID | <f9db514a-ed7d-41e4-ad9c-a9b0d03864eb@googlegroups.com> |
| In reply to | #48115 |
Yes, I did look, but did not immediately understand this point because it seemed unlikely that a constant would have no meaningful address which could be returned by >BODY. Traditionally, Forth was often written in Forth, and a CREATE ... DOES> definition was one way of providing CONSTANT. I agree with Coos, as I stated previously, that by the letter of the standard one cannot guarantee a particular result by using >BODY on a constant. Nevertheless, both in Gforth and kForth, constants do have a valid >BODY address, as illustrated by the OP for Gforth. The problem with the example didn't come up in these systems because of a missing >BODY. It came up because of inlining constants, which one could reasonably argue is a sensible thing to expect for constants. Krishna
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2016-06-14 01:53 +0200 |
| Message-ID | <1s4p3yueyfoaa$.1eceb4lzfz11k.dlg@40tude.net> |
| In reply to | #48097 |
Op Tue, 14 Jun 2016 01:41:47 +0200 schreef Coos Haak: > Op Mon, 13 Jun 2016 15:54:34 -0700 (PDT) schreef > krishna.myneni@ccreweb.org: > >> I guess the point is, when you write >> >> n CONSTANT FOO >> >> do you really mean it? Since Forth permits such low-level manipulations of built-in data structures, either the standard should state explicitly that inlining constants is allowed, or there should be an explicit directive telling the compiler to inline constants. Note the word >BODY is a core word and one would assume it may be used in all allowed situations and work as expected. >> >> Krishna > > Why would you want to change a constant. The name says: I am a CONSTANT. > You should use VALUE for this kind of manipulation. > Or use Figforth ;-) > > groet Coos And above that, when CONSTANT was not built by CREATE and DOES> , >BODY is undefined. Only the self apppointed tzar of Forth may do this. groet Coos
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2016-06-13 17:25 -0700 |
| Message-ID | <a4fd1547-d40a-48f3-b05a-0a59d2df9809@googlegroups.com> |
| In reply to | #48100 |
This argument seems valid. Since the implementation of CONSTANT isn't guaranteed to depend on CREATE ... DOES> , then the use of >BODY isn't portable. Krishna
[toc] | [prev] | [next] | [standalone]
| From | Marek Brunda <marekb@phoenics.org> |
|---|---|
| Date | 2016-06-13 22:23 -0700 |
| Message-ID | <1622adbf-7d5a-45f0-aa43-353fc553177b@googlegroups.com> |
| In reply to | #48103 |
Dne úterý 14. června 2016 2:25:43 UTC+2 krishna...@ccreweb.org napsal(a): > This argument seems valid. Since the implementation of CONSTANT isn't guaranteed to depend on CREATE ... DOES> , then the use of >BODY isn't portable. > > Krishna The majority of contributions is about whether it is or is not standard/portable. It's not point. IMO it's not portable. But traditional constant in forth is not immutable. In addition IMO this is not expected behavior. If there is word >BODY and I know, that it returns addres where the value of the constant lives, I don't assume that changing it has no effect. When you noted VALUE, can anybody explain the reason, why we have VALUEs in addition to VARIABLEs? Thanks
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-06-14 03:13 -0400 |
| Message-ID | <njoaqe$dcr$1@dont-email.me> |
| In reply to | #48109 |
On 6/14/2016 1:23 AM, Marek Brunda wrote: > Dne úterý 14. června 2016 2:25:43 UTC+2 krishna...@ccreweb.org napsal(a): >> This argument seems valid. Since the implementation of CONSTANT isn't guaranteed to depend on CREATE ... DOES> , then the use of >BODY isn't portable. >> >> Krishna > > > The majority of contributions is about whether it is or is not standard/portable. It's not point. IMO it's not portable. But traditional constant in forth is not immutable. In addition IMO this is not expected behavior. If there is word >BODY and I know, that it returns addres where the value of the constant lives, I don't assume that changing it has no effect. > > When you noted VALUE, can anybody explain the reason, why we have VALUEs in addition to VARIABLEs? Value and Variable are used differently. A variable returns the address of the variable to be used with @ and !. A value word returns the value of the data stored or when used with TO allows the data to be updated, i.e. written to. Why would you expect the value of a constant to be mutable? Clearly that is not the intent of a constant, hence the name. Further, not all Forths run on a PC or other machine where the entire program is run from RAM. Sometimes the program and immutable data is stored in ROM memory while means you have to store the mutable data somewhere else. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2016-06-14 09:17 +0200 |
| Subject | VALUE |
| Message-ID | <86d1nk2q9y.fsf_-_@molnjunk.nocrew.org> |
| In reply to | #48109 |
Marek Brunda wrote: > can anybody explain the reason, why we have VALUEs in addition > to VARIABLEs? If I submit some wild guesses, no doubt someone will be delighted to provide corrections. - Using VALUE is a minor convenience when a variable is read many times, but changed rarely. - Provides a way to create global variables that can be used the same way as local variables. - A VALUE doesn't need an address, so can be stored in a register.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-06-14 03:51 -0500 |
| Message-ID | <_LSdnUrFsvUCWMLKnZ2dnUU7-IPNnZ2d@supernews.com> |
| In reply to | #48109 |
Marek Brunda <marekb@phoenics.org> wrote:
>
> When you noted VALUE, can anybody explain the reason, why we have
> VALUEs in addition to VARIABLEs?
You can find the original proposal at
http://www.forth.org/fd/FD-V01N4.pdf. Here is the justification:
At the Catalina standardization meeting,
Chuck Moore suggested rapidly the "TO"
construct to aleviate some, if not all, of
the difficulties associated with address
manipulation. This new construction seems
to me extremely powerful. It should con-
siderably decrease the number of errors
and improve the readability of programs.
It is very easy to understand and to use
(much easier in fact than the constructs
it is replacing!). Its implementation is
also trivial but the lack of experience in
using it may hide some difficulties.
I've never been convinced by this line of reasoning, but it's part of
Forth's history.
Note that this original definition of "TO" works in a rather different
way from TO as eventually standardized.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Marek Brunda <marekb@phoenics.org> |
|---|---|
| Date | 2016-06-14 02:45 -0700 |
| Message-ID | <a54866d8-8985-4eda-9c7e-d3c94766a1cc@googlegroups.com> |
| In reply to | #48117 |
Dne úterý 14. června 2016 10:51:48 UTC+2 Andrew Haley napsal(a): > Marek Brunda <marekb@phoenics.org> wrote: > > > > When you noted VALUE, can anybody explain the reason, why we have > > VALUEs in addition to VARIABLEs? > > You can find the original proposal at > http://www.forth.org/fd/FD-V01N4.pdf. Here is the justification: > > At the Catalina standardization meeting, > Chuck Moore suggested rapidly the "TO" > construct to aleviate some, if not all, of > the difficulties associated with address > manipulation. This new construction seems > to me extremely powerful. It should con- > siderably decrease the number of errors > and improve the readability of programs. > It is very easy to understand and to use > (much easier in fact than the constructs > it is replacing!). Its implementation is > also trivial but the lack of experience in > using it may hide some difficulties. > > I've never been convinced by this line of reasoning, but it's part of > Forth's history. > > Note that this original definition of "TO" works in a rather different > way from TO as eventually standardized. > > Andrew. Incthis article the author states: variables should be dropped altogether. It's 27 years old article. I agree with author - modern forth should live without VARIABLEs in favour to VALUEs. Both concepts are redundant, mutual and poorly understood by novices. We have: CONSTANT VARIABLE VALUE USER There is no clarification if CONSTANT is truly immutable (really it's on half way). VARIABLE vs VALUE - it seems the VARIABLEs are used for "good known" variables for historical reasons. VALUES for the rest. For me it's syntactic sugar but not truly lightweight as syntactic sugar should be. As I understand this, it's just chaos without conception.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-06-15 04:21 -0500 |
| Message-ID | <372dnVicGKWCg_zKnZ2dnUU7-a3NnZ2d@supernews.com> |
| In reply to | #48119 |
Marek Brunda <marekb@phoenics.org> wrote: > > There is no clarification if CONSTANT is truly immutable (really > it's on half way). It is immutable. > VARIABLE vs VALUE - it seems the VARIABLEs are used for "good known" > variables for historical reasons. VALUES for the rest. Not really, as hopefully you'll discover as you learn. VARIABLEs are more flexible than VALUEs because they have addresses. So, you can have a word which operates on a cell in memory and that word will work on the body of a VARIABLE, on an array element, on a field in a structure, and so on. There are also many possibilites for creating "VARIABLE-like" words in Forth, such as words which behave like VARIABLEs but are actually fields in a data structure. In addition, there are some complexities in what exactly you're allowed to do with TO when metaprogramming. So, VARIABLE is the general and flexible case; VALUE is something whose use is rather more specialized. > As I understand this, it's just chaos without conception. It can appear that way, but if you persist it'll become clearer. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2016-08-05 21:02 -0700 |
| Message-ID | <9547bfc2-3e29-4e82-bde3-e582fd584df4@googlegroups.com> |
| In reply to | #48119 |
On Tuesday, June 14, 2016 at 2:45:47 AM UTC-7, Marek Brunda wrote: > We have: CONSTANT VARIABLE VALUE USER > > There is no clarification if CONSTANT is truly immutable (really it's on half way). > > VARIABLE vs VALUE - it seems the VARIABLEs are used for "good known" variables for historical reasons. VALUES for the rest. For me it's syntactic sugar but not truly lightweight as syntactic sugar should be. > > As I understand this, it's just chaos without conception. Maybe the problem is that the ANS standard assumes understanding of Forth implementations. When it mentions an ambiguous condition, you are expected to understand the various reasons it might be ambiguous. They should fix that with hyperlinks to allow drilling down to a detailed rationale. A mutable constant is called a VALUE. I wouldn't consider a CONSTANT to be mutable or tickable. It's reasonable to assume that any Forth you use will support VALUEs. VARIABLEs are actually quite powerful because of the extensibility they provide. Suppose you have VARIABLE FOO. You have lots of code that uses FOO. Then, at some point you decide FOO should be an array instead of a single variable. No problem, you can define something like this: VARIABLE 'FOO : NEWFOO ( <name> -- ) CREATE HERE , CELL ALLOT DOES> 'FOO ! ; : FOO ( -- a ) 'FOO @ ; NEWFOO MYFOO \ create a new instance of FOO MYFOO \ select the new instance 100 FOO ! \ store to this instance of FOO The thing to understand about Forth is that everything is there for a reason. Chuck Moore and others developed the language based on several decades of real world experience and a pruning process that removed features that weren't useful.
[toc] | [prev] | [next] | [standalone]
Page 1 of 6 [1] 2 3 4 5 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web