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 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-08-26 05:20 -0700 |
| Message-ID | <451528b2-cfcf-405d-9245-617d846bcc28@googlegroups.com> |
| In reply to | #33072 |
On Tuesday, 26 August 2014 12:58:06 UTC+1, Albert van der Horst wrote: > You're right that my underlying (FIND) is special in that it observes > the PREFIX flag, but indeed it does so always, not only for the ONLY wordlist. > > So a user can define his own prefixes, e.g. using 0x to recognize > hex numbers like 0x1AC0 only in a context of his choosing. > Very cool. I'm going to have to consider this for my own system.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-08-26 12:30 +0000 |
| Message-ID | <2014Aug26.143042@mips.complang.tuwien.ac.at> |
| In reply to | #33058 |
Mark Wills <markwills1970@gmail.com> writes:
>On Monday, 25 August 2014 16:59:21 UTC+1, Albert van der Horst wrote:
>> I gravitate towards
>> "APE"
>> instead of
>> S" APE"
>
>Interested in your opinion on how you would implement that
>inside the compiler.
>
>I presume that after determining that "APE" is not a dictionary
>entry, and not a valid number, a third check is made to see if it
>it's a valid string (i.e. begins and ends with a " character)?
In the development version of Gforth, there is a recognizer stack, and
one of the recognizers in that stack is a recognizer for strings of
this form. In contrast to the prefix-only approach of Albert van der
Horst, a recognizer can accept (or reject) arbitrary
white-space-delimited things; e.g., the dot-parser that has been
discussed now and then (for recognizing <word1>.<word2>.<word3>
thingies) could be implemented as recognizer. Disadvantage: with a
lot of recognizers, this approach is slower.
>The only potential issue that I see is that it's no longer
>possible to have words in the dictionary that are surrounded by
>quotation marks, surely a very very rare occurrence.
It is, because the dictionary is search first (as for numbers);
however, it would be confusing and therefore should be avoided.
- 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 | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2014-08-25 14:15 +0000 |
| Message-ID | <53fb3736.195424542@news.demon.co.uk> |
| In reply to | #33026 |
On Sun, 24 Aug 2014 03:51:25 -0500, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >Bernd Paysan <bernd.paysan@gmx.de> wrote: >Eh? [COMPILE] is to be applied to immediate words; don't apply it to >non-immediate words. > >> 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. > >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 problems lie in the divergence of common understanding and the ANS wording. I have been saying for a year or two that the Forth200x description of compilation (inherited from ANS) is a mess that I do not understand. 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. 3.4.3.3 Compilation semantics Unless otherwise specified in a “Compilation:” section of the glossary entry, the compilation semantics of a Forth definition shall be to append its execution semantics to the execution semantics of the current definition. 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 ... Would we actually lose anything by making [COMPILE] obsolete in a future standard? 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 | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-08-25 07:44 -0700 |
| Message-ID | <3784f192-0407-41b0-bdde-2f52990d5e72@googlegroups.com> |
| In reply to | #33040 |
On Monday, 25 August 2014 15:15:41 UTC+1, Stephen Pelc wrote: > > Would we actually lose anything by making [COMPILE] obsolete in > a future standard? That seems to be the crux of it, and would be worthy of further debate IMHO. Mark
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-08-25 14:37 +0000 |
| Message-ID | <2014Aug25.163732@mips.complang.tuwien.ac.at> |
| In reply to | #33040 |
stephenXXX@mpeforth.com (Stephen Pelc) writes:
>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.
>
>3.4.3.3 Compilation semantics
>Unless otherwise specified in a “Compilation:” section of the glossary
>entry, the compilation semantics of a Forth definition shall be to
>append its execution semantics to the execution semantics of the
>current definition.
>
>In practice, the only way of marking a word as having "non-default
>compilation semantics" is with IMMEDIATE.
That's the only way a standard program can use, yes.
> There are very, very few
>standard words that must be immediate.
Yes, I think that ( \ [IF] [ELSE] [THEN] are the only ones.
However, there is a significantly larger number of standard words that
have non-default compilation semantics, e.g., IF. These words are
"otherwise specificed in a 'Compilation:' section of the glossary
entry".
> 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".
Your implementation may need such a way, but why do you want it to be
standard?
>Would we actually lose anything by making [COMPILE] obsolete in
>a future standard?
I don't think so.
- 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 | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2014-08-25 15:14 +0000 |
| Message-ID | <53fb512c.202070107@news.demon.co.uk> |
| In reply to | #33042 |
On Mon, 25 Aug 2014 14:37:32 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >> 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". > >Your implementation may need such a way, but why do you want it to be >standard? Without it, [COMPILE] is mostly useless. Another reason for removing [COMPILE] from the standard. 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-08-25 15:33 +0000 |
| Message-ID | <2014Aug25.173320@mips.complang.tuwien.ac.at> |
| In reply to | #33043 |
stephenXXX@mpeforth.com (Stephen Pelc) writes:
>On Mon, 25 Aug 2014 14:37:32 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>> 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".
>>
>>Your implementation may need such a way, but why do you want it to be
>>standard?
>
>Without it, [COMPILE] is mostly useless.
[COMPILE] is not particularly useful anyway, because you can replace
it with either POSTPONE or nothing (and you know which one exactly
from the standard). I don't see how a 'standard way to indicate to a
compiler that a word has "non-default compilation semantics"' makes
[COMPILE] any more useful. Can you give an example?
- 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 | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-08-26 01:56 -0700 |
| Message-ID | <aa05a983-a145-40e0-8234-3ef8d30e7bd0@googlegroups.com> |
| In reply to | #33042 |
On Monday, 25 August 2014 15:37:32 UTC+1, Anton Ertl wrote:
> However, there is a significantly larger number of standard words that
> have non-default compilation semantics, e.g., IF. These words are
> "otherwise specificed in a 'Compilation:' section of the glossary
> entry".
We go around in circles on this every six months :-)
With regards to ticking and compiling these special words, it's
quite simple. Do not put the guts of state-smart words inside of
state-smart words. Put them outside.
Instead of:
: S"
STATE @ IF
\ compiling behaviour code
ELSE
\ not compiling behaviour
THEN ; IMMEDIATE
Just have:
: S"
STATE @ IF
(COMPILE-S")
ELSE
(DO-S")
THEN ; IMMEDIATE
Now the programmer can access the "guts" of the words *as
appropriate*. Neither words are immediate words. Only S" is
immediate, which is just the wrapper. Nothing more than a macro,
really.
The standard could help by identifying the potentially hazardous
words such as S" TO and friends, and *mandating* (go on, you can
do it!) that a *standard* program may *not* tick these words.
Documentation for each system can document the names of the guts
of these hazardous words.
Really, I think that that is all you need to do. Rather than
invent potentially complex implementations, and introduce new
concepts (i.e. specifying a 'family' of words that have
non-default compiliation semantics) just simplify. Document
(in the standard) that words such as TO etc are to be considered
macros, included for convenience and should not be compiled
directly into definitions.
Then, the system, as is, can work for everybody. If people
subsequently complain that compiler x and compiler y do different
things when they compile or postpone TO then so what? They are
outside the boundaries of the standard at that point, and all
bets are off.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-08-26 04:16 -0500 |
| Message-ID | <Q6udnWzs0uwazWHOnZ2dnUU7-K-dnZ2d@supernews.com> |
| In reply to | #33060 |
Mark Wills <markwills1970@gmail.com> wrote: > > The standard could help by identifying the potentially hazardous > words such as S" TO and friends, and *mandating* (go on, you can > do it!) that a *standard* program may *not* tick these words. I really don't think that's a good idea. Forth is an extensible language in which it's possible to write interpreters using the system's own tools. This entitlement extends to the Forth interpreter itself. Whenever Forth departs from this fairly basic principle in the name of cleverness or efficiencey or whatever, things go wrong. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-08-26 02:24 -0700 |
| Message-ID | <a6aad434-a4ba-427b-a2c8-5fb3477bad91@googlegroups.com> |
| In reply to | #33063 |
On Tuesday, 26 August 2014 10:16:55 UTC+1, Andrew Haley wrote: > I really don't think that's a good idea. Forth is an extensible > language in which it's possible to write interpreters using the > system's own tools. This entitlement extends to the Forth interpreter > itself. Whenever Forth departs from this fairly basic principle in > the name of cleverness or efficiencey or whatever, things go wrong. > > Andrew. Good point. In that case, the documentation of a particular system could document any 'gotchas' with respect to compiling certain words (for example state-smart) words, and advise how to get at the guts of "macro" (my nomenclature, there may be a better term) words in order to compile the appropriate behaviour. I don't feel that the standard needs to be changed in order to solve this problem; rather it feels to me that some systems need to be changed in order to fully comply with the standard. I still think however that Stephen's suggestion (re removing [COMPILE]) is a good suggestion. If macro words are implemented 'properly' i.e. in such a way that one can access the guts of the words, then all one needs is POSTPONE.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-08-26 09:36 +0000 |
| Message-ID | <53fc5503$0$15832$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #33063 |
In article <Q6udnWzs0uwazWHOnZ2dnUU7-K-dnZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >Mark Wills <markwills1970@gmail.com> wrote: >> >> The standard could help by identifying the potentially hazardous >> words such as S" TO and friends, and *mandating* (go on, you can >> do it!) that a *standard* program may *not* tick these words. > >I really don't think that's a good idea. Forth is an extensible >language in which it's possible to write interpreters using the >system's own tools. This entitlement extends to the Forth interpreter >itself. Whenever Forth departs from this fairly basic principle in >the name of cleverness or efficiencey or whatever, things go wrong. Of course a standard doesn't dictate me what to do. It just tells me what I can do to enhance the chance that my program runs on another system. The standard indeed says that TO not be ticked AFAIR. That is sensible because ticking TO leads to non-portable programs. > >Andrew. -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-08-26 13:40 +0000 |
| Message-ID | <2014Aug26.154045@mips.complang.tuwien.ac.at> |
| In reply to | #33063 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Mark Wills <markwills1970@gmail.com> wrote:
>>
>> The standard could help by identifying the potentially hazardous
>> words such as S" TO and friends, and *mandating* (go on, you can
>> do it!) that a *standard* program may *not* tick these words.
>
>I really don't think that's a good idea. Forth is an extensible
>language in which it's possible to write interpreters using the
>system's own tools.
But the tools for writing an interpreter are not ' and POSTPONE, but
FIND, EXECUTE and COMPILE,.
Anyway, destandardizing ' S" will not prevent people from writing new
STATE-smart words (and without heeding the guidelines Mark Wills
posted here). Destandardizing STATE may be more fruitful.
- 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 08:57 -0500 |
| Message-ID | <wcidnTNiEtX6D2HOnZ2dnUU7-L2dnZ2d@supernews.com> |
| In reply to | #33082 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > > Destandardizing STATE may be more fruitful. I could not agree more. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-08-26 12:52 +0000 |
| Message-ID | <2014Aug26.145240@mips.complang.tuwien.ac.at> |
| In reply to | #33060 |
Mark Wills <markwills1970@gmail.com> writes:
>On Monday, 25 August 2014 15:37:32 UTC+1, Anton Ertl wrote:
>> However, there is a significantly larger number of standard words that
>> have non-default compilation semantics, e.g., IF. These words are
>> "otherwise specificed in a 'Compilation:' section of the glossary
>> entry".
>
>We go around in circles on this every six months :-)
>
>With regards to ticking and compiling these special words, it's
>quite simple. Do not put the guts of state-smart words inside of
>state-smart words. Put them outside.
>
>Instead of:
>
>: S"
> STATE @ IF
> \ compiling behaviour code
> ELSE
> \ not compiling behaviour
> THEN ; IMMEDIATE
>
>Just have:
>
>: S"
> STATE @ IF
> (COMPILE-S")
> ELSE
> (DO-S")
> THEN ; IMMEDIATE
>
>Now the programmer can access the "guts" of the words *as
>appropriate*. Neither words are immediate words. Only S" is
>immediate, which is just the wrapper. Nothing more than a macro,
>really.
>
>The standard could help by identifying the potentially hazardous
>words such as S" TO and friends, and *mandating* (go on, you can
>do it!) that a *standard* program may *not* tick these words.
>
>Documentation for each system can document the names of the guts
>of these hazardous words.
>
>Really, I think that that is all you need to do. Rather than
>invent potentially complex implementations, and introduce new
>concepts (i.e. specifying a 'family' of words that have
>non-default compiliation semantics) just simplify. Document
>(in the standard) that words such as TO etc are to be considered
>macros, included for convenience and should not be compiled
>directly into definitions.
That's certainly a sane approach towards STATE-smartness. But will
people keep to these guidelines? They have not done so in the past
(not even in the standard; we are not given (COMPILE-S") and (DO-S")),
so I doubt they will in the future.
So what we need is a clean alternative for doing what they want to do
with STATE-smart words.
Arbitrary combinations of interpretation and compilation semantics
appeared to be a solution, but the long-term effects seem to b a
disease in some system implementors that makes them (want to) break
COMPILE,. So maybe we should stay away from that after all.
What people want to do with STATE-smart words most of the time is
parsing words that parse at parse time (not at run-time like '). So
the next alternative is to extend the Forth parser itself with these
capabilities, through (user-defined) recognizers. Let's see how that
plays 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 | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2014-08-26 14:14 +0000 |
| Message-ID | <53fc93b7.284641655@news.demon.co.uk> |
| In reply to | #33077 |
On Tue, 26 Aug 2014 12:52:40 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >Arbitrary combinations of interpretation and compilation semantics >appeared to be a solution, but the long-term effects seem to b a >disease in some system implementors that makes them (want to) break >COMPILE,. So maybe we should stay away from that after all. IMHO you are missing the point that the standard is a servant of Forth's implementers and users. Forth is a language of simplicity. A Forth standard that forces us to increase complexity has something wrong with it. Where the standard increases complexity, either conceptually or of implementations, we should change the standard and not Forth. I'll be happy to remove [COMPILE] as a standard word, but we have to have the discussion about what we want compilation and interpretation to mean before proposing to add or remove words. I have been involved with the standards process since the 1990s as far as I remember. Phrases like "non-default compilation semantics" are a linguistic sign that something is seriously wrong. >What people want to do with STATE-smart words most of the time is >parsing words that parse at parse time (not at run-time like '). So >the next alternative is to extend the Forth parser itself with these >capabilities, through (user-defined) recognizers. Let's see how that >plays out. Recognisers are an implementation technique, not a language prescription. We need to define the problem before defining a solution. 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-08-26 14:36 +0000 |
| Message-ID | <2014Aug26.163611@mips.complang.tuwien.ac.at> |
| In reply to | #33085 |
stephenXXX@mpeforth.com (Stephen Pelc) writes:
>On Tue, 26 Aug 2014 12:52:40 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>Arbitrary combinations of interpretation and compilation semantics
>>appeared to be a solution, but the long-term effects seem to b a
>>disease in some system implementors that makes them (want to) break
>>COMPILE,. So maybe we should stay away from that after all.
>
>IMHO you are missing the point that the standard is a servant of
>Forth's implementers and users. Forth is a language of simplicity.
>A Forth standard that forces us to increase complexity has something
>wrong with it.
>
>Where the standard increases complexity, either conceptually or of
>implementations, we should change the standard and not Forth.
That could mean anything at all. What's your point? Should we all
switch to ColorForth?
>Phrases like "non-default compilation
>semantics" are a linguistic sign that something is seriously
>wrong.
Sounds like the hyphen theory to me ("hypenated Forth words are
evil" or somesuch).
I prefer to discuss concrete problems or concrete proposals rather
than linguistic signs.
>>What people want to do with STATE-smart words most of the time is
>>parsing words that parse at parse time (not at run-time like '). So
>>the next alternative is to extend the Forth parser itself with these
>>capabilities, through (user-defined) recognizers. Let's see how that
>>plays out.
>
>Recognisers are an implementation technique, not a language
>prescription.
I don't know what you mean with "language prescription", but
recognizers are a language feature. They are not primarily an
implementation technique for an existing feature.
>We need to define the problem before defining a
>solution.
The problem has been described above: Find a clean way or a
replacement for words that want to parse at parse time (e.g., S", TO).
Recognizers would be a replacement.
- 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:40 +0200 |
| Message-ID | <lvs48q$8lj$2@online.de> |
| In reply to | #33086 |
Anton Ertl wrote: >>Where the standard increases complexity, either conceptually or of >>implementations, we should change the standard and not Forth. > > That could mean anything at all. What's your point? Should we all > switch to ColorForth? You are pulling a straw man. The way the standard is changed is by rough consensus, so when there's rough consensus to go to ColorForth, then yes, indeed, we'll go to ColorForth. I don't see this consensus, but I can see that a rough consensus to remove words like [COMPILE] and change the spec of words like COMPILE, is possible. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-08-26 10:53 -0500 |
| Message-ID | <APmdnddtCqDCMGHOnZ2dnUVZ8hydnZ2d@supernews.com> |
| In reply to | #33085 |
Stephen Pelc <stephenXXX@mpeforth.com> wrote: > On Tue, 26 Aug 2014 12:52:40 GMT, anton@mips.complang.tuwien.ac.at > (Anton Ertl) wrote: > >>Arbitrary combinations of interpretation and compilation semantics >>appeared to be a solution, but the long-term effects seem to b a >>disease in some system implementors that makes them (want to) break >>COMPILE,. So maybe we should stay away from that after all. > > IMHO you are missing the point that the standard is a servant of > Forth's implementers and users. Forth is a language of simplicity. > A Forth standard that forces us to increase complexity has something > wrong with it. > > Where the standard increases complexity, either conceptually or of > implementations, we should change the standard and not Forth. That's right. > I'll be happy to remove [COMPILE] as a standard word, but we have > to have the discussion about what we want compilation and > interpretation to mean before proposing to add or remove words. > I have been involved with the standards process since the 1990s > as far as I remember. Phrases like "non-default compilation > semantics" are a linguistic sign that something is seriously > wrong. Indeed they are. Something has gone horribly wrong, and most of the proposals for fixing things have been adding more complexity. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-09-23 17:36 +0200 |
| Message-ID | <lvs42o$8lj$1@online.de> |
| In reply to | #33085 |
Stephen Pelc wrote: > On Tue, 26 Aug 2014 12:52:40 GMT, anton@mips.complang.tuwien.ac.at > (Anton Ertl) wrote: > >>Arbitrary combinations of interpretation and compilation semantics >>appeared to be a solution, but the long-term effects seem to b a >>disease in some system implementors that makes them (want to) break >>COMPILE,. So maybe we should stay away from that after all. > > IMHO you are missing the point that the standard is a servant of > Forth's implementers and users. Forth is a language of simplicity. > A Forth standard that forces us to increase complexity has something > wrong with it. I think the point he misses is that the spec of COMPILE, wasn't meant to be what is written in the standard. We have been turning around this for three years now, and Anton doesn't believe that the spec of COMPILE, was written by a human (Mitch Bradley), and did not come from the mouth of God himself. COMPILE, simply is there to perform the compilation semantics of non- immediate words. This is a direct consequence of the interpreter loop Mitch Bradley has stated as original intention why to add COMPILE, - it was the missing piece. Like the standard wording for [COMPILE], COMPILE, then got specified with a traditional Forth system in mind, and therefore, having a non-traditional Forth system like VFX "breaks" both [COMPILE] and COMPILE, . The reason is that the standard is actually misspecifying these two words. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-08-25 12:02 -0500 |
| Message-ID | <dZCdnUcd6L628WbOnZ2dnUU7-aednZ2d@supernews.com> |
| In reply to | #33040 |
Stephen Pelc <stephenXXX@mpeforth.com> wrote: > > The problems lie in the divergence of common understanding and the > ANS wording. I have been saying for a year or two that the Forth200x > description of compilation (inherited from ANS) is a mess that I do > not understand. OK, I agree with that. > 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. > > 3.4.3.3 Compilation semantics > Unless otherwise specified in a ?Compilation:? section of the > glossary entry, the compilation semantics of a Forth definition > shall be to append its execution semantics to the execution > semantics of the current definition. > > 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. Andrew.
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web