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 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-06-18 12:54 +0000 |
| Message-ID | <2016Jun18.145411@mips.complang.tuwien.ac.at> |
| In reply to | #48175 |
krishna.myneni@ccreweb.org writes:
>Apparently you haven't bothered to read the earlier messages, particularly =
>the one in which Anton points out that the major Forth implementations he c=
>hecked permit >BODY to work with a constant, and, therefore, changing the v=
>alue at the body address is permissible.
For some interpretation of "permissible". Just because it works does
not mean that any particular behaviour is guaranteed for it. In the
present case, for these three systems, the effect of changing a
constant in this way is to change all future, but no past
interpretations *and compilations* of the constant.
> The only reason that prevents this=
> "feature" from working is the inlining of the constant value, which is act=
>ually what is contrary to the expected use of the language, since Forth pro=
>vides a deliberate method for inlining the value of a constant if the progr=
>ammer desires to do so.
Standard Forth and these systems provide a deliberate method (VALUE)
for defining a word that, when executed, yields its run-time value;
they also provide a deliberate method (CREATE...DOES>) for defining
words with the guarantee that >BODY can be used to change the value
(>BODY does not work that way for VALUEs on VFX 4.71).
So from these alternative ways, one cannot derive a specific expected
use. If anything, one can argue that it's much easier to redefine
CONSTANT than to replace all uses of constants inside colon
definitions with [ C ] LITERAL throughout the program.
And what would be the result of following your suggestion to replace
uses of C inside colon definitions with "[ C ] literal" in order to
"inline" C? You would then have code where it's much harder to change
the constant if you really want to. Currently you just need to change
the definition of C (or redefine CONSTANT itself, if you want to get
them all) and reload the program, and you will get the behaviour you
expect (except if the programmer did something like "[ C cells ]
literal"); if the programmers followed your suggestion, you would have
a harder time if you want to change C and let it take effect
throughout the program.
- 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-06-18 13:28 +0000 |
| Message-ID | <2016Jun18.152825@mips.complang.tuwien.ac.at> |
| In reply to | #48161 |
krishna.myneni@ccreweb.org writes:
>The original Starting Forth book by Leo Brodie gives an example similar to =
>the one posted by the OP. While the book says it is not recommended to do t=
>his, it also serves as an illustration of the ability provided by a program=
>mer to get at the internals of the system. Having used a system from those =
>days, it feels like the current Forth implementations, including mine, sacr=
>ificed some of that ability for the sake of efficiency, and also maybe for =
>use in more constrained domains.
While in general that is a valid concern (see below), I don't think it
is exemplified at all by this case. We can actually get at the
internals of constants, and on Gforth, SwiftForth, and VFX (not on
iForth) even in the way you expect in this case, and if it is in
read/write memory, change it. That changing it works differently from
the way you expect does not mean you cannot access the internals.
Forth has other ways to make the behaviour the way you expect (and
allow using >BODY on constante even on iForth), as mentioned several
times in this thread.
For the general issue, yes, some of the power of Forth derives from
being able to get at the internals, and unfortunately, that has not
been standardized; on the contrary, the move away from specifying
implementation details in Forth-94 has destandardized much of what we
had in that respect.
One case where Forth-94 actually got a standardized way of what we
used to do with implementation knowledge is "COMPILE,". In Forth-83,
where indirect threaded code was specified, we could use "," for
compiling a word, but by destandardizing ITC, we lost that, and
fortunately Mitch Bradley invented "COMPILE," to fill the resulting
hole.
Many other things for getting at the internals were not standardized,
and when one suggests standardizing something in this direction, a
typical vendor reaction is that the proposed words for this feature
are not needed because one can already do it with standard words in
the vendor's system (but in a non-standard way); as an example, look at
the discussion of DEFER@ and DEFER! in the X:deferred proposal.
Anyway, despite such resistances, we got TRAVERSE-WORDLIST NAME>STRING
NAME>INTERPRET NAME>COMPILE into Forth-2012. It's a start. If you
want more access to internals in a standard way, propose more words
along these lines; or alternatively, propose tighter behaviour for the
existing words. Both paths will be resisted, so you need good
arguments.
One argument is that Reflection is now a standard feature of many
programming languages. Not standardizing it leaves Forth at a
disadvantage compared to these languages in an area that used to be a
strength of Forth.
- 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-18 07:17 -0700 |
| Message-ID | <f4a18e93-4496-4729-88a3-427a7f3edb09@googlegroups.com> |
| In reply to | #48319 |
On Saturday, June 18, 2016 at 9:05:46 AM UTC-5, Anton Ertl wrote: > krishna.myneni@ccreweb.org writes: > >The original Starting Forth book by Leo Brodie gives an example similar to = > >the one posted by the OP. While the book says it is not recommended to do t= > >his, it also serves as an illustration of the ability provided by a program= > >mer to get at the internals of the system. Having used a system from those = > >days, it feels like the current Forth implementations, including mine, sacr= > >ificed some of that ability for the sake of efficiency, and also maybe for = > >use in more constrained domains. > > While in general that is a valid concern (see below), I don't think it > is exemplified at all by this case. We can actually get at the > internals of constants, and on Gforth, SwiftForth, and VFX (not on > iForth) even in the way you expect in this case, and if it is in > read/write memory, change it. That changing it works differently from > the way you expect does not mean you cannot access the internals. > Forth has other ways to make the behaviour the way you expect (and > allow using >BODY on constante even on iForth), as mentioned several > times in this thread. Yes, the behavior of CONSTANTs is not a good example of the concern of being shut off from access to the internals of the system -- I have said the same thing in other messages in this thread. Krishna
[toc] | [prev] | [next] | [standalone]
| From | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-06-18 18:31 -0700 |
| Message-ID | <96595453-c29c-4b2d-aaab-0bbfc446cb3e@googlegroups.com> |
| In reply to | #48319 |
On Sunday, June 19, 2016 at 2:05:46 AM UTC+12, Anton Ertl wrote: > One argument is that Reflection is now a standard feature of many > programming languages. Not standardizing it leaves Forth at a > disadvantage compared to these languages in an area that used to be a > strength of Forth. Just make sure you make it more like the way Python does it, rather than the way Java does it.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-06-25 14:55 +0000 |
| Message-ID | <2016Jun25.165544@mips.complang.tuwien.ac.at> |
| In reply to | #48343 |
lawrencedo99@gmail.com writes:
>On Sunday, June 19, 2016 at 2:05:46 AM UTC+12, Anton Ertl wrote:
>
>> One argument is that Reflection is now a standard feature of many
>> programming languages. Not standardizing it leaves Forth at a
>> disadvantage compared to these languages in an area that used to be a
>> strength of Forth.
>
>Just make sure you make it more like the way Python does it, rather than the way Java does it.
Could you elaborate on that?
- 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 | lawrencedo99@gmail.com |
|---|---|
| Date | 2016-06-25 19:58 -0700 |
| Message-ID | <b1713105-9ba4-40bb-ab79-d4bf8ac1d9f0@googlegroups.com> |
| In reply to | #48507 |
On Sunday, June 26, 2016 at 2:56:02 AM UTC+12, Anton Ertl wrote: > Lawrence D’Oliveiro writes: >> On Sunday, June 19, 2016 at 2:05:46 AM UTC+12, Anton Ertl wrote: >> >>> One argument is that Reflection is now a standard feature of many >>> programming languages. Not standardizing it leaves Forth at a >>> disadvantage compared to these languages in an area that used to be a >>> strength of Forth. >> >> Just make sure you make it more like the way Python does it, rather than >> the way Java does it. > > Could you elaborate on that? Python does its reflection/introspection with just a small handful of builtin functions: delattr, dir, getattr, hasattr, setattr and perhaps vars <https://docs.python.org/3/library/functions.html>. Java, on the other hand, requires about half a dozen classes and who knows how many methods <https://developer.android.com/reference/java/lang/reflect/package-summary.html>. I’ve done it. It’s not pretty <https://github.com/ldo/screeninfo_android/blob/master/src/InfoActivity.java>.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-06-18 21:14 -0700 |
| Message-ID | <b8135b38-7258-4ef3-aec7-071df6bb7b28@googlegroups.com> |
| In reply to | #48319 |
On Saturday, June 18, 2016 at 7:05:46 AM UTC-7, Anton Ertl wrote: > Many other things for getting at the internals were not standardized, > and when one suggests standardizing something in this direction, a > typical vendor reaction is that the proposed words for this feature > are not needed because one can already do it with standard words in > the vendor's system (but in a non-standard way); as an example, look at > the discussion of DEFER@ and DEFER! in the X:deferred proposal. > > Anyway, despite such resistances, we got TRAVERSE-WORDLIST NAME>STRING > NAME>INTERPRET NAME>COMPILE into Forth-2012. It's a start. If you > want more access to internals in a standard way, propose more words > along these lines; or alternatively, propose tighter behaviour for the > existing words. Both paths will be resisted, so you need good > arguments. > > One argument is that Reflection is now a standard feature of many > programming languages. Not standardizing it leaves Forth at a > disadvantage compared to these languages in an area that used to be a > strength of Forth. I have said many times that a cross-compiler needs the ability to take an xt and determine the following attributes of the word: 1.) immediate or non-immediate 2.) what word-list the it is in 3.) smudged or not smudged 4.) smudge-ready or not smudge-ready The cross-compiler also needs to be able to change these attributes. The reason why this stuff isn't in ANS-Forth and won't be in Forth-200x is because Stephen Pelc wants to prevent common Forth users from writing their own cross-compiler --- ANS-Forth and Forth-200x are cripple-ware --- the Standard is designed to prevent Forth programs from being written. To paraphrase Anton Ertl: "These features will be resisted, so you need to abandon ANS-Forth and Forth Inc., and start a new standard from scratch."
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-06-14 19:32 -0400 |
| Message-ID | <njq46v$23g$3@dont-email.me> |
| In reply to | #48158 |
On 6/14/2016 4:28 PM, krishna.myneni@ccreweb.org wrote: > Read the earlier messages in the thread carefully. The general problem is with Forth compilers doing things that are unasked for by the programmer, and which cause unexpected side effects for code which is valid on those systems. In the case of CONSTANT there may be no real cause for concern, other than making clear that inlining may be performed by a system. I haven't seen anything untoward being done by the compiler if you aren't expecting to be able to treat a constant like a variable. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-06-14 17:13 -0700 |
| Message-ID | <87inxbnwb0.fsf@nightsong.com> |
| In reply to | #48163 |
rickman <gnuarm@gmail.com> writes: > I haven't seen anything untoward being done by the compiler if you > aren't expecting to be able to treat a constant like a variable. There's more going on than that. Writing a different value into the symbol's >BODY presumes that CONSTANT is defined something like: : CONSTANT CREATE , DOES> @ ; so the value really does live at the >body and the @ gets run by the address interpreter. But in a native-code implementation there is no address interpreter, and CONSTANT would most likely generate machine code that pushes the given immediate value onto the stack. Overwriting the >BODY and then executing it would simply send the program into the weeds.
[toc] | [prev] | [next] | [standalone]
| From | Marek Brunda <marekb@phoenics.org> |
|---|---|
| Date | 2016-06-14 17:21 -0700 |
| Message-ID | <079f9fe2-ca83-4ea1-84b5-bec23e103c6b@googlegroups.com> |
| In reply to | #48167 |
Again, sometimes there is the need to set value of constant at runtime when the system initializes. After initialization the value of this constant is never changed. However, it can change at next reboot.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-06-14 18:36 -0700 |
| Message-ID | <87eg7znsh9.fsf@nightsong.com> |
| In reply to | #48169 |
Marek Brunda <marekb@phoenics.org> writes: > Again, sometimes there is the need to set value of constant at runtime > when the system initializes. After initialization the value of this > constant is never changed. However, it can change at next reboot. It still boggles my mind that anyone could expect such a thing to be portable. Is there any subroutine-threaded Forth where your example works?
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-06-15 16:06 +0200 |
| Message-ID | <wqCdncZ7C8hX_fzKnZ2dnUU78WednZ2d@supernews.com> |
| In reply to | #48169 |
On 6/15/16 2:21 AM, Marek Brunda wrote: > Again, sometimes there is the need to set value of constant at runtime when the system initializes. After initialization the value of this constant is never changed. However, it can change at next reboot. > That is a reasonable thing to want to do, but CONSTANT is not a portable way to do it. VALUE would give you the behavior you wish. 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 | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2016-06-15 06:36 -0700 |
| Message-ID | <d9e200a4-ae71-4dc1-8eee-d52c6de7a4e4@googlegroups.com> |
| In reply to | #48167 |
Paul Rubin wrote: > But in a native-code implementation there is no address interpreter, and CONSTANT would most likely generate machine code that pushes the given immediate value onto the stack. Overwriting the >BODY and then executing it would simply send the program into the weeds. I've had difficulty following why you claim that a native-code implementation wouldn't permit access to the body of a word, until I realized that you are making a false equivalence between native code compilation and optimizing compilation. The two terms mean different things. However, even in an optimizing, native code system, the following should work without issue: : array ( n -- ) create cells allot does> ; 100 array data ' data >body @ \ get first element 23 ' data >body ! Krishna
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-06-15 09:20 -0500 |
| Message-ID | <y_-dnWqpUP2E-fzKnZ2dnUU7-dudnZ2d@supernews.com> |
| In reply to | #48188 |
krishna.myneni@ccreweb.org wrote:
> Paul Rubin wrote:
>
> But in a native-code implementation there is no address interpreter,
> and CONSTANT would most likely generate machine code that pushes the
> given immediate value onto the stack. Overwriting the >BODY and
> then executing it would simply send the program into the weeds.
>
> I've had difficulty following why you claim that a native-code
> implementation wouldn't permit access to the body of a word, until I
> realized that you are making a false equivalence between native code
> compilation and optimizing compilation. The two terms mean different
They do, but in a native code forth there is an obvious implementation
of CONSTANT which doesn't optimize and neither does it have a body in
data space. It would do something like this:
364 CONSTANT nn produces
364 # R0 MOV R0 PUSH RET
There's no optimization going on there.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2016-06-15 10:55 -0700 |
| Message-ID | <4e5c1efb-b877-4e28-9d5b-8225a8c66370@googlegroups.com> |
| In reply to | #48191 |
Andrew Haley wrote:
> "... in a native code forth there is an obvious implementation
of CONSTANT which doesn't optimize and neither does it have a body in
data space. It would do something like this:
364 CONSTANT nn produces
364 # R0 MOV R0 PUSH RET
There's no optimization going on there."
Ok, that's fine, but there's nothing restricting a native code compiler from reserving an address for the constant value either, and loading the value from that address onto the stack. I'm cognizant of the fact that ANS Forth permits either type of implementation.
Krishna
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-06-15 11:07 -0700 |
| Message-ID | <8760tanx6a.fsf@nightsong.com> |
| In reply to | #48195 |
krishna.myneni@ccreweb.org writes: > 364 # R0 MOV R0 PUSH RET > Ok, that's fine... I'm cognizant of the fact that ANS Forth permits > either type of implementation. Exactly. It's not portable to expect any specific method.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-06-15 16:20 +0200 |
| Message-ID | <8s-dncOPquS7-fzKnZ2dnUU78TXNnZ2d@supernews.com> |
| In reply to | #48188 |
On 6/15/16 3:36 PM, krishna.myneni@ccreweb.org wrote: > Paul Rubin wrote: > >> But in a native-code implementation there is no > address interpreter, and CONSTANT would most likely generate machine > code that pushes the given immediate value onto the stack. Overwriting > the >BODY and then executing it would simply send the program into the weeds. > > I've had difficulty following why you claim that a native-code implementation wouldn't permit access to the body of a word, until I realized that you are making a false equivalence between native code compilation and optimizing compilation. The two terms mean different things. > > However, even in an optimizing, native code system, the following should work without issue: > > : array ( n -- ) create cells allot does> ; > > 100 array data > > ' data >body @ \ get first element > > 23 ' data >body ! > > Krishna Yes, that's fine, since you didn't use CONSTANT to define data. Basic point: use CONSTANT only to name a value that will *never* be changed. If you *ever* need to change it, use another defining word or construct one with the behavior you desire. 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 | mhx@iae.nl |
|---|---|
| Date | 2016-06-15 11:19 -0700 |
| Message-ID | <a36bcebf-22ad-4055-b59b-68cf21e5c59f@googlegroups.com> |
| In reply to | #48188 |
krishna.myneni@ccreweb.org writes Re: Is it sill FORTH ? > Paul Rubin wrote: >> But in a native-code implementation there is no > address interpreter, and CONSTANT would most likely generate machine > code that pushes the given immediate value onto the stack. Overwriting > the >BODY and then executing it would simply send the program into the weeds. > I've had difficulty following why you claim that a native-code implementation > wouldn't permit access to the body of a word, until I realized that you are > making a false equivalence between native code compilation and optimizing > compilation. The two terms mean different things. > However, even in an optimizing, native code system, the following > should work without issue: > : array ( n -- ) create cells allot does> ; > 100 array data > ' data >body @ \ get first element > 23 ' data >body ! And it does: FORTH> : array ( n -- ) create cells allot does> ; ok FORTH> ok FORTH> 100 array data ok FORTH> ok FORTH> ' data >body @ \ get first element ok [1]FORTH> ok [1]FORTH> 23 ' data >body ! ok [1]FORTH> . 0 ok FORTH> data 20 dump $013229C0 17 00 00 00 00 00 00 00--00 00 00 00 00 00 00 00--00 00 00 00 But note this: FORTH> forget test ok FORTH> : test ['] data >body @ 23 ['] data >body ! ( part #2) data @ 22 data ! ; ok FORTH> see test Flags: ANSI $01323100 : test $0132310A push $013229B0 d# $0132310F lea rbp, [rbp -8 +] qword $01323113 mov [rbp 0 +] qword, $01323120 d# $0132311B jmp >BODY+10 ( $012ABDEA ) offset NEAR $01323120 pop rbx $01323121 push [rbx] qword $01323123 push #23 b# $01323125 push $013229B0 d# $0132312A lea rbp, [rbp -8 +] qword $0132312E mov [rbp 0 +] qword, $0132313B d# $01323136 jmp >BODY+10 ( $012ABDEA ) offset NEAR $0132313B pop rbx $0132313C pop rdi $0132313D mov [rbx] qword, rdi ( part #2) $01323140 mov rbx, $013229C0 qword-offset $01323147 mov $013229C0 qword-offset, #22 d# $01323152 push rbx $01323153 ; FORTH> test ok [2]FORTH> .s Data: 23 23 --- System: --- Float: --- ok [2]FORTH> . . 23 23 ok FORTH> 2 data ! ok FORTH> test ok [2]FORTH> swap . . 2 23 ok FORTH> data @ . 22 ok Play it by the simple ANS rules and tricky ticks work, as well as getting optimized @ and ! when letting the compiler perform its magic. And of course there are new extensions: : array ( n -- ) create HERE >R cells DUP allot R> SWAP CONST-DATA does> ; 3 array foo 1 foo ! 2 foo cell+ ! 3 foo 2 cells + ! FORTH> 3 array foo 1 foo ! 2 foo cell+ ! 3 foo 2 cells + ! ok FORTH> ' foo >body ? 1 ok FORTH> ' foo >body cell+ ? 2 ok FORTH> ' foo >body 2 cells + ? 3 ok FORTH> ok FORTH> : tfoo foo @ foo cell+ @ + foo 2 cells + @ * ; ok FORTH> tfoo . 9 ok FORTH> ' tfoo idis $01325680 : tfoo $0132568A push 9 b# $0132568C ; FORTH> : tbar tfoo tfoo * . ; ok FORTH> see tbar Flags: ANSI $01325700 : tbar $0132570A push #81 b# $0132570C jmp .+10 ( $0123968A ) offset NEAR $01325711 ; -marcel
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-06-14 22:10 -0700 |
| Message-ID | <4b6fc18a-c4de-4926-970f-e66be520c838@googlegroups.com> |
| In reply to | #48157 |
On Tuesday, June 14, 2016 at 12:42:05 PM UTC-7, Paul Rubin wrote: > krishna.myneni@ccreweb.org writes: > > it is about remapping the register. ... Sure, you can do it with > > VALUE instead of CONSTANT. > > What's the problem then? Do it with VALUE (or VARIABLE). That's > what they are for. Neither VALUE nor VARIABLE are defined as using CREATE DOES> internally --- >BODY is defined as only working on CREATE DOES> words --- therefore, depending upon >BODY to work on VALUE or VARIABLE is not ANS-Forth. Am I the only one here who has read the ANS-Forth document? >BODY is really intended to be used on user-written CREATE DOES> words --- this is an ad-hoc solution to the problem of CREATE DOES> words being like OOP classes except that they only have one method --- with >BODY you get multiple methods, but written in a hokey way.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-06-15 01:33 -0400 |
| Message-ID | <njqpc5$kq8$1@dont-email.me> |
| In reply to | #48180 |
On 6/15/2016 1:10 AM, hughaguilar96@gmail.com wrote: > On Tuesday, June 14, 2016 at 12:42:05 PM UTC-7, Paul Rubin wrote: >> krishna.myneni@ccreweb.org writes: >>> it is about remapping the register. ... Sure, you can do it with >>> VALUE instead of CONSTANT. >> >> What's the problem then? Do it with VALUE (or VARIABLE). That's >> what they are for. > > Neither VALUE nor VARIABLE are defined as using CREATE DOES> internally --- >BODY is defined as only working on CREATE DOES> words --- therefore, depending upon >BODY to work on VALUE or VARIABLE is not ANS-Forth. > > Am I the only one here who has read the ANS-Forth document? You don't seem to be in the same discussion as the rest of us. No one has said anything about how VALUE or VARIABLE are implemented. The point is that you can use those words to create variables that will do what is needed instead of relying on unspecified behavior of words defined with CONSTANT. Why do you think anyone wishes to use >BODY to access a VALUE or VARIABLE word? -- Rick C
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web