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 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-08-05 21:48 -1000 |
| Message-ID | <O8udnQG0fZ2iCzjKnZ2dnUU7-R_NnZ2d@supernews.com> |
| In reply to | #49807 |
On 8/5/16 6:02 PM, Brad Eckert wrote: > 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. > VARIABLE and VALUE are really optimizations for two different situations: VARIABLE provides you with an address most efficiently. VALUEs do not provide an address, merely access to a changeable constant. Sometimes one is preferable to the other, depending upon what you're going to do with it. 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 | missycurl@gmail.com |
|---|---|
| Date | 2016-08-06 05:37 -0700 |
| Message-ID | <a19a8294-6871-4ec5-a1ea-3244916c884a@googlegroups.com> |
| In reply to | #49809 |
On Saturday, August 6, 2016 at 3:48:21 AM UTC-4, Elizabeth D. Rather wrote: > > VARIABLE and VALUE are really optimizations for two different > situations: VARIABLE provides you with an address most efficiently. > VALUEs do not provide an address, merely access to a changeable > constant. Sometimes one is preferable to the other, depending upon what > you're going to do with it. > > Cheers, > Elizabeth A "changeable constant" ... let's all just let that sink in a minute. I would call that a contradiction in terms. "1. not changing or varying" http://www.dictionary.com/browse/constant
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2016-08-06 06:37 -0700 |
| Message-ID | <af84c7ae-854d-4379-a591-128fc06d3285@googlegroups.com> |
| In reply to | #49813 |
On Saturday, August 6, 2016 at 3:37:46 PM UTC+3, miss...@gmail.com wrote: > On Saturday, August 6, 2016 at 3:48:21 AM UTC-4, Elizabeth D. Rather wrote: > > > > VARIABLE and VALUE are really optimizations for two different > > situations: VARIABLE provides you with an address most efficiently. > > VALUEs do not provide an address, merely access to a changeable > > constant. Sometimes one is preferable to the other, depending upon what > > you're going to do with it. > > > > Cheers, > > Elizabeth > > A "changeable constant" ... let's all just let that sink in a minute. > > I would call that a contradiction in terms. > > "1. not changing or varying" > > http://www.dictionary.com/browse/constant Hi! Changing constants can cause serious troubles! Ex.: 6.674e-11 FCONSTANT G \ gravitational constant 0.0e ' G >body F! \ Wait! Why everything around begins to levitate? -- Have a nice day, humptydumpty
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2016-08-06 08:53 -0500 |
| Message-ID | <no4q5o$v5f$1@dont-email.me> |
| In reply to | #49815 |
On 8/6/2016 8:37 AM, humptydumpty wrote: > On Saturday, August 6, 2016 at 3:37:46 PM UTC+3, miss...@gmail.com wrote: >> On Saturday, August 6, 2016 at 3:48:21 AM UTC-4, Elizabeth D. Rather wrote: >>> >>> VARIABLE and VALUE are really optimizations for two different >>> situations: VARIABLE provides you with an address most efficiently. >>> VALUEs do not provide an address, merely access to a changeable >>> constant. Sometimes one is preferable to the other, depending upon what >>> you're going to do with it. >>> >>> Cheers, >>> Elizabeth >> >> A "changeable constant" ... let's all just let that sink in a minute. >> >> I would call that a contradiction in terms. >> >> "1. not changing or varying" >> >> http://www.dictionary.com/browse/constant > > Hi! > > Changing constants can cause serious troubles! Ex.: > > 6.674e-11 FCONSTANT G \ gravitational constant > 0.0e ' G >body F! > \ Wait! Why everything around begins to levitate? > > -- > Have a nice day, > humptydumpty > That one deserves a special chapter in the book "ANS Forth an alternative reality", another chapter could be "The X word behaves this way, sometimes". -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2016-08-06 07:18 -0700 |
| Message-ID | <2427f735-62b5-40fd-b68c-e56e71f9c705@googlegroups.com> |
| In reply to | #49816 |
On Saturday, August 6, 2016 at 4:54:02 PM UTC+3, Cecil - k5nwa wrote: > On 8/6/2016 8:37 AM, humptydumpty wrote: > > On Saturday, August 6, 2016 at 3:37:46 PM UTC+3, miss...@gmail.com wrote: > >> On Saturday, August 6, 2016 at 3:48:21 AM UTC-4, Elizabeth D. Rather wrote: > >>> > >>> VARIABLE and VALUE are really optimizations for two different > >>> situations: VARIABLE provides you with an address most efficiently. > >>> VALUEs do not provide an address, merely access to a changeable > >>> constant. Sometimes one is preferable to the other, depending upon what > >>> you're going to do with it. > >>> > >>> Cheers, > >>> Elizabeth > >> > >> A "changeable constant" ... let's all just let that sink in a minute. > >> > >> I would call that a contradiction in terms. > >> > >> "1. not changing or varying" > >> > >> http://www.dictionary.com/browse/constant > > > > Hi! > > > > Changing constants can cause serious troubles! Ex.: > > > > 6.674e-11 FCONSTANT G \ gravitational constant > > 0.0e ' G >body F! > > \ Wait! Why everything around begins to levitate? > > > > -- > > Have a nice day, > > humptydumpty > > > > That one deserves a special chapter in the book "ANS Forth an > alternative reality", another chapter could be "The X word behaves this > way, sometimes". > -- > Cecil - k5nwa Yes, yes! :)) A Forth Easter Egg! :) -- Have a nice day, humptydumpty
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2016-08-06 07:40 -0700 |
| Message-ID | <80a404a4-842a-4055-a774-b9330987a6a3@googlegroups.com> |
| In reply to | #49816 |
On Saturday, August 6, 2016 at 4:54:02 PM UTC+3, Cecil - k5nwa wrote:
> On 8/6/2016 8:37 AM, humptydumpty wrote:
> > On Saturday, August 6, 2016 at 3:37:46 PM UTC+3, miss...@gmail.com wrote:
> >> On Saturday, August 6, 2016 at 3:48:21 AM UTC-4, Elizabeth D. Rather wrote:
> >>>
> >>> VARIABLE and VALUE are really optimizations for two different
> >>> situations: VARIABLE provides you with an address most efficiently.
> >>> VALUEs do not provide an address, merely access to a changeable
> >>> constant. Sometimes one is preferable to the other, depending upon what
> >>> you're going to do with it.
> >>>
> >>> Cheers,
> >>> Elizabeth
> >>
> >> A "changeable constant" ... let's all just let that sink in a minute.
> >>
> >> I would call that a contradiction in terms.
> >>
> >> "1. not changing or varying"
> >>
> >> http://www.dictionary.com/browse/constant
> >
> > Hi!
> >
> > Changing constants can cause serious troubles! Ex.:
> >
> > 6.674e-11 FCONSTANT G \ gravitational constant
> > 0.0e ' G >body F!
> > \ Wait! Why everything around begins to levitate?
> >
> > --
> > Have a nice day,
> > humptydumpty
> >
>
> That one deserves a special chapter in the book "ANS Forth an
> alternative reality", another chapter could be "The X word behaves this
> way, sometimes".
> --
> Cecil - k5nwa
A funny thing. Fooling around with macros,
I wrote today something like 'dimensions.fs':
\ dimensions.fs
[UNDEFINED] STARTAPP
[IF]
VOCABULARY STARTAPP ALSO STARTAPP DEFINITIONS
: FORTH-EVALUATE ALSO FORTH ['] EVALUATE CATCH PREVIOUS THROW ;
[THEN]
\ One line macro definer package :)
[UNDEFINED] ENDS>
[IF] : ENDS> R> ; : END >R ; IMMEDIATE [THEN]
: [I]
0 postpone literal
postpone ?DO
postpone I ends>
postpone LOOP
; IMMEDIATE
: [IJ]
0 postpone literal
postpone ?DO
postpone dup 0 postpone literal
postpone ?DO
postpone I postpone J
postpone rot postpone >R
ends>
postpone R>
postpone LOOP
postpone LOOP
postpone drop
; IMMEDIATE
: [I>J]
0 postpone literal
postpone ?DO
postpone I 0 postpone literal
postpone ?DO
postpone I postpone J
ends>
postpone LOOP
postpone LOOP
; IMMEDIATE
: [IJK]
0 postpone literal
postpone ?DO
postpone dup 0 postpone literal
postpone ?DO
postpone over 0 postpone literal
postpone ?DO
postpone I postpone J postpone 2swap
postpone K postpone -rot postpone 2>R
ends>
postpone 2R>
postpone LOOP
postpone LOOP
postpone LOOP
postpone 2drop
; IMMEDIATE
1 [IF]
: i-test [i] . .s end .s ;
10 i-test see i-test
: ij-test [ij] cr . . .s end .s ;
4 3 ij-test see ij-test
: i>j-test [i>j] . . .s 2 spaces end .s ;
4 cr i>j-test see i>j-test
: ijk-test [ijk] cr . . . .s end .s ;
4 3 2 ijk-test see ijk-test
.S cr bye
[THEN]
Have fun!
--
humptydumpty
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-08-06 15:07 -1000 |
| Message-ID | <zIqdnXAlU65QFDvKnZ2dnUU7-XfNnZ2d@supernews.com> |
| In reply to | #49813 |
On 8/6/16 2:37 AM, missycurl@gmail.com wrote: > On Saturday, August 6, 2016 at 3:48:21 AM UTC-4, Elizabeth D. Rather wrote: >> >> VARIABLE and VALUE are really optimizations for two different >> situations: VARIABLE provides you with an address most efficiently. >> VALUEs do not provide an address, merely access to a changeable >> constant. Sometimes one is preferable to the other, depending upon what >> you're going to do with it. >> >> Cheers, >> Elizabeth > > A "changeable constant" ... let's all just let that sink in a minute. > > I would call that a contradiction in terms. > > "1. not changing or varying" > > http://www.dictionary.com/browse/constant In Forth, a CONSTANT returns a value when you invoke its name, whereas a VARIABLE returns an address. In olden times, you could change the value of a CONSTANT by using [value] ' [NAME] >BODY ! or similar phrasing. But in more modern systems, CONSTANTs are often in ROM or even compiled into each definition that references it as a literal. Therefore, ANS Forth asserted that a Standard Program cannot depend upon being able to change the value of a CONSTANT. Instead, it added VALUE, whose behavior is like a CONSTANT (returns its value), but you can change it using TO. So, the pedantically correct description would be, "A data object that behaves like a CONSTANT but which, unlike CONSTANT, has a mechanism by which its value may be changed." Is that better? 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 | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-06 19:14 -0700 |
| Message-ID | <e0b6c552-e2cd-4373-a015-475a0524f5db@googlegroups.com> |
| In reply to | #49824 |
On Saturday, August 6, 2016 at 6:07:31 PM UTC-7, Elizabeth D. Rather wrote: > On 8/6/16 2:37 AM, missycurl@gmail.com wrote: > > On Saturday, August 6, 2016 at 3:48:21 AM UTC-4, Elizabeth D. Rather wrote: > >> > >> VARIABLE and VALUE are really optimizations for two different > >> situations: VARIABLE provides you with an address most efficiently. > >> VALUEs do not provide an address, merely access to a changeable > >> constant. Sometimes one is preferable to the other, depending upon what > >> you're going to do with it. > >> > >> Cheers, > >> Elizabeth > > > > A "changeable constant" ... let's all just let that sink in a minute. > > > > I would call that a contradiction in terms. > > > > "1. not changing or varying" > > > > http://www.dictionary.com/browse/constant > > In Forth, a CONSTANT returns a value when you invoke its name, whereas a > VARIABLE returns an address. In olden times, you could change the value > of a CONSTANT by using [value] ' [NAME] >BODY ! or similar phrasing. But > in more modern systems, CONSTANTs are often in ROM or even compiled into > each definition that references it as a literal. Therefore, ANS Forth > asserted that a Standard Program cannot depend upon being able to change > the value of a CONSTANT. Instead, it added VALUE, whose behavior is like > a CONSTANT (returns its value), but you can change it using TO. So, the > pedantically correct description would be, "A data object that behaves > like a CONSTANT but which, unlike CONSTANT, has a mechanism by which its > value may be changed." > > Is that better? No --- it is not any better --- it is still nonsense. It is very redundant to have both VALUE and VARIABLE for mutable data. Also, it was a huge mistake to make locals like VALUE rather than VARIABLE --- if locals provided an address, and if they were large enough to hold any kind of data (integer or float or whatever), then they could hold any kind of data. Even before VALUE (originally called ITEM) was introduced (in "Forth Dimensions"), I considered CONSTANT to be confusing because it behaved differently from VARIABLE --- I often couldn't remember if a particular datum was a constant or a variable and so I couldn't remember if it returned a value or an address --- also, I would sometimes change a particular datum from constant to variable or vice-versa, but this would screw everything up because it now behaved differently. In Straight Forth I will get rid of VALUE, and I will also get rid of CONSTANT and DCONSTANT etc.. I will instead have an IMMUTABLE word that can be used after a VARIABLE or DVARIABLE etc. definition and will make the last variable immutable --- this means that it gets stored in a part of memory that can't be written to --- if anybody tries to write to an immutable variable this will cause an abort. For example: CREATE BAR 123 , 456 , 789 , IMMUTABLE When IMMUTABLE executes, it makes BAR immutable so it can't be changed again. Typically, it will move the whole thing over to the section of memory that can't be written to. Also, I will go back to the old kind (Forth-79) of VARIABLE that was initialized when it was defined. All variables should be explicitly initialized so the program behaves consistently. Consider this in ANS-Forth: VARIABLE FOO ... \ lots of code here FALSE FOO ! ... \ code here assumes that FOO is initialized If the programmer forgets to initialize FOO explicitly then the program will still run. It will seem to run correctly in the case where the memory allotted to FOO happened to contain a zero --- the program may run correctly sometimes that it is compiled and incorrectly other times that it is compiled --- these are very difficult bugs to track down! With Straight Forth this would be done like this: FALSE VARIABLE FOO If the programmer forgets the FALSE then VARIABLE will give him a stack-underflow error, so he finds out about his mistake immediately.
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2016-08-07 10:38 -0700 |
| Message-ID | <376b51fb-0d81-4441-a68c-323ae528f29e@googlegroups.com> |
| In reply to | #49824 |
On Saturday, August 6, 2016 at 9:07:31 PM UTC-4, Elizabeth D. Rather wrote: > In Forth, a CONSTANT returns a value when you invoke its name, whereas a > VARIABLE returns an address. In olden times, you could change the value > of a CONSTANT by using [value] ' [NAME] >BODY ! or similar phrasing. But > in more modern systems, CONSTANTs are often in ROM or even compiled into > each definition that references it as a literal. Therefore, ANS Forth > asserted that a Standard Program cannot depend upon being able to change > the value of a CONSTANT. Instead, it added VALUE, whose behavior is like > a CONSTANT (returns its value), but you can change it using TO. So, the > pedantically correct description would be, "A data object that behaves > like a CONSTANT but which, unlike CONSTANT, has a mechanism by which its > value may be changed." > > Is that better? > > Cheers, > Elizabeth Maybe a little ... So some person realized he (or she) could essentially hack the definition of words defined as CONSTANTs and make it return a different value than was specified when the CONSTANT was defined. How smart of them. But if you understand what the term CONSTANT means, then the only expectation that makes sense is that the value returned will not change. The fact that there is a hack that you can do to change it is a result of how open Forth is. That is not a bad thing, but just because you CAN do it doesn't mean it is a good idea to ACTUALLY do it, and EXPECT to be able to do it everywhere. For the record Elizabeth, I do not believe that that you are advocating this behavior should be standard. But the OP seems to think it should be. To anyone who is totally OK with the notion that CONSTANTs can change, and that the ability to do such a thing should be expected behavior, then I am going to point out the craziness.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-08-07 20:57 -1000 |
| Message-ID | <FJmdnZFIqLbGsDXKnZ2dnUU7-YnNnZ2d@supernews.com> |
| In reply to | #49848 |
On 8/7/16 7:38 AM, Chris Curl wrote: > On Saturday, August 6, 2016 at 9:07:31 PM UTC-4, Elizabeth D. Rather wrote: >> In Forth, a CONSTANT returns a value when you invoke its name, whereas a >> VARIABLE returns an address. In olden times, you could change the value >> of a CONSTANT by using [value] ' [NAME] >BODY ! or similar phrasing. But >> in more modern systems, CONSTANTs are often in ROM or even compiled into >> each definition that references it as a literal. Therefore, ANS Forth >> asserted that a Standard Program cannot depend upon being able to change >> the value of a CONSTANT. Instead, it added VALUE, whose behavior is like >> a CONSTANT (returns its value), but you can change it using TO. So, the >> pedantically correct description would be, "A data object that behaves >> like a CONSTANT but which, unlike CONSTANT, has a mechanism by which its >> value may be changed." >> >> Is that better? >> >> Cheers, >> Elizabeth > Maybe a little ... > > So some person realized he (or she) could essentially hack the definition > of words defined as CONSTANTs and make it return a different value than > was specified when the CONSTANT was defined. How smart of them. > > But if you understand what the term CONSTANT means, then the only expectation > that makes sense is that the value returned will not change. The fact that > there is a hack that you can do to change it is a result of how open Forth > is. That is not a bad thing, but just because you CAN do it doesn't mean it > is a good idea to ACTUALLY do it, and EXPECT to be able to do it everywhere. > > For the record Elizabeth, I do not believe that that you are advocating > this behavior should be standard. But the OP seems to think it should be. > > To anyone who is totally OK with the notion that CONSTANTs can change, > and that the ability to do such a thing should be expected behavior, then > I am going to point out the craziness. Well, IMO the fact that Standard Forth now recognizes that CONSTANTs are unchangeable and VALUEs *can* be changed reduces the cognitive dissonance but preserves the facility that some people need. Yes, I do want to slap down people who come from Starting Forth and insist on changing CONSTANTs! Cheers, Elizaeth -- ================================================== 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 | Roelf Toxopeus <rt4all@nothishetnet.nl> |
|---|---|
| Date | 2016-08-08 22:20 +0200 |
| Message-ID | <57a8e99e$0$32206$e4fe514c@textnews.kpn.nl> |
| In reply to | #49867 |
On 08/08/16 08:57, Elizabeth D. Rather wrote: > On 8/7/16 7:38 AM, Chris Curl wrote: >> On Saturday, August 6, 2016 at 9:07:31 PM UTC-4, Elizabeth D. Rather >> wrote: >>> In Forth, a CONSTANT returns a value when you invoke its name, whereas a >>> VARIABLE returns an address. In olden times, you could change the value >>> of a CONSTANT by using [value] ' [NAME] >BODY ! or similar phrasing. But >>> in more modern systems, CONSTANTs are often in ROM or even compiled into >>> each definition that references it as a literal. Therefore, ANS Forth >>> asserted that a Standard Program cannot depend upon being able to change >>> the value of a CONSTANT. Instead, it added VALUE, whose behavior is like >>> a CONSTANT (returns its value), but you can change it using TO. So, the >>> pedantically correct description would be, "A data object that behaves >>> like a CONSTANT but which, unlike CONSTANT, has a mechanism by which its >>> value may be changed." >>> >>> Is that better? >>> >>> Cheers, >>> Elizabeth >> Maybe a little ... >> >> So some person realized he (or she) could essentially hack the definition >> of words defined as CONSTANTs and make it return a different value than >> was specified when the CONSTANT was defined. How smart of them. >> >> But if you understand what the term CONSTANT means, then the only >> expectation >> that makes sense is that the value returned will not change. The fact >> that >> there is a hack that you can do to change it is a result of how open >> Forth >> is. That is not a bad thing, but just because you CAN do it doesn't >> mean it >> is a good idea to ACTUALLY do it, and EXPECT to be able to do it >> everywhere. >> >> For the record Elizabeth, I do not believe that that you are advocating >> this behavior should be standard. But the OP seems to think it should be. >> >> To anyone who is totally OK with the notion that CONSTANTs can change, >> and that the ability to do such a thing should be expected behavior, then >> I am going to point out the craziness. > > Well, IMO the fact that Standard Forth now recognizes that CONSTANTs are > unchangeable and VALUEs *can* be changed reduces the cognitive > dissonance but preserves the facility that some people need. Yes, I do > want to slap down people who come from Starting Forth and insist on > changing CONSTANTs! > You're not trying to put the blame on Starting Forth do you? Forth Programmers Handbook, co-authored by you. Second edition 9th printing 2004, page 136, 4.2.3 CONSTANTs and VALUEs <quote> The purpose of a CONSTANT is to provide a name for a value which is referenced often but may be changed seldom or never. ... In order to change a CONSTANT ... ... 100 CONSTANT SIZE 500 ' SIZE >BODY ! </quote> I know that the part between the quotes is deleted in the Third edition, August 2007 Latest revision, October 2010, as provided with SwiftForth. Rightfully so, but perhaps a little too late to be noticed by some.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-08-08 12:14 -1000 |
| Message-ID | <m8adnaWUcsfYmTTKnZ2dnUU7-SnNnZ2d@supernews.com> |
| In reply to | #49880 |
On 8/8/16 10:20 AM, Roelf Toxopeus wrote: > On 08/08/16 08:57, Elizabeth D. Rather wrote: >> On 8/7/16 7:38 AM, Chris Curl wrote: >>> On Saturday, August 6, 2016 at 9:07:31 PM UTC-4, Elizabeth D. Rather >>> wrote: >>>> In Forth, a CONSTANT returns a value when you invoke its name, >>>> whereas a >>>> VARIABLE returns an address. In olden times, you could change the value >>>> of a CONSTANT by using [value] ' [NAME] >BODY ! or similar phrasing. >>>> But >>>> in more modern systems, CONSTANTs are often in ROM or even compiled >>>> into >>>> each definition that references it as a literal. Therefore, ANS Forth >>>> asserted that a Standard Program cannot depend upon being able to >>>> change >>>> the value of a CONSTANT. Instead, it added VALUE, whose behavior is >>>> like >>>> a CONSTANT (returns its value), but you can change it using TO. So, the >>>> pedantically correct description would be, "A data object that behaves >>>> like a CONSTANT but which, unlike CONSTANT, has a mechanism by which >>>> its >>>> value may be changed." >>>> >>>> Is that better? >>>> >>>> Cheers, >>>> Elizabeth >>> Maybe a little ... >>> >>> So some person realized he (or she) could essentially hack the >>> definition >>> of words defined as CONSTANTs and make it return a different value than >>> was specified when the CONSTANT was defined. How smart of them. >>> >>> But if you understand what the term CONSTANT means, then the only >>> expectation >>> that makes sense is that the value returned will not change. The fact >>> that >>> there is a hack that you can do to change it is a result of how open >>> Forth >>> is. That is not a bad thing, but just because you CAN do it doesn't >>> mean it >>> is a good idea to ACTUALLY do it, and EXPECT to be able to do it >>> everywhere. >>> >>> For the record Elizabeth, I do not believe that that you are advocating >>> this behavior should be standard. But the OP seems to think it should >>> be. >>> >>> To anyone who is totally OK with the notion that CONSTANTs can change, >>> and that the ability to do such a thing should be expected behavior, >>> then >>> I am going to point out the craziness. >> >> Well, IMO the fact that Standard Forth now recognizes that CONSTANTs are >> unchangeable and VALUEs *can* be changed reduces the cognitive >> dissonance but preserves the facility that some people need. Yes, I do >> want to slap down people who come from Starting Forth and insist on >> changing CONSTANTs! >> > > You're not trying to put the blame on Starting Forth do you? > > Forth Programmers Handbook, co-authored by you. Second edition 9th > printing 2004, page 136, 4.2.3 CONSTANTs and VALUEs > <quote> > The purpose of a CONSTANT is to provide a name for a value which is > referenced often but may be changed seldom or never. > ... > In order to change a CONSTANT ... > ... 100 CONSTANT SIZE > 500 ' SIZE >BODY ! > </quote> > > I know that the part between the quotes is deleted in the Third edition, > August 2007 Latest revision, October 2010, as provided with SwiftForth. > Rightfully so, but perhaps a little too late to be noticed by some. I'm not trying to put blame anywhere, just pointing out that the "mutable constant" situation which you feel is terrible is resolved now. It used to be common practice, but it isn't in modern Forths. 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 | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-09 00:29 -0700 |
| Message-ID | <7235bee0-d261-4a88-b87d-a8d71becfb9f@googlegroups.com> |
| In reply to | #49880 |
On Monday, August 8, 2016 at 1:20:48 PM UTC-7, Roelf Toxopeus wrote: > On 08/08/16 08:57, Elizabeth D. Rather wrote: > > Well, IMO the fact that Standard Forth now recognizes that CONSTANTs are > > unchangeable and VALUEs *can* be changed reduces the cognitive > > dissonance but preserves the facility that some people need. Yes, I do > > want to slap down people who come from Starting Forth and insist on > > changing CONSTANTs! Elizabeth Rather the dominatrix! LOL > You're not trying to put the blame on Starting Forth do you? > > Forth Programmers Handbook, co-authored by you. Second edition 9th > printing 2004, page 136, 4.2.3 CONSTANTs and VALUEs > <quote> > The purpose of a CONSTANT is to provide a name for a value which is > referenced often but may be changed seldom or never. > ... > In order to change a CONSTANT ... > ... 100 CONSTANT SIZE > 500 ' SIZE >BODY ! > </quote> > > I know that the part between the quotes is deleted in the Third edition, > August 2007 Latest revision, October 2010, as provided with SwiftForth. > Rightfully so, but perhaps a little too late to be noticed by some. Both books were published by Forth Inc. --- everything that comes out of Forth Inc. is crap.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-06 19:30 -0700 |
| Message-ID | <acbb59a2-3b2b-4d0a-8ac4-de196c4c1db1@googlegroups.com> |
| In reply to | #49813 |
On Saturday, August 6, 2016 at 5:37:46 AM UTC-7, miss...@gmail.com wrote: > On Saturday, August 6, 2016 at 3:48:21 AM UTC-4, Elizabeth D. Rather wrote: > > > > VARIABLE and VALUE are really optimizations for two different > > situations: VARIABLE provides you with an address most efficiently. > > VALUEs do not provide an address, merely access to a changeable > > constant. Sometimes one is preferable to the other, depending upon what > > you're going to do with it. > > > > Cheers, > > Elizabeth > > A "changeable constant" ... let's all just let that sink in a minute. > > I would call that a contradiction in terms. > > "1. not changing or varying" > > http://www.dictionary.com/browse/constant Chris Curl --- you are accidentally using your daughter's gmail account again --- I'm assuming that your nickname isn't "Missy." I once received an email from Alex McDonald) in my personal gmail account saying that I could do him a huge favor by dying --- so be careful that you only use your own gmail account on comp.lang.forth --- imagine how difficult your situation will be if your daughter comes to you sobbing and saying: "Some ANS-Forth enthusiast just told me to do him the huge favor of dying! What is ANS-Forth??? Are these friends of yours???"
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2016-08-07 07:42 -0700 |
| Message-ID | <7b7d5337-fc91-4566-a05f-c1f8b7d7670b@googlegroups.com> |
| In reply to | #49828 |
> Chris Curl --- you are accidentally using your daughter's gmail account again --- I'm assuming that your nickname isn't "Missy." > > I once received an email from Alex McDonald) in my personal gmail account saying that I could do him a huge favor by dying --- so be careful that you only use your own gmail account on comp.lang.forth --- imagine how difficult your situation will be if your daughter comes to you sobbing and saying: "Some ANS-Forth enthusiast just told me to do him the huge favor of dying! What is ANS-Forth??? Are these friends of yours???" Ugh, yeah. This is the computer in the kitchen. She is always logging me out and logging in as herself!
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-07 13:34 -0700 |
| Message-ID | <f0d6d895-7cf2-47df-896a-223d7ad1e596@googlegroups.com> |
| In reply to | #49843 |
On Sunday, August 7, 2016 at 7:42:21 AM UTC-7, Chris Curl wrote: > > Chris Curl --- you are accidentally using your daughter's gmail account again --- I'm assuming that your nickname isn't "Missy." > > > > I once received an email from Alex McDonald) in my personal gmail account saying that I could do him a huge favor by dying --- so be careful that you only use your own gmail account on comp.lang.forth --- imagine how difficult your situation will be if your daughter comes to you sobbing and saying: "Some ANS-Forth enthusiast just told me to do him the huge favor of dying! What is ANS-Forth??? Are these friends of yours???" > > Ugh, yeah. This is the computer in the kitchen. She is always logging me out and logging in as herself! It could be worse --- she could NOT log you out and log in as herself, then send an email to another girl that appears to be from you --- then that girl begins hollering: "Mom! A 45-year-old man just sent me an email suggesting that we meet at the mall!"
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-08-08 16:13 -0400 |
| Message-ID | <noap4l$tbk$2@dont-email.me> |
| In reply to | #49813 |
On 8/6/2016 8:37 AM, missycurl@gmail.com wrote: > On Saturday, August 6, 2016 at 3:48:21 AM UTC-4, Elizabeth D. Rather wrote: >> >> VARIABLE and VALUE are really optimizations for two different >> situations: VARIABLE provides you with an address most efficiently. >> VALUEs do not provide an address, merely access to a changeable >> constant. Sometimes one is preferable to the other, depending upon what >> you're going to do with it. >> >> Cheers, >> Elizabeth > > A "changeable constant" ... let's all just let that sink in a minute. > > I would call that a contradiction in terms. > > "1. not changing or varying" > > http://www.dictionary.com/browse/constant I was explaining some of the silly discussions we have in newsgroups and when I talked about this one, it was hard to explain that the discussion was about whether CONSTANTs should be variable or if we should use VARIABLE for that. I got a very incredulous look and she doesn't know anything about programming. Some people just want to make things hard I think. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2016-08-08 15:36 -0500 |
| Message-ID | <noaqgo$3ph$1@dont-email.me> |
| In reply to | #49879 |
On 8/8/2016 3:13 PM, rickman wrote: > On 8/6/2016 8:37 AM, missycurl@gmail.com wrote: >> On Saturday, August 6, 2016 at 3:48:21 AM UTC-4, Elizabeth D. Rather >> wrote: >>> >>> VARIABLE and VALUE are really optimizations for two different >>> situations: VARIABLE provides you with an address most efficiently. >>> VALUEs do not provide an address, merely access to a changeable >>> constant. Sometimes one is preferable to the other, depending upon what >>> you're going to do with it. >>> >>> Cheers, >>> Elizabeth >> >> A "changeable constant" ... let's all just let that sink in a minute. >> >> I would call that a contradiction in terms. >> >> "1. not changing or varying" >> >> http://www.dictionary.com/browse/constant > > I was explaining some of the silly discussions we have in newsgroups and > when I talked about this one, it was hard to explain that the discussion > was about whether CONSTANTs should be variable or if we should use > VARIABLE for that. I got a very incredulous look and she doesn't know > anything about programming. > > Some people just want to make things hard I think. > That can be a chapter in the book on Forth whose title I proposed as "ANS Forth a guide to alternate realities". Sometimes reality seems unreal, but you just have to laugh. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
| From | jim.brakefield@ieee.org |
|---|---|
| Date | 2016-08-06 06:28 -0700 |
| Message-ID | <7b3ba459-5f71-476e-8a4f-72e2201b36e6@googlegroups.com> |
| In reply to | #49809 |
On Saturday, August 6, 2016 at 2:48:21 AM UTC-5, Elizabeth D. Rather wrote: > On 8/5/16 6:02 PM, Brad Eckert wrote: > > 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. > > > > VARIABLE and VALUE are really optimizations for two different > situations: VARIABLE provides you with an address most efficiently. > VALUEs do not provide an address, merely access to a changeable > constant. Sometimes one is preferable to the other, depending upon what > you're going to do with it. > > 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." > ================================================== ]>access to a changeable constant an example: a calibration factor (e.g. offset or gain)
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-08-08 16:42 -0400 |
| Message-ID | <noaqse$39j$1@dont-email.me> |
| In reply to | #49814 |
On 8/6/2016 9:28 AM, jim.brakefield@ieee.org wrote: > > ]>access to a changeable constant > an example: a calibration factor (e.g. offset or gain) How is that a constant? It changes, so it does not fit the definition of constant. What part of "changeable constant" makes sense to you? -- Rick C
[toc] | [prev] | [next] | [standalone]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web