Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #49278 > unrolled thread
| Started by | Chris Curl <ccurl609@gmail.com> |
|---|---|
| First post | 2016-07-21 07:09 -0700 |
| Last post | 2016-07-28 05:33 -0700 |
| Articles | 20 on this page of 169 — 25 participants |
Back to article view | Back to comp.lang.forth
Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-21 07:09 -0700
Re: Dictionary separated from code ... PROS and CONs Pablo Hugo Reda <pabloreda@gmail.com> - 2016-07-21 07:21 -0700
Re: Dictionary separated from code ... PROS and CONs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-21 14:58 +0000
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-21 11:23 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-21 12:42 -0700
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-21 12:40 -1000
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-21 17:07 -0700
Re: Dictionary separated from code ... PROS and CONs Cecil Bayona <cbayona@cbayona.com> - 2016-07-21 19:32 -0500
Re: Dictionary separated from code ... PROS and CONs Paul Rubin <no.email@nospam.invalid> - 2016-07-21 17:40 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-21 17:50 -0700
Re: Dictionary separated from code ... PROS and CONs Cecil Bayona <cbayona@cbayona.com> - 2016-07-21 19:53 -0500
Re: Dictionary separated from code ... PROS and CONs Ron Aaron <rambamist@gmail.com> - 2016-07-22 06:58 +0300
Re: Dictionary separated from code ... PROS and CONs Ron Aaron <rambamist@gmail.com> - 2016-07-22 06:54 +0300
Re: Dictionary separated from code ... PROS and CONs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-22 06:48 +0000
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-22 00:19 -0700
Re: Dictionary separated from code ... PROS and CONs Cecil Bayona <cbayona@cbayona.com> - 2016-07-22 02:33 -0500
Re: Dictionary separated from code ... PROS and CONs Ron Aaron <rambamist@gmail.com> - 2016-07-22 10:45 +0300
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-21 19:41 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-21 20:52 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-22 11:22 -0400
Re: Dictionary separated from code ... PROS and CONs Cecil Bayona <cbayona@cbayona.com> - 2016-07-22 10:49 -0500
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-22 11:16 -0400
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-22 22:11 -0700
Re: Dictionary separated from code ... PROS and CONs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-22 06:32 +0000
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-21 23:58 -0700
Re: Dictionary separated from code ... PROS and CONs missycurl@gmail.com - 2016-07-21 17:02 -0700
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-21 17:06 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-21 17:11 -0700
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-21 15:57 -1000
Re: Dictionary separated from code ... PROS and CONs "HAA" <someone@microsoft.com> - 2016-07-22 13:25 +1000
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-21 20:24 -0700
Re: Dictionary separated from code ... PROS and CONs stephen@mpeforth.com (Stephen Pelc) - 2016-07-22 11:32 +0000
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-22 12:49 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-22 23:10 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-22 22:36 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-21 20:58 -0700
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-21 21:56 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-21 23:38 -0700
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-22 10:43 -0700
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-22 10:56 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-22 14:18 -0400
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-22 08:55 -1000
Re: Dictionary separated from code ... PROS and CONs "WJ" <w_a_x_man@yahoo.com> - 2016-07-25 11:34 +0000
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-22 11:36 -0400
Re: Dictionary separated from code ... PROS and CONs Lars Brinkhoff <lars.spam@nocrew.org> - 2016-07-22 11:15 +0200
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-22 11:37 -0400
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-22 08:56 -1000
Re: Dictionary separated from code ... PROS and CONs "HAA" <someone@microsoft.com> - 2016-07-24 13:16 +1000
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-24 12:58 -0700
Re: Dictionary separated from code ... PROS and CONs "HAA" <someone@microsoft.com> - 2016-07-25 18:09 +1000
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-24 22:34 -1000
Re: Dictionary separated from code ... PROS and CONs "HAA" <someone@microsoft.com> - 2016-07-27 23:08 +1000
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-27 08:58 -1000
CREATE...DOES> etc. and flash (was: Dictionary separated ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-28 09:17 +0000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) "HAA" <someone@microsoft.com> - 2016-07-29 00:19 +1000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-28 14:54 +0000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) humptydumpty <ouatubi@gmail.com> - 2016-07-28 10:00 -0700
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) "HAA" <someone@microsoft.com> - 2016-07-29 21:47 +1000
Re: CREATE...DOES> etc. and flash Coos Haak <chforth@hccnet.nl> - 2016-07-29 15:04 +0200
Re: CREATE...DOES> etc. and flash "HAA" <someone@microsoft.com> - 2016-07-30 18:42 +1000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-29 15:05 +0000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) hughaguilar96@gmail.com - 2016-07-30 02:21 -0700
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) "HAA" <someone@microsoft.com> - 2016-07-31 13:05 +1000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) hughaguilar96@gmail.com - 2016-07-30 21:24 -0700
Re: CREATE...DOES> etc. and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-31 19:07 -0500
Re: CREATE...DOES> etc. and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-01 06:24 +0000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-01 06:14 +0000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) "HAA" <someone@microsoft.com> - 2016-08-02 10:45 +1000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-02 06:59 +0000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) Julian Fondren <julian.fondren@gmail.com> - 2016-08-02 00:34 -0700
Re: CREATE...DOES> etc. and flash Coos Haak <htrofhc@gmail.com> - 2016-08-02 13:57 +0200
Re: CREATE...DOES> etc. and flash Julian Fondren <julian.fondren@gmail.com> - 2016-08-02 06:19 -0700
Re: CREATE...DOES> etc. and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-02 15:28 +0000
Re: CREATE...DOES> etc. and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-02 13:34 -0500
Re: CREATE...DOES> etc. and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-03 07:32 +0000
Re: CREATE...DOES> etc. and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-03 11:51 -0500
Re: CREATE...DOES> etc. and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-04 08:21 +0000
Re: CREATE...DOES> etc. and flash stephen@mpeforth.com (Stephen Pelc) - 2016-08-04 13:18 +0000
Re: CREATE...DOES> etc. and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-04 14:02 +0000
Re: CREATE...DOES> etc. and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-04 12:26 -0500
Re: CREATE...DOES> etc. and flash Mark Wills <markwills1970@gmail.com> - 2016-08-02 07:24 -0700
Re: CREATE...DOES> etc. and flash Julian Fondren <julian.fondren@gmail.com> - 2016-08-02 07:36 -0700
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) humptydumpty <ouatubi@gmail.com> - 2016-08-02 12:14 -0700
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) humptydumpty <ouatubi@gmail.com> - 2016-08-02 12:17 -0700
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) "HAA" <someone@microsoft.com> - 2016-08-06 13:35 +1000
Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) Mark Wills <markwills1970@gmail.com> - 2016-08-02 07:20 -0700
Re: CREATE...DOES> etc. and flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-02 13:43 -0500
Re: CREATE...DOES> etc. and flash "Elizabeth D. Rather" <erather@forth.com> - 2016-07-28 09:19 -1000
Re: CREATE...DOES> etc. and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-29 05:15 +0000
Re: CREATE...DOES> etc. and flash "Elizabeth D. Rather" <erather@forth.com> - 2016-07-28 21:50 -1000
Re: CREATE...DOES> etc. and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-29 08:24 +0000
Re: CREATE...DOES> etc. and flash Brad Eckert <hwfwguy@gmail.com> - 2016-07-29 10:08 -0700
Re: CREATE...DOES> etc. and flash Brad Eckert <hwfwguy@gmail.com> - 2016-07-29 15:06 -0700
Re: CREATE...DOES> etc. and flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-30 06:22 +0000
Re: CREATE...DOES> etc. and flash Paul Rubin <no.email@nospam.invalid> - 2016-07-30 01:07 -0700
Re: CREATE...DOES> etc. and flash hughaguilar96@gmail.com - 2016-07-30 01:30 -0700
Re: CREATE...DOES> etc. and flash Brad Eckert <hwfwguy@gmail.com> - 2016-07-30 10:17 -0700
Re: CREATE...DOES> etc. and flash hughaguilar96@gmail.com - 2016-07-30 00:51 -0700
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-22 05:20 -0700
Re: Dictionary separated from code ... PROS and CONs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-22 13:06 +0000
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-22 08:13 -0700
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-22 09:09 -1000
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-22 14:08 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-22 15:24 -0700
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-22 20:12 -0700
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-22 17:36 -1000
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-22 21:54 -0700
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-22 22:03 -0700
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-22 22:00 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-22 22:19 -0700
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-22 20:40 -1000
Re: Dictionary separated from code ... PROS and CONs "HAA" <someone@microsoft.com> - 2016-07-23 22:23 +1000
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-24 15:48 -0700
Re: Dictionary separated from code ... PROS and CONs missycurl@gmail.com - 2016-07-24 16:04 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-24 19:31 -0400
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-24 17:20 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-24 17:54 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-24 21:27 -0400
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-24 19:18 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-24 22:25 -0400
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-24 20:39 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-24 23:32 -0700
Re: Dictionary separated from code ... PROS and CONs Julian Fondren <julian.fondren@gmail.com> - 2016-07-25 00:30 -0700
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-24 21:36 -1000
Re: Dictionary separated from code ... PROS and CONs Julian Fondren <julian.fondren@gmail.com> - 2016-07-25 00:46 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-25 09:19 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-25 12:35 -0400
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-25 12:32 -0400
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-24 17:48 -1000
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-24 23:09 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-25 12:43 -0400
Re: Dictionary separated from code ... PROS and CONs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-23 06:58 +0000
Re: Dictionary separated from code ... PROS and CONs Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-23 04:02 -0500
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-23 10:43 -0700
Re: Dictionary separated from code ... PROS and CONs Paul Rubin <no.email@nospam.invalid> - 2016-07-23 10:48 -0700
Re: Dictionary separated from code ... PROS and CONs humptydumpty <ouatubi@gmail.com> - 2016-07-23 10:53 -0700
Re: Dictionary separated from code ... PROS and CONs Pablo Hugo Reda <pabloreda@gmail.com> - 2016-07-23 11:24 -0700
Re: Dictionary separated from code ... PROS and CONs Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-24 03:33 -0500
Re: Dictionary separated from code ... PROS and CONs missycurl@gmail.com - 2016-07-24 08:16 -0700
Re: Dictionary separated from code ... PROS and CONs Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-25 04:28 -0500
Re: Dictionary separated from code ... PROS and CONs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-27 11:59 +0000
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-27 07:36 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-27 10:44 -0400
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-27 11:36 -0700
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-27 11:53 -0700
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-27 09:09 -1000
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-27 12:47 -0700
Re: Dictionary separated from code ... PROS and CONs foxaudioresearch@gmail.com - 2016-07-27 13:27 -0700
Re: Dictionary separated from code ... PROS and CONs all2001@spambog.com (Wolfgang Allinger) - 2016-07-27 18:20 -0300
Re: Dictionary separated from code ... PROS and CONs Julian Fondren <julian.fondren@gmail.com> - 2016-07-27 19:40 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-27 19:56 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-28 00:44 -0400
Re: Dictionary separated from code ... PROS and CONs Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-27 16:14 -0500
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-27 18:38 -0700
Re: Dictionary separated from code ... PROS and CONs rickman <gnuarm@gmail.com> - 2016-07-27 16:03 -0400
Re: Dictionary separated from code ... PROS and CONs missycurl@gmail.com - 2016-07-27 21:09 -0700
Re: Dictionary separated from code ... PROS and CONs missycurl@gmail.com - 2016-07-27 21:13 -0700
Re: Dictionary separated from code ... PROS and CONs anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-27 15:25 +0000
Re: Dictionary separated from code ... PROS and CONs Mark Wills <markwills1970@gmail.com> - 2016-07-28 02:53 -0700
Re: Dictionary separated from code ... PROS and CONs JennyB <jennybrien@googlemail.com> - 2016-07-27 09:44 -0700
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-24 13:06 -0700
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-24 15:36 -0700
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-24 12:43 -1000
Re: Dictionary separated from code ... PROS and CONs hughaguilar96@gmail.com - 2016-07-24 15:53 -0700
Re: Dictionary separated from code ... PROS and CONs Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-25 04:32 -0500
Re: Dictionary separated from code ... PROS and CONs Roelf Toxopeus <rt4all@nothishetnet.nl> - 2016-07-23 14:47 +0200
Re: Dictionary separated from code ... PROS and CONs "Elizabeth D. Rather" <erather@forth.com> - 2016-07-22 12:24 -1000
Re: Dictionary separated from code ... PROS and CONs Brad Eckert <hwfwguy@gmail.com> - 2016-07-22 19:47 -0700
Re: Dictionary separated from code ... PROS and CONs Chris Curl <ccurl609@gmail.com> - 2016-07-28 05:33 -0700
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-07-29 15:05 +0000 |
| Subject | Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) |
| Message-ID | <2016Jul29.170530@mips.complang.tuwien.ac.at> |
| In reply to | #49651 |
"HAA" <someone@microsoft.com> writes:
>The problem with using quotations is that it won't work on all systems.
>Run-time code needs to reside in target space. Defining words and
>quotations created by them will reside in host/compiler space.
>Systems where these spaces are different (e.g. target compilers)
>will require a strategy other than quotations.
I sure that cross-compiler writers add some syntax for specifying
whether a quotation is in the host, the target, or both. E.g., if we
take the example from my posting:
: +field ( n1 n2 "name" -- n3 )
[: @ + ;] next-does
[: >body @ ?dup if postpone literal postpone + then ;] next-optimizer
create over , + ;
The first quotation contains the code for the interpretation/execution
semantics of "name"; the second quotation contains the code for when
the xt of "name" is COMPILE,d (intelligent COMPILE,); so the first
quotation is only used when the xt of "name" is EXECUTEd.
In a C-like cross-compilation setting (host: minimal interpretation;
target: no headers, no compilation, no text interpreter), the second
quotation is needed only on the host, but compiles code on the target.
The first quotation may not be needed at all in such a setting: it
would be needed on the host if "name" is text-interpreted or ticked
and EXECUTEd there; it would be needed on the target if "name" is
ticked and EXECUTEd there. Maybe cross-compiler writers want to give
their users finer-grained control than Forth-oriented (i.e.,
host=target) words such as NEXT-DOES and NEXT-OPTIMIZER provide.
But anyway, all these issues also occur for the current regime of
creating a header, then changing it (whether with DOES>, IMMEDIATE,
SET-OPTIMIZER, or whatever), so that's somewhat beside the point I
wanted to discuss.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-30 02:21 -0700 |
| Subject | Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) |
| Message-ID | <a60909fa-1510-4fb7-b8a0-1bca31159976@googlegroups.com> |
| In reply to | #49651 |
On Friday, July 29, 2016 at 4:45:00 AM UTC-7, HAA wrote: > The problem with using quotations is that it won't work on all systems. > Run-time code needs to reside in target space. Defining words and > quotations created by them will reside in host/compiler space. > Systems where these spaces are different (e.g. target compilers) > will require a strategy other than quotations. I don't see any problem with supporting quotations within a cross-compiler. I have said many times that a cross-compiler needs to be able to determine the attributes of a word given the xt of that word, and it needs to be able to change this attributes. The attributes are: which vocabulary the word is in, whether the word is immediate or not, whether the word is smudged or not, and whether the word is smudge-ready or not. What I found when writing MFX is that progress really picked up when I added error-checking. Before compiling an xt into the target system, I checked to make sure that this wasn't an xt in the host system. If it was, compilation aborted with a helpful error-message. This error-checking caught about 95% of the bugs --- I was able to fix these bugs withing minutes --- these bugs had previously not been caught until the target program was simulated, so they took hours to find and fix (or, trying to execute a target xt on the host system typically crashed the host system, which is also a big time-waster). This error-checking will work on quotations as well as colon words --- host system xts don't work on the target system, and vice-versa --- error-checking for these kinds of bugs should be built in to the cross-compiler, otherwise you will never get your cross-compiler written because you waste too much time debugging the thing.
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-07-31 13:05 +1000 |
| Subject | Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) |
| Message-ID | <nnjpnl$115m$1@gioia.aioe.org> |
| In reply to | #49682 |
hughaguilar96@gmail.com wrote:
> On Friday, July 29, 2016 at 4:45:00 AM UTC-7, HAA wrote:
> > The problem with using quotations is that it won't work on all systems.
> > Run-time code needs to reside in target space. Defining words and
> > quotations created by them will reside in host/compiler space.
> > Systems where these spaces are different (e.g. target compilers)
> > will require a strategy other than quotations.
>
> I don't see any problem with supporting quotations within a cross-compiler.
> ...
Consider this, which is less complicated than a cross-compiler.
Your dictionary is separated into compiler and application words.
Words may be defined in either space and be referenced by either.
Without quotations this is no problem ...
application \ switch to application space
: foo1 ... ; \ run-time code for definer foo2
compiler \ switch to compiler space
: foo2 ['] foo1 <does-create> ... ; \ works like CREATE DOES>
: foo3 ... ; \ a subroutine in compiler space
: foo4 ... foo3 ... ; \ a routine in compiler space
application
You decide you want foo1 and foo3 as quotations. How do you ensure
their code, resulting xt's, and parent words get compiled into the correct
dictionary spaces?
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-30 21:24 -0700 |
| Subject | Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) |
| Message-ID | <694feae2-4d8e-421d-a0bc-1324e705a888@googlegroups.com> |
| In reply to | #49696 |
On Saturday, July 30, 2016 at 8:02:15 PM UTC-7, HAA wrote: > hughaguilar96@gmail.com wrote: > > On Friday, July 29, 2016 at 4:45:00 AM UTC-7, HAA wrote: > > > The problem with using quotations is that it won't work on all systems. > > > Run-time code needs to reside in target space. Defining words and > > > quotations created by them will reside in host/compiler space. > > > Systems where these spaces are different (e.g. target compilers) > > > will require a strategy other than quotations. > > > > I don't see any problem with supporting quotations within a cross-compiler. > > ... > > Consider this, which is less complicated than a cross-compiler. > Your dictionary is separated into compiler and application words. > Words may be defined in either space and be referenced by either. > Without quotations this is no problem ... > > application \ switch to application space > > : foo1 ... ; \ run-time code for definer foo2 > > compiler \ switch to compiler space > > : foo2 ['] foo1 <does-create> ... ; \ works like CREATE DOES> > > : foo3 ... ; \ a subroutine in compiler space > > : foo4 ... foo3 ... ; \ a routine in compiler space > > application > > You decide you want foo1 and foo3 as quotations. How do you ensure > their code, resulting xt's, and parent words get compiled into the correct > dictionary spaces? The quotation gets compiled into the same dictionary space as the parent function.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-07-31 19:07 -0500 |
| Subject | Re: CREATE...DOES> etc. and flash |
| Message-ID | <DJmdnRN-9LpcDwPKnZ2dnUU78YWdnZ2d@supernews.com> |
| In reply to | #49696 |
HAA <someone@microsoft.com> wrote: >> ... > > Consider this, which is less complicated than a cross-compiler. > Your dictionary is separated into compiler and application words. > Words may be defined in either space and be referenced by either. > Without quotations this is no problem ... > > application \ switch to application space > > : foo1 ... ; \ run-time code for definer foo2 > > compiler \ switch to compiler space > > : foo2 ['] foo1 <does-create> ... ; \ works like CREATE DOES> > > : foo3 ... ; \ a subroutine in compiler space > > : foo4 ... foo3 ... ; \ a routine in compiler space > > application > > You decide you want foo1 and foo3 as quotations. How do you ensure > their code, resulting xt's, and parent words get compiled into the correct > dictionary spaces? Surely quotations in host compiler words return XTs to be executed in the host compiler space. Quotations in application words return XTs to be executed in the target. If you want a quotation in a host compiler word which will execute on the target, I'll just say "Tough. You can't do that." I guess if there's ever any actual need for such a thing then someone will invent cross-quotations or somesuch. God forbid. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-08-01 06:24 +0000 |
| Subject | Re: CREATE...DOES> etc. and flash |
| Message-ID | <2016Aug1.082431@mips.complang.tuwien.ac.at> |
| In reply to | #49710 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>If you want a quotation in a host compiler word which will execute on
>the target, I'll just say "Tough. You can't do that."
That's certainly another option. You can always fall back to having
separate definitions.
I'll leave it to the implementors of cross-compilers to decide if
letting quotations be elsewhere than the containing definition adds
enough value to support that.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-08-01 06:14 +0000 |
| Subject | Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) |
| Message-ID | <2016Aug1.081459@mips.complang.tuwien.ac.at> |
| In reply to | #49696 |
"HAA" <someone@microsoft.com> writes:
>Consider this, which is less complicated than a cross-compiler.
>Your dictionary is separated into compiler and application words.
>Words may be defined in either space and be referenced by either.
>Without quotations this is no problem ...
>
> application \ switch to application space
>
> : foo1 ... ; \ run-time code for definer foo2
>
> compiler \ switch to compiler space
>
> : foo2 ['] foo1 <does-create> ... ; \ works like CREATE DOES>
>
> : foo3 ... ; \ a subroutine in compiler space
>
> : foo4 ... foo3 ... ; \ a routine in compiler space
>
> application
>
>You decide you want foo1 and foo3 as quotations. How do you ensure
>their code, resulting xt's, and parent words get compiled into the correct
>dictionary spaces?
You can do it for top-level definitions, by introducing COMPILER and
APPLICATION, so why should you be unable to do it for quotations,
maybe as follows:
compiler
: foo2 application[: ... ;] <does-create ... ;
....
If you don't like this syntax, I am sure you have no problem coming up
with a better one.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-08-02 10:45 +1000 |
| Subject | Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) |
| Message-ID | <nnoq9a$8mu$1@gioia.aioe.org> |
| In reply to | #49714 |
Anton Ertl wrote: > "HAA" <someone@microsoft.com> writes: > >Consider this, which is less complicated than a cross-compiler. > >Your dictionary is separated into compiler and application words. > >Words may be defined in either space and be referenced by either. > >Without quotations this is no problem ... > > > > application \ switch to application space > > > > : foo1 ... ; \ run-time code for definer foo2 > > > > compiler \ switch to compiler space > > > > : foo2 ['] foo1 <does-create> ... ; \ works like CREATE DOES> > > > > : foo3 ... ; \ a subroutine in compiler space > > > > : foo4 ... foo3 ... ; \ a routine in compiler space > > > > application > > > >You decide you want foo1 and foo3 as quotations. How do you ensure > >their code, resulting xt's, and parent words get compiled into the correct > >dictionary spaces? > > You can do it for top-level definitions, by introducing COMPILER and > APPLICATION, so why should you be unable to do it for quotations, > maybe as follows: > > compiler > : foo2 application[: ... ;] <does-create ... ; > .... > > If you don't like this syntax, I am sure you have no problem coming up > with a better one. > > - anton It's more than syntax - it's a new word. The point is that quotations are more than nameless words. They limit functionality. If the end goal is removing a name from a word, forth had that capability decades ago e.g. unlinking names. I supported Hugh's bid that quotations should access the parent's locals. I dislike locals as much as quotations but at least it would have given quotations one advantage over regular words.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-08-02 06:59 +0000 |
| Subject | Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) |
| Message-ID | <2016Aug2.085957@mips.complang.tuwien.ac.at> |
| In reply to | #49721 |
"HAA" <someone@microsoft.com> writes:
>Anton Ertl wrote:
>> "HAA" <someone@microsoft.com> writes:
>> >Consider this, which is less complicated than a cross-compiler.
>> >Your dictionary is separated into compiler and application words.
>> >Words may be defined in either space and be referenced by either.
>> >Without quotations this is no problem ...
>> >
>> > application \ switch to application space
>> >
>> > : foo1 ... ; \ run-time code for definer foo2
>> >
>> > compiler \ switch to compiler space
>> >
>> > : foo2 ['] foo1 <does-create> ... ; \ works like CREATE DOES>
>> >
>> > : foo3 ... ; \ a subroutine in compiler space
>> >
>> > : foo4 ... foo3 ... ; \ a routine in compiler space
>> >
>> > application
>> >
>> >You decide you want foo1 and foo3 as quotations. How do you ensure
>> >their code, resulting xt's, and parent words get compiled into the correct
>> >dictionary spaces?
>>
>> You can do it for top-level definitions, by introducing COMPILER and
>> APPLICATION, so why should you be unable to do it for quotations,
>> maybe as follows:
>>
>> compiler
>> : foo2 application[: ... ;] <does-create ... ;
>> ....
>>
>> If you don't like this syntax, I am sure you have no problem coming up
>> with a better one.
>>
>> - anton
>
>It's more than syntax - it's a new word.
So are APPLICATION and COMPILER. But if you prefer, you can also
define APPLICATION, COMPILER, [:, and ;] such that
: foo2 [ application ] [: ... ;] <does-create ... ;
compiler
works.
> The point is that quotations
>are more than nameless words. They limit functionality.
They disallow writing the quotationless code above? Where can I find
that in the quotation proposal?
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-08-02 00:34 -0700 |
| Subject | Re: CREATE...DOES> etc. and flash (was: Dictionary separated ...) |
| Message-ID | <f82b8470-93a9-4593-80bb-14765687524f@googlegroups.com> |
| In reply to | #49722 |
Welp, looks like quotations are a bad idea. Discarded.
** five minutes later **
Hey guys look at this cool thing with return stack stuff:
: call ( a -- ) >r ;
: with-base ( n -- )
base @ swap base ! ( origbase )
r> swap >r ( continuation )
['] call catch
r> base ! throw ;
: .hex ( n -- )
16 with-base . ;
Words like WITH-BASE don't stand out well in longer code.
If only there were some more readable way to do this :(
-- Julian
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <htrofhc@gmail.com> |
|---|---|
| Date | 2016-08-02 13:57 +0200 |
| Subject | Re: CREATE...DOES> etc. and flash |
| Message-ID | <1gzzmrao7eu0n$.1wnakvbslm4iv.dlg@40tude.net> |
| In reply to | #49724 |
Op Tue, 2 Aug 2016 00:34:27 -0700 (PDT) schreef Julian Fondren:
> Welp, looks like quotations are a bad idea. Discarded.
>
>
> ** five minutes later **
>
>
> Hey guys look at this cool thing with return stack stuff:
>
> : call ( a -- ) >r ;
> : with-base ( n -- )
> base @ swap base ! ( origbase )
> r> swap >r ( continuation )
> ['] call catch
> r> base ! throw ;
> : .hex ( n -- )
> 16 with-base . ;
>
> Words like WITH-BASE don't stand out well in longer code.
>
> If only there were some more readable way to do this :(
>
>
> -- Julian
What about this:
: with-base ( n xt -- )
swap base @ >r base !
catch
r> base !
throw
;
: .hex ( n -- )
16 ['] . with-base
;
As a bonus, it works also outside a definition:
4095 16 ' . with-base FFF ok
No (non-standard) return address manipulation
groet Coos
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-08-02 06:19 -0700 |
| Subject | Re: CREATE...DOES> etc. and flash |
| Message-ID | <9f31d956-c03c-4f0c-9333-179c9ffc1056@googlegroups.com> |
| In reply to | #49727 |
On Tuesday, August 2, 2016 at 6:57:20 AM UTC-5, Coos Haak wrote:
> What about this:
>
> : with-base ( n xt -- )
> swap base @ >r base !
> catch
> r> base !
> throw
> ;
>
> : .hex ( n -- )
> 16 ['] . with-base
> ;
>
That looks fine in this exact case. In practice it means lots of
(AUX) FOO-HELPER BAR0 nonsense words whose only purpose is to
provide, for a single word, an XT that maps to a segment of code.
And it's significantly uglier when you have more than one such word.
: fancy ( n-id -- )
with-output-to-string 16 with-base with-database
dup select name from users where ID = $id;
cr ." id: " rot . ." maps to " type ;
: fancy ( n-id -- )
[: [: [: dup select name from users where ID = $id;
cr ." id: " rot . ." maps to " type
;] with-database ;] 16 with-base ;] with-output-to-string ;
: (((fancy))) ( n-id -- )
dup select name from users where ID = $id;
cr ." id: " rot . ." maps to " type ;
: ((fancy)) ( n-id -- )
['] (((fancy))) with-database ;
: (fancy) ( n-id -- )
16 ['] ((fancy)) with-base ;
: fancy ( n-id -- )
['] (fancy) with-output-to-string ;
or
: fancy ( n-id -- )
['] (((fancy)))
['] with-output-to-string
16 ['] with-base
with-database ;
-- Julian
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-08-02 15:28 +0000 |
| Subject | Re: CREATE...DOES> etc. and flash |
| Message-ID | <2016Aug2.172855@mips.complang.tuwien.ac.at> |
| In reply to | #49730 |
Julian Fondren <julian.fondren@gmail.com> writes:
>On Tuesday, August 2, 2016 at 6:57:20 AM UTC-5, Coos Haak wrote:
>> What about this:
>>
>> : with-base ( n xt -- )
>> swap base @ >r base !
>> catch
>> r> base !
>> throw
>> ;
>>
>> : .hex ( n -- )
>> 16 ['] . with-base
>> ;
>>
>
>That looks fine in this exact case.
Not as fine as CATCH allows. With the code above, if there is an
exception between the first "!" and when the CATCH setup is complete,
things will go awry. Let's fix this:
: with-base-helper ( n xt -- )
swap base ! execute ;
: with-base ( n xt -- )
base @ >r ['] with-base-helper catch r> base ! throw ;
That still does not protect against an exception between the CATCH and
the !, but that's the best that is possible with CATCH; Gforth has
TRY...RESTORE...ENDTRY which also covers this window.
With the return-address-manipulating variant this might be:
: with-base-helper ( a n -- )
base ! >r ;
: with-base ( n -- )
r> base @ >r
swap ['] with-base-helper catch
r> base ! throw ;
: .hex ( n -- )
$10 with-base . ;
So we use this return-address stuff and still need helper definitions
(well, maybe the return-address champions can have another
return-address manipulation to get rid of that). And HAA's problem of
dividing .HEX into an application part and a compiler part is not
addressed here, either. And moreover, we cannot use this WITH-BASE
interactively.
By contrast, here's the quotation example:
: with-base ( n xt -- )
base @ >r
[: swap base ! execute ;] catch
r> base ! throw ;
12345 $10 ' . with-base
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-08-02 13:34 -0500 |
| Subject | Re: CREATE...DOES> etc. and flash |
| Message-ID | <bomdnajyMrI0ej3KnZ2dnUU78TednZ2d@supernews.com> |
| In reply to | #49736 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Julian Fondren <julian.fondren@gmail.com> writes: >>On Tuesday, August 2, 2016 at 6:57:20 AM UTC-5, Coos Haak wrote: >>> What about this: >>> >>> : with-base ( n xt -- ) >>> swap base @ >r base ! >>> catch >>> r> base ! >>> throw >>> ; >>> >>> : .hex ( n -- ) >>> 16 ['] . with-base >>> ; >>> >> >>That looks fine in this exact case. > > Not as fine as CATCH allows. With the code above, if there is an > exception between the first "!" and when the CATCH setup is complete, > things will go awry. Can you expand on this? I don't see what code might throw. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-08-03 07:32 +0000 |
| Subject | Re: CREATE...DOES> etc. and flash |
| Message-ID | <2016Aug3.093228@mips.complang.tuwien.ac.at> |
| In reply to | #49741 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Julian Fondren <julian.fondren@gmail.com> writes:
>>>On Tuesday, August 2, 2016 at 6:57:20 AM UTC-5, Coos Haak wrote:
>>>> What about this:
>>>>
>>>> : with-base ( n xt -- )
>>>> swap base @ >r base !
>>>> catch
>>>> r> base !
>>>> throw
>>>> ;
>>>>
>>>> : .hex ( n -- )
>>>> 16 ['] . with-base
>>>> ;
>>>>
>>>
>>>That looks fine in this exact case.
>>
>> Not as fine as CATCH allows. With the code above, if there is an
>> exception between the first "!" and when the CATCH setup is complete,
>> things will go awry.
>
>Can you expand on this? I don't see what code might throw.
Ctrl-C. Of course it depends on the quality of implementation whether
that becomes an exception or not, but at least in Gforth and
SwiftForth, it does.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-08-03 11:51 -0500 |
| Subject | Re: CREATE...DOES> etc. and flash |
| Message-ID | <pb-dnTfT8MOOvD_KnZ2dnUU78UPNnZ2d@supernews.com> |
| In reply to | #49759 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Julian Fondren <julian.fondren@gmail.com> writes: >>>>On Tuesday, August 2, 2016 at 6:57:20 AM UTC-5, Coos Haak wrote: >>>>> What about this: >>>>> >>>>> : with-base ( n xt -- ) >>>>> swap base @ >r base ! >>>>> catch >>>>> r> base ! >>>>> throw >>>>> ; >>>>> >>>>> : .hex ( n -- ) >>>>> 16 ['] . with-base >>>>> ; >>>>> >>>> >>>>That looks fine in this exact case. >>> >>> Not as fine as CATCH allows. With the code above, if there is an >>> exception between the first "!" and when the CATCH setup is complete, >>> things will go awry. >> >>Can you expand on this? I don't see what code might throw. > > Ctrl-C. Of course it depends on the quality of implementation whether > that becomes an exception or not, but at least in Gforth and > SwiftForth, it does. I don't think it's a QOI issue at all: a standard program is quite entitled to assume that code doesn't throw, and doesn't need to defend against that possibility. For the sake of clarity: if you're going to talk about such nostandard behaviour you ought to at least flag it as such. That way your audience doesn't have to scratch its collective head trying to figure out what you might mean. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-08-04 08:21 +0000 |
| Subject | Re: CREATE...DOES> etc. and flash |
| Message-ID | <2016Aug4.102135@mips.complang.tuwien.ac.at> |
| In reply to | #49764 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Can you expand on this? I don't see what code might throw.
>>
>> Ctrl-C. Of course it depends on the quality of implementation whether
>> that becomes an exception or not, but at least in Gforth and
>> SwiftForth, it does.
>
>I don't think it's a QOI issue at all: a standard program is quite
>entitled to assume that code doesn't throw, and doesn't need to defend
>against that possibility.
Which, conversely, means that you think that this behaviour of Gforth
and SwiftForth is non-standard.
I think you are wrong. The standard has a throw code -28 (user
interrupt), which seems to be designed for that. And Forth is a
practical language for real-world environments, and users typing
Ctrl-C are a fact in the real world. What should a system do when the
user types Ctrl-C?
1) Ignore it? That's certainly not what the user intended.
2) Exit the Forth system without letting the application do any
cleanup (the vfxlin way; does VFX behave the same way on other OSs)?
There is no provision for such behaviour in the standard, and as a
user I find this behaviour not very helpful. Still, better than
option 1).
3) Return to the Forth command line without letting the application do
any cleanup (iForth-2.1 behaves that way). There is no provision for
such behaviour in the standard, either. As a user, I find it better,
but the lack of cleanup is not user-friendly. There may be
incompletly updated data structures, but if the user is worried about
that, he can just exit the system, so this is better than option 2).
4) THROW a Forth exception so that the application can clean up and/or
handle the Ctrl-C in some other application-defined way. The
exception -28 in the standard is an indication that this is a standard
behaviour, but a more explicit wording would not hurt. Option 4 is at
least as useful as the other options in the usual case: Even on
programs that are not designed for asynchronous THROWs, it likely
performs all cleanups designed for synchronous THROWs; it may miss
some, but that's not worse than option 3. There may also be
incompletely updated data structures, but that's not worse than option
3).
Now, with option 4, we can get even less probablility of missed
cleanup by appropriate coding, and that's what I discussed earlier.
>For the sake of clarity: if you're going to
>talk about such nostandard behaviour you ought to at least flag it as
>such. That way your audience doesn't have to scratch its collective
>head trying to figure out what you might mean.
I think the audience is well aware that users type Ctrl-C. In
particular, you should be aware of that because we discussed the issue
earlier, in the thread containing
<2014Jul25.125044@mips.complang.tuwien.ac.at>.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2016-08-04 13:18 +0000 |
| Subject | Re: CREATE...DOES> etc. and flash |
| Message-ID | <57a33e82.854570481@news.eternal-september.org> |
| In reply to | #49782 |
On Thu, 04 Aug 2016 08:21:35 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >Ctrl-C are a fact in the real world. What should a system do when the >user types Ctrl-C? > >1) Ignore it? That's certainly not what the user intended. > >2) Exit the Forth system without letting the application do any >cleanup > >3) Return to the Forth command line without letting the application do >any cleanup > >4) THROW a Forth exception so that the application can clean up and/or >handle the Ctrl-C in some other application-defined way. There are plenty of Linux apps that just terminate when Ctrl-C is pressed, e.g. many implementations of pdftex. Without being telepathic as to the user's intentions, it is difficult to predict how much clean-up is required. It all depends on the app. Just because there's a throw code for it does not mean that all Forth systems have to behave the same way. 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 | 2016-08-04 14:02 +0000 |
| Subject | Re: CREATE...DOES> etc. and flash |
| Message-ID | <2016Aug4.160217@mips.complang.tuwien.ac.at> |
| In reply to | #49785 |
stephen@mpeforth.com (Stephen Pelc) writes:
>There are plenty of Linux apps that just terminate when Ctrl-C is
>pressed, e.g. many implementations of pdftex. Without being telepathic
>as to the user's intentions, it is difficult to predict how much
>clean-up is required. It all depends on the app.
Right, and a standard Forth program (or "app", as some now call it)
can specify the cleanup in this kind of idiom:
['] make-a-mess catch ... cleanup code ... throw
No telepathic powers required.
And while a batch program like pdftex should terminate (after cleanup
if necessary) when Ctrl-C is pressed, I would be pretty miffed if,
say, vi just terminated on Ctrl-C. That's why programs have ways of
telling their programming environment that they want to catch user
interrupts; and for Forth the way to catch such things is called
CATCH.
>Just because there's a throw code for it does not mean that all
>Forth systems have to behave the same way.
Right, you don't have to worry about user interrupts in an embedded
system that does not have a user input device. On a computer with a
user interface, I consider it a quality-of-implementation issue.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-08-04 12:26 -0500 |
| Subject | Re: CREATE...DOES> etc. and flash |
| Message-ID | <TJOdnQ_oI5sj5z7KnZ2dnUU78cHNnZ2d@supernews.com> |
| In reply to | #49782 |
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: >>>>Can you expand on this? I don't see what code might throw. >>> >>> Ctrl-C. Of course it depends on the quality of implementation whether >>> that becomes an exception or not, but at least in Gforth and >>> SwiftForth, it does. >> >>I don't think it's a QOI issue at all: a standard program is quite >>entitled to assume that code doesn't throw, and doesn't need to defend >>against that possibility. > > Which, conversely, means that you think that this behaviour of Gforth > and SwiftForth is non-standard. That#s right. > I think you are wrong. The standard has a throw code -28 (user > interrupt), which seems to be designed for that. And Forth is a > practical language for real-world environments, and users typing > Ctrl-C are a fact in the real world. What should a system do when the > user types Ctrl-C? I'm saying that the behaviour is reasonable, and it is nonstandard. These things are not mutually exclusive. Clearly there are situations in which a standard Forth system will do nonstandard things, such as when you power off the system. >>For the sake of clarity: if you're going to talk about such >>nostandard behaviour you ought to at least flag it as such. That >>way your audience doesn't have to scratch its collective head trying >>to figure out what you might mean. > > I think the audience is well aware that users type Ctrl-C. In > particular, you should be aware of that because we discussed the issue > earlier, in the thread containing > <2014Jul25.125044@mips.complang.tuwien.ac.at>. We did. I thought you were wrong then too. The standard specifies what each word does. In doing so, it limits the actions of each word to the specified behaviour. In <2007Dec2.160116@mips.complang.tuwien.ac.at> you wrote: > I interpret the standard as follows: A standard system must execute > a standard program exactly as described in the standard, and don't > perform any additional user-visible actions (at least wrt state > mentioned in the standard). THROWing from a standard word in response to a Ctrl-C is an additional user-visible action. Andrew.
[toc] | [prev] | [next] | [standalone]
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.forth
csiph-web