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 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-08-08 12:31 -1000 |
| Message-ID | <s96dne-eL_ujlTTKnZ2dnUU7-enNnZ2d@supernews.com> |
| In reply to | #49882 |
On 8/8/16 10:42 AM, rickman wrote: > 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? In Forthese for many years "constant" meant a data object that returned a value when it was referenced by name. A technical term, Forth jargon. Nowadays, Standard Forth constants cannot be changed, and the data object that returns a changeable value when referenced is called VALUE. Can we stop arguing about this now? 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-08-08 16:38 -0700 |
| Message-ID | <87h9au3k7e.fsf@jester.gateway.pace.com> |
| In reply to | #49882 |
rickman <gnuarm@gmail.com> writes: > What part of "changeable constant" makes sense to you? limit (sqrt(3)) = 2 3->4
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2016-08-08 22:49 -0700 |
| Message-ID | <81853035-40f1-4d31-a47b-9fe334f45747@googlegroups.com> |
| In reply to | #49887 |
On Tuesday, August 9, 2016 at 1:38:31 AM UTC+2, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: > > What part of "changeable constant" makes sense to you? > > limit (sqrt(3)) = 2 > 3->4 Which Forth is that? In iForth I have the floating-point constant PI, accurate to 64 bits. One could say that with : PI 355 114 / S>D ; I change the system PI as thorough as over-writing it would do (unless the system has the word FORGET). In that sense defining PI on a system that doesn't have PI is not unlike over-writing the universe's PI :-) Or, what you probably mean, PI is irrational, so any definition for it is an approximation that overwrites a constant. I guess "3->4" is Forth's : 3 4 ; . That is probably slightly more mind boggling to a Forth beginner. FORTH> : 3 4 ; ok FORTH> 3 . 4 ok FORTH> %11 . 3 ok FORTH> octal 3 . 4 ok FORTH> decimal 1 2 + . 3 ok Are there programming languages that return '4' in all these cases? The concept of 'changing a constant' may need to be seen in context. Even today, on certain processors general floating-point literals do not exist. Code like 'pi 1.23e f+' is equivalent to 'pi _unnamed_ F@ f+' always. ISTR that in the old days some compters lacked general literals, and therefore you would SEE that '12 14 +' compiled to '_unnamed1_ @ _unnamed2_ @ +' and such. To a Forth mind it would not be a big thing to store something else in the _unnamedxx_ if that led to more efficient (or less) code. It would be clearer and shorter than variable a 12 a ! variable b 14 b ! ... a @ b @ + ... Perfectly logical :-) -marcel
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-08-08 23:43 -0700 |
| Message-ID | <877fbq30ig.fsf@jester.gateway.pace.com> |
| In reply to | #49888 |
mhx@iae.nl writes: >> limit (sqrt(3)) = 2 >> 3->4 > Which Forth is that? It's supposed to be math notation. The limit of sqrt(3) is 2, as 3 approaches 4.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-08-08 22:16 -1000 |
| Message-ID | <VJSdnYcyE8H5DDTKnZ2dnUU7-UnNnZ2d@supernews.com> |
| In reply to | #49888 |
On 8/8/16 7:49 PM, mhx@iae.nl wrote: > On Tuesday, August 9, 2016 at 1:38:31 AM UTC+2, Paul Rubin wrote: >> rickman <gnuarm@gmail.com> writes: >>> What part of "changeable constant" makes sense to you? >> >> limit (sqrt(3)) = 2 >> 3->4 > > Which Forth is that? > > In iForth I have the floating-point constant PI, accurate to 64 bits. > One could say that with : PI 355 114 / S>D ; I change the system PI as > thorough as over-writing it would do (unless the system has the word > FORGET). In that sense defining PI on a system that doesn't have PI > is not unlike over-writing the universe's PI :-) > Or, what you probably mean, PI is irrational, so any definition for it > is an approximation that overwrites a constant. > > I guess "3->4" is Forth's : 3 4 ; . > > That is probably slightly more mind boggling to a Forth beginner. > FORTH> : 3 4 ; ok > FORTH> 3 . 4 ok > FORTH> %11 . 3 ok > FORTH> octal 3 . 4 ok > FORTH> decimal 1 2 + . 3 ok > > Are there programming languages that return '4' in all these cases? > > The concept of 'changing a constant' may need to be seen in context. > Even today, on certain processors general floating-point literals do > not exist. Code like 'pi 1.23e f+' is equivalent to 'pi _unnamed_ F@ f+' > always. ISTR that in the old days some compters lacked general literals, > and therefore you would SEE that '12 14 +' compiled to '_unnamed1_ @ > _unnamed2_ @ +' and such. To a Forth mind it would not be a big thing > to store something else in the _unnamedxx_ if that led to more efficient > (or less) code. It would be clearer and shorter than > variable a 12 a ! > variable b 14 b ! > ... a @ b @ + ... > > Perfectly logical :-) Long ago, we used to define 0, 1, and 2 as CONSTANTs because the dictionary search is first, so they'd have been found, and this was much faster than going all through the search and then doing a number conversion. 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 | JUERGEN <epldfpga@aol.com> |
|---|---|
| Date | 2016-08-09 03:54 -0700 |
| Message-ID | <08c62fb0-387b-4cb8-9087-d3054adbce11@googlegroups.com> |
| In reply to | #49897 |
On Tuesday, August 9, 2016 at 9:16:43 AM UTC+1, Elizabeth D. Rather wrote:
> On 8/8/16 7:49 PM, mhx@iae.nl wrote:
> > On Tuesday, August 9, 2016 at 1:38:31 AM UTC+2, Paul Rubin wrote:
> >> rickman <gnuarm@gmail.com> writes:
> >>> What part of "changeable constant" makes sense to you?
> >>
> >> limit (sqrt(3)) = 2
> >> 3->4
> >
> > Which Forth is that?
> >
> > In iForth I have the floating-point constant PI, accurate to 64 bits.
> > One could say that with : PI 355 114 / S>D ; I change the system PI as
> > thorough as over-writing it would do (unless the system has the word
> > FORGET). In that sense defining PI on a system that doesn't have PI
> > is not unlike over-writing the universe's PI :-)
> > Or, what you probably mean, PI is irrational, so any definition for it
> > is an approximation that overwrites a constant.
> >
> > I guess "3->4" is Forth's : 3 4 ; .
> >
> > That is probably slightly more mind boggling to a Forth beginner.
> > FORTH> : 3 4 ; ok
> > FORTH> 3 . 4 ok
> > FORTH> %11 . 3 ok
> > FORTH> octal 3 . 4 ok
> > FORTH> decimal 1 2 + . 3 ok
> >
> > Are there programming languages that return '4' in all these cases?
> >
> > The concept of 'changing a constant' may need to be seen in context.
> > Even today, on certain processors general floating-point literals do
> > not exist. Code like 'pi 1.23e f+' is equivalent to 'pi _unnamed_ F@ f+'
> > always. ISTR that in the old days some compters lacked general literals,
> > and therefore you would SEE that '12 14 +' compiled to '_unnamed1_ @
> > _unnamed2_ @ +' and such. To a Forth mind it would not be a big thing
> > to store something else in the _unnamedxx_ if that led to more efficient
> > (or less) code. It would be clearer and shorter than
> > variable a 12 a !
> > variable b 14 b !
> > ... a @ b @ + ...
> >
> > Perfectly logical :-)
>
> Long ago, we used to define 0, 1, and 2 as CONSTANTs because the
> dictionary search is first, so they'd have been found, and this was much
> faster than going all through the search and then doing a number conversion.
>
> 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."
> ==================================================
Just to quote from Stephen Pelc's book, Chapter 5 Components of Forth
Constants and Variables
"Many times in a program we need to use a value to represent something, a type of flower, or a bus route number. On other occasions the value corresponds to an actual value rather than an association, the price of roses today, the ASCII code for a special key. Some of this data never changes; it is constant. Other data changes from day to day or minute to minute. The two types of data are created by CONSTANT, VARIABLE and VALUE. Naming data makes programs easier to write and read, as people remember names more easily than numbers. "
and a bit further on
"VALUEs
The word VALUE creates a variable that returns its contents (value) when referenced, and is widely used for variables that are mostly read and rarely changed. A VALUE is defined with an initial value.
55 VALUE FOO
In embedded systems, you can rely on a VALUE being initialised at power up, whereas the ANS specification does not require VARIABLEs to be initialised. You get the contents of a VALUE by referring to it, but you set it by prefixing it with the word TO.
: test \ n --
cr .” The value of FOO was “ foo .
to foo
.” and is now “ foo . ;
"
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2016-06-14 03:42 -0700 |
| Message-ID | <a0f2a981-694d-453e-bab9-f7edb913ae4c@googlegroups.com> |
| In reply to | #48109 |
On Tuesday, June 14, 2016 at 12:23:50 AM UTC-5, 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. Per the title of your message, "Is it still Forth?", I interpreted your question as whether or not your example conforms to the ANS standard. I think the answer to this is no, because applying >BODY to a constant is not guaranteed to be unambiguous. > 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. Yes, this is a different question, and it is still a problem. Inlining a constant seems reasonable but also has un-Forth-like side-effects. Forth is not C, and the philosophy of optimization at the expense of versatility is troubling. Krishna
[toc] | [prev] | [next] | [standalone]
| From | Marek Brunda <marekb@phoenics.org> |
|---|---|
| Date | 2016-06-14 04:58 -0700 |
| Message-ID | <8180efa4-db6c-4e19-9d0d-c21e3aa35060@googlegroups.com> |
| In reply to | #48127 |
> Yes, this is a different question, and it is still a problem. Inlining a constant seems reasonable but also has un-Forth-like side-effects. Forth is not C, and the philosophy of optimization at the expense of versatility is troubling. > > > Krishna For me forth was always about flexibility. Inflexible standard forth with red tapes and syntax (aka recognizers) has no advantage above other languages. Ancient forths like de facto standard fig-forth was really more compatible than modern STANDARD forths today. "Standard forth" is a contradiction. There is no wai to standardize all problems on the planet without flexibility loss.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2016-06-14 05:04 -0700 |
| Message-ID | <be9d6ac0-1f9b-4b59-94eb-d0ea89eec68c@googlegroups.com> |
| In reply to | #48091 |
On Monday, 13 June 2016 23:54:36 UTC+1, krishna...@ccreweb.org wrote: > 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 Indeed, but this is Forth, and nobody agrees on anything. Folk don't even agree on what they disagree on. Hence myriad different behaviours are perfectly fine, and perfectly standard, whilst we'll all disagree that they are/aren't. Forth.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-06-13 19:22 -0400 |
| Message-ID | <njnf86$5on$1@dont-email.me> |
| In reply to | #48090 |
On 6/13/2016 6:45 PM, Paul Rubin wrote: > 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. Of course the OP's code is not portable. Why would you have an expectation that a constant will be stored in RAM as opposed to non-volatile, non-writable memory? If you want to modify the value, it shouldn't be declared with constant, it should be created with value and modified with to. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2016-06-14 05:22 -0700 |
| Message-ID | <f3d57db2-9195-4565-aac8-a0fd79d1cc7b@googlegroups.com> |
| In reply to | #48093 |
I expect a constant to be in RAM because Forth supports an interactive environment, so I should be able to obtain the value of a constant onto the stack from the interpreter. Then, it seems to me that >BODY should always work on a constant. This is consistent with Anton's tests on different systems. Krishna
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-06-14 12:41 +0000 |
| Message-ID | <2016Jun14.144145@mips.complang.tuwien.ac.at> |
| In reply to | #48139 |
krishna.myneni@ccreweb.org writes:
>I expect a constant to be in RAM because Forth supports an interactive envi=
>ronment, so I should be able to obtain the value of a constant onto the sta=
>ck from the interpreter.
There are systems such as Mecrisp that compile to flash, where you
cannot overwrite individual cells. They don't have enough RAM to keep
all the code in RAM.
Concerning the expectations that changing a constant (where it works)
affects earlier compiled uses of the constant, this is just one of the
ways to be flexible. Consider the following:
5 variable x
x . \ A
x
7 ' x >body !
. \ B
Should the output B be 7? Should the output A change to 7 when the
constant is changed?
The likely answer of a Forth user is "no", because no Forth systems
behave that way. But if you argue with flexibility, this would be
more flexible, no? And indeed I have seen a presentation of IIRC
DrScheme (now DrRacket) where IIRC a time was output, and the output
changed (similar to changing A in the example above) as time passed.
Should we go there? Maybe. Should this be the default behaviour of
everything? I don't think so.
So we had a time (and implementation approach) where changing
constants changed the values used in earlier-compiled code, and with
currently prevailing implementations, the default is that changing
constants does not affect earlier compiled code, but you can get the
old behaviour by redefining CONSTANT. And it seems that production
code out there is not negatively impacted by the currently prevailing
behaviour.
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2016-06-14 06:30 -0700 |
| Message-ID | <d39fcf63-0e59-4c55-9ede-837bfcc28319@googlegroups.com> |
| In reply to | #48142 |
On Tuesday, June 14, 2016 at 8:04:50 AM UTC-5, Anton Ertl wrote: > krishna.myneni@ccreweb.org writes: > >I expect a constant to be in RAM because Forth supports an interactive envi= > >ronment, so I should be able to obtain the value of a constant onto the sta= > >ck from the interpreter. > > There are systems such as Mecrisp that compile to flash, where you > cannot overwrite individual cells. They don't have enough RAM to keep > all the code in RAM. > I don't like the idea of restricting what used to be conventionally allowed Forth usage just for the sake of embedded systems. It seems to me that embedded systems should redefine CONSTANT rather than imposing arbitrary restrictions on general purpose Forth systems. > Concerning the expectations that changing a constant (where it works) > affects earlier compiled uses of the constant, this is just one of the > ways to be flexible. Consider the following: > > 5 variable x > x . \ A > x > 7 ' x >body ! > . \ B > > Should the output B be 7? Should the output A change to 7 when the > constant is changed? > > The likely answer of a Forth user is "no", because no Forth systems > behave that way. But if you argue with flexibility, this would be > more flexible, no? I think the above example is not useful because Forth systems never behaved that way, while in the OP's example, Forth systems did exist which had the behavior expected by the OP. > And indeed I have seen a presentation of IIRC > DrScheme (now DrRacket) where IIRC a time was output, and the output > changed (similar to changing A in the example above) as time passed. > > Should we go there? Maybe. Should this be the default behaviour of > everything? I don't think so. > > So we had a time (and implementation approach) where changing > constants changed the values used in earlier-compiled code, and with > currently prevailing implementations, the default is that changing > constants does not affect earlier compiled code, but you can get the > old behaviour by redefining CONSTANT. And it seems that production > code out there is not negatively impacted by the currently prevailing > behaviour. > I'm not necessarily arguing that we should go back to the previous expectation, i.e. that inlining constants is not the default behavior. However, the language of the standard may need to be more specific about the permissiveness of compilers to inline constants. In general, as Mark Wills pointed out, it is not a good idea in Forth for the compiler to assume that the compiler can change the meaning of code as written by the programmer, e.g. n1 CONSTANT foo \ explicitly compile the current value of foo : bar1 [ foo ] literal ; : bar2 foo ; n2 ' foo >body ! Now, executing bar1 at any time after its definition, we expect without ambiguity to obtain n1. However, from a programmer's perspective, bar2 should compile an execution token to foo, in which case it would return n2 after the above code. The notion of a compiler doing something other than what is expected by the programmer is dangerous, as a general rule. Krishna
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-06-14 14:21 +0000 |
| Message-ID | <2016Jun14.162138@mips.complang.tuwien.ac.at> |
| In reply to | #48143 |
krishna.myneni@ccreweb.org writes:
>On Tuesday, June 14, 2016 at 8:04:50 AM UTC-5, Anton Ertl wrote:
>> So we had a time (and implementation approach) where changing
>> constants changed the values used in earlier-compiled code, and with
>> currently prevailing implementations, the default is that changing
>> constants does not affect earlier compiled code, but you can get the
>> old behaviour by redefining CONSTANT. And it seems that production
>> code out there is not negatively impacted by the currently prevailing
>> behaviour.
>>=20
>
>I'm not necessarily arguing that we should go back to the previous expectat=
>ion, i.e. that inlining constants is not the default behavior. However, the=
> language of the standard may need to be more specific about the permissive=
>ness of compilers to inline constants.
I think that the standard is clear enough about that (in particular,
that there is no standard way to change constants), but if you think
differently, feel free to propose a wording change.
>In general, as Mark Wills pointed ou=
>t, it is not a good idea in Forth for the compiler to assume that the compi=
>ler can change the meaning of code as written by the programmer, e.g.
>
>n1 CONSTANT foo
>
>\ explicitly compile the current value of foo
>
>: bar1 [ foo ] literal ; =20
>
>: bar2 foo ;
>
>n2 ' foo >body !
>
>Now, executing bar1 at any time after its definition, we expect without amb=
>iguity to obtain n1. However, from a programmer's perspective, bar2 should =
>compile an execution token to foo, in which case it would return n2 after t=
>he above code.
>
>The notion of a compiler doing something other than what is expected by the=
> programmer is dangerous, as a general rule.
True, but in the present case, judging by the lack of complaints, it
seems that programmers don't make use of such an expectation in
production code. They may try it during debugging, and will quickly
find that current systems do not meet their expectations, but that's
not particularly dangerous.
If we had a significant usage of changing of constants, then the way
to go would have been to standardize that existing practice (e.g., by
allowing >BODY to be used on CONSTANTs, and by having wording
corresponding to the wording of VALUE in CONSTANT), and for those
cases where we want an optimizable constant, have a new defining word
such as CONSTANT-CONSTANT (in contrast to the variable CONSTANTs that
would then be standard).
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-06-14 13:21 -0400 |
| Message-ID | <njpee2$d8r$2@dont-email.me> |
| In reply to | #48148 |
On 6/14/2016 10:21 AM, Anton Ertl wrote: > krishna.myneni@ccreweb.org writes: >> On Tuesday, June 14, 2016 at 8:04:50 AM UTC-5, Anton Ertl wrote: >>> So we had a time (and implementation approach) where changing >>> constants changed the values used in earlier-compiled code, and with >>> currently prevailing implementations, the default is that changing >>> constants does not affect earlier compiled code, but you can get the >>> old behaviour by redefining CONSTANT. And it seems that production >>> code out there is not negatively impacted by the currently prevailing >>> behaviour. >>> =20 >> >> I'm not necessarily arguing that we should go back to the previous expectat= >> ion, i.e. that inlining constants is not the default behavior. However, the= >> language of the standard may need to be more specific about the permissive= >> ness of compilers to inline constants. > > I think that the standard is clear enough about that (in particular, > that there is no standard way to change constants), but if you think > differently, feel free to propose a wording change. Is this group insane? If you want to be able to change a constant as a matter of course, doesn't that make it a VARIABLE? >> In general, as Mark Wills pointed ou= >> t, it is not a good idea in Forth for the compiler to assume that the compi= >> ler can change the meaning of code as written by the programmer, e.g. >> >> n1 CONSTANT foo >> >> \ explicitly compile the current value of foo >> >> : bar1 [ foo ] literal ; =20 >> >> : bar2 foo ; >> >> n2 ' foo >body ! >> >> Now, executing bar1 at any time after its definition, we expect without amb= >> iguity to obtain n1. However, from a programmer's perspective, bar2 should = >> compile an execution token to foo, in which case it would return n2 after t= >> he above code. >> >> The notion of a compiler doing something other than what is expected by the= >> programmer is dangerous, as a general rule. > > True, but in the present case, judging by the lack of complaints, it > seems that programmers don't make use of such an expectation in > production code. They may try it during debugging, and will quickly > find that current systems do not meet their expectations, but that's > not particularly dangerous. > > If we had a significant usage of changing of constants, then the way > to go would have been to standardize that existing practice (e.g., by > allowing >BODY to be used on CONSTANTs, and by having wording > corresponding to the wording of VALUE in CONSTANT), and for those > cases where we want an optimizable constant, have a new defining word > such as CONSTANT-CONSTANT (in contrast to the variable CONSTANTs that > would then be standard). How is a constant being... *constant* become "unexpected"? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> |
|---|---|
| Date | 2016-06-14 17:45 -0400 |
| Message-ID | <20160614174513.41bfbaef@_> |
| In reply to | #48154 |
On Tue, 14 Jun 2016 13:21:08 -0400 rickman <gnuarm@gmail.com> wrote: <OT> > Is this group insane? You only have two choices for answers. "No, it isn't," and, "Yes, it is." Let's explore both of them for a minute. A) No, it isn't. That means you're the only guy in the room who is insane. And, you're surrounded by a bunch of people who can lock you up against your will. Now, you're locked in a room by yourself. B) Yes, it is. That means you're the only sane guy in the room. That's usually not a good situation to be in, unless you can find a lockable door and empty room to hide from the insane. Now, you're in locked room by yourself. Either way, the outcome is the same. You end up in a locked room all by yourself. Why do people ask such questions? Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-06-14 10:55 -0500 |
| Message-ID | <6cednUveVcl5tf3KnZ2dnUU7-bPNnZ2d@supernews.com> |
| In reply to | #48139 |
krishna.myneni@ccreweb.org wrote:
> I expect a constant to be in RAM because Forth supports an
> interactive environment, so I should be able to obtain the value of
> a constant onto the stack from the interpreter. Then, it seems to me
> that >BODY should always work on a constant.
It's never really worked even on "traditional" systems, where you'd
have code definitions and something like
' LIT 13 + CONSTANT PUT
... PUT JSR, ...
Change PUT by ticking the constant at your peril. And no, this isn't
a particularly odd example.
But I really don't undertsnad people demand that horrible practices
like trying to change the value of a CONSTANT should work portably.
It's only making life hard for the maintenance programmer.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2016-06-13 16:38 -0700 |
| Message-ID | <10c7ee49-ba91-41f9-93ce-e860c6ab3cf8@googlegroups.com> |
| In reply to | #48090 |
What does native code compilation have to do with this issue? A native code compiler can compile machine instructions to do the same thing as expected by the OP. This is a question of an unexpected optimization. The execution of compiled code should not differ from the execution of interpreted code, except maybe in rare cases and only then when it is clearly documented in the standard. Krishna
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-06-13 16:41 -0700 |
| Message-ID | <87ziqoodvp.fsf@nightsong.com> |
| In reply to | #48095 |
krishna.myneni@ccreweb.org writes: > What does native code compilation have to do with this issue? Clobbering the >body of a word shouldn't be expected to have well-defined results. > The execution of compiled code should not differ from the execution of > interpreted code I don't see how that applies here. Anyway, what happened seems consistent with Forth's early-binding philosophy.
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2016-06-14 03:54 -0700 |
| Message-ID | <8a368ba5-a227-40f6-afa4-5434d52694e9@googlegroups.com> |
| In reply to | #48096 |
On Monday, June 13, 2016 at 6:41:47 PM UTC-5, Paul Rubin wrote: > krishna.myneni@ccreweb.org writes: > > What does native code compilation have to do with this issue? > > Clobbering the >body of a word shouldn't be expected to have > well-defined results. > ... Why not? >BODY just returns an address in memory. What I choose to do with that address is my business, not the compiler's. Krishna
[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