Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
CELL and CELL+ Words
216 views
Skip to first unread message
Charles Richmond
Sep 15, 2012, 3:24:53 PM9/15/12
to
I am trying to write a program using the FORTH-83 standard, and I have *no*
CELL or CELL+ words. Can someone tell me exactly how to implement these
words using only the FORTH-83 standard words???
--
numerist at aquaporin4 dot com
CELL or CELL+ words. Can someone tell me exactly how to implement these
words using only the FORTH-83 standard words???
--
numerist at aquaporin4 dot com
Mark Wills
Sep 15, 2012, 4:32:56 PM9/15/12
to
On Sep 15, 8:24 pm, "Charles Richmond" <numer...@aquaporin4.com>
wrote:
Okay, if it's Forth 83 then it's a 16 bit system. So:
: CELLS 2* ;
: CELLS+ CELLS + ;
I'm not sure what you would want CELL for? I guess it's definition
would be:
: CELL 2 ;
For a 16 bit system. But you might as wee just say 1 CELLS
You might want CHARS also. On my 16-bit Forth-83 system it's simply:
: CHARS ( n -- n) ;
I.e. it doesn't do anything!
Hope this helps.
Mark
wrote:
: CELLS 2* ;
: CELLS+ CELLS + ;
I'm not sure what you would want CELL for? I guess it's definition
would be:
: CELL 2 ;
For a 16 bit system. But you might as wee just say 1 CELLS
You might want CHARS also. On my 16-bit Forth-83 system it's simply:
: CHARS ( n -- n) ;
I.e. it doesn't do anything!
Hope this helps.
Mark
Jason Damisch
Sep 15, 2012, 4:33:40 PM9/15/12
to Charles Richmond
> CELL or CELL+ words. Can someone tell me exactly how to implement these
>
> words using only the FORTH-83 standard words???
16 bit
: CELL 2 ;
: CELL+ 2+ ;
32 bit
: CELL 4 ;
: CELL+ 4 + ;
Elizabeth D. Rather
Sep 15, 2012, 4:53:47 PM9/15/12
to
compile anything. :-)
>
> Hope this helps.
>
> Mark
>
--
==================================================
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."
==================================================
Mark Wills
Sep 15, 2012, 5:25:37 PM9/15/12
to
>
> "Forth-based products and Services for real-time
> applications since 1973."
> ==================================================
Well spotted! That was of course a deliberate mistake to see who was
> "Forth-based products and Services for real-time
> applications since 1973."
> ==================================================
paying attention ;-)
Mark
Rod Pemberton
Sep 15, 2012, 11:34:54 PM9/15/12
to
"Mark Wills" <forth...@gmail.com> wrote in message
news:05e83358-6ce4-4fba...@o19g2000vbo.googlegroups.com...
Where did that word come from?
I took it he was wanting ANS' CELLS and CELL+ for Forth 83, assuming
he mistyped CELL for CELLS ...
> [...]
> I'm not sure what you would want CELL for?
Obviously ... to do this:
: CELL 2 ;
: CELL+ CELL + ;
: CELLS CELL * ;
Oh, you were pointing out your suspicion he had a typo too... You point it
out rather dryly: ask why CELL is needed and place an extra S on CELL+
and CELL... That was very droll.
Rod Pemberton
news:05e83358-6ce4-4fba...@o19g2000vbo.googlegroups.com...
> On Sep 15, 8:24 pm, "Charles Richmond" <numer...@aquaporin4.com>
> wrote:
> > I am trying to write a program using the FORTH-83 standard, and I
> > have *no* CELL or CELL+ words. Can someone tell me exactly how
> > to implement these words using only the FORTH-83 standard words???
>
>
> wrote:
> > I am trying to write a program using the FORTH-83 standard, and I
> > have *no* CELL or CELL+ words. Can someone tell me exactly how
> > to implement these words using only the FORTH-83 standard words???
>
>
> Okay, if it's Forth 83 then it's a 16 bit system. So:
>
> : CELLS 2* ;
> : CELLS+ CELLS + ;
>
"CELLS+"
>
> : CELLS 2* ;
> : CELLS+ CELLS + ;
>
Where did that word come from?
I took it he was wanting ANS' CELLS and CELL+ for Forth 83, assuming
he mistyped CELL for CELLS ...
> [...]
> I guess it's definition would be:
>
> : CELL 2 ;
...
>
> : CELL 2 ;
> I'm not sure what you would want CELL for?
: CELL 2 ;
: CELL+ CELL + ;
: CELLS CELL * ;
Oh, you were pointing out your suspicion he had a typo too... You point it
out rather dryly: ask why CELL is needed and place an extra S on CELL+
and CELL... That was very droll.
Rod Pemberton
Mark Wills
Sep 16, 2012, 4:23:15 AM9/16/12
to
On Sep 16, 4:31 am, "Rod Pemberton" <do_not_h...@notemailnotz.cmm>
wrote:
> "Mark Wills" <forthfr...@gmail.com> wrote in message
Actually I wasn't being facetious. I don't actually recall seeing CELL
and CELL+ in legacy code before (Forth Dimensions being just about my
only source, apart from the smattering of books that I have). I'm only
aware of CHARS and CELLS, and (later I became aware of) CELLS+. Note,
all plurals. I'm not aware of the singular (CELL CELL+).
To recap, my system, which *is* Forth 83 compliant (with a fairly
generous smattering of ANS94 too - in fact, it wouldn't take much work
to make it ANS94 compliant) has CHARS and CELLS, as follows:
: CHARS ( -- ) ; IMMEDIATE
: CELLS ( #cells -- #bytes) 2* ;
At start-up I don't have CELLS+. When needed I define it as follows:
: CELLS+ CELLS + ;
Or, for slightly better performance on a lowly ITC system such as
mine:
: CELLS+ ( n --) COMPILE CELLS COMPILE + ; IMMEDIATE
I can only think that the OP is looking at some code that has CELL
defined in order to make the code a little clearer to understand. It's
probably not worth the expense of a colon definition; probably better
to use a constant, if the OP's system supports it:
2 CONSTANT CELL
Et voilà.
As you pointed out though, I think you're right: CELL+ is probably is
typo. It probably should be CELLS+.
----------------------
As a total aside, in case it's interesting to you Rod (as I know
you're working on an ITC system) in my system the CFA of CELLS
actually points to the machine code of 2*. That way, I save 4 bytes
(yes, memory is that tight in the 16K ROM in which it is
implemented!). Thus CELLS uses 2*'s shift instruction and call to
NEXT. :-)
Mark
wrote:
> "Mark Wills" <forthfr...@gmail.com> wrote in message
and CELL+ in legacy code before (Forth Dimensions being just about my
only source, apart from the smattering of books that I have). I'm only
aware of CHARS and CELLS, and (later I became aware of) CELLS+. Note,
all plurals. I'm not aware of the singular (CELL CELL+).
To recap, my system, which *is* Forth 83 compliant (with a fairly
generous smattering of ANS94 too - in fact, it wouldn't take much work
to make it ANS94 compliant) has CHARS and CELLS, as follows:
: CHARS ( -- ) ; IMMEDIATE
: CELLS ( #cells -- #bytes) 2* ;
At start-up I don't have CELLS+. When needed I define it as follows:
: CELLS+ CELLS + ;
Or, for slightly better performance on a lowly ITC system such as
mine:
: CELLS+ ( n --) COMPILE CELLS COMPILE + ; IMMEDIATE
I can only think that the OP is looking at some code that has CELL
defined in order to make the code a little clearer to understand. It's
probably not worth the expense of a colon definition; probably better
to use a constant, if the OP's system supports it:
2 CONSTANT CELL
Et voilà.
As you pointed out though, I think you're right: CELL+ is probably is
typo. It probably should be CELLS+.
----------------------
As a total aside, in case it's interesting to you Rod (as I know
you're working on an ITC system) in my system the CFA of CELLS
actually points to the machine code of 2*. That way, I save 4 bytes
(yes, memory is that tight in the 16K ROM in which it is
implemented!). Thus CELLS uses 2*'s shift instruction and call to
NEXT. :-)
Mark
Coos Haak
Sep 16, 2012, 9:53:42 AM9/16/12
to
Op Sun, 16 Sep 2012 01:23:15 -0700 (PDT) schreef Mark Wills:
<snip>
Long story short: ISO/ANS Forth only has CHARS CHAR+ CELLS CELL+
CELLS+ and +CELLS are found in F-PC and Win32Forth.
--
Coos
CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html
<snip>
Long story short: ISO/ANS Forth only has CHARS CHAR+ CELLS CELL+
CELLS+ and +CELLS are found in F-PC and Win32Forth.
--
Coos
CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html
Hugh Aguilar
Sep 16, 2012, 8:44:43 PM9/16/12
to
On Sep 15, 12:24 pm, "Charles Richmond" <numer...@aquaporin4.com>
wrote:
Back in the old days of Forth-83, pretty much everybody defined
constants of their data type sizes. This is basic abstraction ---
define constants rather than use literals scattered about so that if
the value changes in the future (upgrading from 16-bit to 32-bit, for
example), only the constant needs to be changed.
I don't like CELLS just because it is a big word and tends to clutter
up the source-code. I used W in those days, and I still do.
In my novice package (http://www.forth.org/novice.html) I have this:
1 chars constant c
1 cells constant w
2 cells constant d
1 floats constant f
You can also have W+ and W* if your Forth doesn't do any optimization
to take care of this kind of thing automatically.
Are you writing in UR/Forth?
wrote:
constants of their data type sizes. This is basic abstraction ---
define constants rather than use literals scattered about so that if
the value changes in the future (upgrading from 16-bit to 32-bit, for
example), only the constant needs to be changed.
I don't like CELLS just because it is a big word and tends to clutter
up the source-code. I used W in those days, and I still do.
In my novice package (http://www.forth.org/novice.html) I have this:
1 chars constant c
1 cells constant w
2 cells constant d
1 floats constant f
You can also have W+ and W* if your Forth doesn't do any optimization
to take care of this kind of thing automatically.
Are you writing in UR/Forth?
Charles Richmond
Sep 17, 2012, 1:15:15 PM9/17/12
to
"Mark Wills" <forth...@gmail.com> wrote in message
news:bf750a8c-b51b-4631...@fm12g2000vbb.googlegroups.com...
>
> [snip...] [snip...] [snip...]
>
>Actually I wasn't being facetious. I don't actually recall seeing CELL
>and CELL+ in legacy code before (Forth Dimensions being just about my
>only source, apart from the smattering of books that I have). I'm only
>aware of CHARS and CELLS, and (later I became aware of) CELLS+. Note,
>all plurals. I'm not aware of the singular (CELL CELL+).
>
>To recap, my system, which *is* Forth 83 compliant (with a fairly
>generous smattering of ANS94 too - in fact, it wouldn't take much work
>to make it ANS94 compliant) has CHARS and CELLS, as follows:
>
>: CHARS ( -- ) ; IMMEDIATE
>: CELLS ( #cells -- #bytes) 2* ;
>
>At start-up I don't have CELLS+. When needed I define it as follows:
>
>: CELLS+ CELLS + ;
>
>Or, for slightly better performance on a lowly ITC system such as
>mine:
>
>: CELLS+ ( n --) COMPILE CELLS COMPILE + ; IMMEDIATE
>
>I can only think that the OP is looking at some code that has CELL
>defined in order to make the code a little clearer to understand. It's
>probably not worth the expense of a colon definition; probably better
>to use a constant, if the OP's system supports it:
>
>2 CONSTANT CELL
>
>Et voil�.
>Actually I wasn't being facetious. I don't actually recall seeing CELL
>and CELL+ in legacy code before (Forth Dimensions being just about my
>only source, apart from the smattering of books that I have). I'm only
>aware of CHARS and CELLS, and (later I became aware of) CELLS+. Note,
>all plurals. I'm not aware of the singular (CELL CELL+).
>
>To recap, my system, which *is* Forth 83 compliant (with a fairly
>generous smattering of ANS94 too - in fact, it wouldn't take much work
>to make it ANS94 compliant) has CHARS and CELLS, as follows:
>
>: CHARS ( -- ) ; IMMEDIATE
>: CELLS ( #cells -- #bytes) 2* ;
>
>At start-up I don't have CELLS+. When needed I define it as follows:
>
>: CELLS+ CELLS + ;
>
>Or, for slightly better performance on a lowly ITC system such as
>mine:
>
>: CELLS+ ( n --) COMPILE CELLS COMPILE + ; IMMEDIATE
>
>I can only think that the OP is looking at some code that has CELL
>defined in order to make the code a little clearer to understand. It's
>probably not worth the expense of a colon definition; probably better
>to use a constant, if the OP's system supports it:
>
>2 CONSTANT CELL
>
>
>As you pointed out though, I think you're right: CELL+ is probably is
>typo. It probably should be CELLS+.
OP here: I got the CELL+ and (you are right) CELLS from Leo Brodie's
>As you pointed out though, I think you're right: CELL+ is probably is
>typo. It probably should be CELLS+.
_Starting Forth_ book on the Forth Inc. web site:
http://www.forth.com/starting-forth/sf8/sf8.html
I was interested in defining a word to create a two-dimensional array.
Perhaps I need to re-read this chapter...
Charles Richmond
Sep 17, 2012, 1:20:51 PM9/17/12
to
"Hugh Aguilar" <hughag...@yahoo.com> wrote in message
news:d6b76291-a003-4894...@pz10g2000pbb.googlegroups.com...
make the program "FORTH-83" compliant.
news:d6b76291-a003-4894...@pz10g2000pbb.googlegroups.com...
On Sep 15, 12:24 pm, "Charles Richmond" <numer...@aquaporin4.com>
wrote:
>> I am trying to write a program using the FORTH-83 standard, and I have
>> *no*
>> CELL or CELL+ words. Can someone tell me exactly how to implement these
>> words using only the FORTH-83 standard words???
>>
>
wrote:
>> I am trying to write a program using the FORTH-83 standard, and I have
>> *no*
>> CELL or CELL+ words. Can someone tell me exactly how to implement these
>> words using only the FORTH-83 standard words???
>>
>
>Back in the old days of Forth-83, pretty much everybody defined
>constants of their data type sizes. This is basic abstraction ---
>define constants rather than use literals scattered about so that if
>the value changes in the future (upgrading from 16-bit to 32-bit, for
>example), only the constant needs to be changed.
>
>I don't like CELLS just because it is a big word and tends to clutter
>up the source-code. I used W in those days, and I still do.
>
>In my novice package (http://www.forth.org/novice.html) I have this:
>
>1 chars constant c
>1 cells constant w
>2 cells constant d
>1 floats constant f
>
>You can also have W+ and W* if your Forth doesn't do any optimization
>to take care of this kind of thing automatically.
>
>Are you writing in UR/Forth?
My application is actually being written using F-PC, but I was hoping to
>constants of their data type sizes. This is basic abstraction ---
>define constants rather than use literals scattered about so that if
>the value changes in the future (upgrading from 16-bit to 32-bit, for
>example), only the constant needs to be changed.
>
>I don't like CELLS just because it is a big word and tends to clutter
>up the source-code. I used W in those days, and I still do.
>
>In my novice package (http://www.forth.org/novice.html) I have this:
>
>1 chars constant c
>1 cells constant w
>2 cells constant d
>1 floats constant f
>
>You can also have W+ and W* if your Forth doesn't do any optimization
>to take care of this kind of thing automatically.
>
>Are you writing in UR/Forth?
make the program "FORTH-83" compliant.
Message has been deleted
Hugh Aguilar
Sep 17, 2012, 6:44:03 PM9/17/12
to
On Sep 17, 10:15 am, "Charles Richmond" <numer...@aquaporin4.com>
wrote:
like all Forth Inc. publications it is ultra-novice level. I wouldn't
bother with it.
There are a couple of array definers in my novice package that you can
use.
http://www.forth.org/novice.html
Everything in there is ANS-Forth, but it should be no problem to
convert it into Forth-83.
wrote:
> OP here: I got the CELL+ and (you are right) CELLS from Leo Brodie's
> _Starting Forth_ book on the Forth Inc. web site:
>
> http://www.forth.com/starting-forth/sf8/sf8.html
>
> I was interested in defining a word to create a two-dimensional array.
>
> Perhaps I need to re-read this chapter...
"Starting Forth" is a cute book, what with all of the cartoons, but
> _Starting Forth_ book on the Forth Inc. web site:
>
> http://www.forth.com/starting-forth/sf8/sf8.html
>
> I was interested in defining a word to create a two-dimensional array.
>
> Perhaps I need to re-read this chapter...
like all Forth Inc. publications it is ultra-novice level. I wouldn't
bother with it.
There are a couple of array definers in my novice package that you can
use.
http://www.forth.org/novice.html
Everything in there is ANS-Forth, but it should be no problem to
convert it into Forth-83.
Hugh Aguilar
Sep 17, 2012, 6:54:52 PM9/17/12
to
On Sep 17, 10:20 am, "Charles Richmond" <numer...@aquaporin4.com>
wrote:
> "Hugh Aguilar" <hughaguila...@yahoo.com> wrote in message
> news:d6b76291-a003-4894...@pz10g2000pbb.googlegroups.com...
PC) in which the stack pointer could sometimes be an odd number, which
kills the speed.
I used TCOM a lot for creating .com utilities, but never much cared
for F-PC --- UR/Forth was better for writing large programs. I also
had another Forth compiler for generating MS-DOS programs, but it
wasn't interactive.
Why are you messing with MS-DOS anyway?
wrote:
> "Hugh Aguilar" <hughaguila...@yahoo.com> wrote in message
> news:d6b76291-a003-4894...@pz10g2000pbb.googlegroups.com...
> >Are you writing in UR/Forth?
>
> My application is actually being written using F-PC, but I was hoping to
> make the program "FORTH-83" compliant.
There was a bug in F-PC (it may have been TCOM, but I think it was F-
>
> My application is actually being written using F-PC, but I was hoping to
> make the program "FORTH-83" compliant.
PC) in which the stack pointer could sometimes be an odd number, which
kills the speed.
I used TCOM a lot for creating .com utilities, but never much cared
for F-PC --- UR/Forth was better for writing large programs. I also
had another Forth compiler for generating MS-DOS programs, but it
wasn't interactive.
Why are you messing with MS-DOS anyway?
Ed
Sep 18, 2012, 3:31:09 AM9/18/12
to
Charles Richmond wrote:
> ...
by most Forth primers (a hint to authors).
Below is a typical implementation.
\ Multi-dimension array
: ARRAY ( dimn..dim1 n itemsize "name" )
create
>r dup c, 1 swap 0 do over , * loop r> dup , *
dup 0< abort" array size" allot
does> ( idxn..idx1 -- addr )
count 0 tuck do >r cell+ dup @ rot r> + * loop + cell+ ;
If speed is an issue the DOES> part can be written in
machine-code. For an 8086 DTC forth with TOS on
stack, it might look like this:
: ARRAY ( dimn..dim1 n itemsize "name" )
create
>r dup c, 1 swap 0 do over , * loop r> dup , *
dup 0< abort" array size" allot
;code ( idxn..idx1 -- addr ) bx pop ( pfa)
0 [bx] cl mov ch ch sub bx inc ax ax sub
1 $: dx pop dx ax add 2 # bx add 0 [bx] mul 1 $ loop
bx inc bx inc ax bx add bx push next end-code
> ...
> http://www.forth.com/starting-forth/sf8/sf8.html
>
> I was interested in defining a word to create a two-dimensional array.
>
> Perhaps I need to re-read this chapter...
For whatever reason, multi-dimension arrays are ignored
>
> I was interested in defining a word to create a two-dimensional array.
>
> Perhaps I need to re-read this chapter...
by most Forth primers (a hint to authors).
Below is a typical implementation.
\ Multi-dimension array
: ARRAY ( dimn..dim1 n itemsize "name" )
create
>r dup c, 1 swap 0 do over , * loop r> dup , *
dup 0< abort" array size" allot
does> ( idxn..idx1 -- addr )
count 0 tuck do >r cell+ dup @ rot r> + * loop + cell+ ;
If speed is an issue the DOES> part can be written in
machine-code. For an 8086 DTC forth with TOS on
stack, it might look like this:
: ARRAY ( dimn..dim1 n itemsize "name" )
create
>r dup c, 1 swap 0 do over , * loop r> dup , *
dup 0< abort" array size" allot
;code ( idxn..idx1 -- addr ) bx pop ( pfa)
0 [bx] cl mov ch ch sub bx inc ax ax sub
1 $: dx pop dx ax add 2 # bx add 0 [bx] mul 1 $ loop
bx inc bx inc ax bx add bx push next end-code
Mark Wills
Sep 18, 2012, 4:53:44 AM9/18/12
to
On Sep 17, 6:15 pm, "Charles Richmond" <numer...@aquaporin4.com>
wrote:
> "Mark Wills" <forthfr...@gmail.com> wrote in message
>
> - Show quoted text -
Well, here is what I came up with:
: 2dArray ( compile: r c -- children: r c -- addr )
create dup cells , * cells allot
does> dup >r @ rot * swap cells + r> 2+ + ;
I was surprised it was as large as that, and I figure I must be
missing something much simpler here.
Here it is line by line:
: 2dArray
create \ create the dictionary entry
dup \ duplicate columns
cells \ convert it to bytes (array pitch)
, \ store it in pfa of child
* \ multiply row and columns
cells allot \ convert to bytes and allot them
does> \ behaviour of the children:
dup >r \ dup pfa and save on return stack
@ \ fetch array pitch
rot \ get rows on top of stack
* \ multiply by array pitch
swap cells \ get columns and convert to bytes
+ \ add rows
r> \ get pfa back from return stack
1 CELLS+ \ add 1 cell to account for pitch storage
+ \ add to row/column offset
;
Create an array like this:
8 9 2dArray fred
The above creates an array called fred that is 8 rows by 9 columns.
To access the array, simply state row, column, and the array name
followed by ! or @:
3 4 fred @
Fetches the contents of the cell at row 3 column 4. (Rows and columns
start at 0)
To write to a cell, place your payload, your row and column, and your
array:
1234 3 4 fred !
I gave it a quick test and it seems to work fine. Note: In true Forth
fashion, there are no array bounds checks! You're on your own! It
would be a useful excercise to add array bounds checking.
Please feel free to ask questions if anything is unclear. Please also
note though that while the code above does work, I feel a bit uneasy
about it. I have a nagging feeling that "there must be a simpler way".
I didn't want your post to go unanswered though. I'd be interested to
see how Elizabeth et would tackle the problem.
Regards
Mark
wrote:
> "Mark Wills" <forthfr...@gmail.com> wrote in message
>
> news:bf750a8c-b51b-4631...@fm12g2000vbb.googlegroups.com...
>
>
>
>
>
>
>
> > [snip...] [snip...] [snip...]
>
> >Actually I wasn't being facetious. I don't actually recall seeing CELL
> >and CELL+ in legacy code before (Forth Dimensions being just about my
> >only source, apart from the smattering of books that I have). I'm only
> >aware of CHARS and CELLS, and (later I became aware of) CELLS+. Note,
> >all plurals. I'm not aware of the singular (CELL CELL+).
>
> >To recap, my system, which *is* Forth 83 compliant (with a fairly
> >generous smattering of ANS94 too - in fact, it wouldn't take much work
> >to make it ANS94 compliant) has CHARS and CELLS, as follows:
>
> >: CHARS ( -- ) ; IMMEDIATE
> >: CELLS ( #cells -- #bytes) 2* ;
>
> >At start-up I don't have CELLS+. When needed I define it as follows:
>
> >: CELLS+ CELLS + ;
>
> >Or, for slightly better performance on a lowly ITC system such as
> >mine:
>
> >: CELLS+ ( n --) COMPILE CELLS COMPILE + ; IMMEDIATE
>
> >I can only think that the OP is looking at some code that has CELL
> >defined in order to make the code a little clearer to understand. It's
> >probably not worth the expense of a colon definition; probably better
> >to use a constant, if the OP's system supports it:
>
> >2 CONSTANT CELL
>
> >Et voilà.
> news:bf750a8c-b51b-4631...@fm12g2000vbb.googlegroups.com...
>
>
>
>
>
>
>
> > [snip...] [snip...] [snip...]
>
> >Actually I wasn't being facetious. I don't actually recall seeing CELL
> >and CELL+ in legacy code before (Forth Dimensions being just about my
> >only source, apart from the smattering of books that I have). I'm only
> >aware of CHARS and CELLS, and (later I became aware of) CELLS+. Note,
> >all plurals. I'm not aware of the singular (CELL CELL+).
>
> >To recap, my system, which *is* Forth 83 compliant (with a fairly
> >generous smattering of ANS94 too - in fact, it wouldn't take much work
> >to make it ANS94 compliant) has CHARS and CELLS, as follows:
>
> >: CHARS ( -- ) ; IMMEDIATE
> >: CELLS ( #cells -- #bytes) 2* ;
>
> >At start-up I don't have CELLS+. When needed I define it as follows:
>
> >: CELLS+ CELLS + ;
>
> >Or, for slightly better performance on a lowly ITC system such as
> >mine:
>
> >: CELLS+ ( n --) COMPILE CELLS COMPILE + ; IMMEDIATE
>
> >I can only think that the OP is looking at some code that has CELL
> >defined in order to make the code a little clearer to understand. It's
> >probably not worth the expense of a colon definition; probably better
> >to use a constant, if the OP's system supports it:
>
> >2 CONSTANT CELL
>
>
> >As you pointed out though, I think you're right: CELL+ is probably is
> >typo. It probably should be CELLS+.
>
> OP here: I got the CELL+ and (you are right) CELLS from Leo Brodie's
> _Starting Forth_ book on the Forth Inc. web site:
>
> http://www.forth.com/starting-forth/sf8/sf8.html
>
> I was interested in defining a word to create a two-dimensional array.
>
> Perhaps I need to re-read this chapter...
>
> --
>
> numerist at aquaporin4 dot com- Hide quoted text -
> >As you pointed out though, I think you're right: CELL+ is probably is
> >typo. It probably should be CELLS+.
>
> OP here: I got the CELL+ and (you are right) CELLS from Leo Brodie's
> _Starting Forth_ book on the Forth Inc. web site:
>
> http://www.forth.com/starting-forth/sf8/sf8.html
>
> I was interested in defining a word to create a two-dimensional array.
>
> Perhaps I need to re-read this chapter...
>
> --
>
>
> - Show quoted text -
Well, here is what I came up with:
: 2dArray ( compile: r c -- children: r c -- addr )
create dup cells , * cells allot
does> dup >r @ rot * swap cells + r> 2+ + ;
I was surprised it was as large as that, and I figure I must be
missing something much simpler here.
Here it is line by line:
: 2dArray
create \ create the dictionary entry
dup \ duplicate columns
cells \ convert it to bytes (array pitch)
, \ store it in pfa of child
* \ multiply row and columns
cells allot \ convert to bytes and allot them
does> \ behaviour of the children:
dup >r \ dup pfa and save on return stack
@ \ fetch array pitch
rot \ get rows on top of stack
* \ multiply by array pitch
swap cells \ get columns and convert to bytes
+ \ add rows
r> \ get pfa back from return stack
1 CELLS+ \ add 1 cell to account for pitch storage
+ \ add to row/column offset
;
Create an array like this:
8 9 2dArray fred
The above creates an array called fred that is 8 rows by 9 columns.
To access the array, simply state row, column, and the array name
followed by ! or @:
3 4 fred @
Fetches the contents of the cell at row 3 column 4. (Rows and columns
start at 0)
To write to a cell, place your payload, your row and column, and your
array:
1234 3 4 fred !
I gave it a quick test and it seems to work fine. Note: In true Forth
fashion, there are no array bounds checks! You're on your own! It
would be a useful excercise to add array bounds checking.
Please feel free to ask questions if anything is unclear. Please also
note though that while the code above does work, I feel a bit uneasy
about it. I have a nagging feeling that "there must be a simpler way".
I didn't want your post to go unanswered though. I'd be interested to
see how Elizabeth et would tackle the problem.
Regards
Mark
Mark Wills
Sep 18, 2012, 4:58:14 AM9/18/12
to
That's very neat. For the benefit of the OP, Ed's code (it took me a
little time to realise what I was looking at) is a generic ARRAY word
that can create arrays of any number of dimensions!
True black belt stuff :-)
Andrew Haley
Sep 18, 2012, 5:50:21 AM9/18/12
to
Mark Wills <forth...@gmail.com> wrote:
> That's very neat. For the benefit of the OP, Ed's code (it took me a
> little time to realise what I was looking at) is a generic ARRAY word
> that can create arrays of any number of dimensions!
>
> True black belt stuff :-)
It's an amusing exercise, but it's not always that great an idea
> That's very neat. For the benefit of the OP, Ed's code (it took me a
> little time to realise what I was looking at) is a generic ARRAY word
> that can create arrays of any number of dimensions!
>
> True black belt stuff :-)
actually to use a generic N-dimensional array. Uses of arrays are
different and therefore have different needs: maybe you want an array
of pointers to objects, maybe you want flexible arrays where each
dimension isn't the same size, maybe the array is sparse, etc. It's
so easy to define arrays that you can define the right array for your
needs: that's the Forth way.
Andrew.
Mark Wills
Sep 18, 2012, 6:09:36 AM9/18/12
to
On Sep 18, 10:50 am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
Agreed. Looking at Ed's code, it's probably great if you need a 4 or 5
dimension array, but if you wanted (say) a 2D array, you'd probably
roll code specifically for a 2d array and benefit from the increased
performance that would result.
wrote:
dimension array, but if you wanted (say) a 2D array, you'd probably
roll code specifically for a 2d array and benefit from the increased
performance that would result.
Andrew Haley
Sep 18, 2012, 9:47:05 AM9/18/12
to
Mark Wills <forth...@gmail.com> wrote:
> Looking at Ed's code, it's probably great if you need a 4 or 5
> dimension array, but if you wanted (say) a 2D array, you'd probably
> roll code specifically for a 2d array and benefit from the increased
> performance that would result.
If you look closely you'll see that's flat 16-bit x86 code. There's
> Looking at Ed's code, it's probably great if you need a 4 or 5
> dimension array, but if you wanted (say) a 2D array, you'd probably
> roll code specifically for a 2d array and benefit from the increased
> performance that would result.
nowhere to put a 4- or 5-dimension array. ;-)
Andrew.
Hugh Aguilar
Sep 18, 2012, 2:45:21 PM9/18/12
to
On Sep 18, 1:53 am, Mark Wills <forthfr...@gmail.com> wrote:
> I gave it a quick test and it seems to work fine. Note: In true Forth
> fashion, there are no array bounds checks! You're on your own! It
> would be a useful excercise to add array bounds checking.
I don't think that "true Forth fashion" implies no bounds checking. It
> I gave it a quick test and it seems to work fine. Note: In true Forth
> fashion, there are no array bounds checks! You're on your own! It
> would be a useful excercise to add array bounds checking.
can help catch bugs. I have bounds checking in my 1ARRAY etc. definers
(although not in ARY which is a generic definer that works for any
number of dimensions).
http://www.forth.org/novice.html
Ed
Sep 20, 2012, 11:20:07 AM9/20/12
to
Mark Wills wrote:
> ...
For better or worse, I added the "itemsize" parameter :)
> ...
> Oh wow, that's ninja Forth, Ed ;-)
>
> That's very neat. For the benefit of the OP, Ed's code (it took me a
> little time to realise what I was looking at) is a generic ARRAY word
> that can create arrays of any number of dimensions!
To my knowledge the routine has been around since the mid 80's.
>
> That's very neat. For the benefit of the OP, Ed's code (it took me a
> little time to realise what I was looking at) is a generic ARRAY word
> that can create arrays of any number of dimensions!
For better or worse, I added the "itemsize" parameter :)
Hugh Aguilar
Sep 21, 2012, 11:48:46 PM9/21/12
to
to have specified sizes. The advantage of my ARY over yours is that it
is possible to obtain the address of a sub-array and then iterate over
it.
It is possible in my implementation to provide all of the indices and
get an element address. In your implementation however, this is the
only way to access the array. If you are iterating over a sub-array,
you have to do the entire calculation for every element. With my ARY
you only have to do the portion of the calculation necessary for the
sub-array, as the calculation to find the sub-array done once in front
of the loop.
Ed
Sep 23, 2012, 9:42:39 PM9/23/12
to
Making things run faster often comes at the cost of more code.
Whether it is justified will depend on the situation. Not every
application needs arrays which run at the maximum possible
speed. Factor in all the other things a program must do and
array speed may become insignificant. Selecting a routine
appropriate to the application is good economics.
I welcome your faster array routine. The more routines available
to Forth users, the better off Forth will be.
Hugh Aguilar
Sep 24, 2012, 12:10:50 AM9/24/12
to
On Sep 23, 6:42 pm, "Ed" <inva...@nospam.com> wrote:
> Which doesn't rule out the usefulness of the simpler routine.
>
> Making things run faster often comes at the cost of more code.
> Whether it is justified will depend on the situation. Not every
> application needs arrays which run at the maximum possible
> speed. Factor in all the other things a program must do and
> array speed may become insignificant. Selecting a routine
> appropriate to the application is good economics.
I like your definer. I don't know if it is "Ninja Forth," but it is
> Which doesn't rule out the usefulness of the simpler routine.
>
> Making things run faster often comes at the cost of more code.
> Whether it is justified will depend on the situation. Not every
> application needs arrays which run at the maximum possible
> speed. Factor in all the other things a program must do and
> array speed may become insignificant. Selecting a routine
> appropriate to the application is good economics.
definitely black-belt Forth (maybe shodan). With your permission I
will include it in the next novice-package release (with an attribute
of course) --- I've already got two ways to define arrays, so three
would be okay.
With low-level fundamental support code such as an array definer, I
will put in a lot of effort to make it fast. In many cases arrays may
be the crux of the program, and their speed the time-critical aspect
of the program.
With code that is not used much, you are right that simplicity out-
weighs efficiency. You can get the program running first, and only
worry about the performance later on if the program is too slow.
Considering how fast modern computers are, speed is not going to be an
issue very often.
I remember when I was a teenager one of my first Forth programs was a
port of a BASIC program from a book. It was a simulation of a simple
ecosystem with predators and prey. The prey moved around randomly at
first, but they could "learn" to avoid getting eaten. There was an 8
dimensional array. The 8 dimensions represented the 8 adjacent
squares. When they succeeded in not getting eaten, they would remember
what their environment looked like at the time (what was adjacent to
them) and what they did to live (which direction they moved), and they
would do the same thing again. Because the predators moved according
to fixed rules, some of the prey would "learn" a pattern to travel in
which they were guaranteed to live, although most of them would get
eaten before they figured this out. That program definitely needed
fast arrays! The advantage of Forth over BASIC was that I could make
the arrays fast. I think I made sure the multiplications were powers
of two and could be done by shifting, to avoid integer multiplication
which was horribly slow on the 6502 --- I don't remember the details
very well --- that was a long time ago.
Back in the 1980s, there were books and magazines with programs like
this. Not very useful, but quite fun. We don't see this kind of
programming anymore. Nowadays programming is dull dull dull. :-( I
mean, really, who thinks that building websites is fun? But that is
what almost everybody is doing.
> I welcome your faster array routine. The more routines available
> to Forth users, the better off Forth will be.
Forth code made available. I think that novices feel overwhelmed when
they start learning Forth, because they have to implement so much low-
level stuff themselves before they can even begin to write
applications. If you tell a novice that he has to implement an array
definer, he is going to leave and not come back. They need to have fun
with the language first --- and the way to have fun is to write
programs that do something interesting. :-)
Ed
Sep 24, 2012, 7:31:01 AM9/24/12
to
Hugh Aguilar wrote:
> ...
for years. It's effectively public domain. No attribution required.
> ...
> I like your definer. I don't know if it is "Ninja Forth," but it is
> definitely black-belt Forth (maybe shodan). With your permission I
> will include it in the next novice-package release (with an attribute
> of course) --- I've already got two ways to define arrays, so three
> would be okay.
The code has been kicking around in public under various guises
> definitely black-belt Forth (maybe shodan). With your permission I
> will include it in the next novice-package release (with an attribute
> of course) --- I've already got two ways to define arrays, so three
> would be okay.
for years. It's effectively public domain. No attribution required.
Mark Wills
Sep 24, 2012, 10:08:18 AM9/24/12
to
On Sep 24, 5:10 am, Hugh Aguilar <hughaguila...@yahoo.com> wrote:
> If you tell a novice that he has to implement an array
> definer, he is going to leave and not come back. They need to have fun
> with the language first --- and the way to have fun is to write
> programs that do something interesting. :-)
I do think that's a good point wrt making the language easier for
> If you tell a novice that he has to implement an array
> definer, he is going to leave and not come back. They need to have fun
> with the language first --- and the way to have fun is to write
> programs that do something interesting. :-)
newcomers. I'm familiar with the argument as to why arrays are no
included in any of the standards, but one can't help wonder if it
might be an idea to specify a very simple array definer and accessor
suite of words as suitable candidates for standardisation.
As Hugh says, it does make the language a lot easier from the get-go
from new-comers.
I do appreciate that the standard is not there for new-comers, but one
does wonder how many people look at the language and think "yack"
because it 'lacks' essential features such as arrays.
Andrew Haley
Sep 24, 2012, 11:40:22 AM9/24/12
to
Mark Wills <forth...@gmail.com> wrote:
>
> I do appreciate that the standard is not there for new-comers, but one
> does wonder how many people look at the language and think "yack"
> because it 'lacks' essential features such as arrays.
And infix, and typed variables, etc, etc. The point is not to add
>
> I do appreciate that the standard is not there for new-comers, but one
> does wonder how many people look at the language and think "yack"
> because it 'lacks' essential features such as arrays.
useless features that no experienced user would ever want, but to make
the language as good as Forth can be.
The key to arrays is to show people early on how easy they are to
define (p195 in Starting FORTH, 1st. ed.) If they're the kind of
person likely to "get" Forth they'll get that one easily enough.
Andrew.
Elizabeth D. Rather
Sep 24, 2012, 1:52:19 PM9/24/12
to
person to fish..." philosophy. It is very important to make the point
early on in a person's Forth career that the language is extensible, so
that *your* arrays will work exactly the way *you* need them to.
Cheers,
Elizabeth
Ed
Sep 25, 2012, 5:40:35 AM9/25/12
to
Elizabeth D. Rather wrote:
> On 9/24/12 4:08 AM, Mark Wills wrote:
> > On Sep 24, 5:10 am, Hugh Aguilar <hughaguila...@yahoo.com> wrote:
> >> If you tell a novice that he has to implement an array
> >> definer, he is going to leave and not come back. They need to have fun
> >> with the language first --- and the way to have fun is to write
> >> programs that do something interesting. :-)
> >
> > I do think that's a good point wrt making the language easier for
> > newcomers. I'm familiar with the argument as to why arrays are no
> > included in any of the standards, but one can't help wonder if it
> > might be an idea to specify a very simple array definer and accessor
> > suite of words as suitable candidates for standardisation.
> >
> > As Hugh says, it does make the language a lot easier from the get-go
> > from new-comers.
> >
> > I do appreciate that the standard is not there for new-comers, but one
> > does wonder how many people look at the language and think "yack"
> > because it 'lacks' essential features such as arrays.
> >
>
> There are examples given in most books on Forth, following the "teach a
> person to fish..." philosophy. It is very important to make the point
> early on in a person's Forth career that the language is extensible, so
> that *your* arrays will work exactly the way *you* need them to.
IIRC Stephen and yourself concluded it was more productive to simply
supply a string package than to constantly harangue folks telling them
to go away and build their own. Hugh obviously reached the same
conclusion w.r.t. to multi-dimension arrays - as did I.
Not everyone is a Chuck Moore - who is bright enough to build what
he needs, when he needs it - and gets it right the first time.
If there is a "Forth way" of handling multi-dimension array scenarios
that's different from the solution I provided, I need to be shown how.
Mark Wills
Sep 25, 2012, 5:51:36 AM9/25/12
to
>
> - Show quoted text -
That's a good point. At least a suite of string words has been
> - Show quoted text -
standardised, even if it is an optional package (nothing wrong with
that).
It at least counters a newcomers objection: "What? It doesn't do
STRINGS????? Are you frickin' CRAZY??? Screw this... See you later!"
I'm sure the same argument could arise with reference to arrays! For
example, your typical newbie says to himself "Okay, I think I'm
getting this Forth thing. I think I'll sit down and write a little
bubble sort routine"... If he's come from other languages (extrememly
likely) he'll reach for an array and fill backwards, or fill it with
random numbers. Then he'll see that arrays don't exist. Then we say,
"Oh, just use CREATE DOES>" - he goes off to have a look at CREATE
DOES> and his head explodes! He's not ready for CREATE DOES> yet!
I'd be interested to hear how Elizabeth solves this particular
objection in the classroom. She must have come across it many times
from students.
"What? No *ARRAYS*?..." :-)
I have to say - I'm very much on the fence on this one. There are
valid points on both sides...
Elizabeth D. Rather
Sep 25, 2012, 2:33:54 PM9/25/12
to
On 9/24/12 11:51 PM, Mark Wills wrote:
...
In the first place, CREATE ... DOES> isn't needed for simple arrays.
The first day of my course is devoted to practicing stack skills and
writing simple definitions. No data objects of any kind.
The second day we look at CONSTANTs, VALUEs, VARIABLEs, CREATE, and
ALLOT. We talk about @, C@, 2@, and their ! counterparts. These are
presented as examples of defining words with defining behaviors and
instance behaviors characteristic of each kind.
We get loops of various kinds, and know how to define simple arrays and
do things with them in loops.
On the third day, we get characters, strings, and input/output number
conversions, as well as I/O (KEY, EMIT, TYPE, ACCEPT).
By the fourth day, folks are pretty comfortable with a bunch of defining
words with different instance behaviors, ways of allocating and
accessing memory, and when I introduce the use of DOES> to work with
CREATE in creating new classes of words with user-defined instance
behaviors, they are quite ready. They write their own 2-dimension arrays
with bounds checking on the fourth day of class, usually without difficulty.
...
> I'm sure the same argument could arise with reference to arrays! For
> example, your typical newbie says to himself "Okay, I think I'm
> getting this Forth thing. I think I'll sit down and write a little
> bubble sort routine"... If he's come from other languages (extrememly
> likely) he'll reach for an array and fill backwards, or fill it with
> random numbers. Then he'll see that arrays don't exist. Then we say,
> "Oh, just use CREATE DOES>" - he goes off to have a look at CREATE
> DOES> and his head explodes! He's not ready for CREATE DOES> yet!
>
> I'd be interested to hear how Elizabeth solves this particular
> objection in the classroom. She must have come across it many times
> from students.
>
> "What? No *ARRAYS*?..." :-)
>
> I have to say - I'm very much on the fence on this one. There are
> valid points on both sides...
Happy to help :-)
> example, your typical newbie says to himself "Okay, I think I'm
> getting this Forth thing. I think I'll sit down and write a little
> bubble sort routine"... If he's come from other languages (extrememly
> likely) he'll reach for an array and fill backwards, or fill it with
> random numbers. Then he'll see that arrays don't exist. Then we say,
> "Oh, just use CREATE DOES>" - he goes off to have a look at CREATE
> DOES> and his head explodes! He's not ready for CREATE DOES> yet!
>
> I'd be interested to hear how Elizabeth solves this particular
> objection in the classroom. She must have come across it many times
> from students.
>
> "What? No *ARRAYS*?..." :-)
>
> I have to say - I'm very much on the fence on this one. There are
> valid points on both sides...
In the first place, CREATE ... DOES> isn't needed for simple arrays.
The first day of my course is devoted to practicing stack skills and
writing simple definitions. No data objects of any kind.
The second day we look at CONSTANTs, VALUEs, VARIABLEs, CREATE, and
ALLOT. We talk about @, C@, 2@, and their ! counterparts. These are
presented as examples of defining words with defining behaviors and
instance behaviors characteristic of each kind.
We get loops of various kinds, and know how to define simple arrays and
do things with them in loops.
On the third day, we get characters, strings, and input/output number
conversions, as well as I/O (KEY, EMIT, TYPE, ACCEPT).
By the fourth day, folks are pretty comfortable with a bunch of defining
words with different instance behaviors, ways of allocating and
accessing memory, and when I introduce the use of DOES> to work with
CREATE in creating new classes of words with user-defined instance
behaviors, they are quite ready. They write their own 2-dimension arrays
with bounds checking on the fourth day of class, usually without difficulty.
John Passaniti
Sep 25, 2012, 2:57:41 PM9/25/12
to
On Monday, September 24, 2012 1:52:20 PM UTC-4, Elizabeth D. Rather wrote:
> There are examples given in most books on Forth, following
> the "teach a person to fish..." philosophy. It is very
> important to make the point early on in a person's Forth
> career that the language is extensible, so that *your*
> arrays will work exactly the way *you* need them to.
First thought experiment:
> There are examples given in most books on Forth, following
> the "teach a person to fish..." philosophy. It is very
> important to make the point early on in a person's Forth
> career that the language is extensible, so that *your*
> arrays will work exactly the way *you* need them to.
Let's say the ANS Forth standard had another section added. It's another optional wordset of common algorithms and data structures-- the best of what Forth professionals have come up and included in their personal toolboxes. Like every other optional wordset, no Forth vendor is forced to implement it and no Forth user would be forced to use it.
Now, tell me how Forth would be in any way diminished by the inclusion of such code. Better yet, tell me why the existing optional wordsets don't have whatever negative property you see.
Second thought experiment:
You have somehow caused all Forth code ever written to be accessible in a huge database. You have also written code that lets you look at all this code in terms of structure and larger patterns in the code, not just raw text.
You are curious about the various ways people implement common data structures. So you issue a query that chew through the database and produces for you a report.
The question: In your classes, you undoubtedly present how to build arrays. In that presentation, you might show two or three ways-- maybe one is more performance oriented and does no bounds checking. Maybe another one does bounds checking. Maybe one manages storage as part of creation. Maybe you show the various pros and cons of each.
Now, for each of the different flavors of arrays you present, what percentage of the code across all of the Forth code ever written implements those patterns?
My point, of course, is that we are told that arrays and other common algorithms and data structures are all some hyper-specialized unique snowflake. There is nothing common, nothing canonical, nothing that can be extracted and reused. Do you really believe that? If so, why? If not, why not offer these as an optional wordset?
Elizabeth D. Rather
Sep 25, 2012, 3:12:30 PM9/25/12
to
scenarios you suggest, except for the simple fact that they all take a
lot of community effort and it hasn't happened. The Forth community has
enough trouble maintaining a simple language standard, let alone
standardizing libraries and setting up vast databases of them.
Most Forth systems (certainly the commercial ones) come with a lot of
useful code above and beyond what's standardized. So viewing Forth as
limited to what's in the current Standard is, well, a limited view.
Also, there's the fact that if it takes you 5 minutes to define the kind
of array you want, it's easier to just do it than to spend lots of time
searching databases for it.
Josh Grams
Sep 25, 2012, 3:19:32 PM9/25/12
to
Mark Wills wrote:
> Then we say, "Oh, just use CREATE DOES>" - he goes off to have a look
> at CREATE DOES> and his head explodes! He's not ready for CREATE DOES>
> yet!
Bah. The only ones whose heads are in danger of exploding are those
> Then we say, "Oh, just use CREATE DOES>" - he goes off to have a look
> at CREATE DOES> and his head explodes! He's not ready for CREATE DOES>
> yet!
silly people who try to implement Forth without learning the
language first. :-P Teaching someone to *use* CREATE .. DOES> is
trivial:
CREATE foo \ define foo as an address where you can put data
17 CELLS ALLOT \ once you allocate space there
\ Then immediately afterwards you can use DOES> to compile code which
\ will extend foo's default behavior:
DOES> ( u.index -- addr.cell )
( addr.foo ) swap cells + ;
There, that's all you need to know!
OK, I'm exaggerating, but not by all *that* much...you can usually
explain CREATE .. DOES> to someone in five minutes or so.
--Josh
John Passaniti
Sep 25, 2012, 5:07:02 PM9/25/12
to
On Tuesday, September 25, 2012 3:12:31 PM UTC-4, Elizabeth D. Rather wrote:
> There's absolutely nothing whatever wrong with all the
> wonderful scenarios you suggest, except for the simple
> fact that they all take a lot of community effort and
> it hasn't happened. The Forth community has enough
> trouble maintaining a simple language standard, let
> alone standardizing libraries and setting up vast
> databases of them.
It's an old discussion, but here's my current take: There is no longer any valid excuse. Years ago when only a handful of languages ruled the Earth, it was valid to say that people didn't have the patterns and practices needed to successfully build a strong and vibrant community around a language. The infrastructure to create online databases of code (essentially content management systems for code) exist and only need to be downloaded, installed, and configured. Successful patterns for the communities are plenty, and it only takes someone to objectively review what has worked and what hasn't.
> There's absolutely nothing whatever wrong with all the
> wonderful scenarios you suggest, except for the simple
> fact that they all take a lot of community effort and
> it hasn't happened. The Forth community has enough
> trouble maintaining a simple language standard, let
> alone standardizing libraries and setting up vast
> databases of them.
The proof of this is that there are languages that continue to spring up and it's shocking how quickly they converge on repositories and vibrant community structures that actually work. That's not saying those languages are in any sense better than Forth, but the people and the patterns around them certainly have learned from the experience of other languages.
> Most Forth systems (certainly the commercial ones) come with a lot of
> useful code above and beyond what's standardized. So viewing Forth as
> limited to what's in the current Standard is, well, a limited view.
> Also, there's the fact that if it takes you 5 minutes to define the kind
> of array you want, it's easier to just do it than to spend lots of time
> searching databases for it.
When we cut through all the happy talk about the virtues of constantly reinventing the same damn infrastructure over and over again, what I keep coming back to is one word: factoring. The Forth notion of factoring is low-level and almost trivial. When I look at other language communities and their repositories of code, I see factoring at a higher level-- at the level of the community itself. Reducing redundancy and coming up with names for abstractions can also mean finding redundancy within the community and inventing the systems that allow for those names to be found.
Andrew Haley
Sep 25, 2012, 6:39:03 PM9/25/12
to
Ed <inv...@nospam.com> wrote:
>
> Not everyone is a Chuck Moore - who is bright enough to build what
> he needs, when he needs it - and gets it right the first time.
No, but you don't need to be Chuck Moore to write an array definer.
>
> Not everyone is a Chuck Moore - who is bright enough to build what
> he needs, when he needs it - and gets it right the first time.
> If there is a "Forth way" of handling multi-dimension array scenarios
> that's different from the solution I provided, I need to be shown how.
arrays is in a state of sin. For another way, see
https://groups.google.com/forum/#!msg/comp.lang.forth/0Yv-kCscn0c/sS6ySMFv82IJ
and the ensuing dicussion.
Andrew.
Coos Haak
Sep 25, 2012, 6:46:39 PM9/25/12
to
Op 25 Sep 2012 19:19:32 GMT schreef Josh Grams:
Nice idea, does not work with Win32Forth and SwiftForth because they have a
compile-only DOES>. It works in Gforth though.
--
Coos
CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html
compile-only DOES>. It works in Gforth though.
--
Coos
CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html
Elizabeth D. Rather
Sep 25, 2012, 6:47:45 PM9/25/12
to
On 9/25/12 11:07 AM, John Passaniti wrote:
>> Most Forth systems (certainly the commercial ones) come with a lot of
>> >useful code above and beyond what's standardized. So viewing Forth as
>> >limited to what's in the current Standard is, well, a limited view.
> Feel free to take the portable code examples that come with your Forth and publish them online for free download with a license that allows them to be freely reused as people wish. As long as such code is bound to the purchase of a particular vendor's Forth or isn't licensed for reuse, it only helps the person who buys the Forth, not the larger community.
>
We've long since lost count of how many thousands of free SwiftForths
>> Most Forth systems (certainly the commercial ones) come with a lot of
>> >useful code above and beyond what's standardized. So viewing Forth as
>> >limited to what's in the current Standard is, well, a limited view.
> Feel free to take the portable code examples that come with your Forth and publish them online for free download with a license that allows them to be freely reused as people wish. As long as such code is bound to the purchase of a particular vendor's Forth or isn't licensed for reuse, it only helps the person who buys the Forth, not the larger community.
>
and SwiftX's have been downloaded. Folks are welcome to make use of the
samples, etc., on those systems.
Ed
Sep 26, 2012, 1:20:33 AM9/26/12
to
> > ...
Not "standardized", rather supplied as additional functions or user-
loadable package.
Typically these packages use counted strings - good enough for most
situations. The advantage is a) the user hasn't been left in the lurch
and b) when he gains competency, he's got something to work with.
This has to be better than staring at a blank slate.
> It at least counters a newcomers objection: "What? It doesn't do
> STRINGS????? Are you frickin' CRAZY??? Screw this... See you later!"
Yes, that's the risk. My first encounter with Forth was not positive and
I rejected it.
> > Not everyone is a Chuck Moore - who is bright enough to build what
> > he needs, when he needs it - and gets it right the first time.
> >
> > If there is a "Forth way" of handling multi-dimension array scenarios
> > that's different from the solution I provided, I need to be shown how.- Hide quoted text -
> >
> > - Show quoted text -
>
> That's a good point. At least a suite of string words has been
> standardised, even if it is an optional package (nothing wrong with
> that).
> ...
> > he needs, when he needs it - and gets it right the first time.
> >
> > If there is a "Forth way" of handling multi-dimension array scenarios
> > that's different from the solution I provided, I need to be shown how.- Hide quoted text -
> >
> > - Show quoted text -
>
> That's a good point. At least a suite of string words has been
> standardised, even if it is an optional package (nothing wrong with
> that).
Not "standardized", rather supplied as additional functions or user-
loadable package.
Typically these packages use counted strings - good enough for most
situations. The advantage is a) the user hasn't been left in the lurch
and b) when he gains competency, he's got something to work with.
This has to be better than staring at a blank slate.
> It at least counters a newcomers objection: "What? It doesn't do
> STRINGS????? Are you frickin' CRAZY??? Screw this... See you later!"
I rejected it.
Paul Rubin
Sep 26, 2012, 2:06:12 AM9/26/12
to
"Ed" <inv...@nospam.com> writes:
>> It at least counters a newcomers objection: "What? It doesn't do
>> STRINGS????? Are you frickin' CRAZY??? Screw this... See you later!"
> Yes, that's the risk. My first encounter with Forth was not positive and
> I rejected it.
Forth IMHO is pretty close to an assembly language, which normally
>> It at least counters a newcomers objection: "What? It doesn't do
>> STRINGS????? Are you frickin' CRAZY??? Screw this... See you later!"
> Yes, that's the risk. My first encounter with Forth was not positive and
> I rejected it.
wouldn't come with strings or arrays either. I remember going "wow"
when someone posted how to make an array definer, e.g.
: make-array ( n "name" -- ) CREATE cells allot
DOES> ( n -- addr ) swap cells + ;
It might be interesting to use have a wiki section (maybe on or
http://c2.com/cgi/wiki?ForthLanguage or http://wiki.forthfreak.net )
where people can post useful patterns like that, but they seem more like
code examples than something to standardize.
At least for small embedded programs, I can understand the idea of using
application-specific array mechanisms if the application uses arrays.
.
John Passaniti
Sep 26, 2012, 10:02:17 AM9/26/12
to
On Tuesday, September 25, 2012 6:47:46 PM UTC-4, Elizabeth D. Rather wrote:
> We've long since lost count of how many thousands of
> free SwiftForths and SwiftX's have been downloaded.
> Folks are welcome to make use of the samples, etc.,
> on those systems.
So that code is licensed to be used anywhere? I can download a free SwiftForth, take whatever source is provided in that package, use it with *any* Forth, and release that code (in source or executable forms)?
> We've long since lost count of how many thousands of
> free SwiftForths and SwiftX's have been downloaded.
> Folks are welcome to make use of the samples, etc.,
> on those systems.
If the answer is yes, bravo!
If the answer is no, then that's (part of) my point.
Anton Ertl
Sep 26, 2012, 11:58:45 AM9/26/12
to
John Passaniti <john.pa...@gmail.com> writes:
>Let's say the ANS Forth standard had another section added. It's another o=
>ptional wordset of common algorithms and data structures-- the best of what=
> Forth professionals have come up and included in their personal toolboxes.=
> Like every other optional wordset, no Forth vendor is forced to implement=
>uch code. Better yet, tell me why the existing optional wordsets don't hav=
should be such a wordset; why haven't you proposed it?
>My point, of course, is that we are told that arrays and other common algor=
>ithms and data structures are all some hyper-specialized unique snowflake. =
> There is nothing common, nothing canonical, nothing that can be extracted =
>and reused.
In the case of arrays, what is common is already there in Forth.
Wait, Gforth has one additional word for arrays:
: th cells + ;
But that's already a specific word for arrays of cells. For other
element sizes, we would need to replace CELLS with something else, so
TH is not a common factor for arrays.
- 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 2012: http://www.euroforth.org/ef12/
>Let's say the ANS Forth standard had another section added. It's another o=
>ptional wordset of common algorithms and data structures-- the best of what=
> Forth professionals have come up and included in their personal toolboxes.=
> Like every other optional wordset, no Forth vendor is forced to implement=
> it and no Forth user would be forced to use it.
>
>Now, tell me how Forth would be in any way diminished by the inclusion of s=
>
>uch code. Better yet, tell me why the existing optional wordsets don't hav=
>e whatever negative property you see.
Nobody has proposed such a wordset. You seem to think that there
should be such a wordset; why haven't you proposed it?
>My point, of course, is that we are told that arrays and other common algor=
>ithms and data structures are all some hyper-specialized unique snowflake. =
> There is nothing common, nothing canonical, nothing that can be extracted =
>and reused.
In the case of arrays, what is common is already there in Forth.
Wait, Gforth has one additional word for arrays:
: th cells + ;
But that's already a specific word for arrays of cells. For other
element sizes, we would need to replace CELLS with something else, so
TH is not a common factor for arrays.
- 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 2012: http://www.euroforth.org/ef12/
David Thompson
Oct 11, 2012, 3:10:44 AM10/11/12
to
On Tue, 25 Sep 2012 23:06:12 -0700, Paul Rubin
<no.e...@nospam.invalid> wrote:
> "Ed" <inv...@nospam.com> writes:
> >> It at least counters a newcomers objection: "What? It doesn't do
> >> STRINGS????? Are you frickin' CRAZY??? Screw this... See you later!"
> > Yes, that's the risk. My first encounter with Forth was not positive and
> > I rejected it.
>
> Forth IMHO is pretty close to an assembly language, which normally
> wouldn't come with strings or arrays either. I remember going "wow"
> when someone posted how to make an array definer, <snip>
<no.e...@nospam.invalid> wrote:
> "Ed" <inv...@nospam.com> writes:
> >> It at least counters a newcomers objection: "What? It doesn't do
> >> STRINGS????? Are you frickin' CRAZY??? Screw this... See you later!"
> > Yes, that's the risk. My first encounter with Forth was not positive and
> > I rejected it.
>
> Forth IMHO is pretty close to an assembly language, which normally
> wouldn't come with strings or arrays either. I remember going "wow"
Some machines have (some) strings in hardware -- or at least ISA,
which is often firmware instead -- and therefore in assembler:
S/360 MVC CLC TR TRT ED EDMK maybe more I've forgotten
x86 rep-movs rep-cmps rep-scas
Some PDP-11 models had a CIS (Commercial Insn Set) option, and VAX had
an expanded version whose mnemonics I have mercifully forgotten
Cray and similar number-crunchers had (1-d) arrays of at least
floating point numbers.
And back in the days when many/most programs were in assembly, most
assemblers did macros, and IME on machines that didn't already have
strings in hardware, among the first macros most people/shops added
were at least minimal string operations.
Elizabeth D. Rather
Oct 11, 2012, 3:16:39 AM10/11/12
to
Forth does come with a variety of string words (s" ." ." c" type,
accept, move, cmove, etc.), but acknowledges that what you want to do
with strings probably is specific to your application, so it also makes
it easy (easier than assembler, by quite some) to define such operators.
Alex McDonald
Oct 11, 2012, 6:15:22 AM10/11/12
to
On Oct 11, 8:10 am, David Thompson <dave.thomps...@verizon.net> wrote:
> On Tue, 25 Sep 2012 23:06:12 -0700, Paul Rubin
>
> <no.em...@nospam.invalid> wrote:
> On Tue, 25 Sep 2012 23:06:12 -0700, Paul Rubin
>
operations. Strings are a high level construct. Forth has a buffer
(address and length) with S" and a counted string as part of the
language as the things-operated-on. MOVE, COMPARE and the like are
primitive operations; SEARCH and SKIP are higher level constructs, but
only just. On an IBM mainframe as you note, they're one opcode. SKIP
is the opcode TRT; COMPARE is the opcode CUSE. An IBM HLASM programmer
would feel right at home with Forth -- as I did.
Alex McDonald
Oct 11, 2012, 6:16:58 AM10/11/12
to
0 new messages