Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #53228 > unrolled thread
| Started by | Nathan Schulzke <nschulzke@gmail.com> |
|---|---|
| First post | 2016-12-09 09:25 -0800 |
| Last post | 2017-01-07 15:37 +0000 |
| Articles | 20 on this page of 171 — 22 participants |
Back to article view | Back to comp.lang.forth
Ideal Stack Machine Instruction Set Nathan Schulzke <nschulzke@gmail.com> - 2016-12-09 09:25 -0800
Re: Ideal Stack Machine Instruction Set Nathan Schulzke <nschulzke@gmail.com> - 2016-12-09 09:30 -0800
Re: Ideal Stack Machine Instruction Set trans <transfire@gmail.com> - 2016-12-09 10:23 -0800
Re: Ideal Stack Machine Instruction Set Nathan Schulzke <nschulzke@gmail.com> - 2016-12-09 16:37 -0800
Re: Ideal Stack Machine Instruction Set hughaguilar96@gmail.com - 2016-12-09 17:01 -0800
Re: Ideal Stack Machine Instruction Set Nathan Schulzke <nschulzke@gmail.com> - 2016-12-10 09:07 -0800
Re: Ideal Stack Machine Instruction Set Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-01-01 21:40 -0500
Re: Ideal Stack Machine Instruction Set "Elizabeth D. Rather" <erather@forth.com> - 2017-01-01 21:06 -1000
Re: Ideal Stack Machine Instruction Set Paul Rubin <no.email@nospam.invalid> - 2017-01-03 17:22 -0800
Re: Ideal Stack Machine Instruction Set Lars Brinkhoff <lars.spam@nocrew.org> - 2017-01-04 10:09 +0100
Re: Ideal Stack Machine Instruction Set john <anon@example.com> - 2017-01-04 11:59 +0000
Re: Ideal Stack Machine Instruction Set hughaguilar96@gmail.com - 2017-01-04 10:56 -0800
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-04 23:58 +0100
Re: Ideal Stack Machine Instruction Set Paul Rubin <no.email@nospam.invalid> - 2017-01-04 20:06 -0800
Re: Ideal Stack Machine Instruction Set Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-05 04:12 -0600
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-05 12:43 +0100
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-05 16:38 +0000
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-05 19:17 +0100
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-05 18:26 +0000
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-06 01:56 +0100
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-07 15:53 +0000
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-07 18:20 +0100
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-08 16:33 +0000
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-08 20:02 +0100
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-09 17:53 +0000
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-09 20:22 +0100
Re: Ideal Stack Machine Instruction Set minforth@arcor.de - 2017-01-09 08:04 -0800
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-09 17:04 +0000
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-09 20:22 +0100
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-10 01:41 +0100
Re: Ideal Stack Machine Instruction Set minforth@arcor.de - 2017-01-09 22:16 -0800
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-10 09:44 +0000
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-10 15:19 +0100
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-10 15:24 +0000
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-10 15:35 +0000
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-10 22:12 +0100
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-10 22:42 +0000
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-11 00:23 +0100
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-10 23:35 +0000
Re: Ideal Stack Machine Instruction Set minforth@arcor.de - 2017-01-10 23:38 -0800
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-11 10:32 +0000
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-11 12:52 +0100
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-11 13:23 +0000
Re: Ideal Stack Machine Instruction Set minforth@arcor.de - 2017-01-11 06:08 -0800
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-11 14:39 +0000
Re: Ideal Stack Machine Instruction Set franck.bensusan@gmail.com - 2017-01-11 23:00 -0800
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-12 13:55 +0000
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-12 14:06 +0000
Re: Ideal Stack Machine Instruction Set franck.bensusan@gmail.com - 2017-01-13 06:29 -0800
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-13 14:52 +0000
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-14 12:23 +0000
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-12 15:47 +0100
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-12 15:09 +0000
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-12 20:23 +0100
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-12 21:21 +0000
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-13 03:45 +0100
Re: Ideal Stack Machine Instruction Set Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-13 02:55 -0600
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-13 14:29 +0000
Re: Ideal Stack Machine Instruction Set Bernd Linsel <bl1@gmx.com> - 2017-01-13 16:11 +0100
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-13 17:26 +0100
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-13 17:27 +0100
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-13 17:01 +0000
nt=xt? (was: Ideal Stack Machine Instruction Set) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-14 15:35 +0000
Re: nt=xt? (was: Ideal Stack Machine Instruction Set) stephen@mpeforth.com - 2017-01-14 13:58 -0800
Re: nt=xt? (was: Ideal Stack Machine Instruction Set) hughaguilar96@gmail.com - 2017-01-14 14:52 -0800
Re: nt=xt? (was: Ideal Stack Machine Instruction Set) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-15 14:00 +0000
Re: nt=xt? (was: Ideal Stack Machine Instruction Set) albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-15 16:51 +0100
Re: nt=xt? (was: Ideal Stack Machine Instruction Set) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-15 16:04 +0000
Re: nt=xt? (was: Ideal Stack Machine Instruction Set) hughaguilar96@gmail.com - 2017-01-15 13:47 -0800
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-14 12:39 +0000
Re: Ideal Stack Machine Instruction Set Matthias Trute <matthias.trute@gmail.com> - 2017-01-12 22:14 -0800
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-14 13:45 +0000
Re: Ideal Stack Machine Instruction Set franck.bensusan@gmail.com - 2017-01-14 08:51 -0800
Re: Ideal Stack Machine Instruction Set minforth@arcor.de - 2017-01-14 09:23 -0800
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-14 18:02 +0000
Re: Ideal Stack Machine Instruction Set franck.bensusan@gmail.com - 2017-01-09 23:42 -0800
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-10 09:36 +0000
Re: Ideal Stack Machine Instruction Set franck.bensusan@gmail.com - 2017-01-10 03:55 -0800
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-10 13:40 +0000
Re: Ideal Stack Machine Instruction Set franck.bensusan@gmail.com - 2017-01-10 06:40 -0800
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-05 12:45 +0100
Re: Ideal Stack Machine Instruction Set Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-06 08:19 -0800
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-06 17:57 +0100
Re: Ideal Stack Machine Instruction Set mhx@iae.nl - 2017-01-08 01:34 -0800
Re: Ideal Stack Machine Instruction Set john <anon@example.com> - 2017-01-08 17:08 +0000
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-02 16:49 +0000
Re: Ideal Stack Machine Instruction Set hughaguilar96@gmail.com - 2016-12-09 14:52 -0800
Re: Ideal Stack Machine Instruction Set Paul Rubin <no.email@nospam.invalid> - 2016-12-09 14:56 -0800
Re: Ideal Stack Machine Instruction Set Brad Eckert <hwfwguy@gmail.com> - 2016-12-23 13:13 -0800
Re: Ideal Stack Machine Instruction Set minforth@arcor.de - 2017-01-06 06:58 -0800
Re: Ideal Stack Machine Instruction Set Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-06 09:32 -0600
Re: Ideal Stack Machine Instruction Set minforth@arcor.de - 2017-01-06 09:11 -0800
Re: Ideal Stack Machine Instruction Set Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-06 12:41 -0600
Re: Ideal Stack Machine Instruction Set "Elizabeth D. Rather" <erather@forth.com> - 2017-01-06 21:31 -1000
Re: Ideal Stack Machine Instruction Set hughaguilar96@gmail.com - 2017-01-07 13:28 -0800
Re: Ideal Stack Machine Instruction Set Coos Haak <htrofhc@gmail.com> - 2017-01-07 23:00 +0100
Re: Ideal Stack Machine Instruction Set hughaguilar96@gmail.com - 2017-01-07 14:37 -0800
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-08 00:06 +0100
Re: Ideal Stack Machine Instruction Set hughaguilar96@gmail.com - 2017-01-07 18:50 -0800
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-08 14:28 +0100
Re: Ideal Stack Machine Instruction Set hughaguilar96@gmail.com - 2017-01-08 19:34 -0800
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-09 06:27 +0100
Re: Ideal Stack Machine Instruction Set hughaguilar96@gmail.com - 2017-01-10 00:08 -0800
Re: Ideal Stack Machine Instruction Set Alex <alex@rivadpm.com> - 2017-01-10 10:01 +0000
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-10 13:12 +0100
Re: Ideal Stack Machine Instruction Set stephen@mpeforth.com - 2017-01-08 07:23 -0800
Re: Ideal Stack Machine Instruction Set hughaguilar96@gmail.com - 2017-01-08 19:41 -0800
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-09 17:41 +0000
Re: Ideal Stack Machine Instruction Set "Elizabeth D. Rather" <erather@forth.com> - 2017-01-07 18:56 -1000
TO implementation (was: Ideal Stack Machine Instruction Set) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-07 14:02 +0000
Re: TO implementation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-07 10:51 -0600
Re: TO implementation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-08 15:27 +0000
Re: TO implementation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-08 13:36 -0600
Re: TO implementation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-09 18:20 +0000
Re: TO implementation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-10 03:56 -0600
Re: TO implementation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-15 15:15 +0000
Re: TO implementation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-15 13:34 -0600
Re: TO implementation hughaguilar96@gmail.com - 2017-01-15 14:04 -0800
Re: TO implementation stephen@mpeforth.com - 2017-01-15 14:24 -0800
Re: TO implementation hughaguilar96@gmail.com - 2017-01-15 15:42 -0800
Re: TO implementation hughaguilar96@gmail.com - 2017-01-15 15:56 -0800
Re: TO implementation awegel@arcor.de (Alexander Wegel) - 2017-01-16 14:25 +0100
Re: TO implementation hughaguilar96@gmail.com - 2017-01-16 11:30 -0800
Re: TO implementation awegel@arcor.de (Alexander Wegel) - 2017-01-17 02:00 +0100
Re: TO implementation albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-17 12:59 +0100
Re: TO implementation awegel@arcor.de (Alexander Wegel) - 2017-01-17 14:38 +0100
Re: TO implementation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-17 15:47 +0000
Re: TO implementation hughaguilar96@gmail.com - 2017-01-17 10:24 -0800
Re: TO implementation hughaguilar96@gmail.com - 2017-01-16 17:02 -0800
Re: TO implementation awegel@arcor.de (Alexander Wegel) - 2017-01-17 06:00 +0100
Re: TO implementation Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-01-15 22:19 -0500
Re: TO implementation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-16 08:57 -0600
Re: TO implementation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-19 11:26 +0000
Re: TO implementation Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-01-19 20:49 -0500
Re: TO implementation minforth@arcor.de - 2017-01-20 00:27 -0800
Re: TO implementation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-20 12:20 +0000
Re: TO implementation Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-01-26 22:42 -0500
Re: TO implementation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-27 08:33 +0000
Re: TO implementation minforth@arcor.de - 2017-01-27 03:59 -0800
Re: TO implementation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-19 11:40 +0000
Re: TO implementation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-19 05:55 -0600
Re: TO implementation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-19 14:46 +0000
Re: TO implementation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-19 11:03 -0600
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-06 20:22 +0100
Re: Ideal Stack Machine Instruction Set Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-07 03:54 -0600
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-07 13:51 +0000
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-07 18:50 +0100
Re: Ideal Stack Machine Instruction Set mhx@iae.nl - 2017-01-08 02:05 -0800
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-06 17:41 +0100
Re: Ideal Stack Machine Instruction Set minforth@arcor.de - 2017-01-06 09:15 -0800
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-06 18:40 +0100
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-06 20:25 +0100
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-07 14:55 +0100
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-07 18:55 +0100
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-07 19:10 +0100
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-08 01:25 +0100
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-08 02:17 +0100
Re: Ideal Stack Machine Instruction Set mhx@iae.nl - 2017-01-08 01:53 -0800
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-08 17:03 +0100
Re: Ideal Stack Machine Instruction Set Coos Haak <htrofhc@gmail.com> - 2017-01-08 17:51 +0100
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-08 18:30 +0100
Re: Ideal Stack Machine Instruction Set Paul Rubin <no.email@nospam.invalid> - 2017-01-08 10:51 -0800
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-08 20:06 +0100
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-07 15:31 +0000
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-07 18:20 +0100
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-07 18:56 +0100
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-07 19:10 +0100
Re: Ideal Stack Machine Instruction Set albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-08 01:26 +0100
Re: Ideal Stack Machine Instruction Set awegel@arcor.de (Alexander Wegel) - 2017-01-08 02:06 +0100
Re: Ideal Stack Machine Instruction Set hughaguilar96@gmail.com - 2017-01-06 17:23 -0800
Re: Ideal Stack Machine Instruction Set anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-07 15:37 +0000
Page 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-01-19 05:55 -0600 |
| Subject | Re: TO implementation |
| Message-ID | <oOKdnZp0RLvSNB3FnZ2dnUU7-e2dnZ2d@supernews.com> |
| In reply to | #54160 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>> So what's the point of your implementation approach? >> >>The assertion was that TO requires parsing. My counter-assertion is >>that it doesn't. That is all. It doesn't require parsing for basic >>functionality, and it doesn't require parsing for performance. > > The question is if the cure is not worse than the disease. That's a question. It's not the question that was being discussed. > For performance it certainly looks to me like it is. But you haven't said why: all you have said is that the implementation looks complex. The generated code would be the same. Unless this is some odd quibble about compile-time performance, of course... Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-19 14:46 +0000 |
| Subject | Re: TO implementation |
| Message-ID | <2017Jan19.154639@mips.complang.tuwien.ac.at> |
| In reply to | #54161 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>> So what's the point of your implementation approach?
>>>
>>>The assertion was that TO requires parsing. My counter-assertion is
>>>that it doesn't. That is all. It doesn't require parsing for basic
>>>functionality, and it doesn't require parsing for performance.
>>
>> The question is if the cure is not worse than the disease.
>
>That's a question. It's not the question that was being discussed.
Maybe you did not. I did. And if this implementation approach is
worse, why should anybody be interested in it?
>> For performance it certainly looks to me like it is.
>
>But you haven't said why: all you have said is that the implementation
>looks complex. The generated code would be the same. Unless this is
>some odd quibble about compile-time performance, of course...
Because the performance issue either gives worse performance, or
fragile behaviour. Consider:
5 value x
: -> to ;
7 -> x
x . \ prints 7
So, Y appears to behave like an alias of X.
: foo -> x ;
3 foo y .
The X in FOO can be compiled as checking the flag, then you have the
right behaviour, but worse performance; or you can assume that the
flag is not set, then FOO does not behave like the interpreted -> X.
Or -> is inlined, and the compiler can see TO X and optimize it, and
it behaves as expected; until someone turns off the inliner to deal
with some other issue.
You may argue that this usage is not allowed, but as somebody else has
pointed out, that does not stop Forth programmers (nor does it stop
programmers of other languages).
Why do we want to get rid of a parsing TO? Because the STATE-smart
parsing implementation is fragile, and the robust implementation
approach has an additional cost that many Forthers are reluctant to
pay for just a few words (they prefer to argue, for two decades now,
over whether the robustness is necessary). If your approach gets rid
of parsing, but not of fragility or implementation cost, it has
nothing to offer.
- 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 | 2017-01-19 11:03 -0600 |
| Subject | Re: TO implementation |
| Message-ID | <KeOdneBQX_zlbB3FnZ2dnUU7-cnNnZ2d@supernews.com> |
| In reply to | #54168 |
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: >>>>> So what's the point of your implementation approach? >>>> >>>>The assertion was that TO requires parsing. My counter-assertion is >>>>that it doesn't. That is all. It doesn't require parsing for basic >>>>functionality, and it doesn't require parsing for performance. >>> >>> The question is if the cure is not worse than the disease. >> >>That's a question. It's not the question that was being discussed. > > Maybe you did not. I did. And if this implementation approach is > worse, why should anybody be interested in it? The question which arose was whether TO needs to parse. The answer is "no". I didn't ask the question. >>> For performance it certainly looks to me like it is. >> >>But you haven't said why: all you have said is that the implementation >>looks complex. The generated code would be the same. Unless this is >>some odd quibble about compile-time performance, of course... > > Because the performance issue either gives worse performance, or > fragile behaviour. Consider: > > 5 value x > : -> to ; > 7 -> x > x . \ prints 7 > > So, Y appears to behave like an alias of X. Isn't this incorrect code? User error, surely. Any ocurrence of TO has to be followed by a value or a local, or similar. > You may argue that this usage is not allowed, I do argue precisely that. > but as somebody else has pointed out, that does not stop Forth > programmers (nor does it stop programmers of other languages). So what? We already know that it's possible to write many things in Forths that might work on one system but not others. > Why do we want to get rid of a parsing TO? It means there's one fewer word which requires magic (or, worse, STATE-smartness) to implement its interpretation and compilation semantics. From an implementation point of view a simple flag-setting non-optimizing version of TO is easy. This approach, then, has two virtues: it's very easy in the case of a simple interpreter and not too awful in the case of an optimizing compiler. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-01-06 20:22 +0100 |
| Message-ID | <o4oqq6$5p8$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #53785 |
In article <a14a63ff-378c-4440-9fa3-b8c9862251b0@googlegroups.com>, <minforth@arcor.de> wrote: >Am Freitag, 6. Januar 2017 16:32:59 UTC+1 schrieb Andrew Haley: >> minforth@arcor.de wrote: >> > >> > It's the same old story ad nauseam, to repair Forth's traditional >> > compiler directives. And it is getting worse with each invention of >> > new overloadings of TO. Already TO is overloaded 4 times: singles, >> > doubles, floats and locals. Overloading cries for boxed values and >> > OO, but.... >> > >> > What should FIND TO return then? Forbidding it is a very poor excuse >> > IMO. >> >> TO could be implemented with no special compilation semantics at all. >> >> The original implementation set a flag which was read and cleared by >> the next child of VALUE. Today's optimizing compilers are quite >> capable of turning that into a simple stored, so there's no reason for >> TO to be overloaded at all: it's just a word. >> >> Andrew. > >How so ?? >It must be some IMMEDIATE version then, and NOT state-smart! TO is interesting. The standards demands that it parses. In my book that means that it is IMMEDIATE. A long time ago I won the discussion about whether it is possible to have a standard program that decides whether TO parses or not. There is none. Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-01-07 03:54 -0600 |
| Message-ID | <Zp-dndBU1PInJ-3FnZ2dnUU7-amdnZ2d@supernews.com> |
| In reply to | #53789 |
Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote: > In article <a14a63ff-378c-4440-9fa3-b8c9862251b0@googlegroups.com>, > <minforth@arcor.de> wrote: >>Am Freitag, 6. Januar 2017 16:32:59 UTC+1 schrieb Andrew Haley: > > TO is interesting. The standards demands that it parses. > In my book that means that it is IMMEDIATE. > > A long time ago I won the discussion about whether it is possible to > have a standard program that decides whether TO parses or not. > There is none. I think that may be so, but in that case we should look at improving the standard. The only reason for that restriction AFAICR was to do with what happens when you have a TO at the end of a line of Foth source. It's important to be able to have a user-written text interpreter that works. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-07 13:51 +0000 |
| Message-ID | <2017Jan7.145111@mips.complang.tuwien.ac.at> |
| In reply to | #53789 |
albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>TO is interesting. The standards demands that it parses.
...
>A long time ago I won the discussion about whether it is possible to
>have a standard program that decides whether TO parses or not.
>There is none.
I.e., the standard does not require that a standard-compliant TO
parses. In Forth-2012 the rationale of TO expands on this as follows:
|Some implementations of TO do not parse; instead they set a mode flag
|that is tested by the subsequent execution of name. Standard programs
|must use TO as if it parses. Therefore TO and name must be contiguous
|and on the same line in the source text.
- 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 | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-01-07 18:50 +0100 |
| Message-ID | <o4r9p4$do2$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #53808 |
In article <2017Jan7.145111@mips.complang.tuwien.ac.at>, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes: >>TO is interesting. The standards demands that it parses. >... >>A long time ago I won the discussion about whether it is possible to >>have a standard program that decides whether TO parses or not. >>There is none. > >I.e., the standard does not require that a standard-compliant TO >parses. In Forth-2012 the rationale of TO expands on this as follows: > >|Some implementations of TO do not parse; instead they set a mode flag >|that is tested by the subsequent execution of name. Standard programs >|must use TO as if it parses. Therefore TO and name must be contiguous >|and on the same line in the source text. Much better. Marcel had array-values with indices as normal values requiring AAP TO (( INDEX )) ARRAY That is not contiguous and has become non-standard. It must be AAP INDEX TO ARRAY (It is left as an exercise for the reader to find out why AAP TO INDEX ARRAY fails when INDEX is a VALUE. ) > >- anton Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2017-01-08 02:05 -0800 |
| Message-ID | <de0cbe32-c76a-429c-8234-8fd4c2bf5d94@googlegroups.com> |
| In reply to | #53816 |
On Saturday, January 7, 2017 at 6:40:02 PM UTC+1, Albert van der Horst wrote: > In article <2017Jan7.145111@mips.complang.tuwien.ac.at>, > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > >albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes: > >>TO is interesting. The standards demands that it parses. > >... > >>A long time ago I won the discussion about whether it is possible to > >>have a standard program that decides whether TO parses or not. > >>There is none. > > > >I.e., the standard does not require that a standard-compliant TO > >parses. In Forth-2012 the rationale of TO expands on this as follows: > > > >|Some implementations of TO do not parse; instead they set a mode flag > >|that is tested by the subsequent execution of name. Standard programs > >|must use TO as if it parses. Therefore TO and name must be contiguous > >|and on the same line in the source text. > > Much better. > > Marcel had array-values with indices as normal values > requiring > AAP TO (( INDEX )) ARRAY > > That is not contiguous and has become non-standard. > It must be > AAP INDEX TO ARRAY > > (It is left as an exercise for the reader to find out why > AAP TO INDEX ARRAY > fails when INDEX is a VALUE. ) It is only difficult because you focus on the how. An ordinary Forth user wants TO to send AAP to ARRAY, not to INDEX, so obviously s/he needs to skip INDEX with the (( )) . When you know how this is *done* you use AAP many_words TO many_other_words (( load_some_files INDEX format_hard_disk )) ARRAY and win the obfuscated Forth contest :-) -marcel
[toc] | [prev] | [next] | [standalone]
| From | awegel@arcor.de (Alexander Wegel) |
|---|---|
| Date | 2017-01-06 17:41 +0100 |
| Message-ID | <1mzfuip.1uycbxyuvldczN%awegel@arcor.de> |
| In reply to | #53779 |
<minforth@arcor.de> wrote: > It's the same old story ad nauseam, to repair Forth's traditional compiler > directives. And it is getting worse with each invention of new overloadings > of TO. Already TO is overloaded 4 times: singles, doubles, floats and locals. > Overloading cries for boxed values and OO, but.... I had TO, 2TO, FTO, and no locals at all. No need to open the can of overloading (using several words named differently like this is idiomatic in forth anyway). I didn't look in forth2012, but in dpans94 TO is only for single cells (applying to stuff not created by VALUE or local is marked ambiguous). > What should FIND TO return then? (You mean: C" TO" FIND .) Probably FIND should return the xt of TO? I mean - in a system where TO can be applied to doubles, floats or locals, TO itself must be smart about this. (?) > Forbidding it is a very poor excuse IMO. Well, TO *does* have interpretation semantics, so FINDing it isn't forbidden in 4.1.2!
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-01-06 09:15 -0800 |
| Message-ID | <de97e176-5ca4-4c2c-9dea-38b3f19fe3e1@googlegroups.com> |
| In reply to | #53783 |
Am Freitag, 6. Januar 2017 17:41:31 UTC+1 schrieb Alexander Wegel: > > Well, TO *does* have interpretation semantics, so FINDing it isn't > forbidden in 4.1.2! Sure, as long as you have extra headers for each data type you have. But already in Forth94 TO was overloaded for locals. You might create your own LTO then .. ;-)
[toc] | [prev] | [next] | [standalone]
| From | awegel@arcor.de (Alexander Wegel) |
|---|---|
| Date | 2017-01-06 18:40 +0100 |
| Message-ID | <1mzg0mg.urzwbs9tluyuN%awegel@arcor.de> |
| In reply to | #53786 |
<minforth@arcor.de> wrote:
> Am Freitag, 6. Januar 2017 17:41:31 UTC+1 schrieb Alexander Wegel:
> >
> > Well, TO *does* have interpretation semantics, so FINDing it isn't
> > forbidden in 4.1.2!
>
> Sure, as long as you have extra headers for each data type you have.
You objected against FINDing it being forbidden, which it isn't.
Using it for doubles or floats on the other hand *is* forbidden (in the
sense that ambiguous=forbidden).
> But already in Forth94 TO was overloaded for locals.
> You might create your own LTO then .. ;-)
In some system (OFW) i saw, it was similar to that. Storing to locals
was done by a couple of words called {0!}, {1!}, etc. which where
compiled by TO.
After all there can be only a couple of locals (this makes it possible
to encode "TO localx" as a single xt).
In a system where TO is overloaded, it has to figure out what to compile
anyway, so TO itself should be smart enough to handle the code
selection.
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-01-06 20:25 +0100 |
| Message-ID | <o4oqup$5pv$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #53787 |
In article <1mzg0mg.urzwbs9tluyuN%awegel@arcor.de>, Alexander Wegel <awegel@arcor.de> wrote: ><minforth@arcor.de> wrote: > >> Am Freitag, 6. Januar 2017 17:41:31 UTC+1 schrieb Alexander Wegel: >> > >> > Well, TO *does* have interpretation semantics, so FINDing it isn't >> > forbidden in 4.1.2! >> >> Sure, as long as you have extra headers for each data type you have. > >You objected against FINDing it being forbidden, which it isn't. > >Using it for doubles or floats on the other hand *is* forbidden (in the >sense that ambiguous=forbidden). That is why Marcel Hendrix invented DVALUE's FVALUE's DLOCAL's FLOCAL's and whatnot. Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | awegel@arcor.de (Alexander Wegel) |
|---|---|
| Date | 2017-01-07 14:55 +0100 |
| Message-ID | <1mzg6bv.1dxm3a2vhjc95N%awegel@arcor.de> |
| In reply to | #53790 |
Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote: > In article <1mzg0mg.urzwbs9tluyuN%awegel@arcor.de>, > Alexander Wegel <awegel@arcor.de> wrote: > ><minforth@arcor.de> wrote: > > > >> Am Freitag, 6. Januar 2017 17:41:31 UTC+1 schrieb Alexander Wegel: > >> > > >> > Well, TO *does* have interpretation semantics, so FINDing it isn't > >> > forbidden in 4.1.2! > >> > >> Sure, as long as you have extra headers for each data type you have. > > > >You objected against FINDing it being forbidden, which it isn't. > > > >Using it for doubles or floats on the other hand *is* forbidden (in the > >sense that ambiguous=forbidden). > > That is why Marcel Hendrix invented DVALUE's FVALUE's DLOCAL's FLOCAL's > and whatnot. Correction: he called it 2VALUE, just as i did. His take on this seems more elaborate though.
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-01-07 18:55 +0100 |
| Message-ID | <o4ra28$dpd$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #53804 |
In article <1mzg6bv.1dxm3a2vhjc95N%awegel@arcor.de>, Alexander Wegel <awegel@arcor.de> wrote: >Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote: > >> In article <1mzg0mg.urzwbs9tluyuN%awegel@arcor.de>, >> Alexander Wegel <awegel@arcor.de> wrote: >> ><minforth@arcor.de> wrote: >> > >> >> Am Freitag, 6. Januar 2017 17:41:31 UTC+1 schrieb Alexander Wegel: >> >> > >> >> > Well, TO *does* have interpretation semantics, so FINDing it isn't >> >> > forbidden in 4.1.2! >> >> >> >> Sure, as long as you have extra headers for each data type you have. >> > >> >You objected against FINDing it being forbidden, which it isn't. >> > >> >Using it for doubles or floats on the other hand *is* forbidden (in the >> >sense that ambiguous=forbidden). >> >> That is why Marcel Hendrix invented DVALUE's FVALUE's DLOCAL's FLOCAL's >> and whatnot. > >Correction: he called it 2VALUE, just as i did. >His take on this seems more elaborate though. You can find DVALUE e.g. in SIEVE.FRT of transputer Forth hccdemo5.zip (about 1994). Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | awegel@arcor.de (Alexander Wegel) |
|---|---|
| Date | 2017-01-07 19:10 +0100 |
| Message-ID | <1mzhwwu.keub4051vwyrN%awegel@arcor.de> |
| In reply to | #53817 |
Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote: > >> That is why Marcel Hendrix invented DVALUE's FVALUE's DLOCAL's FLOCAL's > >> and whatnot. > > > >Correction: he called it 2VALUE, just as i did. > >His take on this seems more elaborate though. > > You can find DVALUE e.g. in SIEVE.FRT of transputer Forth hccdemo5.zip > (about 1994). Ok, so he changed the name to 2value in the meantime. Do you have a link to that demo?
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-01-08 01:25 +0100 |
| Message-ID | <o4s0tn$g48$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #53821 |
In article <1mzhwwu.keub4051vwyrN%awegel@arcor.de>, Alexander Wegel <awegel@arcor.de> wrote: >Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote: > >> >> That is why Marcel Hendrix invented DVALUE's FVALUE's DLOCAL's FLOCAL's >> >> and whatnot. >> > >> >Correction: he called it 2VALUE, just as i did. >> >His take on this seems more elaborate though. >> >> You can find DVALUE e.g. in SIEVE.FRT of transputer Forth hccdemo5.zip >> (about 1994). > >Ok, so he changed the name to 2value in the meantime. > >Do you have a link to that demo? Go to my page below and download hccdemo6.zip. You can also get there from the transputer page. Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | awegel@arcor.de (Alexander Wegel) |
|---|---|
| Date | 2017-01-08 02:17 +0100 |
| Message-ID | <1mzigzx.1navou67rmh8vN%awegel@arcor.de> |
| In reply to | #53830 |
Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote: > In article <1mzhwwu.keub4051vwyrN%awegel@arcor.de>, > Alexander Wegel <awegel@arcor.de> wrote: > >Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote: > > > >> >> That is why Marcel Hendrix invented DVALUE's FVALUE's DLOCAL's FLOCAL's > >> >> and whatnot. > >> > > >> >Correction: he called it 2VALUE, just as i did. > >> >His take on this seems more elaborate though. > >> > >> You can find DVALUE e.g. in SIEVE.FRT of transputer Forth hccdemo5.zip > >> (about 1994). > > > >Ok, so he changed the name to 2value in the meantime. > > > >Do you have a link to that demo? > Go to my page below and download hccdemo6.zip. > > You can also get there from the transputer page. Ah i already wondered why there's just a demo6. Thanks.
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2017-01-08 01:53 -0800 |
| Message-ID | <1871c3c4-bbd9-484c-b27c-9e50c30f855d@googlegroups.com> |
| In reply to | #53790 |
On Friday, January 6, 2017 at 8:14:37 PM UTC+1, Albert van der Horst wrote: > In article <1mzg0mg.urzwbs9tluyuN%awegel@arcor.de>, > Alexander Wegel <awegel@arcor.de> wrote: > ><minforth@arcor.de> wrote: > > > >> Am Freitag, 6. Januar 2017 17:41:31 UTC+1 schrieb Alexander Wegel: > >> > > >> > Well, TO *does* have interpretation semantics, so FINDing it isn't > >> > forbidden in 4.1.2! > >> > >> Sure, as long as you have extra headers for each data type you have. > > > >You objected against FINDing it being forbidden, which it isn't. > > > >Using it for doubles or floats on the other hand *is* forbidden (in the > >sense that ambiguous=forbidden). > > That is why Marcel Hendrix invented DVALUE's FVALUE's DLOCAL's FLOCAL's > and whatnot. Once you embrace the TO concept (Paul Bartholdi), there is no reason to stop at VALUE and LOCAL. iForth has also SFVALUE, DFVALUE (explicit single and double precision, FVALUE is extended 80-bit), UVALUE ( uninitialized ), ZVALUE ( complex ) GVALUE ( any type, for XOPG ). The messages are not limited to TO and +TO -- also FROM, -TO, CLEAR, SIZEOF, /OF are most times supported. All these VALUEs also have a LOCAL pendant. It is quite easy to write new messages and new value types. I still remember that I was very annoyed when first confronted with the TO concept. It helped to write down what I thought was objectively wrong with it. That they were in FysForth and that the tForth team had an enthusiastic user also mellowed my initial outrage. -marcel
[toc] | [prev] | [next] | [standalone]
| From | awegel@arcor.de (Alexander Wegel) |
|---|---|
| Date | 2017-01-08 17:03 +0100 |
| Message-ID | <1mzjdyx.ukjclc1kqckziN%awegel@arcor.de> |
| In reply to | #53848 |
<mhx@iae.nl> wrote: > On Friday, January 6, 2017 at 8:14:37 PM UTC+1, Albert van der Horst wrote: > > In article <1mzg0mg.urzwbs9tluyuN%awegel@arcor.de>, > > Alexander Wegel <awegel@arcor.de> wrote: > > ><minforth@arcor.de> wrote: > > > > > >> Am Freitag, 6. Januar 2017 17:41:31 UTC+1 schrieb Alexander Wegel: > > >> > > > >> > Well, TO *does* have interpretation semantics, so FINDing it isn't > > >> > forbidden in 4.1.2! > > >> > > >> Sure, as long as you have extra headers for each data type you have. > > > > > >You objected against FINDing it being forbidden, which it isn't. > > > > > >Using it for doubles or floats on the other hand *is* forbidden (in the > > >sense that ambiguous=forbidden). > > > > That is why Marcel Hendrix invented DVALUE's FVALUE's DLOCAL's FLOCAL's > > and whatnot. > > Once you embrace the TO concept (Paul Bartholdi), there is > no reason to stop at VALUE and LOCAL. Thanks for the hint - gookling yielded http://www.forth.org/fd/FD-V01N4.pdf And behold - it was C.M. who suggested "the TO concept" (pre 1980). Still learning something. Interesting - it was supposed to *replace* the fetch and store operators in order to avoid their pitfalls (and to improve the code clarity and generated code quality). It still had its own pitfalls, because still you need to choose the properly typed arguments and type-specific operators (d+, f+, ..) with possibility of a mismatch. Simplistic example: FVALUE fu 2 TO fu \ will use a value from f-stack instead of 2
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <htrofhc@gmail.com> |
|---|---|
| Date | 2017-01-08 17:51 +0100 |
| Message-ID | <9ibuhy7dgbmd.17dz5r69a37vy.dlg@40tude.net> |
| In reply to | #53855 |
Op Sun, 8 Jan 2017 17:03:56 +0100 schreef Alexander Wegel: > <mhx@iae.nl> wrote: > >> On Friday, January 6, 2017 at 8:14:37 PM UTC+1, Albert van der Horst wrote: >>> In article <1mzg0mg.urzwbs9tluyuN%awegel@arcor.de>, >>> Alexander Wegel <awegel@arcor.de> wrote: >>> ><minforth@arcor.de> wrote: >>> > >>> >> Am Freitag, 6. Januar 2017 17:41:31 UTC+1 schrieb Alexander Wegel: >>> >> > >>> >> > Well, TO *does* have interpretation semantics, so FINDing it isn't >>> >> > forbidden in 4.1.2! >>> >> >>> >> Sure, as long as you have extra headers for each data type you have. >>> > >>> >You objected against FINDing it being forbidden, which it isn't. >>> > >>> >Using it for doubles or floats on the other hand *is* forbidden (in the >>> >sense that ambiguous=forbidden). >>> >>> That is why Marcel Hendrix invented DVALUE's FVALUE's DLOCAL's FLOCAL's >>> and whatnot. >> >> Once you embrace the TO concept (Paul Bartholdi), there is >> no reason to stop at VALUE and LOCAL. > > Thanks for the hint - gookling yielded > > http://www.forth.org/fd/FD-V01N4.pdf > > And behold - it was C.M. who suggested "the TO concept" (pre 1980). > > Still learning something. > > Interesting - it was supposed to *replace* the fetch and store operators > in order to avoid their pitfalls (and to improve the code clarity and > generated code quality). > > It still had its own pitfalls, because still you need to choose the > properly typed arguments and type-specific operators (d+, f+, ..) with > possibility of a mismatch. > Simplistic example: > > FVALUE fu > 2 TO fu \ will use a value from f-stack instead of 2 Nothing different from: FVARIABLE foo 2 foo f! In both cases you have to write '2e' or '2e0' instead of '2'. groet Coos
[toc] | [prev] | [next] | [standalone]
Page 8 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