Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #32949 > unrolled thread
| Started by | hughaguilar96@yahoo.com |
|---|---|
| First post | 2014-08-17 21:09 -0700 |
| Last post | 2014-08-19 13:55 +0100 |
| Articles | 20 on this page of 110 — 13 participants |
Back to article view | Back to comp.lang.forth
does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-17 21:09 -0700
Re: does VFX have the same bug as Gforth? Bee <forth@calcentral.com> - 2014-08-17 23:06 -0700
Re: does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-18 17:03 -0700
Re: does VFX have the same bug as Gforth? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-08-18 22:19 -0400
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-19 09:14 +0000
Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-08-19 15:23 +0200
Re: does VFX have the same bug as Gforth? "Alex McDonald" <blog@rivadpm.com> - 2014-08-19 14:54 +0100
Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-08-19 16:09 +0200
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-19 15:39 +0000
Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-08-19 22:34 +0200
Re: does VFX have the same bug as Gforth? "Alex McDonald" <blog@rivadpm.com> - 2014-08-19 23:29 +0100
Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-08-20 23:06 +0200
Re: does VFX have the same bug as Gforth? "Alex McDonald" <blog@rivadpm.com> - 2014-08-20 22:21 +0100
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-20 07:46 +0000
Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-08-21 00:26 +0200
Re: does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-20 22:42 -0700
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-21 10:23 +0000
Re: does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-21 23:29 -0700
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-22 12:54 +0000
Re: does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-22 17:54 -0700
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-23 10:46 +0000
Re: does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-23 11:15 -0700
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-24 13:32 +0000
Re: does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-24 10:40 -0700
Re: does VFX have the same bug as Gforth? Bee <forth@calcentral.com> - 2014-08-24 22:03 -0700
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-25 08:31 +0000
Re: does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-25 22:55 -0700
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-21 12:45 +0000
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-22 15:13 +0000
Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-08-22 18:47 +0200
Re: does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-22 18:28 -0700
Re: does VFX have the same bug as Gforth? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-08-23 04:44 -0400
Re: does VFX have the same bug as Gforth? Coos Haak <chforth@hccnet.nl> - 2014-08-23 16:15 +0200
Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-23 11:50 -0500
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-23 07:15 +0000
Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-08-23 22:12 +0200
Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-24 03:51 -0500
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-24 13:36 +0000
Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-25 04:16 -0500
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-25 09:44 +0000
Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-25 11:53 -0500
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 06:34 +0000
Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-26 03:55 -0500
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 12:37 +0000
Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-26 08:24 -0500
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 13:55 +0000
Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-26 10:42 -0500
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 16:05 +0000
Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-09-23 17:20 +0200
Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-23 11:29 -0500
Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-09-23 23:01 +0200
Re: does VFX have the same bug as Gforth? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-08-25 15:59 +0000
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 06:23 +0000
Re: does VFX have the same bug as Gforth? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-08-26 09:15 +0000
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 13:23 +0000
Re: does VFX have the same bug as Gforth? Mark Wills <markwills1970@gmail.com> - 2014-08-26 01:41 -0700
Re: does VFX have the same bug as Gforth? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-08-26 09:32 +0000
Re: does VFX have the same bug as Gforth? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-08-26 09:43 +0000
Re: does VFX have the same bug as Gforth? Mark Wills <markwills1970@gmail.com> - 2014-08-26 02:48 -0700
Re: does VFX have the same bug as Gforth? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-08-26 11:58 +0000
Re: does VFX have the same bug as Gforth? Mark Wills <markwills1970@gmail.com> - 2014-08-26 05:20 -0700
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 12:30 +0000
Re: does VFX have the same bug as Gforth? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-08-25 14:15 +0000
Re: does VFX have the same bug as Gforth? Mark Wills <markwills1970@gmail.com> - 2014-08-25 07:44 -0700
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-25 14:37 +0000
Re: does VFX have the same bug as Gforth? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-08-25 15:14 +0000
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-25 15:33 +0000
Re: does VFX have the same bug as Gforth? Mark Wills <markwills1970@gmail.com> - 2014-08-26 01:56 -0700
Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-26 04:16 -0500
Re: does VFX have the same bug as Gforth? Mark Wills <markwills1970@gmail.com> - 2014-08-26 02:24 -0700
Re: does VFX have the same bug as Gforth? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-08-26 09:36 +0000
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 13:40 +0000
Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-26 08:57 -0500
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 12:52 +0000
Re: does VFX have the same bug as Gforth? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-08-26 14:14 +0000
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 14:36 +0000
Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-09-23 17:40 +0200
Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-26 10:53 -0500
Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-09-23 17:36 +0200
Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-25 12:02 -0500
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 06:42 +0000
Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-26 04:08 -0500
Re: does VFX have the same bug as Gforth? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-08-26 10:37 +0000
Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-26 08:30 -0500
Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-28 08:47 -0500
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-29 13:03 +0000
Re: does VFX have the same bug as Gforth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-29 09:16 -0500
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 13:06 +0000
Re: does VFX have the same bug as Gforth? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-08-26 07:36 -0400
Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-09-23 17:28 +0200
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-24 09:48 +0000
Re: does VFX have the same bug as Gforth? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-08-24 15:55 -0400
Re: does VFX have the same bug as Gforth? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-08-24 15:55 -0400
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-25 08:26 +0000
Re: does VFX have the same bug as Gforth? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-08-26 07:36 -0400
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-26 12:12 +0000
Re: does VFX have the same bug as Gforth? Bernd Paysan <bernd.paysan@gmx.de> - 2014-09-23 17:45 +0200
Re: does VFX have the same bug as Gforth? Mark Wills <markwills1970@gmail.com> - 2014-08-21 03:25 -0700
Re: does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-21 23:14 -0700
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-19 14:16 +0000
Re: does VFX have the same bug as Gforth? Bee <forth@calcentral.com> - 2014-08-17 23:16 -0700
Re: does VFX have the same bug as Gforth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-08-19 09:40 +0000
Re: does VFX have the same bug as Gforth? Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-08-18 09:16 +0100
Re: does VFX have the same bug as Gforth? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-08-18 09:32 +0100
Re: does VFX have the same bug as Gforth? "Alex McDonald" <blog@rivadpm.com> - 2014-08-18 13:09 +0100
Re: does VFX have the same bug as Gforth? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-08-18 12:29 +0000
Re: does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-18 17:10 -0700
Re: does VFX have the same bug as Gforth? Bee <forth@calcentral.com> - 2014-08-18 17:48 -0700
Re: does VFX have the same bug as Gforth? hughaguilar96@yahoo.com - 2014-08-18 18:23 -0700
Re: does VFX have the same bug as Gforth? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-08-19 13:55 +0100
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-08-26 06:42 +0000 |
| Message-ID | <2014Aug26.084224@mips.complang.tuwien.ac.at> |
| In reply to | #33047 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Stephen Pelc <stephenXXX@mpeforth.com> wrote:
>> In practice, the only way of marking a word as having "non-default
>> compilation semantics" is with IMMEDIATE. There are very, very few
>> standard words that must be immediate. Now that various Forths (not
>> just VFX) have techniques to introduce "non-default compilation
>> semantics" without using IMMEDIATE, we need a standard way to
>> indicate to a compiler that a word has "non-default compilation
>> semantics".
>
>Or remove the techniques by which Forths introduce "non-default
>compilation semantics" without using IMMEDIATE.
There are no such features in the standard, so we cannot remove them
from there. But we can keep it that way.
Concerning systems, they still may want to implement S", TO, etc. In
the long run, we should remove these words from the standard. In the
meantime, some systems will have these features for implementing such
words, and others will implement them as STATE-smart immediate words
(which also have problems).
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-08-26 04:08 -0500 |
| Message-ID | <T_mdncMjfdMI02HOnZ2dnUU7-QudnZ2d@supernews.com> |
| In reply to | #33056 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Stephen Pelc <stephenXXX@mpeforth.com> wrote: >>> In practice, the only way of marking a word as having "non-default >>> compilation semantics" is with IMMEDIATE. There are very, very few >>> standard words that must be immediate. Now that various Forths (not >>> just VFX) have techniques to introduce "non-default compilation >>> semantics" without using IMMEDIATE, we need a standard way to >>> indicate to a compiler that a word has "non-default compilation >>> semantics". >> >>Or remove the techniques by which Forths introduce "non-default >>compilation semantics" without using IMMEDIATE. > > There are no such features in the standard, so we cannot remove them > from there. Indeed not; I'm not proposing a change in the standard. It's a QOI issue. > But we can keep it that way. > > Concerning systems, they still may want to implement S", TO, etc. > In the long run, we should remove these words from the standard. In > the meantime, some systems will have these features for implementing > such words, and others will implement them as STATE-smart immediate > words (which also have problems). True enough, but these problems are (IMO, YMMV) far less severe than the problems (with FIND, etc.) we've been discussing for the past few years. Long ago you said: > So FIND as specified/guaranteed by the standard is deficient and > should not be taken seriously. Maybe we should do something about > that. My suggestion for the "do something" is to make the systems fit the specifications of FIND and SEARCH-WORDLIST, which seem to assume that the only way to create a word with non-default semantics is with IMMEDIATE . Andrew.
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2014-08-26 10:37 +0000 |
| Message-ID | <53fc62fd.272167097@news.demon.co.uk> |
| In reply to | #33061 |
On Tue, 26 Aug 2014 04:08:37 -0500, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >My suggestion for the "do something" is to make the systems fit the >specifications of FIND and SEARCH-WORDLIST, which seem to assume that >the only way to create a word with non-default semantics is with >IMMEDIATE . Hey, ho. It's back to state-smart words ... Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-08-26 08:30 -0500 |
| Message-ID | <UvWdneulU5ecEWHOnZ2dnUU7-RudnZ2d@supernews.com> |
| In reply to | #33069 |
Stephen Pelc <stephenXXX@mpeforth.com> wrote: > On Tue, 26 Aug 2014 04:08:37 -0500, Andrew Haley > <andrew29@littlepinkcloud.invalid> wrote: > >>My suggestion for the "do something" is to make the systems fit the >>specifications of FIND and SEARCH-WORDLIST, which seem to assume that >>the only way to create a word with non-default semantics is with >>IMMEDIATE . > > Hey, ho. It's back to state-smart words ... It's the lesser of two evils. Having been around this for years, there doesn't seem to be a cleaner solution. But you know my take on this: "combined words", dual-XT words, etc., are just state-smart words in drag. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-08-28 08:47 -0500 |
| Message-ID | <F7KdnbjWsMeermLOnZ2dnUU7-bGdnZ2d@supernews.com> |
| In reply to | #33069 |
Stephen Pelc <stephenXXX@mpeforth.com> wrote: > On Tue, 26 Aug 2014 04:08:37 -0500, Andrew Haley > <andrew29@littlepinkcloud.invalid> wrote: > >>My suggestion for the "do something" is to make the systems fit the >>specifications of FIND and SEARCH-WORDLIST, which seem to assume that >>the only way to create a word with non-default semantics is with >>IMMEDIATE . > > Hey, ho. It's back to state-smart words ... Well, so what? There's nothing wrong with STATE-smartness that can't be fixed with a little discipline. That's no different from anything else in Forth: anything can be abused. As Anton put it fifteen years ago, all you have to do is provide "the combined word as state-smart word, but also provide the two constituents, e.g., s"-int and s"-comp. Advise the users to use the state-smart word only directly in the text interpreter. They should use only the constituents with ', postpone, etc." Making this change would get rid of some considerable complexity in the standard and in implementations, and make Forth easier to understand. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-08-29 13:03 +0000 |
| Message-ID | <2014Aug29.150350@mips.complang.tuwien.ac.at> |
| In reply to | #33105 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Well, so what? There's nothing wrong with STATE-smartness that can't
>be fixed with a little discipline. That's no different from anything
>else in Forth: anything can be abused.
>
>As Anton put it fifteen years ago, all you have to do is provide "the
>combined word as state-smart word, but also provide the two
>constituents, e.g., s"-int and s"-comp. Advise the users to use the
>state-smart word only directly in the text interpreter. They should
>use only the constituents with ', postpone, etc."
>
>Making this change would get rid of some considerable complexity in
>the standard and in implementations, and make Forth easier to
>understand.
So, will we see a proposal from you that proposes S"-INT, S"-COMP, and
removes '/[']/POSTPONE/[COMPILE] S", and likewise for TO, IS, and
ACTION-OF? If we keep STATE, one might also add a way to let
programmers specify that a word cannot be used with
'/[']/POSTPONE/[COMPILE].
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-08-29 09:16 -0500 |
| Message-ID | <0cGdnQZqWYTdFp3JnZ2dnUU7-WWdnZ2d@supernews.com> |
| In reply to | #33117 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Well, so what? There's nothing wrong with STATE-smartness that can't >>be fixed with a little discipline. That's no different from anything >>else in Forth: anything can be abused. >> >>As Anton put it fifteen years ago, all you have to do is provide "the >>combined word as state-smart word, but also provide the two >>constituents, e.g., s"-int and s"-comp. Advise the users to use the >>state-smart word only directly in the text interpreter. They should >>use only the constituents with ', postpone, etc." >> >>Making this change would get rid of some considerable complexity in >>the standard and in implementations, and make Forth easier to >>understand. > > So, will we see a proposal from you that proposes S"-INT, S"-COMP, > and removes '/[']/POSTPONE/[COMPILE] S", and likewise for TO, IS, > and ACTION-OF? If we keep STATE, one might also add a way to let > programmers specify that a word cannot be used with > '/[']/POSTPONE/[COMPILE]. Maybe. It would be a substantial improvement. However, I suspect that vendors and users have had enough of all this churn and would not welecome any further proposals for change. But this is not very different from what you wrote fifteen or so years ago: > My advice to systems implementors is: Don't write state-smart words > (except maybe s" and to, and then provide state-dumb constituents). Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-08-26 13:06 +0000 |
| Message-ID | <2014Aug26.150646@mips.complang.tuwien.ac.at> |
| In reply to | #33061 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>True enough, but these problems are (IMO, YMMV) far less severe than
>the problems (with FIND, etc.) we've been discussing for the past few
>years.
My mileage is very different. I have had breakage in a demonstration
with STATE-smart words, while the only problem with FIND as
implemented in Gforth 0.7.0 is aesthetic.
>Long ago you said:
>
>> So FIND as specified/guaranteed by the standard is deficient and
>> should not be taken seriously. Maybe we should do something about
>> that.
>
>My suggestion for the "do something" is to make the systems fit the
>specifications of FIND and SEARCH-WORDLIST, which seem to assume that
>the only way to create a word with non-default semantics is with
>IMMEDIATE .
Sure, systems would not be standard if they did not fit the
specification of FIND and (if implemented) SEARCH-WORDLIST. However,
the specification of FIND is weak ("For a given string, the values
returned by FIND while compiling may differ from those returned while
not compiling."), so a system can satisfy it while having other ways
than IMMEDIATE to create words with non-default compilation semantics.
In particular, Gforth 0.7.0 has such a way (INTERPRET/COMPILE:) and
still fits the specification of FIND and SEARCH-WORDLIST; *and* its
FIND can be used in a user-defined interpreter.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-08-26 07:36 -0400 |
| Message-ID | <op.xk66ilwr6zenlw@localhost> |
| In reply to | #33040 |
On Mon, 25 Aug 2014 10:15:41 -0400, Stephen Pelc <stephenXXX@mpeforth.com> wrote: > On Sun, 24 Aug 2014 03:51:25 -0500, Andrew Haley > <andrew29@littlepinkcloud.invalid> wrote: >> Bernd Paysan <bernd.paysan@gmx.de> wrote: >> If I want to use [COMPILE] I need to know if a word is immediate. So, >> it's impossible to use [COMPILE] on system-supplied words in a >> portable program. I must use POSTPONE for that. I may use [COMPILE] >> on my own words, though. > > As the VFX experience shows, it's actually worse than that. There's a > disconnect between "traditional" Forth and ANS Forth. Traditional > Forths assume a conceptually very simple interpreter/compiler loop. > I like that model and believe that it should be preserved. It's > part of the essence of Forth. > > [...] > The ANS definition of [COMPILE] does not mention immediacy. Instead > it talks about "default compilation semantics". The implied "default > compilation semantics" are given by section 3.4.3.3 in Forth2012. > > [...] > In practice, the only way of marking a word as having "non-default > compilation semantics" is with IMMEDIATE. There are very, very few > standard words that must be immediate. Now that various Forths > (not just VFX) have techniques to introduce "non-default compilation > semantics" without using IMMEDIATE, we need a standard way to indicate > to a compiler that a word has "non-default compilation semantics". > > Perhaps we should introduce N-DCS. I can see another header flag > coming on ... > What about two immediate flags? One would be for "Compilation:" and the other for "Execution:". IMMEDIATE would default to setting the flag for "Compilation:", but both would be used to determine immediacy of a word, i.e., logically OR'd. DOES> and ( appear to be the only CORE words that would get both. Other words with interpretation semantics that seem to have unlisted compilation semantics, may need both too, e.g., : CREATE CONSTANT VARIABLE. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-09-23 17:28 +0200 |
| Message-ID | <lvs3j7$u8j$2@online.de> |
| In reply to | #33040 |
Stephen Pelc wrote: > Would we actually lose anything by making [COMPILE] obsolete in > a future standard? No; this however means that we must put it on the obsolecent list *now* (in Forth 2012). And I would recommend to reword [COMPILE] to say what it actually does, i.e. make the next word non-immediate. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-08-24 09:48 +0000 |
| Message-ID | <2014Aug24.114818@mips.complang.tuwien.ac.at> |
| In reply to | #33023 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>
>> But that's not the point I wanted to make. In a traditional
>> implementation, VFX's implementation of [COMPILE]
>>
>> : [compile] ' compile, ; immediate
>>
>> is correct.
>
>No. Gforth shows that this assertion is not correct.
On the contrary. When Gforth was traditional, it had this
implementation of [COMPILE]. Then Gforth became non-traditional by
having an EXIT that was defined as IMMEDIATE COMPILE-ONLY; and this
necessitated the special-casing of EXIT in the implementation of
[COMPILE].
>If you change a single
>thing, e.g. make one of those compile-only words which have "execution
>semantics" in the standard immediate, you break [compile]. If you make IF
>non-immediate, you break [compile]. Note that you can implement IF in a way
>that e.g. scans for ELSE and THEN in the threaded code (at run-time), and
>therefore just has default compilation semantics, without any fancy smart
>COMPILE, and you still break [compile].
Sure, if somebody implemented IF in a non-traditional way like you
suggest, one would have to adjust [COMPILE] to it like we did with
Gforth for EXIT.
>All [compile] does is to undo the immediate flag. It's not specified that
>way, but people implement it that way.
That's the traditional implementation, yes.
>And because it's not specified that
>way, you either have to honor the traditional immediate flag stuff in your
>implementation (like we do in Gforth with the excepton of EXIT, and there,
>we can now change it thanks to COMPILE,),
You mean, if we change COMPILE, in the VFX way, we do not need to
special-case EXIT. But we would need to special-case a lot of other
words, including IF, as start of this subthread shows.
>or you have to special-case all
>standard words where you changed that flag.
Or you implement it in another way.
>> VFX's change to COMPILE, broke it. You asked for
>> breakage? Here's one example. And I did not even need to search for
>> it.
>
>Let's try something different: change Gforth's EXIT to be non-immediate
>through the new use of compile,. Our test candidate is foo:
>
>: foo ." a" [compile] exit ." b" ; ok
>foo a ok
>
>So [compile] exit (the immediate, non-tickable Gforth exit which is special-
>cased in [compile]) works as intented: It's just equal to EXIT alone. Fine.
>Now, our EXIT handles stuff like cleaning up locals, so we had to make it
>immediate. Try SET-COMPILER:
>
>:noname drop postpone exit ; : exit -14 throw ; set-compiler
>:1: warning: redefined EXIT with exit ok
>: foo ." a" [compile] exit ." b" ; ok
>foo a ok
>
>Works. This now is the new EXIT, which is not special-cased by [compile].
>It is non-immediate, as the Forth-83 standard has meant EXIT to be. It does
>SET-COMPILER magic, because that is how you can implement stuff like
>cleaning up local stacks in EXIT. The new magic doesn't change anything,
>because EXIT has default compilation semantics, and the compilation
>semantics is specified with SET-COMPILER.
>
>So: It's not the new COMPILE, which breaks [COMPILE], it is the choice of
>making IF and friends non-immediate. Or, as in Gforth, making EXIT
>immediate (but we did add the workaround into [COMPILE]).
Sure, after changing COMPILE, and IF (and other compiler words) the
way he did, Stephen Pelc (or whoever did it) could havegone through
all uses of COMPILE, and look at the consequences and change either
the uses of COMPILE, (e.g., in [COMPILE]) or the definitions of IF and
friends to avoid breakage. The fact that he either didn't or
overlooked at least this breakage (and there may be more, I did not do
any analysis, and came across this just by a conincidential bug report
in another thread) does not indicate that these changes were thought
through.
Anyway, it's a counterexample that disproves your "no problems from
this change in COMPILE," claim.
BTW, I think that many people will find your "non-immediate" term to
be contrary to their expecteations (and it's also contrary to your
usage in other places). And given that the specification of [COMPILE]
does not talk about immediacy, it's completely unwarranted.
>So that's my conclusion: The standard had tried to make the question,
>whether a word is immediate or not a choice of the implementer, but failed.
It succeeded. Some systems implement EXIT as a normal word, Gforth
implements it as immediate compile-only word. Normal compilation
works with it, POSTPONE works with it, [COMPILE] works with it. Where
do you see a failure.
>The result is that it mandates
>a pretty traditional implementation, where IF is immediate and EXIT is not.
It does not, as demonstrated by Gforth, where EXIT is immediate
compile-only.
>There's one question, whether we leave this traditional stuff in Gforth, and
>my answer is pretty much: yes. That's due to the goals of Gforth. We
>should make EXIT non-immediate, and allow to tick all those compile-only
>words, because you still can COMPILE, them (or EXECUTE them if you think
>they are immediate, and in Gforth, the assumption will be correct).
Unfortunetely, your confusion of terminology does not tell me what you
mean with "non-immediate" here. Do you mean that we should have
"' ;S alias exit", with a thunk for freeing the locals?
>R and friends have default compilation semantics and no
interpretation semantics in the standard, and are implemented as
normal words in Gforth; you can tick them and EXECUTE them and
COMPILE, them. They are not immediate, and it's unclear to me why one
should have to think that they are immediate before EXECUTEing them,
but in any case, that assumption would be incorrect. The only
exception in this category of words is EXIT, which is not implemented
as a normal word, and therefore you cannot tick it.
>The other question is whether we want the standard to mandate this
>traditional flags, or if we rather leave it up to the implementer, and drop
>[COMPILE].
The standard does not mandate any traditional flags in connection with
[COMPILE] now. FIND and SEARCH-WORDLIST are specified to report
whether a word is immediate, though.
We can declare [COMPILE] obsolescent, because it has been superseded
by POSTPONE, but technically it is mostly ok.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-08-24 15:55 -0400 |
| Message-ID | <op.xk34akow6zenlw@localhost> |
| In reply to | #33023 |
On Sat, 23 Aug 2014 16:12:19 -0400, Bernd Paysan <bernd.paysan@gmx.de> wrote: > Anton Ertl wrote: >> But that's not the point I wanted to make. In a traditional >> implementation, VFX's implementation of [COMPILE] >> >> : [compile] ' compile, ; immediate >> >> is correct. > > No. Gforth shows that this assertion is not correct. If you change a > single thing, e.g. make one of those compile-only words which have > "execution semantics" in the standard immediate, you break [compile]. > If you make IF non-immediate, you break [compile]. Why exactly does making IF non-immediate break [compile] ? I.e., is this something to do with ' (tick) and immediate words, or due to something else? Is this breakage only for GForth or only for compiled Forths? Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-08-24 15:55 -0400 |
| Message-ID | <op.xk34blz26zenlw@localhost> |
| In reply to | #33010 |
On Fri, 22 Aug 2014 12:47:39 -0400, Bernd Paysan <bernd.paysan@gmx.de> wrote: > If you look at the definition of [COMPILE] in Gforth, you see that > there's an obvious way to fix [COMPILE] in VFX: > > : [compile] ( compilation "name" -- ; run-time ? -- ? ) > \ core-ext bracket-> compile > comp' drop > dup [ comp' exit drop ] literal = if > execute \ EXIT has default compilation semantics, perform them > else > compile, > then ; immediate > > Yeah, there's a special casing for EXIT, because people using [COMPILE] > will assume EXIT to be non-immediate, so we "cheat". This makes no sense to me. If "people using [COMPILE] will assume EXIT to be non-immediate" and "all [compile] does is to undo the immediate flag" (BP in a later post), why would anyone ever use [COMPILE] on an assumed, non-immediate EXIT ? There would be absolutely no point in doing that, right? Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-08-25 08:26 +0000 |
| Message-ID | <2014Aug25.102650@mips.complang.tuwien.ac.at> |
| In reply to | #33032 |
"Rod Pemberton" <dont_use_email@xnothavet.cqm> writes:
>If "people using [COMPILE] will assume EXIT to be non-immediate" and
>"all [compile] does is to undo the immediate flag" (BP in a later post),
>why would anyone ever use [COMPILE] on an assumed, non-immediate EXIT ?
>There would be absolutely no point in doing that, right?
Yes, one normally won't use [COMPILE] on words with default
compilation semantics like EXIT (immediacy and user expectations have
little to do with it, though). The standard still specifies what
happens when you do it, so a standard system has to implement it.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-08-26 07:36 -0400 |
| Message-ID | <op.xk66iat06zenlw@localhost> |
| In reply to | #33034 |
On Mon, 25 Aug 2014 04:26:50 -0400, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > "Rod Pemberton" <dont_use_email@xnothavet.cqm> writes: >> If "people using [COMPILE] will assume EXIT to be non-immediate" and >> "all [compile] does is to undo the immediate flag" (BP in a later post), >> why would anyone ever use [COMPILE] on an assumed, non-immediate EXIT ? >> There would be absolutely no point in doing that, right? > > Yes, one normally won't use [COMPILE] on words with default > compilation semantics like EXIT (immediacy and user expectations have > little to do with it, though). The standard still specifies what > happens when you do it, so a standard system has to implement it. > If EXIT has to be added to [COMPILE] to fix it with VFX, why doesn't R> >R R@ LEAVE UNLOOP I J need to be added too? Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-08-26 12:12 +0000 |
| Message-ID | <2014Aug26.141246@mips.complang.tuwien.ac.at> |
| In reply to | #33070 |
"Rod Pemberton" <dont_use_email@xnothavet.cqm> writes:
>On Mon, 25 Aug 2014 04:26:50 -0400, Anton Ertl
><anton@mips.complang.tuwien.ac.at> wrote:
>> "Rod Pemberton" <dont_use_email@xnothavet.cqm> writes:
>
>>> If "people using [COMPILE] will assume EXIT to be non-immediate" and
>>> "all [compile] does is to undo the immediate flag" (BP in a later post),
>>> why would anyone ever use [COMPILE] on an assumed, non-immediate EXIT ?
>>> There would be absolutely no point in doing that, right?
>>
>> Yes, one normally won't use [COMPILE] on words with default
>> compilation semantics like EXIT (immediacy and user expectations have
>> little to do with it, though). The standard still specifies what
>> happens when you do it, so a standard system has to implement it.
>>
>
>If EXIT has to be added to [COMPILE] to fix it with VFX, why doesn't
>R> >R R@ LEAVE UNLOOP I J need to be added too?
I guess you mean Gforth, not VFX (VFX gets [COMPILE] IF wrong, but
AFAIK [COMPILE] EXIT right). The implementation of EXIT in Gforth is
as an immediate compile-only word, whereas the implementation of R> >R
R@ UNLOOP I J is as a normal word, so they don't need to be
special-cased. LEAVE is an immediate compile-only word in Gforth and
should be special-cased, too; thanks for pointing that out.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-09-23 17:45 +0200 |
| Message-ID | <lvs4j0$8lj$3@online.de> |
| In reply to | #33074 |
Anton Ertl wrote: > LEAVE is an immediate compile-only word in Gforth and > should be special-cased, too; thanks for pointing that out. If you want to change this in the current git head, rather use the smart compile, to implement LEAVE's compilation semantics than to special-case [COMPILE]. That way, LEAVE will become "traditional" (non-immediate compile-only), and better fit with the goals of Gforth (less surprise). -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-08-21 03:25 -0700 |
| Message-ID | <c4aa2f94-1728-43eb-b394-d5245686d053@googlegroups.com> |
| In reply to | #32977 |
On Wednesday, 20 August 2014 08:46:06 UTC+1, Anton Ertl wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: > > >Anton Ertl wrote: > > > > > >> Bernd Paysan <bernd.paysan@gmx.de> writes: > > >>>Alex McDonald wrote: > > >>>> I would like to see that explained, since setting a single behaviour for > > >>>> IMMEDIATE words in my Forth has not caused any problems for me; and I > > >>>> struggle to see what code this might break. Can you give a concrete > > >>>> example? > > >>> > > >>>Ok, simple example: > > >>> > > >>>: cond, ( xt -- ) >r postpone IF r> compile, postpone THEN ; > > >>>: ?exit ( -- ) ['] exit cond, ; immediate > > >>> > > >>>Works fine when EXIT is not immediate - that's my assumption for now that > > >>>EXIT is non-immediate. > > >> > > >> Just write it as > > >> > > >> : cond, ( ct -- ) 2>r postpone IF 2r> execute postpone THEN ; > > >> : ?exit ( -- ) [comp'] exit cond, ; immediate > > >> > > >> and it will work whether EXIT is immediate or not. You may argue that > > >> [COMP'] is not standard, but neither is "['] exit". > > > > > >They are non-standard on a different level. ['] EXIT is an ambiguous > > >condition (i.e. non-standard, because there's no consent between different > > >implementers), [COMP'] is non-standard, because it's using a Gforth > > >extension, not even proposed for inclusion into a future standard, and > > >probably facing difficulties to get in. > > > > Given that there is no consent between implementors on what ['] EXIT > > should mean, it's unlikely to get in, and there is no proposal for > > including ['] EXIT in a future standard, either. > > > > Concerning [COMP'], given that there we have NAME>COMPILE in Forth > > 200x, the most difficult step in standardizing it has already been > > taken. But true, there is no proposal on [COMP']. The main > > difficulty I would expect now is that "application programmers don't > > need it", i.e., the objection would be that too few people write words > > like COND, and ?EXIT to make [COMP'] worth standardizing, and that > > would also be a counterargument to proposals for changing ['] or > > COMPILE,. > > > > Anyway, to make your code above work, you would also need to change > > COMPILE, in an incompatible way, and we have learned from bad > > experiences in the past (e.g., NOT) that this is a very bad idea. In > > no existing Forth system COMPILE, works the way you want it to; I see > > no chance that a proposal for such a change to COMPILE, would come > > through. > > > > >It's non-portable just like + with overflow is non-portable, because > > >different machines could behave different on overflow. > > > > An overflow on + is non-standard, but portable: Every Forth system > > performs wraparound and uses 2s-complement representation for signed > > integers. > > > > In contrast, ['] EXIT does not work on all Forth systems, and behaves > > differently in different Forth systems where it does not produce an > > error. > > > > >so it's very likely that the code out there > > >that actually does use ['] EXIT wants an xt as result. Something to > > >COMPILE,, to be precise, because that's the only use of that xt which makes > > >sense. > > > > As your example shows, what makes sense (if you can tick EXIT) depends > > on the way that EXIT is implemented. If it is implemented as > > IMMEDIATE word, then it makes sense to EXECUTE the xt in COND,. > > > > I tried the following code on iforth-2.1, vfxlin 4.60, > > SwiftForth 3.4.4, Gforth 0.7.0, and bigFORTH 2.3.1: > > > > : bla ['] exit execute ." x" ; bla > > > > iForth outputs nothing. > > vfxlin produces an error -14 when BLA executes. > > sf outputs "x". > > gforth produces an error -14 when ['] executes. > > bigforth outputs "x". > > > > Not very much portability here. > > > > Next test: > > : x ['] exit compile, ; immediate : a x ." a" ; immediate : b a ." b" ; b > > > > iforth outputs "b". > > sf outputs "b". > > vfxlin outputs "b". > > gforth produces an error -14 when ['] executes. > > bigforth outputs "b". > > > > Four of these systems make "['] exit compile," behave like POSTPONE > > EXIT (e.g., by implementing EXIT as a word with default compilation > > semantics (something like +)). > > > > Now a way to get a guaranteed tickable EXIT is to redefine it (all > > words defined by the user in standard Forth have interpretation > > semantics and are therefore tickable): > > > > : exit postpone exit ; immediate > > > > But as you point out, this changes what "['] exit compile," does: > > > > : exit postpone exit ; immediate : x ['] exit compile, ; immediate : a x ." a" ; immediate : b a ." b" ; b > > > > iforth outputs "a". > > sf outputs "a". > > vfxlin outputs "a". > > gforth outputs "a". > > bigforth outputs "a". > > > > Let's try the EXECUTE variant with that EXIT again: > > > > : exit postpone exit ; immediate : x ['] exit execute ; immediate : a x ." a" ; immediate : b a ." b" ; b > > > > iforth outputs "b". > > sf outputs "b". > > vfxlin outputs "b". > > gforth outputs "b". > > bigforth outputs "b". > > > > So the definition > > > > : exit postpone exit ; immediate > > > > makes ['] EXIT portable, but changes it on all systems. Maybe your > > next argument is that this redefinition of EXIT is wrong, and we > > should either not use it (but what else?) or change it's meaning along > > with the meaning of "COMPILE,", but my conclusion is that ['] EXIT is > > just a bad idea. As for "the only thing that makes sense", thinging > > about these examples I did not get the feeling that COMPILE, makes > > more or less sense than EXECUTE for ['] EXIT. > > > > >The way a standard process works means that we probably need to change the > > >definition of COMPILE, because it no longer reflects a consent within the > > >Forth community. > > > > The definition of "consent" is not "Bernd Paysan's opinion". Also, a > > single dissenting opinion does not dissolve consent. > > > > > There's simply an ambiguous condition if you COMPILE, a > > >word with "special compilation semantics". This would be the first > > >transition step. After this is done, Anton still can say "I want COMPILE, > > >to be equivalent to POSTPONE LITERAL POSTPONE EXECUTE", and has his say in > > >the compiler he maintains, but it's no longer something standard. > > > > Taking away standard guarantees to programs (and in this case there > > really are programs out there the rely on this guarantee) is a bad > > idea. Even if you find consent on such a change (which is a long way > > from dissolution of the consent on the current definition), the way to > > do it would be to declare COMPILE, obsolescent, and define another > > word that has the behaviour you want, whatever that may be. > > > > >And the fact that it is no longer standard is a consequence of the > > >"normative Kraft des Faktischen" as a German philosopher put it (the > > >normative force of the factual - that is the main driving force of roughly > > >consent-based standards) - there *are* popular systems out there where this > > >relation doesn't hold, and funny enough, the Forth system Anton and I > > >maintain, is among them - but so far, only if you actually use the non- > > >standard extension SET-COMPILER or COMP: to break this assumption (which > > >means there is no standard way to write a program that exhibits this non- > > >standard behavior of COMPILE,). > > > > Sure, you can make any system behave in non-standard ways by writing > > non-standard programs (e.g., you might patch the implementation of > > COMPILE,). That's nothing spectacular, and no justification for > > changing the meaning of COMPILE, for standard programs. > > > > >If we make this extension standard (optional wordset, of course), then there > > >is a standard way to break the original COMPILE, assumption, and that would > > >be phase 2 of the long transition. > > > > I don't see enough value in standardizing this "feature" to sacrifice > > the COMPILE,-EXECUTE relation for it. Also, even if I was not in > > play, I have my doubts that you will get consent among implementors. > > After all, this requires standardizing things about the implementation > > that they have been very reluctant to standardize. > > > > >The first thing I want to do with COMPILE, however is to remove this stupid > > >COMPILE, is compile-only restriction. I can't find a Forth where this is > > >really the case, all compile > > > > > >: test [ ' + compile, ] ; > > > > That's certainly a good idea, but it has nothing to do with the rest > > of your ideas about COMPILE,. > > > > >Anton's proposal how to resolve the backward compatibility solution is to > > >invent a new name for this new COMPILE, so e.g. XT, might do better (which > > >would be defined as "append the compilation semantics of the xt"), and > > >define COMPILE, so that it indeed does the equivalent of POSTPONE LITERAL > > >POSTPONE EXECUTE, maybe optimizing the common case (default compilation > > >semantics). > > > > No, my idea is to use COMP' and [COMP']. "XT," or whatever it is > > called would just be a way to integrate your idea of how COMPILE, > > should behave in a backwards-compatible way. > > > > My other idea is to get rid of words that have both interpretation > > semantics and non-default non-immediate compilation semantics (S", TO, > > IS ...). Then we really just have one xt per word, > > > > >But that approach breaks the "user-implemented text > > >interpreter", which was the motivation of Mitch Bradley to introduce > > >COMPILE, at all. > > > > It does not. The user-defined text interpreter works fine with the > > currently-standard COMPILE,. Ok, it needs an ugly FIND, but that > > uglyness is a bastard of words like S" and FIND; trying to make FIND > > less ugly by breaking COMPILE, is a bad idea. > > > > >The change to COMPILE, I probably would suggest would be, in the proporsal > > >with SET-COMPILER: > > > > > >SET-COMPILER ( comp-xt -- ) > > >modifies the compilation semantics of the last definition to execute comp-xt > > >on compilation > > > > > >comp-xt: ( i*x xt -- j*y ) > > >performs the compilation semantics of xt. > > > > > >COMPILE, ( xt -- ) > > >If xt has a special compilation semantics set by SET-COMPILER, perform this > > >special compilation semantics, otherwise append the execution semantics of > > >xt (default compilation semantics). > > > > > >That way it is clearly extending the current COMPILE, in a way that now xts > > >can carry non-default compilation semantics - and it's non-ambiguous by > > >itself (i.e. still well-defined). And of course we need to say that the > > >system has to document which words with special compilation semantics are > > >actually implemented that way. > > > > No from me for the change to COMPILE,. > > > > - anton > > -- > > M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html > > comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html > > New standard: http://www.forth200x.org/forth200x.html > > EuroForth 2014: http://www.euroforth.org/ef14/ Perhaps a more disruptive approach is needed (long-term). I'm beginning to think in terms of different classes of XT in order to get hold of the appropriate semantics. Maybe we need to start thinking of CSs (compilation semantics), ETs (execution semantics) and ITs (interpretation semantics) etc, rather than one single 'type' of XT. Then, COMPILE, POSTPONE et al can work with them unmodified with no intelligence required in tick and friends. One doesn't have guess at what might come back. If you call for an IT (interpretation semantic token), you *know* you're going to get an IT (or perhaps a THROW if inappropriate to ask for one, or a zero). If you get something back, then you can compile it. E.g. Isemantic: DUP Asks for the interpretation semantic token for DUP (probably isn't one). Using this approach, it would be quite legal for some words to have different combinations of semantics for the appropriate semantic modes. And much more portable.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-08-21 23:14 -0700 |
| Message-ID | <ba613b0e-5e8d-4037-8135-b62047de3c12@googlegroups.com> |
| In reply to | #32989 |
On Thursday, August 21, 2014 3:25:17 AM UTC-7, Mark Wills wrote: > Isemantic: DUP > > Asks for the interpretation semantic token for DUP (probably isn't one). In my cross-compiler, words such as DUP are defined in both HOST and TARG. The TARG version is in the target processor's memory and it is what duplicates the top item on the stack. The HOST version was generated automatically, and it compiles the TARG version. Immediate words (such as IF and semi-colon) are in HOST, and there is no TARG version. There is never any confusion about whether an xt is supposed to execute at run-time on the target processor or at compile-time on the host processor. Also, if you have an xt and you don't know whether it is HOST or TARG, it is possible to test it to determine which it is.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-08-19 14:16 +0000 |
| Message-ID | <2014Aug19.161604@mips.complang.tuwien.ac.at> |
| In reply to | #32969 |
"Alex McDonald" <blog@rivadpm.com> writes:
>> The problem is a lack in the standard: While ANS Forth has a clean way
>> to pass tokens for interpretation semantics (simply do ' FOO EXECUTE),
>> there is no equivalent token to pass for compilation. Gforth has COMP'
>> FOO EXECUTE to solve that problem, VFX has ' FOO COMPILE, - but that
>> works only for the internals of VFX, not for (user defined) immediate
>> words.
>>
>> I actually like the way VFX does it (which is why Gforth git head can
>> support the same stuff), and to get rid of IMMEDIATE could be a good
>> idea, but to make this standard is likely breaking some old code (even
>> with a legacy IMMEDIATE, which just sets the compilation behavior to
>> be equivalent to the interpretation), and therefore requires a lengthy
>> transition.
>>
>
>I would like to see that explained, since setting a single behaviour for
>IMMEDIATE words in my Forth has not caused any problems for me; and I
>struggle to see what code this might break. Can you give a concrete
>example?
COMPILE, is equivalent to
: compile, postpone literal postpone execute ;
There is code around that relies on that, e.g., Mini-OOF has:
: method ( m v -- m' v ) Create over , swap cell+ swap
DOES> ( ... o -- ... ) @ over @ + @ execute ;
...
: :: ( class "name" -- ) ' >body @ + @ compile, ;
If you do something like
object class
method foo
end-class bar
' s" bar defines foo
bar new constant bar1
: bar-foo [ bar :: foo ] ;
bar1 foo xxx" type \ should output xxx
bar1 bar-foo xxx" type \ should output xxx
the last two lines should produce the same results because of the
equivalence. In Gforth it does. In vfxlin 4.60 it does not.
Before Bernd gets his lengthy transition, he would have to convince
the standards committee to change COMPILE, from its current
specificiation to the one he prefers. And I, for one, am violently
opposed to that idea. I think that the equivalence above is a
valuable feature and we should not part with it.
As long as words with non-default non-immediate compilation semantics
are rare, that's an issue hardly anybody will notice, though.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web