Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #40779 > unrolled thread
| Started by | rickman <gnuarm@gmail.com> |
|---|---|
| First post | 2015-07-24 12:19 -0400 |
| Last post | 2015-11-30 02:55 -0500 |
| Articles | 20 on this page of 178 — 30 participants |
Back to article view | Back to comp.lang.forth
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-24 12:19 -0400
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-24 10:15 -0700
Re: Which scripting for embedded automation? foxaudioresearch@gmail.com - 2015-07-24 10:32 -0700
Re: Which scripting for embedded automation? "WJ" <w_a_x_man@yahoo.com> - 2015-07-24 23:06 +0000
Re: Which scripting for embedded automation? Don Y <this@is.not.me.com> - 2015-07-24 17:00 -0700
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-24 20:52 -0400
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-07-25 01:28 -0700
Re: Which scripting for embedded automation? josv@planet.nl - 2015-07-25 07:15 -0700
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-25 10:19 -0400
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-25 10:26 -0700
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-07-27 00:42 -0700
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-26 22:07 -1000
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-07-27 01:44 -0700
Re: Which scripting for embedded automation? foxaudioresearch@gmail.com - 2015-07-27 05:57 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 14:02 +0100
Re: Which scripting for embedded automation? foxaudioresearch@gmail.com - 2015-07-27 08:41 -0700
Re: Which scripting for embedded automation? Julian Fondren <julian.fondren@gmail.com> - 2015-07-27 08:36 -0700
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-25 10:20 -0400
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-26 04:01 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-26 18:53 +0100
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-26 11:18 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-26 20:25 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-27 07:36 +0000
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-27 01:12 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-27 10:02 +0000
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 13:44 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-27 15:15 +0000
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-27 04:52 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 14:01 +0100
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-27 06:16 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 14:33 +0100
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 14:34 +0100
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-27 10:47 -0700
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-27 08:12 -1000
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-27 11:24 -0700
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-27 08:41 -1000
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-27 12:49 -0700
Re: Which scripting for embedded automation? Julian Fondren <julian.fondren@gmail.com> - 2015-07-27 14:38 -0700
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-27 12:02 -1000
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-07-27 11:16 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 20:11 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-27 13:50 +0000
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-27 08:56 -0700
Re: Which scripting for embedded automation? Doug Hoffman <glidedog@gmail.com> - 2015-08-09 09:32 -0400
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-08-09 16:30 -1000
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-09 22:56 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-10 08:53 +0000
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-08-10 08:28 -1000
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-11 15:17 +0000
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-10 14:14 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-10 16:29 -0700
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-08-11 01:44 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-08-11 11:09 +0100
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-08-11 11:03 -0400
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-08-11 08:08 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-08-11 17:21 +0100
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-11 22:05 -0700
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-08-12 05:50 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-08-12 18:02 +0100
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-08-12 05:51 -0700
Re: Which scripting for embedded automation? mhx@iae.nl - 2015-08-12 10:18 -0700
Re: Which scripting for embedded automation? mhx@iae.nl - 2015-08-13 10:37 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-14 12:13 +0000
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-14 21:30 +0200
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-14 13:05 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-15 16:57 +0000
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-16 00:12 +0200
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-16 09:44 +0000
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-17 00:06 +0200
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-18 09:13 +0000
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-18 09:02 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-08-19 00:02 +0100
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-08-18 14:20 -1000
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-19 03:12 +0200
Re: Which scripting for embedded automation? mhx@iae.nl - 2015-08-14 13:09 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-14 13:43 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-15 17:10 +0000
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-12 21:16 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-12 21:31 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-12 21:39 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-13 13:43 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-08-13 10:55 +0100
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-14 12:06 -0700
Re: Which scripting for embedded automation? Alex McDonald <blog@rivadpm.com> - 2015-08-14 18:33 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-15 19:33 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-23 16:59 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-13 15:52 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-10 08:43 +0000
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-27 06:04 -0700
Re: Which scripting for embedded automation? Julian Fondren <ayrnieu@gmail.com> - 2015-07-26 13:49 -0700
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-26 14:56 -1000
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-26 14:20 -0400
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-26 17:29 -0700
Re: Which scripting for embedded automation? "WJ" <w_a_x_man@yahoo.com> - 2015-08-10 22:52 +0000
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-26 17:11 -0400
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-26 22:38 +0100
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-26 15:07 -1000
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-26 21:26 -0400
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-26 16:49 -1000
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-27 01:30 -0400
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-26 22:19 -1000
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-27 19:31 -0400
Re: Which scripting for embedded automation? Julian Fondren <julian.fondren@gmail.com> - 2015-07-27 16:44 -0700
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-27 20:32 -0400
Re: Which scripting for embedded automation? Bernd Linsel <bl1@gmx.com> - 2015-07-28 18:57 +0200
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-27 22:03 -1000
Re: Which scripting for embedded automation? stephen@mpeforth.com (Stephen Pelc) - 2015-07-27 09:12 +0000
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-07-27 11:02 -0700
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-27 14:14 -0400
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 20:17 +0100
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-27 19:33 -0400
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-27 22:05 -1000
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-28 12:47 +0100
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-28 23:52 -0400
Re: Which scripting for embedded automation? awegel@arcor.de (Alexander Wegel) - 2015-07-29 12:24 +0200
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-27 19:32 -0400
Re: Which scripting for embedded automation? Bernd Linsel <bl1@gmx.com> - 2015-07-28 19:22 +0200
Re: Which scripting for embedded automation? Walter Banks <walter@bytecraft.com> - 2015-07-28 15:46 -0400
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-28 23:47 -0400
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-29 07:22 +0000
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-29 00:48 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-29 10:15 +0000
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-31 11:34 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-04 09:21 +0000
Re: Which scripting for embedded automation? Walter Banks <walter@bytecraft.com> - 2015-07-29 13:27 -0400
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-29 18:53 -0400
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-30 12:40 +0000
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-30 22:15 -0400
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-30 21:51 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-31 10:32 +0000
Re: Which scripting for embedded automation? David Thompson <dave.thompson2@verizon.net> - 2015-08-16 02:31 -0400
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-16 09:53 +0000
Re: Which scripting for embedded automation? Bernd Linsel <bl1@gmx.com> - 2015-07-29 17:50 +0200
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-30 13:14 +0000
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-29 10:28 +0000
Re: Which scripting for embedded automation? Bernd Linsel <bl1@gmx.com> - 2015-07-29 18:24 +0200
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-29 17:09 +0000
Re: Which scripting for embedded automation? Bernd Linsel <bl1@gmx.com> - 2015-07-30 02:01 +0200
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-07-29 17:58 -0700
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-30 21:26 -0400
Re: Which scripting for embedded automation? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-31 00:06 -0700
Re: Which scripting for embedded automation? Hannu Vuolasaho <vuokkosetae@gmail.com> - 2015-07-31 13:35 +0300
Re: Which scripting for embedded automation? Mikael Nordman <oh2aun@gmail.com> - 2015-08-01 01:12 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-07-31 15:05 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-30 12:03 +0000
Re: Which scripting for embedded automation? Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-11-02 16:29 +0100
Re: Which scripting for embedded automation? Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-11-02 16:58 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-02 15:43 +0000
Re: Which scripting for embedded automation? Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-11-02 18:24 +0100
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-02 20:09 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-03 12:07 +0000
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-03 22:22 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-04 09:47 +0000
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-04 14:59 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-04 14:13 +0000
Re: Which scripting for embedded automation? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-02 20:29 +0000
Re: Which scripting for embedded automation? Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-11-05 12:02 +0100
Re: Which scripting for embedded automation? Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-11-05 15:57 +0100
Re: Which scripting for embedded automation? Walter Banks <walter@bytecraft.com> - 2015-07-28 15:32 -0400
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-07-29 16:35 -0700
Re: Which scripting for embedded automation? Walter Banks <walter@bytecraft.com> - 2015-08-01 22:50 -0400
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-01 20:06 -0700
Re: Which scripting for embedded automation? humptydumpty <ouatubi@gmail.com> - 2015-07-26 22:56 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-27 07:32 +0000
Re: Which scripting for embedded automation? humptydumpty <ouatubi@gmail.com> - 2015-07-27 01:46 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-27 07:54 +0000
Re: Which scripting for embedded automation? humptydumpty <ouatubi@gmail.com> - 2015-07-27 22:42 -0700
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-28 02:38 -0700
Re: Which scripting for embedded automation? humptydumpty <ouatubi@gmail.com> - 2015-07-28 05:28 -0700
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-28 05:41 -0700
Re: Which scripting for embedded automation? humptydumpty <ouatubi@gmail.com> - 2015-07-28 05:49 -0700
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-28 14:14 -0400
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-28 07:38 -1000
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-28 13:37 -0700
Re: Which scripting for embedded automation? "WJ" <w_a_x_man@yahoo.com> - 2015-11-28 18:06 +0000
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-11-29 02:45 -0500
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-11-29 23:02 -0800
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-11-30 02:55 -0500
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-07-26 11:18 -0700 |
| Message-ID | <87io96rdea.fsf@jester.gateway.sonic.net> |
| In reply to | #40803 |
"Alex McDonald" <blog@rivadpm.com> writes: > The definition of a 1 dimensional array is trivial; perhaps that's why. > : 1dim create cells allot does> swap cells + ; You're going to use arrays with no bounds checks to script potentially hostile internet devices? Sounds dangerous to me.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-07-26 20:25 +0100 |
| Message-ID | <mp3c4u$1rs$1@dont-email.me> |
| In reply to | #40804 |
on 26/07/2015 19:18:20, Paul Rubin wrote:
> "Alex McDonald" <blog@rivadpm.com> writes:
>> The definition of a 1 dimensional array is trivial; perhaps that's why.
>> : 1dim create cells allot does> swap cells + ;
>
> You're going to use arrays with no bounds checks to script potentially
> hostile internet devices? Sounds dangerous to me.
>
>
That wasn't the original complaint; it was that there was not even a cell
sized array in Forth.
: 1dim create dup , cells allot
does> 2dup @ 0 within abort" index out of bounds"
swap 1+ cells + ;
Now we have a cell sized bounds checked array.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-07-27 07:36 +0000 |
| Message-ID | <2015Jul27.093626@mips.complang.tuwien.ac.at> |
| In reply to | #40806 |
"Alex McDonald" <blog@rivadpm.com> writes:
>on 26/07/2015 19:18:20, Paul Rubin wrote:
>> "Alex McDonald" <blog@rivadpm.com> writes:
>>> The definition of a 1 dimensional array is trivial; perhaps that's why.
>>> : 1dim create cells allot does> swap cells + ;
>>
>> You're going to use arrays with no bounds checks to script potentially
>> hostile internet devices? Sounds dangerous to me.
>>
>>
>
>That wasn't the original complaint; it was that there was not even a cell
>sized array in Forth.
>
>: 1dim create dup , cells allot
> does> 2dup @ 0 within abort" index out of bounds"
> swap 1+ cells + ;
This demonstrates why there is no built-in array word in Forth. You
may want named, bounds-checked arrays, you may want named
non-bounds-checked arrays, you may want unnamed bounds-checked arrays,
or you may want unnamed non-bounds-checked arrays. Now combined this
with the option of lower bound <>0, and you get 8 variants. And I
guess one can come up with cases where that is not sufficient.
BTW, instead of 0 WITHIN, you can also write U< 0= (or non-standard
U>=). Let's compare a few variations and see what VFX generates:
: foo1 0 within ; ok
see foo1
FOO1
( 080BF310 BA00000000 ) MOV EDX, 00000000
( 080BF315 2BD3 ) SUB EDX, EBX
( 080BF317 8B4D00 ) MOV ECX, [EBP]
( 080BF31A 2BCB ) SUB ECX, EBX
( 080BF31C 3BCA ) CMP ECX, EDX
( 080BF31E 1BDB ) SBB EBX, EBX
( 080BF320 8D6D04 ) LEA EBP, [EBP+04]
( 080BF323 C3 ) NEXT,
( 20 bytes, 8 instructions )
: foo2 u< 0= ;
FOO2 is redefined ok
see foo2
FOO2
( 080BF370 3B5D00 ) CMP EBX, [EBP]
( 080BF373 0F97C3 ) SETNBE/A BL
( 080BF376 F6DB ) NEG BL
( 080BF378 0FBEDB ) MOVSX EBX, BL
( 080BF37B F7D3 ) NOT EBX
( 080BF37D 8D6D04 ) LEA EBP, [EBP+04]
( 080BF380 C3 ) NEXT,
( 17 bytes, 7 instructions )
: foo3 u>= ; ok
see foo3
FOO3
( 080BF3A0 3B5D00 ) CMP EBX, [EBP]
( 080BF3A3 0F96C3 ) SETBE/NA BL
( 080BF3A6 F6DB ) NEG BL
( 080BF3A8 0FBEDB ) MOVSX EBX, BL
( 080BF3AB 8D6D04 ) LEA EBP, [EBP+04]
( 080BF3AE C3 ) NEXT,
( 15 bytes, 6 instructions )
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-07-27 01:12 -0700 |
| Message-ID | <878ua2qar9.fsf@jester.gateway.sonic.net> |
| In reply to | #40821 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > This demonstrates why there is no built-in array word in Forth. You > may want named, bounds-checked arrays, you may want named > non-bounds-checked arrays, you may want unnamed bounds-checked arrays, > or you may want unnamed non-bounds-checked arrays. Now combined this > with the option of lower bound <>0, and you get 8 variants. We're talking about scripting so there is no need for non-checked arrays. I don't see why lower bound <>0 makes more variants: Ada and Haskell support that for ordinary arrays. Other languages don't support it, suggesting that it's not so useful most of the time. Of somewhat more relevance for scripting is dictionaries as first-class values. For that, native string values and GC or refcounting help a lot.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-07-27 10:02 +0000 |
| Message-ID | <2015Jul27.120240@mips.complang.tuwien.ac.at> |
| In reply to | #40824 |
Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> This demonstrates why there is no built-in array word in Forth. You
>> may want named, bounds-checked arrays, you may want named
>> non-bounds-checked arrays, you may want unnamed bounds-checked arrays,
>> or you may want unnamed non-bounds-checked arrays. Now combined this
>> with the option of lower bound <>0, and you get 8 variants.
>
>We're talking about scripting so there is no need for non-checked
>arrays.
The complaint was about Forth, which is not limited to scripting. So
if anybody would have added more array-specific words, he would have
to either make a choice between these variants, or provide them all.
>I don't see why lower bound <>0 makes more variants: Ada and
>Haskell support that for ordinary arrays. Other languages don't support
>it, suggesting that it's not so useful most of the time.
So, not useful most of the time, but useful some of the time, but at
extra implementation cost. Sounds like anybody providing such words
would have to make a choice, or provide all variants.
>Of somewhat
>more relevance for scripting is dictionaries as first-class values. For
>that, native string values and GC or refcounting help a lot.
In my experience, they would not help at all. What I missed from
standard Forth in this area is:
* A variant of WORDLIST that does not fold case, in order to be able
to use arbitrary data as keys. Gforth provides that with TABLE.
* A good interface to insert programmatically-generated keys into
WORDLISTs or TABLEs. Gforth provides NEXTNAME, or one could use
EXECUTE-PARSING, but both are not really satisfactory.
What I have not missed is the capability to delete specific items from
a wordlist/table. I have also not missed "native strings" (whatever
that may be) or GC or refcounting.
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-07-27 13:44 +0100 |
| Message-ID | <mp591b$n8j$1@dont-email.me> |
| In reply to | #40829 |
on 27/07/2015 11:02:41, anton wrote: > In my experience, they would not help at all. What I missed from > standard Forth in this area is: > > * A variant of WORDLIST that does not fold case, in order to be able > to use arbitrary data as keys. Gforth provides that with TABLE. Yes, this is very useful. I have wordlist case-asis constant wid CASE-ASIS modifies WID to be case insensitive. WID is actually an object with 3 predefined & replaceable methods (create, find and iterate-over). > > * A good interface to insert programmatically-generated keys into > WORDLISTs or TABLEs. Gforth provides NEXTNAME, or one could use > EXECUTE-PARSING, but both are not really satisfactory. > > What I have not missed is the capability to delete specific items from > a wordlist/table. A variant of HIDE would suffice?
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-07-27 15:15 +0000 |
| Message-ID | <2015Jul27.171510@mips.complang.tuwien.ac.at> |
| In reply to | #40831 |
"Alex McDonald" <blog@rivadpm.com> writes:
>on 27/07/2015 11:02:41, anton wrote:
>
>> In my experience, they would not help at all. What I missed from
>> standard Forth in this area is:
>>
>> * A variant of WORDLIST that does not fold case, in order to be able
>> to use arbitrary data as keys. Gforth provides that with TABLE.
>
>Yes, this is very useful. I have
>
>wordlist case-asis constant wid
>
>CASE-ASIS modifies WID to be case insensitive.
Cute!
>> What I have not missed is the capability to delete specific items from
>> a wordlist/table.
>
>A variant of HIDE would suffice?
As I said, I have not missed it. So "nothing" suffices.
- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | glidedog@gmail.com |
|---|---|
| Date | 2015-07-27 04:52 -0700 |
| Message-ID | <3cbca55c-e604-4ae9-a445-3413186b679f@googlegroups.com> |
| In reply to | #40821 |
On 7/27/15 3:36 AM, Anton Ertl wrote: > "Alex McDonald" writes: >> on 26/07/2015 19:18:20, Paul Rubin wrote: >>> "Alex McDonald" writes: >>>> The definition of a 1 dimensional array is trivial; perhaps >>>> that's why. : 1dim create cells allot does> swap cells + ; >>> >>> You're going to use arrays with no bounds checks to script >>> potentially hostile internet devices? Sounds dangerous to me. >>> >>> >> >> That wasn't the original complaint; it was that there was not even >> a cell sized array in Forth. >> >> : 1dim create dup , cells allot does> 2dup @ 0 within abort" index >> out of bounds" swap 1+ cells + ; > > This demonstrates why there is no built-in array word in Forth. Does it? Not sure what harm providing Alex's first-try version as built in would cause. It's certainly a very common use case. It would not not prevent one from creating different versions if desired. As it is newbies to Forth must first learn the create ... does> idiom, which is definitely not trivial in my opinion, before they can do something as common as using an array the way Alex shows which I think is a good one. Or they must search the various libraries. It took me awhile to realize that the Forth standard, by its own explicit declaration, is constructed to minimize the word set to primarily support embedded programming. From the Forth standard 29 Feb 2012 "A.1.2 Scope The result of the effort to satisfy all of these objectives is a Standard arranged so that the required word set remains small. Thus ANS Forth can be provided for resource-constrained embedded systems." So I take this as the standing rationale for keeping Forth stripped down. This remark has since been removed. I don't know why. Nothing has changed. -Doug
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-07-27 14:01 +0100 |
| Message-ID | <mp5a0c$qot$1@dont-email.me> |
| In reply to | #40830 |
on 27/07/2015 12:52:50, wrote: > On 7/27/15 3:36 AM, Anton Ertl wrote: >> "Alex McDonald" writes: >>> on 26/07/2015 19:18:20, Paul Rubin wrote: >>>> "Alex McDonald" writes: >>>>> The definition of a 1 dimensional array is trivial; perhaps >>>>> that's why. : 1dim create cells allot does> swap cells + ; >>>> >>>> You're going to use arrays with no bounds checks to script >>>> potentially hostile internet devices? Sounds dangerous to me. >>>> >>>> >>> >>> That wasn't the original complaint; it was that there was not even >>> a cell sized array in Forth. >>> >>> : 1dim create dup , cells allot does> 2dup @ 0 within abort" index >>> out of bounds" swap 1+ cells + ; >> >> This demonstrates why there is no built-in array word in Forth. > > Does it? Not sure what harm providing Alex's first-try version as > built in would cause. It's certainly a very common use case. It would > not not prevent one from creating different versions if desired. Why should the language standard provide one use case and not others? > > As it is newbies to Forth must first learn the create ... does> idiom, > which is definitely not trivial in my opinion, before they can do > something as common as using an array the way Alex shows which I think > is a good one. Or they must search the various libraries. Which is why Hugh Aguilar wrote his "novice" package, which provides zero based, specifiable size element, arrays with up to 6 (!!!) possible dimensions. (Why 6?) If that helps you, then I suspect that you're never going to get very far as a competent Forth programmer. Providing such a set of arrays IMHO demonstrates the futility of trying to cover every eventuality, a goal it fails to achieve. What is true, and Rod Pemberton showed this in his response upthread, is a misunderstanding of how CREATE DOES> works. But contrast that with understanding how to use it successfully. Using CREATE DOES> is pretty simple and straightforward, as in this example, and I don't understand why you might think it so hard.
[toc] | [prev] | [next] | [standalone]
| From | glidedog@gmail.com |
|---|---|
| Date | 2015-07-27 06:16 -0700 |
| Message-ID | <16ca60eb-595d-49ac-b3c5-b122176f3398@googlegroups.com> |
| In reply to | #40833 |
On 7/27/15 9:01 AM, Alex McDonald wrote:> on 27/07/2015 12:52:50, wrote: >> On 7/27/15 3:36 AM, Anton Ertl wrote: >>> "Alex McDonald" writes: >>>> on 26/07/2015 19:18:20, Paul Rubin wrote: >>>>> "Alex McDonald" writes: >>>>>> The definition of a 1 dimensional array is trivial; perhaps >>>>>> that's why. : 1dim create cells allot does> swap cells + ; >>>>> >>>>> You're going to use arrays with no bounds checks to script >>>>> potentially hostile internet devices? Sounds dangerous to me. >>>>> >>>>> >>>> >>>> That wasn't the original complaint; it was that there was not even >>>> a cell sized array in Forth. >>>> >>>> : 1dim create dup , cells allot does> 2dup @ 0 within abort" index >>>> out of bounds" swap 1+ cells + ; >>> >>> This demonstrates why there is no built-in array word in Forth. >> >> Does it? Not sure what harm providing Alex's first-try version as >> built in would cause. It's certainly a very common use case. It would >> not not prevent one from creating different versions if desired. > > Why should the language standard provide one use case and not others? Because of the part you snipped. To keep the wordset as small as possible to primarily support embedded programming. It also explains why not even the one (most?)common array use case is provided. I accept all that. Doesn' explain the existence of words like cell+, cells, 1+, and many other truly trivial words, which I find somewhat baffling. -Doug
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-07-27 14:33 +0100 |
| Message-ID | <mp5bt4$266$1@dont-email.me> |
| In reply to | #40836 |
on 27/07/2015 14:16:56, wrote: > On 7/27/15 9:01 AM, Alex McDonald wrote:> on 27/07/2015 12:52:50, > > wrote: >>> On 7/27/15 3:36 AM, Anton Ertl wrote: > > wrote: >>>> "Alex McDonald" writes: > > wrote: >>>>> on 26/07/2015 19:18:20, Paul Rubin wrote: > > wrote: >>>>>> "Alex McDonald" writes: > > wrote: >>>>>>> The definition of a 1 dimensional array is trivial; perhaps > > wrote: >>>>>>> that's why. : 1dim create cells allot does> swap cells + ; > > wrote: >>>>>> > > wrote: >>>>>> You're going to use arrays with no bounds checks to script > > wrote: >>>>>> potentially hostile internet devices? Sounds dangerous to me. > > wrote: >>>>>> > > wrote: >>>>>> > > wrote: >>>>> > > wrote: >>>>> That wasn't the original complaint; it was that there was not even > > wrote: >>>>> a cell sized array in Forth. > > wrote: >>>>> > > wrote: >>>>> : 1dim create dup , cells allot does> 2dup @ 0 within abort" index > > wrote: >>>>> out of bounds" swap 1+ cells + ; > > wrote: >>>> > > wrote: >>>> This demonstrates why there is no built-in array word in Forth. > > wrote: >>> > > wrote: >>> Does it? Not sure what harm providing Alex's first-try version as > > wrote: >>> built in would cause. It's certainly a very common use case. It would > > wrote: >>> not not prevent one from creating different versions if desired. > > wrote: >> > > wrote: >> Why should the language standard provide one use case and not others? > wrote: > > Because of the part you snipped. To keep the wordset as small as > possible to primarily support embedded programming. It also explains > why not even the one (most?)common array use case is provided. I > accept all that. Doesn' explain the existence of words like cell+, > cells, 1+, and many other truly trivial words, which I find somewhat > baffling. > > -Doug > The optional wordset may be large, but the core wordset is still very small. One reason that CELL+ 1+ etc make it is due to (most not all) processor architectures where such operations can be single instructions. Most Forth systems, especially DTC and ITC, don't provide optimisations to make 1 + an INCrement for instance. And the baggage of history. There are no array words because no-one since Forth-79 some 46 years ago has ever seen the need to standardise them. Provide them, sure; and many have done so.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-07-27 14:34 +0100 |
| Message-ID | <mp5bv6$266$2@dont-email.me> |
| In reply to | #40837 |
on 27/07/2015 14:33:56, "Alex McDonald" wrote: > on 27/07/2015 14:16:56, wrote: >> On 7/27/15 9:01 AM, Alex McDonald wrote:> on 27/07/2015 12:52:50, >> > wrote: >>>> On 7/27/15 3:36 AM, Anton Ertl wrote: >> > wrote: >>>>> "Alex McDonald" writes: >> > wrote: >>>>>> on 26/07/2015 19:18:20, Paul Rubin wrote: >> > wrote: >>>>>>> "Alex McDonald" writes: >> > wrote: >>>>>>>> The definition of a 1 dimensional array is trivial; perhaps >> > wrote: >>>>>>>> that's why. : 1dim create cells allot does> swap cells + ; >> > wrote: >>>>>>> >> > wrote: >>>>>>> You're going to use arrays with no bounds checks to script >> > wrote: >>>>>>> potentially hostile internet devices? Sounds dangerous to me. >> > wrote: >>>>>>> >> > wrote: >>>>>>> >> > wrote: >>>>>> >> > wrote: >>>>>> That wasn't the original complaint; it was that there was not even >> > wrote: >>>>>> a cell sized array in Forth. >> > wrote: >>>>>> >> > wrote: >>>>>> : 1dim create dup , cells allot does> 2dup @ 0 within abort" index >> > wrote: >>>>>> out of bounds" swap 1+ cells + ; >> > wrote: >>>>> >> > wrote: >>>>> This demonstrates why there is no built-in array word in Forth. >> > wrote: >>>> >> > wrote: >>>> Does it? Not sure what harm providing Alex's first-try version as >> > wrote: >>>> built in would cause. It's certainly a very common use case. It would >> > wrote: >>>> not not prevent one from creating different versions if desired. >> > wrote: >>> >> > wrote: >>> Why should the language standard provide one use case and not others? >> wrote: >> >> Because of the part you snipped. To keep the wordset as small as >> possible to primarily support embedded programming. It also explains >> why not even the one (most?)common array use case is provided. I >> accept all that. Doesn' explain the existence of words like cell+, >> cells, 1+, and many other truly trivial words, which I find somewhat >> baffling. >> >> -Doug >> > > The optional wordset may be large, but the core wordset is still very > small. One reason that CELL+ 1+ etc make it is due to (most not all) > processor architectures where such operations can be single > instructions. Most Forth systems, especially DTC and ITC, don't > provide optimisations to make 1 + an INCrement for instance. And the > baggage of history. > > There are no array words because no-one since Forth-79 some 46 years > ago has ever seen the need to standardise them. Provide them, sure; > and many have done so. > 46? Time flies, but not that fast. 36 was meant.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-07-27 10:47 -0700 |
| Message-ID | <874mkpqyq8.fsf@jester.gateway.sonic.net> |
| In reply to | #40837 |
"Alex McDonald" <blog@rivadpm.com> writes: > The optional wordset may be large, but the core wordset is still very > small. I was surprised to notice that the core wordset contains quite a bit of what I'd consider to be bloat, e.g. words for fancy output formatting that typical embedded applications would have no way to use (no text output device!), and that for interactive testing are at best only slightly useful.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-07-27 08:12 -1000 |
| Message-ID | <0YydnbhAWZUT6SvInZ2dnUU7-TOdnZ2d@supernews.com> |
| In reply to | #40844 |
On 7/27/15 7:47 AM, Paul Rubin wrote: > "Alex McDonald" <blog@rivadpm.com> writes: >> The optional wordset may be large, but the core wordset is still very >> small. > > I was surprised to notice that the core wordset contains quite a bit of > what I'd consider to be bloat, e.g. words for fancy output formatting > that typical embedded applications would have no way to use (no text > output device!), and that for interactive testing are at best only > slightly useful. > Don't forget, the core wordset doesn't have to be present in a kernel or running system. In fact, it is explicitly ok to provide words as loadable options or even on paper. Sure, an embedded system without output wouldn't use a lot of things. But programmers want some general level of facilities they can count on being able to find if they need them. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-07-27 11:24 -0700 |
| Message-ID | <87wpxlpifo.fsf@jester.gateway.sonic.net> |
| In reply to | #40846 |
"Elizabeth D. Rather" <erather@forth.com> writes: > Don't forget, the core wordset doesn't have to be present in a kernel > or running system. In fact, it is explicitly ok to provide words as > loadable options or even on paper. I would have thought "loadable options" was another way to say "optional" and the organization of the standard was that words that weren't important in a minimal core would be put in optional word sets. > Sure, an embedded system without output wouldn't use a lot of > things. But programmers want some general level of facilities they can > count on being able to find if they need them. Sure, but given typical Forth programs, I'd have thought that the formatted output stuff was relatively deluxe and belonged in an optional set. By contrast I'd keep KEY, EMIT, and friends in the core set, even though those same embedded systems couldn't use them.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-07-27 08:41 -1000 |
| Message-ID | <NtidncHurOjN5ivInZ2dnUU7-eGdnZ2d@supernews.com> |
| In reply to | #40849 |
On 7/27/15 8:24 AM, Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> Don't forget, the core wordset doesn't have to be present in a kernel >> or running system. In fact, it is explicitly ok to provide words as >> loadable options or even on paper. > > I would have thought "loadable options" was another way to say > "optional" and the organization of the standard was that words that > weren't important in a minimal core would be put in optional word sets. No, that is not the intent. Optional wordsets don't have to be provided in any form. Core words can be provided in many forms, not necessarily in a kernel or always resident. >> Sure, an embedded system without output wouldn't use a lot of >> things. But programmers want some general level of facilities they can >> count on being able to find if they need them. > > Sure, but given typical Forth programs, I'd have thought that the > formatted output stuff was relatively deluxe and belonged in an optional > set. By contrast I'd keep KEY, EMIT, and friends in the core set, even > though those same embedded systems couldn't use them. > The Core Wordset is the minimal expectation for a programmable system, and includes a lot of things that might be useful in the programming process but not necessarily in a final application. It also includes, for example, words that would be difficult or inefficient to add without "carnal knowledge". Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-07-27 12:49 -0700 |
| Message-ID | <87si89peis.fsf@jester.gateway.sonic.net> |
| In reply to | #40850 |
"Elizabeth D. Rather" <erather@forth.com> writes: > No, that is not the intent. Optional wordsets don't have to be > provided in any form. Core words can be provided in many forms, not > necessarily in a kernel or always resident. Aha, thanks for pointing out that distinction. > The Core Wordset is the minimal expectation for a programmable system, > and includes a lot of things that might be useful in the programming > process but not necessarily in a final application. It also includes, > for example, words that would be difficult or inefficient to add > without "carnal knowledge". If the criterion is "might be useful" that covers the kitchen sink! I'd expect the formatted output stuff is straightforward to implement in portable Forth, and not likely that important in the programming process given the availability of dot, dot-quote, TYPE, and so on.
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2015-07-27 14:38 -0700 |
| Message-ID | <c9d7c3d1-480a-4a4e-9e36-8a2aeb173733@googlegroups.com> |
| In reply to | #40853 |
On Monday, July 27, 2015 at 2:49:16 PM UTC-5, Paul Rubin wrote: > If the criterion is "might be useful" that covers the kitchen sink! If the ridiculous were the case, then things would be ridiculous. > I'd expect the formatted output stuff is straightforward to implement in > portable Forth, and not likely that important in the programming process > given the availability of dot, dot-quote, TYPE, and so on. OK, next time my time machine is available, I'll hop into it and try get the Forth-79 people to not include pictured numeric output. I had "settle WWI in favor of Germany" next on my list of things to do, but this is probably a better cause. Speaking of Forth-79, it has an interesting section that included 'uncontrolled word definitions', "included for public reference of words that have present usage and/or are candidates for future standardization". Interesting as these words seem to be pretty obscure. !BITS ( n1 addr n2 -- ) Store the value of n1 masked by n2 into the equivalent masked part of the contents of addr, without affecting bits outside the mask. +BLOCK ( n1 -- n2 ) Leave the sum of n1 plus the number of the block being interpreted. -' ( -- addr 0 | -1 ) Leave the paraeter field of <name> beneath zero (false) if the name can be found in the CONTEXT vocabulary; leave only true if not found. COM ( n1 -- n2 ) Leave the one's complement of n1. And there several words that have new names. IFTRUE ... OTHERWISE ... IFEND f.e. works similarly to [IF] ... [ELSE] ... [THEN] REMEMBER is basically MARKER SET ( n addr -- ) Defines a word <name> which, when executed, will cause the value n to be stored at address. WHERE Output information about the status of FORTH, (e.g., after an error abort). Indicate at least the last word compiled and the last word accessed. -- Julian
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-07-27 12:02 -1000 |
| Message-ID | <PZqdnaXv_afENyvInZ2dnUU7-QudnZ2d@supernews.com> |
| In reply to | #40853 |
On 7/27/15 9:49 AM, Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> No, that is not the intent. Optional wordsets don't have to be >> provided in any form. Core words can be provided in many forms, not >> necessarily in a kernel or always resident. > > Aha, thanks for pointing out that distinction. > >> The Core Wordset is the minimal expectation for a programmable system, >> and includes a lot of things that might be useful in the programming >> process but not necessarily in a final application. It also includes, >> for example, words that would be difficult or inefficient to add >> without "carnal knowledge". > > If the criterion is "might be useful" that covers the kitchen sink! > I'd expect the formatted output stuff is straightforward to implement in > portable Forth, and not likely that important in the programming process > given the availability of dot, dot-quote, TYPE, and so on. Yes, well, the choice was a "negotiated settlement" between advocates of radical minmalism and "kitchen sink" enthusiasts! In the case of the formatted output stuff, though, it would be really hard to know how to implement words like # #S HOLD etc. without knowing where the numeric output string was being constructed and how to manage the process. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-07-27 11:16 -0700 |
| Message-ID | <3ea434ae-832a-4297-9e97-d1073ca9dff6@googlegroups.com> |
| In reply to | #40844 |
On Monday, July 27, 2015 at 10:47:29 AM UTC-7, Paul Rubin wrote: > "Alex McDonald" <blog@rivadpm.com> writes: > > The optional wordset may be large, but the core wordset is still very > > small. > > I was surprised to notice that the core wordset contains quite a bit of > what I'd consider to be bloat, e.g. words for fancy output formatting > that typical embedded applications would have no way to use (no text > output device!), and that for interactive testing are at best only > slightly useful. I have been saying since 2009 that Forth-200x is doomed to failure because it is a single language-standard that is supposed to work on hugely different targets. A better plan would be to have two versions of Forth, and both standardized --- one for micro-controllers and one for desktop-computers. The micro-controller Forth would always be cross-compiled (the cross-compiler would be written in the desktop-computer Forth). It would be quite minimal compared to the grossly bloated ANS-Forth standard. It would work with different cell sizes (16-bit or 32-bit typically). The desktop-computer Forth would be 64-bit and would have a lot more support for text and numerical programming. It would also be designed specifically to support a cross-compiler though; it would have features not available in Forth-200x (such as being able to examine an xt and determine what word-list it is in and whether it is immediate or not). Realistically, you can't have one language standard that works on both the 64-bit x86 and the 16-bit MSP-430 --- you are going to be a "jack of all trades and a master of none" --- this is the path to failure that Forth-200x is striding down, following closely on ANS-Forth's heals.
[toc] | [prev] | [next] | [standalone]
Page 2 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