Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #20052 > unrolled thread
| Started by | Rob Sciuk <rob@controlq.com> |
|---|---|
| First post | 2013-02-26 17:03 -0500 |
| Last post | 2013-02-27 13:10 -1000 |
| Articles | 20 on this page of 115 — 20 participants |
Back to article view | Back to comp.lang.forth
MiniForth 0.1.18 has just been released ... Rob Sciuk <rob@controlq.com> - 2013-02-26 17:03 -0500
Re: MiniForth 0.1.18 has just been released ... "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-27 04:06 -0500
Re: MiniForth 0.1.18 has just been released ... Richard Owlett <rowlett@pcnetinc.com> - 2013-02-27 05:30 -0600
Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-27 06:34 -0600
Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-27 14:42 +0000
Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-27 11:54 -0600
Re: MiniForth 0.1.18 has just been released ... Rob Sciuk <rob@controlq.com> - 2013-02-27 15:27 -0500
Re: MiniForth 0.1.18 has just been released ... Coos Haak <chforth@hccnet.nl> - 2013-02-27 21:58 +0100
Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-27 16:33 -0600
Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-02 17:23 +0000
Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-02 15:12 -0600
Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-03 14:30 +0000
Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-03 14:49 -0600
Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-07 16:58 +0000
Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-07 16:35 -0600
Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-08 17:29 +0000
Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-08 12:17 -0600
Re: MiniForth 0.1.18 has just been released ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-28 00:17 +0100
Re: MiniForth 0.1.18 has just been released ... Paul Rubin <no.email@nospam.invalid> - 2013-02-28 01:04 -0800
Re: MiniForth 0.1.18 has just been released ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-28 17:10 +0100
Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-28 11:20 -0600
Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-02 16:54 +0000
Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-02 15:38 -0600
Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-03 14:43 +0000
Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-03 15:05 -0600
Re: MiniForth 0.1.18 has just been released ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-03 23:14 +0100
Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-04 03:41 -0600
Re: MiniForth 0.1.18 has just been released ... Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-03-04 11:00 +0000
Re: MiniForth 0.1.18 has just been released ... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-04 12:47 +0000
Re: MiniForth 0.1.18 has just been released ... Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-03-04 16:27 +0000
Re: MiniForth 0.1.18 has just been released ... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-04 19:27 +0000
Re: MiniForth 0.1.18 has just been released ... Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-03-04 20:46 +0000
Re: MiniForth 0.1.18 has just been released ... Alex McDonald <blog@rivadpm.com> - 2013-03-05 00:19 -0800
Re: MiniForth 0.1.18 has just been released ... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-05 12:17 +0000
Re: MiniForth 0.1.18 has just been released ... Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-03-05 17:22 +0000
Re: MiniForth 0.1.18 has just been released ... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-05 17:52 +0000
Re: MiniForth 0.1.18 has just been released ... Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-03-05 17:03 +0000
Re: MiniForth 0.1.18 has just been released ... Rob Sciuk <rob@controlq.com> - 2013-03-05 12:38 -0500
Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-05 17:57 +0000
Re: MiniForth 0.1.18 has just been released ... Rob Sciuk <rob@controlq.com> - 2013-03-05 13:29 -0500
Re: MiniForth 0.1.18 has just been released ... Andy Valencia <user@vsta.org> - 2013-03-05 22:19 +0000
Re: MiniForth 0.1.18 has just been released ... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-05 17:58 +0000
Re: MiniForth 0.1.18 has just been released ... Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-03-05 19:26 +0000
Re: MiniForth 0.1.18 has just been released ... Alex McDonald <blog@rivadpm.com> - 2013-03-05 11:19 -0800
Forth convergence with rest of world Andy Valencia <user@vsta.org> - 2013-03-05 22:17 +0000
Re: Forth convergence with rest of world Alex McDonald <blog@rivadpm.com> - 2013-03-05 15:15 -0800
Re: Forth convergence with rest of world Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-06 17:35 +0100
Re: Forth convergence with rest of world albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-06 16:44 +0000
Re: Forth convergence with rest of world Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-06 17:39 +0000
Re: Forth convergence with rest of world Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-05 18:16 -0600
Re: Forth convergence with rest of world Rob Sciuk <rob@controlq.com> - 2013-03-06 13:49 -0500
Re: Forth convergence with rest of world Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-06 19:11 +0000
Re: Forth convergence with rest of world Rob Sciuk <rob@controlq.com> - 2013-03-06 14:24 -0500
Re: Forth convergence with rest of world Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-06 19:40 +0000
Re: Forth convergence with rest of world "Elizabeth D. Rather" <erather@forth.com> - 2013-03-06 09:26 -1000
Re: Forth convergence with rest of world "Elizabeth D. Rather" <erather@forth.com> - 2013-03-06 09:26 -1000
Re: Forth convergence with rest of world Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-06 15:34 -0600
Re: Forth convergence with rest of world Andy Valencia <user@vsta.org> - 2013-03-06 22:04 +0000
Re: Forth convergence with rest of world "Elizabeth D. Rather" <erather@forth.com> - 2013-03-06 12:09 -1000
Re: Forth convergence with rest of world Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-07 04:24 -0600
Re: Forth convergence with rest of world Alex McDonald <blog@rivadpm.com> - 2013-03-07 04:15 -0800
Re: Forth convergence with rest of world Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-07 08:42 -0600
Re: Forth convergence with rest of world Alex McDonald <blog@rivadpm.com> - 2013-03-07 13:50 -0800
Re: Forth convergence with rest of world Rob Sciuk <rob@controlq.com> - 2013-03-07 12:12 -0500
Re: Forth convergence with rest of world Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-07 18:36 +0000
Re: Forth convergence with rest of world Rob Sciuk <rob@controlq.com> - 2013-03-07 14:07 -0500
Re: Forth convergence with rest of world Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-07 19:43 +0000
Re: Forth convergence with rest of world anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-08 17:27 +0000
Re: Forth convergence with rest of world "Elizabeth D. Rather" <erather@forth.com> - 2013-03-07 08:47 -1000
Re: Forth convergence with rest of world awegel@arcor.de (Alex Wegel) - 2013-03-07 21:42 +0100
Re: Forth convergence with rest of world Alex McDonald <blog@rivadpm.com> - 2013-03-07 14:43 -0800
Re: Forth convergence with rest of world "Elizabeth D. Rather" <erather@forth.com> - 2013-03-07 13:53 -1000
Re: Forth convergence with rest of world stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-07 12:38 +0000
Re: Forth convergence with rest of world Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-07 08:43 -0600
Re: Forth convergence with rest of world Syd Rumpo <usenet@nononono.co.uk> - 2013-03-08 18:04 +0000
Re: Forth convergence with rest of world Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-08 12:18 -0600
Re: Forth convergence with rest of world Syd Rumpo <usenet@nononono.co.uk> - 2013-03-08 18:36 +0000
Re: Forth convergence with rest of world "Elizabeth D. Rather" <erather@forth.com> - 2013-03-08 14:30 -1000
Re: Forth convergence with rest of world Syd Rumpo <usenet@nononono.co.uk> - 2013-03-09 01:27 +0000
Re: Forth convergence with rest of world Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-09 02:43 -0600
Re: MiniForth 0.1.18 has just been released ... Mark Wills <markrobertwills@yahoo.co.uk> - 2013-03-05 01:19 -0800
Re: MiniForth 0.1.18 has just been released ... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-05 12:01 +0000
Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-08 17:02 +0000
Re: MiniForth 0.1.18 has just been released ... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-04 12:45 +0000
Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-04 11:58 -0600
Re: MiniForth 0.1.18 has just been released ... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-04 19:34 +0000
Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-04 15:15 -0600
Re: MiniForth 0.1.18 has just been released ... Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2013-03-04 23:31 +0100
Re: MiniForth 0.1.18 has just been released ... Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-03-05 17:07 +0000
Re: MiniForth 0.1.18 has just been released ... Rob Sciuk <rob@controlq.com> - 2013-03-05 12:11 -0500
Re: MiniForth 0.1.18 has just been released ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-05 00:32 +0100
Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-07 17:00 +0000
Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-07 16:52 -0600
Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-08 17:32 +0000
Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-08 12:25 -0600
Re: MiniForth 0.1.18 has just been released ... Brad Eckert <hwfwguy@gmail.com> - 2013-03-11 09:57 -0700
Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-11 12:05 -0500
Re: MiniForth 0.1.18 has just been released ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-11 17:20 +0000
Re: MiniForth 0.1.18 has just been released ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-11 14:05 -0500
Re: MiniForth 0.1.18 has just been released ... Alex McDonald <blog@rivadpm.com> - 2013-03-11 14:35 -0700
Re: MiniForth 0.1.18 has just been released ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-12 00:21 +0100
Re: MiniForth 0.1.18 has just been released ... stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-12 12:13 +0000
Re: MiniForth 0.1.18 has just been released ... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-11 19:16 +0000
Re: MiniForth 0.1.18 has just been released ... Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-11 19:29 +0000
Re: MiniForth 0.1.18 has just been released ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-11 21:36 +0100
Re: MiniForth 0.1.18 has just been released ... Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-11 20:52 +0000
Re: MiniForth 0.1.18 has just been released ... Alex McDonald <blog@rivadpm.com> - 2013-03-11 14:39 -0700
Re: MiniForth 0.1.18 has just been released ... Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-11 21:52 +0000
Re: MiniForth 0.1.18 has just been released ... Coos Haak <chforth@hccnet.nl> - 2013-03-12 01:11 +0100
Re: MiniForth 0.1.18 has just been released ... Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-03-12 00:41 +0000
Re: MiniForth 0.1.18 has just been released ... Coos Haak <chforth@hccnet.nl> - 2013-03-12 17:33 +0100
Re: MiniForth 0.1.18 has just been released ... Rob Sciuk <rob@controlq.com> - 2013-02-27 11:51 -0500
Re: MiniForth 0.1.18 has just been released ... "Elizabeth D. Rather" <erather@forth.com> - 2013-02-27 09:25 -1000
Re: MiniForth 0.1.18 has just been released ... Rob Sciuk <rob@controlq.com> - 2013-02-27 17:23 -0500
Re: MiniForth 0.1.18 has just been released ... "Elizabeth D. Rather" <erather@forth.com> - 2013-02-27 13:10 -1000
Page 1 of 6 [1] 2 3 4 5 6 Next page →
| From | Rob Sciuk <rob@controlq.com> |
|---|---|
| Date | 2013-02-26 17:03 -0500 |
| Subject | MiniForth 0.1.18 has just been released ... |
| Message-ID | <alpine.BSF.2.00.1302261641340.449@yoko.controlq.com> |
With apologies to Bernd, I am in no way attempting to out-do or upstage the incredible gforth interpreter, I have just revised the MiniForth.c revision to 0.1.18. Owing to a long ago promised user request, I have made " and ." both immediate and state smart, so that the " and ." will work as expected either interactively or in a colon word as follows: bash-3.2$ mforth -- MiniForth-Hosted alpha Version: 00.01.18D -- www.ControlQ.com ok : x " hi mom" type cr ; ok ' x see -- x (629940) word flg: 0. 609940 (literal) = 6461743 609950 type 609958 cr 609960 next ok x hi mom ok : z ." print me" cr ; ok ' z see -- z (629960) word flg: 0. 609968 (literal) = 6461732 609978 type 609980 cr 609988 next ok z print me ok This follows the MiniForth convention of caching strings (both nfa's and user strings) in a heap at the far end of the dictionary space. This means that the original string storage (save) semantics are preserved, and the following constructs will continue to work unchanged: (It also assists with alignment issues in the dictionary, as it eliminates the requirement to pad strings to a word address on those architectures which require strict alignment rules (for portability)). ok " mystring" save constant xyzzy ok xyzzy type cr mystring ok ." print this out" cr print this out ok No other changes were made since the 0.1.17 revision, and the link is unchanged: http://www.ControlQ.com/OpenSource/MiniForth.c
[toc] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnotz.cnm> |
|---|---|
| Date | 2013-02-27 04:06 -0500 |
| Message-ID | <kgki6a$nq2$1@speranza.aioe.org> |
| In reply to | #20052 |
"Rob Sciuk" <rob@controlq.com> wrote in message news:alpine.BSF.2.00.1302261641340.449@yoko.controlq.com... > > Owing to a long ago promised user request, I have made " and ." > both immediate and state smart, so that the " and ." will work > as expected either interactively or in a colon word as follows: > I'm waiting on Ms. Rather to reply that you shouldn't do that, i.e., state smart words. She's been telling me that for the past three years now. Are you paying attention? RP
[toc] | [prev] | [next] | [standalone]
| From | Richard Owlett <rowlett@pcnetinc.com> |
|---|---|
| Date | 2013-02-27 05:30 -0600 |
| Message-ID | <AZCdnayHrqP9c7DMnZ2dnUVZ_smdnZ2d@supernews.com> |
| In reply to | #20054 |
Rod Pemberton wrote: > "Rob Sciuk" <rob@controlq.com> wrote in message > news:alpine.BSF.2.00.1302261641340.449@yoko.controlq.com... >> >> Owing to a long ago promised user request, I have made " and ." >> both immediate and state smart, so that the " and ." will work >> as expected either interactively or in a colon word as follows: >> > > I'm waiting on Ms. Rather to reply that you shouldn't do that, > i.e., state smart words. She's been telling me that for the past > three years now. Are you paying attention? > I don't recall Ms. Rather's comments on state smart words or the context of the discussion. However, I suspect that her emphasis would have been on the line of arguing against designing state smartness in as a feature of a Forth implementation, not against adding state smart words to an implementation that already had state smart words.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-02-27 06:34 -0600 |
| Message-ID | <ld2dnSjumPbvYLDMnZ2dnUVZ_rudnZ2d@supernews.com> |
| In reply to | #20056 |
Richard Owlett <rowlett@pcnetinc.com> wrote: > Rod Pemberton wrote: >> "Rob Sciuk" <rob@controlq.com> wrote in message >> news:alpine.BSF.2.00.1302261641340.449@yoko.controlq.com... >>> >>> Owing to a long ago promised user request, I have made " and ." >>> both immediate and state smart, so that the " and ." will work >>> as expected either interactively or in a colon word as follows: >>> >> >> I'm waiting on Ms. Rather to reply that you shouldn't do that, >> i.e., state smart words. She's been telling me that for the past >> three years now. Are you paying attention? > > I don't recall Ms. Rather's comments on state smart words or the > context of the discussion. However, I suspect that her emphasis > would have been on the line of arguing against designing state > smartness in as a feature of a Forth implementation, not against > adding state smart words to an implementation that already had state > smart words. I don't think so. State-smartness is a something we're stuck with because of a few standard words, but that doesn't justify making ." state-smart when the standard specifies ." and .( . Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2013-02-27 14:42 +0000 |
| Message-ID | <2013Feb27.154239@mips.complang.tuwien.ac.at> |
| In reply to | #20057 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>I don't think so. State-smartness is a something we're stuck with
>because of a few standard words
There is no standard word that is specified as state-smart, so no, we
are not stuck with it.
>but that doesn't justify making ."
>state-smart when the standard specifies ." and .( .
It seems that people really like being able to cut code from a colon
definition and paste it into the interpreter, and they write
STATE-smart words to get this effect. STATE-smart cause problems when
they are ticked or POSTPONEd, but that's beyond the horizon.
We have had the ' ['] and ." .( solution for many years, and people
still implement STATE-smart words, despite their problems and people
like me doing a lot to inform people of these problems. So maybe we
should provide an alternative, less problematic solution instead of
trying to get people to use the ." ."( approach.
Recognizers may be this solution. E.g., if you have a recognizer for
strings, you could write
"hello" type
and that would work inside a colon def and outside, instead of
." hello"
or
.( hello)
Or, if that's too much typing, you could also define a recognizer for
."hello"
The problems go away because you cannot ' or POSTPONE ."hello". And
if you write
]] ."hello" [[
it does the right thing, i.e., the equivalent of
"hello" POSTPONE 2literal POSTPONE type
- 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 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-02-27 11:54 -0600 |
| Message-ID | <YuSdnXJ4Xv7y1bPMnZ2dnUVZ_umdnZ2d@supernews.com> |
| In reply to | #20061 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>I don't think so. State-smartness is a something we're stuck with >>because of a few standard words > > There is no standard word that is specified as state-smart, so no, we > are not stuck with it. I think we are. As you may be aware, I do not accept your definition of "state-smart" as meaning only words that use the variable STATE. As far as I am concerned, state-smart words are those with non-default compilation semantics and different compilation and interpretation semantics. The problem with such words is not how state-smartness is achieved, it is those different semantics. It is this property that leads to obscure bugs. That is what we are stuck with. >>but that doesn't justify making ." state-smart when the standard >>specifies ." and .( . > > It seems that people really like being able to cut code from a colon > definition and paste it into the interpreter, and they write > STATE-smart words to get this effect. STATE-smart cause problems when > they are ticked or POSTPONEd, but that's beyond the horizon. > > We have had the ' ['] and ." .( solution for many years, and people > still implement STATE-smart words, despite their problems and people > like me doing a lot to inform people of these problems. So maybe we > should provide an alternative, less problematic solution instead of > trying to get people to use the ." ."( approach. But that would just result in even more obscure horrors. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Rob Sciuk <rob@controlq.com> |
|---|---|
| Date | 2013-02-27 15:27 -0500 |
| Message-ID | <alpine.BSF.2.00.1302271524070.54509@yoko.controlq.com> |
| In reply to | #20068 |
On Wed, 27 Feb 2013, Andrew Haley wrote: > I think we are. As you may be aware, I do not accept your definition > of "state-smart" as meaning only words that use the variable STATE. > As far as I am concerned, state-smart words are those with non-default > compilation semantics and different compilation and interpretation > semantics. The problem with such words is not how state-smartness is > achieved, it is those different semantics. It is this property that > leads to obscure bugs. > > That is what we are stuck with. Are you implying that immediate words are also state smart?
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2013-02-27 21:58 +0100 |
| Message-ID | <xqf0zw2ypiwx.9o5c2h0nhosj.dlg@40tude.net> |
| In reply to | #20074 |
Op Wed, 27 Feb 2013 15:27:52 -0500 schreef Rob Sciuk: > On Wed, 27 Feb 2013, Andrew Haley wrote: > >> I think we are. As you may be aware, I do not accept your definition >> of "state-smart" as meaning only words that use the variable STATE. >> As far as I am concerned, state-smart words are those with non-default >> compilation semantics and different compilation and interpretation >> semantics. The problem with such words is not how state-smartness is >> achieved, it is those different semantics. It is this property that >> leads to obscure bugs. >> >> That is what we are stuck with. > > Are you implying that immediate words are also state smart? No. Not as described in the standard. ." is immediate and compiles a string for later displaying. .( is immediate and displays the string regardless of compiling or interpreting. s" in core compiles a string. s" in file compiles a string or puts its address/length on the stack depending on compiling or intepreting. This could be regarded as state smart IMO. -- Coos CHForth, 16 bit DOS applications http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-02-27 16:33 -0600 |
| Message-ID | <DNKdne6-K8QqFLPMnZ2dnUVZ_vSdnZ2d@supernews.com> |
| In reply to | #20074 |
Rob Sciuk <rob@controlq.com> wrote: > On Wed, 27 Feb 2013, Andrew Haley wrote: > >> I think we are. As you may be aware, I do not accept your definition >> of "state-smart" as meaning only words that use the variable STATE. >> As far as I am concerned, state-smart words are those with non-default >> compilation semantics and different compilation and interpretation >> semantics. The problem with such words is not how state-smartness is >> achieved, it is those different semantics. It is this property that >> leads to obscure bugs. >> >> That is what we are stuck with. > > Are you implying that immediate words are also state smart? Not really, no. An immediate word, unless it is state-smart, has identical compilation and interpretation semantics. In hindsight, I wonder if the language of ANS Forth that describes this was a mistake. All this talk about "interpretation semantics", "compilation semantics" and so on introduced new and unfamiliar terms to Forth. Strictly speaking, it may be that S" cannot be implemented as an immediate STATE-smart word; I suspect this was not intended. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2013-03-02 17:23 +0000 |
| Message-ID | <2013Mar2.182334@mips.complang.tuwien.ac.at> |
| In reply to | #20084 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Rob Sciuk <rob@controlq.com> wrote:
>> On Wed, 27 Feb 2013, Andrew Haley wrote:
>>
>>> I think we are. As you may be aware, I do not accept your definition
>>> of "state-smart" as meaning only words that use the variable STATE.
>>> As far as I am concerned, state-smart words are those with non-default
>>> compilation semantics and different compilation and interpretation
>>> semantics. The problem with such words is not how state-smartness is
>>> achieved, it is those different semantics. It is this property that
>>> leads to obscure bugs.
>>>
>>> That is what we are stuck with.
>>
>> Are you implying that immediate words are also state smart?
>
>Not really, no. An immediate word, unless it is state-smart, has
>identical compilation and interpretation semantics.
A STATE-smart word also has identical compilation and interpretation
semantics. These semantics just check STATE at run-time and do
different things depending on STATE at that time.
>In hindsight, I wonder if the language of ANS Forth that describes
>this was a mistake. All this talk about "interpretation semantics",
>"compilation semantics" and so on introduced new and unfamiliar terms
>to Forth.
I think it's pretty good. But maybe it's not good enough.
What language would you use instead?
> Strictly speaking, it may be that S" cannot be implemented
>as an immediate STATE-smart word; I suspect this was not intended.
I see that you are coming around to the more common way of using
"STATE-smart". Good.
Yes, they intended to allow STATE-smart implementations. Could be
fixed by de-standardizing ' S", POSTPONE S" etc.
- 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 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-03-02 15:12 -0600 |
| Message-ID | <X_ednc5OXeHZ9q_MnZ2dnUVZ_qWdnZ2d@supernews.com> |
| In reply to | #20181 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Rob Sciuk <rob@controlq.com> wrote: >>> On Wed, 27 Feb 2013, Andrew Haley wrote: >>> >>>> I think we are. As you may be aware, I do not accept your definition >>>> of "state-smart" as meaning only words that use the variable STATE. >>>> As far as I am concerned, state-smart words are those with non-default >>>> compilation semantics and different compilation and interpretation >>>> semantics. The problem with such words is not how state-smartness is >>>> achieved, it is those different semantics. It is this property that >>>> leads to obscure bugs. >>>> >>>> That is what we are stuck with. >>> >>> Are you implying that immediate words are also state smart? >> >>Not really, no. An immediate word, unless it is state-smart, has >>identical compilation and interpretation semantics. > > A STATE-smart word also has identical compilation and interpretation > semantics. These semantics just check STATE at run-time and do > different things depending on STATE at that time. In which case they're different. "Does different things" is a reasonable operational definition of "has different semantics". >>In hindsight, I wonder if the language of ANS Forth that describes >>this was a mistake. All this talk about "interpretation semantics", >>"compilation semantics" and so on introduced new and unfamiliar terms >>to Forth. > > I think it's pretty good. But maybe it's not good enough. > > What language would you use instead? > >> Strictly speaking, it may be that S" cannot be implemented >> as an immediate STATE-smart word; I suspect this was not intended. > > I see that you are coming around to the more common way of using > "STATE-smart". Good. Not at all. If you can see any way in which I'm being inconsistent or changing my mind, I'm sure you'll be specific when you let me know. > Yes, they intended to allow STATE-smart implementations. Could be > fixed by de-standardizing ' S", POSTPONE S" etc. That would be nice. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2013-03-03 14:30 +0000 |
| Message-ID | <2013Mar3.153002@mips.complang.tuwien.ac.at> |
| In reply to | #20188 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Not really, no. An immediate word, unless it is state-smart, has
>>>identical compilation and interpretation semantics.
>>
>> A STATE-smart word also has identical compilation and interpretation
>> semantics. These semantics just check STATE at run-time and do
>> different things depending on STATE at that time.
>
>In which case they're different. "Does different things" is a
>reasonable operational definition of "has different semantics".
If the run-time of STATE-smart words was inseparable from the time it
was parsed (at which time the text interpreter selects interpretation
semantics or compilation semantics, or ' selects the
execution/interpretation semantics or POSTPONE selects the compilation
semantics), you would have a point. But the STATE at parsing is only
the same as the STATE at run-time if the word is processed by the text
interpreter.
For the other ways of processing the word, the STATE can be anything
at run-time, and actually the STATE at parsing is irrelevant there,
because what matters is which word parses the word.
>>> Strictly speaking, it may be that S" cannot be implemented
>>> as an immediate STATE-smart word; I suspect this was not intended.
>>
>> I see that you are coming around to the more common way of using
>> "STATE-smart". Good.
>
>Not at all. If you can see any way in which I'm being inconsistent or
>changing my mind, I'm sure you'll be specific when you let me know.
In the above, you use "immediate STATE-smart word" for a flawed
implementation technique for combined words, whereas earlier you
claimed
>>>> I do not accept your definition
>>>> of "state-smart" as meaning only words that use the variable STATE.
>>>> As far as I am concerned, state-smart words are those with non-default
>>>> compilation semantics and different compilation and interpretation
>>>> semantics.
- 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 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-03-03 14:49 -0600 |
| Message-ID | <05udnd6_I_3GKq7MnZ2dnUVZ_sSdnZ2d@supernews.com> |
| In reply to | #20207 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>Not really, no. An immediate word, unless it is state-smart, has >>>>identical compilation and interpretation semantics. >>> >>> A STATE-smart word also has identical compilation and interpretation >>> semantics. These semantics just check STATE at run-time and do >>> different things depending on STATE at that time. >> >>In which case they're different. "Does different things" is a >>reasonable operational definition of "has different semantics". > > If the run-time of STATE-smart words was inseparable from the time it > was parsed (at which time the text interpreter selects interpretation > semantics or compilation semantics, or ' selects the > execution/interpretation semantics or POSTPONE selects the compilation > semantics), you would have a point. But the STATE at parsing is only > the same as the STATE at run-time if the word is processed by the text > interpreter. Well,yes. > For the other ways of processing the word, the STATE can be anything > at run-time, and actually the STATE at parsing is irrelevant there, > because what matters is which word parses the word. I don't know what point you're trying to make. >>>> Strictly speaking, it may be that S" cannot be implemented >>>> as an immediate STATE-smart word; I suspect this was not intended. >>> >>> I see that you are coming around to the more common way of using >>> "STATE-smart". Good. >> >>Not at all. If you can see any way in which I'm being inconsistent or >>changing my mind, I'm sure you'll be specific when you let me know. > > In the above, you use "immediate STATE-smart word" for a flawed > implementation technique for combined words, whereas earlier you > claimed > >>>>> I do not accept your definition of "state-smart" as meaning only >>>>> words that use the variable STATE. As far as I am concerned, >>>>> state-smart words are those with non-default compilation >>>>> semantics and different compilation and interpretation >>>>> semantics. Yes. STATE-smart is not equal to "state-smart". Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2013-03-07 16:58 +0000 |
| Message-ID | <2013Mar7.175812@mips.complang.tuwien.ac.at> |
| In reply to | #20214 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Yes. STATE-smart is not equal to "state-smart".
Concratulations on wasting quite a bit of my time, and the reader's
time by chooding confusing terminology.
- 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 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-03-07 16:35 -0600 |
| Message-ID | <MpOdnS6IIOu2i6TMnZ2dnUVZ_rSdnZ2d@supernews.com> |
| In reply to | #20400 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Yes. STATE-smart is not equal to "state-smart". > > Concratulations on wasting quite a bit of my time, and the reader's > time by chooding confusing terminology. Well, I'll be happy to choode something else when someone comes up with a decent suggestion. But as I said, the distinction is not important to me, so I don't think it really needs to be made in most cases. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2013-03-08 17:29 +0000 |
| Message-ID | <2013Mar8.182910@mips.complang.tuwien.ac.at> |
| In reply to | #20416 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Yes. STATE-smart is not equal to "state-smart".
>>
>> Concratulations on wasting quite a bit of my time, and the reader's
>> time by chooding confusing terminology.
>
>Well, I'll be happy to choode something else when someone comes up
>with a decent suggestion. But as I said, the distinction is not
>important to me, so I don't think it really needs to be made in most
>cases.
If you claim that the standard requires state-smartness (and that's
what I reacted to), the distinction is certainly important, maybe not
to you, but then you might also say that 2+2=5, because the
distinction is not important to you. It would still be wrong.
- 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 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-03-08 12:17 -0600 |
| Message-ID | <3oydneltaI6ztqfMnZ2dnUVZ_s6dnZ2d@supernews.com> |
| In reply to | #20454 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>Yes. STATE-smart is not equal to "state-smart". >>> >>> Concratulations on wasting quite a bit of my time, and the reader's >>> time by chooding confusing terminology. >> >>Well, I'll be happy to choode something else when someone comes up >>with a decent suggestion. But as I said, the distinction is not >>important to me, so I don't think it really needs to be made in most >>cases. > > If you claim that the standard requires state-smartness (and that's > what I reacted to), the distinction is certainly important, maybe not > to you, but then you might also say that 2+2=5, because the > distinction is not important to you. It would still be wrong. I do indeed claim that the standard requires state-smartness. And you know why I say that. Your claim rests on your own defintion of "state-smart". But I'm bored of this conversation. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2013-02-28 00:17 +0100 |
| Message-ID | <kgm45k$9lj$1@online.de> |
| In reply to | #20068 |
Andrew Haley wrote: > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>I don't think so. State-smartness is a something we're stuck with >>>because of a few standard words >> >> There is no standard word that is specified as state-smart, so no, we >> are not stuck with it. > > I think we are. As you may be aware, I do not accept your definition > of "state-smart" as meaning only words that use the variable STATE. > As far as I am concerned, state-smart words are those with non-default > compilation semantics and different compilation and interpretation > semantics. The problem with such words is not how state-smartness is > achieved, it is those different semantics. It is this property that > leads to obscure bugs. > > That is what we are stuck with. IMHO the problem here is the problem of improper terminology, which is a recognized problem since at least 2500 years (Confucius, Lunyu XIII, 3.3 "to set the words right"). Interpretation and compilation are something different. The default interpretation semantics of a word is set by its CFA in classic Forth (we call this the "doer" in Gforth). You have a variable, it is putting its address on the stack. You have a colon definition, it is executing the compiled code in that code definition. These are, in OOP terminology, "methods". In classical Forth, we have these methods for the interpreter, and we reuse them for executing the compiled code, as we have threaded code. What we don't have is a method for compiling a word. We have a "default compilaton semantics", which is do COMPILE, on the word. And we have non- default compilation semantics, which is achieved by making the word immediate. Forth Inc's Forths didn't have a STATE variable for quite some time. The Forth Inc. approach therefore was, when there was the need for similar words of which one would interpret and the other would compile, to use []s for the compiled version. Or use something like .( and ." for interpretation and compilation. This might be easy for implementation, but it clutters up the conceptual stuff. Forth is an interactive environment, and one key feature of an interactive environment is that you can use words directly on the command line. That's why others like figForth had STATE, and used state-smart words. Immediate words which decide on STATE if they were being compiled or interpreted. This unclutters the namespace, but as STATE is a state variable (haha), it makes these programs stateful, even though they are pretty simple. Being stateful by itself is not that much of a problem - for me, the concept of compilation was a "state", and I haven't had problems with a rather large set of state-smart words e.g. in Bernd-OOF. These words are state-smart, because OOP is a non-trivial extension to Forth. Anton's concept of compilation was that of a "semantics", and he had problems with rather trivial state-smart words. Semantics means "if I postpone something, I want it to behave at run-time as if it was compiled"; it is detached from the actual state I'm in. Anton simply made non-immediate words which did compile something, e.g. : foo postpone bar ; : test [ foo ] ; and it didn't work. Instead of adding the immediate to foo, and removing the square brackets, he started to change Gforth to match his idea that compilation is a semantics - and well, that wasn't actually his idea. That's how the ANS Forth standard is written (at least most of the time, we have some corners where the stateful nature of Forth shines through). This shows that we had a discrepancy between reality and the concepts we use to specify our language. There are two ways out: Either adapt reality to the spec, or change the spec. There's one thing we can't change: The fact that compilation and interpretation aren't the same thing, and are now much less so than they used to be 20, 30 years ago. Even threaded code Forths like Gforth use a primitive-centric approach, where each doer has an associated compile, action. Up to recent changes, this was just a case statement in COMPILE,, now it is a method in the word's vtable. Well, taking that OOP approach at what words do, and that a word has more than one single interface (i.e. more than the doer) allows for some quite nice things. For a start, you can add your special compilation action as COMPILE,-method instead of making the word immediate. I added some further methods, one for POSTPONE (the word itself knows what to do when being postponed; except for the recognizers, that's a default action), one is for TO (this is split up in compile TO and interpret TO, and maybe I should think about also handling the POSTPONE case of TO ;-). The recognizer address something different, they address parsing actions. In classical Forth, we have parsing actions done by the immediate words themselves. With the recognizer, the parsing part is separated, and the recognizer does it, not the thing it finds. This reduces the places where things are parsed - the recognizer is part of the outer interpreter, and thus it takes parsing out of the stateful part. It parses the same way, regardless if it's in interpretation, compilation, or postpone mode (the ]] [[ mode, which we didn't have 10 years ago). This is exactly what the users apparently want, and why we moved from char [char] to '<char>', which is stateless. I don't think we are through with all that. The recognizer is powerful and dangerous. The vtable with various actions is powerful, too, and might be about as dangerous. You can have your own postpone action, so ]] s" foo bar" [[ could work just as well as the ]] "foo bar" [[ recognizer version. These concepts are there to allow the programmer to write a language which the user wants to use, and hopefully is less bug- prone than the ad-hoc approach at state-smartness we had in the past. But it's still a smart word, it can have a lot of non-default behavior. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-02-28 01:04 -0800 |
| Message-ID | <7xlia87qs1.fsf@ruckus.brouhaha.com> |
| In reply to | #20086 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > The recognizer address something different, they address parsing actions. > In classical Forth, we have parsing actions done by the immediate words > themselves. With the recognizer, the parsing part is separated, and the > recognizer does it, not the thing it finds. I wonder if you've looked at Retroforth. Each dict header has a "class handler" which is a code pointer that gets called after the word is parsed. I guess that would have been intolerable in vintage Forth because it burns an extra cell in every dict header, but maybe it's acceptable now. It seems to clean up a fair number of issues. Since only a few classes are defined, I guess the class handler could be squished from a cell to a few bits. Retroforth does still have a "compiler" variable, equivalent to "state" or at least similar to it. http://retroforth.org/docs/An_Introduction_to_Retro.html
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2013-02-28 17:10 +0100 |
| Message-ID | <kgnvha$ukk$2@online.de> |
| In reply to | #20092 |
Paul Rubin wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >> The recognizer address something different, they address parsing actions. >> In classical Forth, we have parsing actions done by the immediate words >> themselves. With the recognizer, the parsing part is separated, and the >> recognizer does it, not the thing it finds. > > I wonder if you've looked at Retroforth. Each dict header has a "class > handler" which is a code pointer that gets called after the word is > parsed. That's similar to Manfred Malow's "Prelude" concept. That is for parsing words. The recognizer stack is for looking at words and numbers, and parsing those. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[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