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 1 of 6 [1] 2 3 4 5 6 Next page →
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-08-17 21:09 -0700 |
| Subject | does VFX have the same bug as Gforth? |
| Message-ID | <e12e788c-8ad5-4967-ac7c-003f72dad673@googlegroups.com> |
In this thread: https://groups.google.com/forum/#!searchin/comp.lang.forth/LC53%7Csort:relevance/comp.lang.forth/wP5nw1ClzsM/E-TV9v2y9RoJ I found out that in Gforth not all words have xt values. If you tick certain words the system will abort with an error message, although the word is in the dictionary. Specifically, ticking semi-colon causes Gforth to abort. This was a surprise to me, and I considered it to be a bug, but Anton Ertl said that I had no reason to expect every word to have an xt, and that it was my fault --- that I just don't know ANS-Forth very well. I haven't taken Gforth seriously since that time --- I don't consider it to be suitable for commercial work with problems like this. My question is, does VFX have this same bug? The reason why I ask, is that I'm starting a big project and I want to use VFX. Is there any way to determine if an ANS-Forth compliant system has this bug or not? It is not just semi-colon, but I actually expect every word in the dictionary to have an xt. I could try ticking every word in the dictionary to see if doing so for any word aborts the system, but this seems rather tedious. I could just assume that anything that WORDS finds must have an xt, but this isn't guaranteed to work. Most likely, the only way to find out if an ANS-Forth compliant system has the bug or not, is to just ask the person who wrote the code --- that would be Stephen Pelc in the case of VFX --- but in the case of Gforth there are a variety of people involved, and it is not clear which ones of them have the authority to say that the bug is there or not.
[toc] | [next] | [standalone]
| From | Bee <forth@calcentral.com> |
|---|---|
| Date | 2014-08-17 23:06 -0700 |
| Message-ID | <7f2a965b-6053-44c4-ac8c-5c977f197de8@googlegroups.com> |
| In reply to | #32949 |
This is not a 'bug'. The gforth word to find the xt for compile-only words is: COMP' Bill (aka eforth) On Sunday, August 17, 2014 9:09:10 PM UTC-7, hughag...@yahoo.com wrote: > In this thread: > https://groups.google.com/forum/#!searchin/comp.lang.forth/LC53%7Csort:relevance/comp.lang.forth/wP5nw1ClzsM/E-TV9v2y9RoJ > I found out that in Gforth not all words have xt values. If you tick certain words the system will abort with an error message, although the word is in the dictionary. Specifically, ticking semi-colon causes Gforth to abort.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-08-18 17:03 -0700 |
| Message-ID | <bdfba712-08a4-4aaa-9f67-ee4ee47f7fb7@googlegroups.com> |
| In reply to | #32950 |
On Sunday, August 17, 2014 11:06:54 PM UTC-7, Bee wrote: > This is not a 'bug'. > > The gforth word to find the xt for compile-only words is: > > COMP' How am I supposed to know whether a word is compile-only or not? If I already know what word I have encountered, then I don't need to tick it to find out --- also, I don't need the xt, because I can POSTPONE it. I was told previously that semi-colon didn't have an xt, but now you tell me that it does have an xt but that ' can't find it and COMP' can find it --- if it has an xt, why doesn't ' just spit it out? None of this stuff makes any sense whatsoever!
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-08-18 22:19 -0400 |
| Message-ID | <op.xkth2ffy6zenlw@localhost> |
| In reply to | #32957 |
On Mon, 18 Aug 2014 20:03:59 -0400, <hughaguilar96@yahoo.com> wrote: > How am I supposed to know whether a word is compile-only or not? What you need to ask is: 1) How is *code* supposed to "know" whether a word is tick'able or not? 2) How is *code* supposed to "know" whether a word is compile-only or not? No one really cares if you know or not ... The real issue is how code can determine answers to those questions without a person being involved as part of the process. I.e., universal code. Apparently, Hugh expects Forth code to be universal and/or portable due to ANS. C isn't, even after multiple standards. It's only partially so. (Although, even that simple, truthful statement likely to start an intense flame war on comp.lang.c.) > I was told previously that semi-colon didn't have an xt, but now you > tell me that it does have an xt but that ' can't find it and COMP' can > find it --- if it has an xt, why doesn't ' just spit it out? I can't imagine an interpreted Forth not having an xt for semi-colon. I can understand a compiled Forth not having an xt for semi-colon. > None of this stuff makes any sense whatsoever! Doh! Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-08-19 09:14 +0000 |
| Message-ID | <2014Aug19.111459@mips.complang.tuwien.ac.at> |
| In reply to | #32957 |
hughaguilar96@yahoo.com writes:
>On Sunday, August 17, 2014 11:06:54 PM UTC-7, Bee wrote:
>> This is not a 'bug'.
>>
>> The gforth word to find the xt for compile-only words is:
>>
>> COMP'
>
>How am I supposed to know whether a word is compile-only or not? If I already know what word I have encountered, then I don't need to tick it to find out --- also, I don't need the xt, because I can POSTPONE it.
When you want to get the interpretation semantics of a word, use
'/[']. When you want to get the compilation semantics, use
COMP'/[COMP']. You just need to know what you want to do. Of course,
for words that don't have interpretation semantics, ticking them may
produce an error (if you are lucky), but you can see in the standard
whether a word has defined interpretation semantics or not; and for
your own words, you should know that, too.
If you want to compile the compilation semantics of ";", then yes, use
"POSTPONE ;". "[comp'] ; execute" is an alternative.
>I was told previously that semi-colon didn't have an xt, but now you tell me that it does have an xt but that ' can't find it and COMP' can find it --- if it has an xt, why doesn't ' just spit it out?
Because ' produces the xt representing the interpretation semantics.
One could implement it to spit out some other xt if the word does not
have interpretation semantics; for compile-only words an xt that
performs the compilation semantics when EXECUTEd is the traditional
behaviour. But given that Gforth deviates from traditional ideas in
this area in other ways, I chose to produce an error so that the other
non-traditional behaviour does not come as a surprise.
The behaviour of ' has led to most, if not all complaints in this
area. Maybe we should have done the traditional thing instead; or
maybe the behaviour of ' has fullfilled it's purpose. In any case,
the error message tells the traditionalists how to get the xt they
want:
' ;
:4: Cannot tick compile-only word (try COMP' ... DROP)
' >>>;<<<
- 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-08-19 15:23 +0200 |
| Message-ID | <lsvj4l$543$1@online.de> |
| In reply to | #32962 |
Anton Ertl wrote: > Because ' produces the xt representing the interpretation semantics. > One could implement it to spit out some other xt if the word does not > have interpretation semantics; for compile-only words an xt that > performs the compilation semantics when EXECUTEd is the traditional > behaviour. Since the question was about VFX: For those words, VFX usually returns xts which throw an error when excuted. ' ; execute Err# -14 ERR: Attempt to interpret a compile only definition. -> ' ; execute In Gforth, you get this error when you ', i.e. before the execute ' ; execute :1: error: Interpreting a compile-only word ' >>>;<<< execute (it highlight's ;, because ' scans the input and then decides to throw). 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. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-08-19 14:54 +0100 |
| Message-ID | <lsvkvr$400$1@dont-email.me> |
| In reply to | #32968 |
on 19/08/2014 14:23:34, Bernd Paysan wrote: > Anton Ertl wrote: > >> Because ' produces the xt representing the interpretation semantics. >> One could implement it to spit out some other xt if the word does not >> have interpretation semantics; for compile-only words an xt that >> performs the compilation semantics when EXECUTEd is the traditional >> behaviour. > > Since the question was about VFX: For those words, VFX usually returns > xts which throw an error when excuted. > > ' ; execute > Err# -14 ERR: Attempt to interpret a compile only definition. > -> ' ; execute > > In Gforth, you get this error when you ', i.e. before the execute > > ' ; execute >:1: error: Interpreting a compile-only word > ' >>>;<<< execute > > (it highlight's ;, because ' scans the input and then decides to > throw). > > 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?
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-08-19 16:09 +0200 |
| Message-ID | <lsvlqi$bcb$1@online.de> |
| In reply to | #32969 |
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. But unfortunately, you loaded the locals extensions before, and there, EXIT has been defined as (cut&paste these lines into your Forth first): : adjust-localstack ( -- ) ." Adjust local stack" ; : exit ( -- ) adjust-localstack postpone exit ; immediate And now, after defining cond, and ?exit as above, we enter: : zero? ?exit ." zero" ; Let's test it: 0 zero? zero ok 1 zero? Adjust local stackzero ok Oops. That's not exactly what we wanted. -- 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-19 15:39 +0000 |
| Message-ID | <2014Aug19.173925@mips.complang.tuwien.ac.at> |
| In reply to | #32970 |
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".
- 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-08-19 22:34 +0200 |
| Message-ID | <lt0cd2$uu$1@online.de> |
| In reply to | #32972 |
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. An ambiguous condition means that when you write that code, you depend on an environmental restriction, and it's non-portable, but it's still using standard words. It's non-portable just like + with overflow is non-portable, because different machines could behave different on overflow. A predictable, intuitive response of the system to this ambiguous condition is certainly preferred, and what's a "intuitive response" depends upon the author of the code using that construct - so this depends on the existing code base, and the mentality that we don't existing break code - at least not with the systems where it originally ran on. The likelyhood that the existing code base depends on ['] EXIT to throw an error is zero (no code base ever depends on not compiling ;-), 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. 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. 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. 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,). This is, because we don't break code, and if you have funny uses of the current Gforth model, you still can continue to use them. We don't know how much fun you had with the dual-xt approach, but we won't break your code if you did. Certainly not without a long enough period of warning. 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. 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, ] ; 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). But that approach breaks the "user-implemented text interpreter", which was the motivation of Mitch Bradley to introduce COMPILE, at all. And the code that uses COMPILE, exactly that way also exists. 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. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-08-19 23:29 +0100 |
| Message-ID | <lt0j5r$346$1@dont-email.me> |
| In reply to | #32974 |
on 19/08/2014 21:34:42, Bernd Paysan wrote: > 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. An ambiguous > condition means that when you write that code, you depend on an > environmental restriction, and it's non-portable, but it's still using > standard words. > > It's non-portable just like + with overflow is non-portable, because > different machines could behave different on overflow. A predictable, > intuitive response of the system to this ambiguous condition is > certainly preferred, and what's a "intuitive response" depends upon > the author of the code using that construct - so this depends on the > existing code base, and the mentality that we don't existing break > code - at least not with the systems where it originally ran on. The > likelyhood that the existing code base depends on ['] EXIT to throw an > error is zero (no code base ever depends on not compiling ;-), 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. > > 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. 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. > > 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,). This > is, because we don't break code, and if you have funny uses of the > current Gforth model, you still can continue to use them. We don't > know how much fun you had with the dual-xt approach, but we won't > break your code if you did. Certainly not without a long enough period > of warning. > > 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. > > 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, ] ; > > 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). But that approach breaks the > "user-implemented text interpreter", which was the motivation of Mitch > Bradley to introduce COMPILE, at all. And the code that uses COMPILE, > exactly that way also exists. > > 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. > Or we could abandon COMPILE, and provide POSTPONE,
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-08-20 23:06 +0200 |
| Message-ID | <lt32jv$flu$1@online.de> |
| In reply to | #32975 |
Alex McDonald wrote: >> 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. >> > > Or we could abandon COMPILE, and provide POSTPONE, That means you have to change code that uses Mitch Bradley's generic compiler - if you invent new words for functions which already exist, and are already used that way, you break code. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-08-20 22:21 +0100 |
| Message-ID | <lt33j3$ust$1@dont-email.me> |
| In reply to | #32983 |
on 20/08/2014 22:06:05, Bernd Paysan wrote: > Alex McDonald wrote: > >>> 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. >>> >> >> Or we could abandon COMPILE, and provide POSTPONE, > > That means you have to change code that uses Mitch Bradley's generic > compiler - if you invent new words for functions which already exist, > and are already used that way, you break code. > Abandon in the sense of WORD ; like WORD COMPILE, is there but to be avoided. Code such as Mitch's continues to work, since where it works (or doesn't work) doesn't change.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-08-20 07:46 +0000 |
| Message-ID | <2014Aug20.094606@mips.complang.tuwien.ac.at> |
| In reply to | #32974 |
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/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-08-21 00:26 +0200 |
| Message-ID | <lt37a0$tnf$1@online.de> |
| In reply to | #32977 |
Anton Ertl wrote: > 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. Hm, if I understand the test correctly, 4 out of 5 systems had a consent on what ['] EXIT COMPILE, means, and the only dissenting oppinion is Anton Ertl's. Which does not really break consent. > Concerning [COMP'], given that there we have NAME>COMPILE in Forth > 200x, the most difficult step in standardizing it has already been > taken. Yes. > 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. It has already been changed in several Forth systems, and apparently not caused user complaints. While not being able to ' EXIT has caused people to complain, several times. This is just one case. Do you take bug reports like that serious or do you close them with Ulrich Drepper "invalid, as the standard allows me to be a dick, and break your program" reason? This behavior is obviously different from the user expectation, and as the standard says it's an ambiguous condition, you can as well just make the user to be right. That's the way we want it from the GCC team. We should live by our standards. > In > no existing Forth system COMPILE, works the way you want it to; It works that way in three Forth systems. > In contrast, ['] EXIT does not work on all Forth systems, and behaves > differently in different Forth systems where it does not produce an > error. Well, let's see: > 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. As EXIT has no interpretation semantics, it is quite easy to see why executing the returning xt does not lead to something useful. > 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 +)). Yes, that's what a user would expect from EXIT - it has no interpretation semantics, so it can't be EXECUTEd, but it has compilation semantics, so COMPILE, maybe can do something with it. It still might be immediate, but apparently, 4 out of 5 Forth systems found a way to have a non-immediate EXIT. In Gforth git head, you can define it easily: :noname drop postpone exit ; : exit -14 throw ; set-compiler And then suddenly, gforth also outputs "b". > 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. Yes, this means that the standard does not allow the user to define a reasonably derived version of EXIT. That's because the standard has poor tools for defining such words. IMMEDIATE is a pretty crappy solution. > 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. But COMPILE, did work 4 out of 5 cases, and the case it didn't work is the one which is implemented following your oppinion, and it can easily be fixed. So if you exclude the one dissenting voice, there's a consent. >>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. That's certainly a nonsense argument, because the dissenting COMPILE, is already in VFX, in Gforth git head, and in Win32Forth (in the STC version). > 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. The consent already dissolved (3 implementers in the small world of Forth is a big chunk that matters). And the straw mens you are errecting to prove that this COMPILE, is going to cause problems are not conclusive. Your point is that this COMPILE, is going to break code like Mini-OOF if you define a new word with special compilation semantics (with SET-COMPILER), and assign it to a method. Yes, this is going to break Mini-OOF. However, as SET-COMPILER is new, it's not going to break legacy Mini-OOF programs, because they simply can't do that (there wasn't a SET-COMPILER when they had been written, and words like EXIT weren't tickable). And the old words with special compilation semantics like S" still use the dual-xt approach (in the git head Gforth, not in VFX), which doesn't cause this problem. To illustrate what kind of problem we are talking about, I've done this in VFX: variable foo ok : [foo] foo @ execute ; ok : foo, foo @ compile, ; ok ' s" foo ! ok [foo] bla" type bla ok : test [ foo, bla" ] type ; ok test bla ok And that's how you are supposed to use this in Gforth: variable foo ok : [foo] foo @ execute ; ok : foo, foo @ compile, ; ok ' s" foo ! ok [foo] bla" type bla ok : test [ foo, ] type ; ok test bla" bla ok Certainly, this is not portable *now*. I can't imagine that Stephen will change VFX, this COMPILE, is a central feature, and convincing him to use the ugly FIND will be difficult. > 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. Yes. But Stephen actually started convincing others to do so, and he succeeded. The idea that it's my proposal is silly; I jumped late on this smart COMPILE, bandwagon. Win32Forth STC already had it, you made a posting proposing that, and Stephen gave a talk at a EuroForth, and then I was convinced. This is nothing new, this has been in VFX for ages (and with "ages" I mean really right from start). This is known to work with the 1 million lines of CCS, and it also works with the 500 lines of guru code in BerndOOF. There's very little which survives both tests, and BerndOOF is actually of the class *you* think would fail (it doesn't, because to fail, it would have to use SET-COMPILER in inappropriate places). > 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, That has been implemented with recognizers in Gforth git head. This however means that you have to remove several words from the standard... that's not going to happen too quickly. We might get an RFD for recognizes soon, though. >>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. Yes, but the ugly FIND is an "Anton Ertl's oppinion", nobody else in the set of the 5 Forths you tested has implemented the ugly FIND. They all have a FIND which doesn't depend on STATE. It's still ugly, because it takes a counted string, but that can be fixed easily. > No from me for the change to COMPILE,. The change already happened in several popular Forth systems. I'm just describing reality. You can continue to ignore reality (apparently you are doing that, because you say that this new COMPILE, is my oppinion only, instead of researching how many systems actually do it that way). But a standard usually codifies existing practice, and this practice already exists. If your system doesn't have a SET-COMPILER, the COMPILE, behaves as it used to be. If it has, it behaves differently - on words where SET- COMPILER has been used. The words with problems like TO, IS, S" have so many problems that ticking them certainly results in something outside the scope of the standard, so they don't matter. You just can't use ' S" COMPILE, portably, because it doesn't work *now*, and that's 20 years after ANS Forth has codified something where it is pretty clear how that should work - and at that time, it didn't work in any Forth system, including Gforth. That sort of standardization is not going to work. Standardize the things people already do is much more likely to succeed. The big difference between changing NOT and changing COMPILE, as discussed here is that changing NOT instantly broke a lot of code. The change of COMPILE, apparently went much better. I don't remember any code been broken by this in Gforth git head. We can ask Stephen, how much code breakage he has observed. This change on the other hand fixes something in Forth, which is really ugly: state smart words. It doesn't fix them in the way you want to, but your solution just moves the uglyness to FIND, and therefore, none of the other impementers of popular systems wants to follow you. And the new COMPILE, solution doesn't have the drawbacks. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-08-20 22:42 -0700 |
| Message-ID | <bb6a560a-3dbe-4919-9262-5fbeb1c4a05d@googlegroups.com> |
| In reply to | #32985 |
On Wednesday, August 20, 2014 3:26:09 PM UTC-7, Bernd Paysan wrote: > The words with problems like TO, IS, S" have so many problems that ticking > them certainly results in something outside the scope of the standard, so > they don't matter. You just can't use ' S" COMPILE, portably, because it > doesn't work *now*, and that's 20 years after ANS Forth has codified > something where it is pretty clear how that should work - and at that time, > it didn't work in any Forth system, including Gforth. That sort of > standardization is not going to work. Standardize the things people already > do is much more likely to succeed. This issue originally arose because my MACRO: stored xts in order to provide early-binding --- rather than store source-code as it does now, which suffers from the problem of late-binding. The original version that saved xts had problems of its own though --- any immediate word that parses text out of the input stream has to be special-cased --- this includes TO IS S" \ etc.. So I'm not going back to this version anyway. As for my new project, I want FIND to find anything that is in the dictionary. I'm not necessarily going to execute an xt after I have it --- if it is from the wrong word-list, then I will just abort with an error message. This brings us to another problem with ANS-Forth --- there is no easy way to examine an xt and find out what word-list it was defined in (Stephen Pelc already recommended that I do a search on the entire dictionary to find the xt, but that is inefficient for an error-check that has to be done routinely). In UR/Forth this was trivial because the vocabulary number (called a wid nowadays) was in the header --- so no search had to be done.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-08-21 10:23 +0000 |
| Message-ID | <2014Aug21.122342@mips.complang.tuwien.ac.at> |
| In reply to | #32987 |
hughaguilar96@yahoo.com writes:
>As for my new project, I want FIND to find anything that is in the dictiona=
>ry. I'm not necessarily going to execute an xt after I have it --- if it is=
> from the wrong word-list, then I will just abort with an error message. Th=
>is brings us to another problem with ANS-Forth --- there is no easy way to =
>examine an xt and find out what word-list it was defined in (Stephen Pelc a=
>lready recommended that I do a search on the entire dictionary to find the =
>xt, but that is inefficient for an error-check that has to be done routinel=
>y).
You can check in Forth-94 with SEARCH-WORDLIST whether a word is in a
specific wordlist.
- 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 | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-08-21 23:29 -0700 |
| Message-ID | <50361c09-574e-4a96-b1ae-dbae3d3ef24c@googlegroups.com> |
| In reply to | #32990 |
On Thursday, August 21, 2014 3:23:42 AM UTC-7, Anton Ertl wrote: > hughaguilar96@yahoo.com writes: > >As for my new project, I want FIND to find anything that is in the dictiona= > >ry. I'm not necessarily going to execute an xt after I have it --- if it is= > > from the wrong word-list, then I will just abort with an error message. Th= > >is brings us to another problem with ANS-Forth --- there is no easy way to = > >examine an xt and find out what word-list it was defined in (Stephen Pelc a= > >lready recommended that I do a search on the entire dictionary to find the = > >xt, but that is inefficient for an error-check that has to be done routinel= > >y). > > You can check in Forth-94 with SEARCH-WORDLIST whether a word is in a > specific wordlist. You're just repeating what Pelc said. Both of you seem to think that I'm too dumb to read the ANS-Forth manual and know about this stuff --- you just want me to be a novice, and to ask the comp.lang.forth crowd to explain ANS-Forth to me --- that is what you want everybody to be, forever. I already said that it is inefficient to search the entire dictionary to find the xt (which is what SEARCH-WORDLIST does). ANS-Forth is just so inefficient and over-complicated! In UR/Forth, the vocabulary number (nowadays called a wid) was in the header, so there was no need to search at all. If you have only one hash-table, rather than separate hash-tables for each word-list, then it is pretty much guaranteed that you are storing the wid for each word in that word's header. What I'm asking for is a way to directly obtain that wid given the header, and to go from an xt to a header. Pelc said this in private correspondence: > No. What you can do is go from the xt to the name. > ' foo >name count \ -- caddr len > and then use SEARCH-WORDLIST to iterate through all the > wordlists. See also WALKWORDLIST and WALKALLWORDLISTS in the > manual. The only problem is that >NAME isn't ANS-Forth. He is trying to get me to write vendor-specific code, so I will be locked into VFX. Actually, that is not the only problem --- we also have the gross inefficiency of searching the entire dictionary, as described above.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-08-22 12:54 +0000 |
| Message-ID | <2014Aug22.145437@mips.complang.tuwien.ac.at> |
| In reply to | #33000 |
hughaguilar96@yahoo.com writes:
>On Thursday, August 21, 2014 3:23:42 AM UTC-7, Anton Ertl wrote:
>> hughaguilar96@yahoo.com writes:
>> You can check in Forth-94 with SEARCH-WORDLIST whether a word is in a
>> specific wordlist.
...
>I already said that it is inefficient to search the entire dictionary to fi=
>nd the xt (which is what SEARCH-WORDLIST does).
SEARCH-WORDLIST searches one wordlist, not the entire dictionary, and
I expect that search to be efficient (it certainly is in Gforth).
Given that you first get the xt with FIND or ' (which searches the
whole search order), the check with SEARCH-WORDLIST will only add a
small constant factor to the overall cost.
If that's too inefficient for your taste, you have the option to stick
with UR/Forth. If would be interesting to the overall speed
difference between UR/Forth (using the wid-in-header feature) and
Gforth (using SEARCH-WORDLIST) for the thing you want to do.
Actually, if you are only interested in words from one wordlist, you
could use SEARCH-WORDLIST instead of FIND or ' from the start, making
it more efficient than FIND/' with wid-in-header. Caveat: Gforth's
SEARCH-WORDLIST always returns the xt representing the interpretation
semantics.
>If you have only one hash-table, rather than separate hash-tables for each =
>word-list, then it is pretty much guaranteed that you are storing the wid f=
>or each word in that word's header.
Gforth has one hash table for all word lists, but it does not store
the wid for each word in that word's header. Words with the same name
in different wordlists are guaranteed to be in different hash buckets
from the way we construct the hash value, so there is no need to
compare the wids; if we find the word in that bucket, it is guaranteed
to be in the wordlist we are searching.
- 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 | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-08-22 17:54 -0700 |
| Message-ID | <f3028c88-cdd3-4e05-98cd-d3457410ca3d@googlegroups.com> |
| In reply to | #33006 |
On Friday, August 22, 2014 5:54:37 AM UTC-7, Anton Ertl wrote: > hughaguilar96@yahoo.com writes: > >On Thursday, August 21, 2014 3:23:42 AM UTC-7, Anton Ertl wrote: > >> hughaguilar96@yahoo.com writes: > >> You can check in Forth-94 with SEARCH-WORDLIST whether a word is in a > >> specific wordlist. > > >I already said that it is inefficient to search the entire dictionary to fi= > >nd the xt (which is what SEARCH-WORDLIST does). > > SEARCH-WORDLIST searches one wordlist, not the entire dictionary, and > > I expect that search to be efficient (it certainly is in Gforth). If the point is to find out which word-list the xt was defined in, then how do I know which word-list to search? I have to search all of the word-lists until I find it. > Given that you first get the xt with FIND or ' (which searches the > whole search order), the check with SEARCH-WORDLIST will only add a > small constant factor to the overall cost. Assuming that the searches are done in the same way, which is likely, then doing two searches rather than one will double the cost. > If that's too inefficient for your taste, you have the option to stick > with UR/Forth. If would be interesting to the overall speed > difference between UR/Forth (using the wid-in-header feature) and > Gforth (using SEARCH-WORDLIST) for the thing you want to do. For one thing, UR/Forth had >NAME and ANS-Forth doesn't, so how are you going to compare them? If you do get >NAME (VFX has it), then a comparison can be made. I just extract the voc-no from the header directly, so this is a matter of a few instructions. Any kind of search done on the entire dictionary looking for a match of the xt, is going to be orders of magnitude slower. If you want an overall comparison of speed of UR/Forth code to Gforth, I don't know how that would come out. I haven't actually used UR/Forth since leaving Testra, and no work has been done on UR/Forth in 20 years as LMI is out of business. UR/Forth was DTC which was a good idea for the 80486, but not so good for modern processors with caching (because every colon word has its own personal docolon routine, which results in a lot of code-cache thrashing). Also, UR/Forth did no optimization at all. UR/Forth was significantly faster than PolyForth, which is what it was competing against in its day. I did some benchmarking and found that UR/Forth code was pretty close in speed to Borland Turbo-C code. Back then I wrote recursive-descent searches that could take hours or even days to run, so speed was an issue for me. I visited Testra last week, and they are still using UR/Forth. I knew that if they are still using MFX, they would also still be using UR/Forth as MFX has some assembly-language code (my code that extracts the voc-no from the header), and that ANS-Forth doesn't allow for this, so porting MFX to ANS-Forth would be difficult. They have upgraded the MiniForth to an FPGA from the old Lattice isp1048 PLD, so it is several times faster and uses about 3% of the power as it did 20 years ago. It is called RACE now, but it is the same as the MiniForth from a programming stand-point --- they never rewrote MFX, and continue using it to this day. > >If you have only one hash-table, rather than separate hash-tables for each = > >word-list, then it is pretty much guaranteed that you are storing the wid f= > >or each word in that word's header. > > Gforth has one hash table for all word lists, but it does not store > the wid for each word in that word's header. Words with the same name > in different wordlists are guaranteed to be in different hash buckets > from the way we construct the hash value, so there is no need to > compare the wids; if we find the word in that bucket, it is guaranteed > to be in the wordlist we are searching. I don't understand this at all. UR/Forth just prepended the voc-no onto the front of the name before doing the search of the hash-table. The code that prepends the voc-no to the name contains a bug, btw.. This involved moving the string forward by one byte to make room for the voc-no. Doing so overwrites one byte of code past the string, which doesn't belong to the string. This doesn't cause any problems normally, because there is normally nothing out there, but it can cause problems under certain circumstances when there is other data out there. I discovered this bug when I was writing my 65c02 cross-compiler under 16-bit UR/Forth. I told Ray Duncan, and he said that fixing the bug would slow down compilation speed too much, and the bug doesn't cause any problems during typical use. I wasn't much impressed by this answer! Later on at Testra I used the 32-bit UR/Forth, and the bug was still there. Ray Duncan had said that I was the only one who had run into the bug, but at Testra I found that they knew about the bug too, and had also already fixed it. When LMI went out of business, Testra obtained the source-code for UR/Forth, and they are likely the only people in the world today with the source-code and still using UR/Forth. I'm not a big fan of UR/Forth. It was far superior to PolyForth though --- the problem with 16-bit PolyForth was that it put everything (compiler, dictionary, user code, user data, etc.) in a single 64K segment. It was obviously just a port to the 8086 from an old processor (most likely the PDP-11) that was limited to 64K total --- and nobody at Forth Inc. knew how the segment registers worked on the 8086, so they missed out on the big memory of the 8086 (which is the only good feature that the 8086 has). There is no way that I would have gotten my cross-compiles to work under PolyForth due to PolyForth's memory problem, so I'm glad that UR/Forth existed --- the flaws in UR/Forth were minor and could easily be worked around.
[toc] | [prev] | [next] | [standalone]
Page 1 of 6 [1] 2 3 4 5 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web