A word is a ... (was Designing Language - Why Forth?)
Andy Dent
Something interesting was the polarised answers to my
>Should I try to stop thinking of a Forth word as an object with one
>method?
I think there was a couple of "not really, yes it is like that" and more
"A word is a subroutine/procedure."
Particularly forthright was Julian Noble's
>Everything in Forth is either a subroutine or a literal number.
>There is NOTHING ELSE in the language.
I think this goes to the heart of what Forth Thinking is about and
hopefully will be of use to other people coming to Forth.
I really can't buy the "word is just a subroutine" argument because
words can contain storage and so remember state changes and its
behaviour can vary *without any external reference* from call to call.
But, that may be my dark past speaking.
Is it considered *bad form* for words to modify their stored state?
>I think of Forth as being a purely functional language.
Interesting. I'm also studying Scheme at present (to help with the XSLT
I will shortly be immersed in).
OK, here's my more complicated definition.
Forth words are very fractal in nature - as you "zoom in" from the
highest level of application complexity, words look similar in pattern.
Thus, the following explanation applies at the level of one particular
word and then again to other words from which it is composed.
Consider Forth word as either a Sentence or the Verbs, Nouns and
Modifiers that make up that Sentence.
Noun words tend to represent things. They will often either provide:
- an address of external storage
- an address of their own dictionary space
- a number to be used as a literal
Verb words act upon the nouns.
Any Forth word in the Sentence can be changed after the sentence is
written and compiled using vectored execution.
Revectoring a word changes *how* it plays its role but not the overall
grammar of the sentence, which is glued together by the stack effects of
each word in turn.
(OK, so it woould be possible for some bloody-minded type to revector so
many words that the complete meaning of the sentence changed but I
suspect that would be consdered exceedingly bad form!)
--
Andy Dent BSc MACS AACM
OOFILE - Cross-Platform Database, Reports, Graphs, GUI in C++
PP2MFC - PowerPlant->MFC portability
http://www.oofile.com.au/
Jonah Thomas
> Something interesting was the polarised answers to my
>>Should I try to stop thinking of a Forth word as an object with one
>>method?
> I think there was a couple of "not really, yes it is like that" and more
> "A word is a subroutine/procedure."
> Particularly forthright was Julian Noble's
>>Everything in Forth is either a subroutine or a literal number.
>>There is NOTHING ELSE in the language.
> I think this goes to the heart of what Forth Thinking is about and
> hopefully will be of use to other people coming to Forth.
> I really can't buy the "word is just a subroutine" argument because
> words can contain storage and so remember state changes and its
> behaviour can vary *without any external reference* from call to call.
Forth words are subroutines. They have inputs and outputs and it's
usually bad form for them to have hidden states.
CREATE DOES> gives you an object with one method. CREATE DOES>
children each include an instance of a data structure -- if they don't
then there's no point in using CREATE .
So the way I think of it, Forth words are always subroutines (unless
they're implemented as macros which is sometimes bad form). And they
are occasionally objects with one method.
> But, that may be my dark past speaking.
> Is it considered *bad form* for words to modify their stored state?
CREATE DOES> children might need to modify their stored state.
Sometimes that's what they're for. It isn't bad form for a CREATE
DOES> child to accept inputs and return an address, so that you give
it data to determine which item in the data structure to use, and then
let other words read the value of the item or change it.
But for example, say you have a word FOO and you want to track how
many times it gets used. To see how many times it gets called
(assuming the number is so small it doesn't overflow before you check it)
: CALLED
CREATE 0 , ' ,
DOES> 1 OVER +! CELL+ @ EXECUTE ;
CALLED FOO FOO
\ write the name twice instead of reading the same string twice.
\ a convenience for example code that won't actually be used.
When you want to get the count you can do
' FOO >BODY @ ( and of course you can make a name for that too. )
Whatever FOO did before, now it increments its counter and then does
the same thing. If you don't need the convenience of a command to
make words like that, you can do just:
VARIABLE FOO-COUNT
: FOO
1 FOO-COUNT +! FOO ;
So here's a word that modifies its stored state, and it isn't bad form
to do it. You just have to be careful. What you put on the stack is
visible, what you put into a hidden data structure stays hidden until
you look at it.
> OK, here's my more complicated definition.
> Forth words are very fractal in nature - as you "zoom in" from the
> highest level of application complexity, words look similar in pattern.
> Thus, the following explanation applies at the level of one particular
> word and then again to other words from which it is composed.
> Consider Forth word as either a Sentence or the Verbs, Nouns and
> Modifiers that make up that Sentence.
> Noun words tend to represent things. They will often either provide:
> - an address of external storage
> - an address of their own dictionary space
> - a number to be used as a literal
> Verb words act upon the nouns.
> Any Forth word in the Sentence can be changed after the sentence is
> written and compiled using vectored execution.
If you want to recompile, you can redefine any word without vectored
execution. If you know ahead of time you'LL want to change a word at
runtime then you can defer it and then change it without a recompile
of that word and all the words that come after it.
> Revectoring a word changes *how* it plays its role but not the overall
> grammar of the sentence, which is glued together by the stack effects of
> each word in turn.
Yes!
> (OK, so it woould be possible for some bloody-minded type to revector so
> many words that the complete meaning of the sentence changed but I
> suspect that would be consdered exceedingly bad form!)
Whatever works. The stack effects have to stay the same or the stack
comments will be wrong, which is extremely bad form. The names ought
to make sense in the new context. If you do so much changing around
that it doesn't make sense, or it starts looking complicated, it's
probably better to rewrite. Too much tinkering and it gets clumsy and
hard to read and hard to modify correctly.
Jerry Avins
...
> I really can't buy the "word is just a subroutine" argument because
> words can contain storage and so remember state changes and its
> behaviour can vary *without any external reference* from call to call.
I come from an embedded background, so I try to make all words
reentrant. I note those that might be but aren't. I don't have a picture
of what you mean about words having "internal" storage. Certainly
arrays, whose names are words, might exemplify what you mean, but I
suspect you have something else in mind.
> But, that may be my dark past speaking.
Brodie gives an example of a word that generates successive entries in a
list, assigning to each one a successor number. There, however, the
storage is not in the word, but on the stack. Most code is ROMable.
> Is it considered *bad form* for words to modify their stored state?
Please give me an example of a word with a variable internal state. My
imagination is a bit slow today.
...
> Any Forth word in the Sentence can be changed after the sentence is
> written and compiled using vectored execution.
Not exactly. If the original word in the sentence was vectored, then it
can be revectored. Your statement seems to me to be analogous to saying
that any machine-code jump can be turned into an indirect jump. It can,
but only by patching the original code in a way that gave "patch" its
original CS meaning.
> Revectoring a word changes *how* it plays its role but not the overall
> grammar of the sentence, which is glued together by the stack effects of
> each word in turn.
In my little boards, the basic console output word, on which others are
built, is EMIT. EMIT is vectored: its definition is
: EMIT ( n -- ) (EMIT) @ EXECUTE ; / (EMIT) is RAM
The code to which (EMIT) points "talks to" a UART. By storing a new
vector in (EMIT), I can redirect output to an LCD. Most words are not
vectored. Indirection has cost.
> (OK, so it woould be possible for some bloody-minded type to revector so
> many words that the complete meaning of the sentence changed but I
> suspect that would be consdered exceedingly bad form!)
Not unless the original words were specifically designed to support it.
Jerry
--
Engineering is the art of making what you want from things you can get.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
Julian V. Noble
>
> I generated an impressive rush of responses with my first thread.
>
> Something interesting was the polarised answers to my
> >Should I try to stop thinking of a Forth word as an object with one
> >method?
>
> I think there was a couple of "not really, yes it is like that" and more
> "A word is a subroutine/procedure."
>
> Particularly forthright was Julian Noble's
> >Everything in Forth is either a subroutine or a literal number.
> >There is NOTHING ELSE in the language.
>
> I think this goes to the heart of what Forth Thinking is about and
> hopefully will be of use to other people coming to Forth.
>
> I really can't buy the "word is just a subroutine" argument because
> words can contain storage and so remember state changes and its
> behaviour can vary *without any external reference* from call to call.
Of course they can. In fact that is the essence of my technique
for compiling finite state machines. See
http://www.jfar.org/article001.html
> But, that may be my dark past speaking.
Almost certainly is.
> Is it considered *bad form* for words to modify their stored state?
Most words do not have stored state. However, CONSTANTs,
VARIABLEs and VALUEs store data (somewhere--it doesn't have to
be in the contiguous body of the word).
If you looked at my Forth Primer you will know that the data
you store in a CONSTANT cannot be changed in a portable way
(this is not to say that in a particular Forth implementation
you can't do it, just that you shouldn;t and if you do it
won't necessarily work on a different ANS Forth).
5 CONSTANT five
five . 5 ok
A CONSTANT is a subroutine that attaches a name to a storage unit
and, when invoked, places the contents on the stack.
A VARIABLE is a subroutine that returns the address of a
storage unit that was allocated when the VARIABLE was defined.
So you can put data in it
VARIABLE x
3 x ! \ puts the integer 3 in x
x @ \ puts whatever was in x on the stack;
\ the content of x is unchanged.
A VALUE gives you the best of both worlds. Think of it as
a CONSTANT that _can_ be changed.
14 VALUE y
y . 14 ok
17 TO y ok
y . 17 ok
The words I am most familiar with that have stored state are in
fact my finite state machines (see URL given above). They contain
an allocated storage unit that holds the current state, and what
you are compiling is a set of actions and state transitions (that
reset the state), that I represent in tabular form. Basically the
table _is_ the fsm. So of course it is good form for fsm's to
change state in response to varying inputs. The key is to make
certain that a given state and input correspond to something for
the fsm to do. It is vital that you don't try to access a table
entry that hasn't been defined, e.g. But with my method it is
virtually impossible to do that. (And if you wanted to slow down
the execution you could easily add error checking.)
[ rest deleted because others can answer better than I ]
--
Julian V. Noble
Professor Emeritus of Physics
j...@lessspamformother.virginia.edu
^^^^^^^^^^^^^^^^^^
http://galileo.phys.virginia.edu/~jvn/
"For there was never yet philosopher that could endure the
toothache patiently."
-- Wm. Shakespeare, Much Ado about Nothing. Act v. Sc. 1.
Peter Lawrence
>
> I generated an impressive rush of responses with my first thread.
>
> Something interesting was the polarised answers to my
> >Should I try to stop thinking of a Forth word as an object with one
> >method?
>
> I think there was a couple of "not really, yes it is like that" and more
> "A word is a subroutine/procedure."
>
> Particularly forthright was Julian Noble's
> >Everything in Forth is either a subroutine or a literal number.
> >There is NOTHING ELSE in the language.
>
> I think this goes to the heart of what Forth Thinking is about and
> hopefully will be of use to other people coming to Forth.
>
> I really can't buy the "word is just a subroutine" argument because
> words can contain storage and so remember state changes and its
> behaviour can vary *without any external reference* from call to call.
If you look at http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?query=forth you
will find the Foldoc entry on Forth. I contributed some of it, in particular
the first draft of the sentence "Forth takes the idea of subroutines to an
extreme - nearly everything is a subroutine." I seem to recall that the
editor cut something like "... and even things like data structures are
handled in a very subroutine-like way" from the end of my draft. Obviously
for some people that "subroutine-like" is enough to qualify as a subroutine.
PML.
--
GST+NPT=JOBS
I.e., a Goods and Services Tax (or almost any other broad based production
tax), with a Negative Payroll Tax, promotes employment.
See http://users.netlink.com.au/~peterl/publicns.html#AFRLET2 and the other
items on that page for some reasons why.
Albert van der Horst
Sorry, but this is not what one normally means by stored state.
Stored states come into play in wordsets. Like OPEN-FILE READ-FILE
CLOSE-FILE and <# # #>.
Words of a wordset are coupled by an underlying concept that
greatly helps to keep large programs in order.
Stored state is absolutely indispensible in wordsets. It is what
allows us to go one step up on the abstraction ladder.
Imagine the horrors if you have to keep in mind all the data
that is involved in a file instead of using OPEN-FILE and a
handle.
And so much for the not very insightful phrase that Forth is
just words and numbers (not necessarily: ciforth e.g. is just words
and words.)
"
I live in a house.
What is that, a house?
Oh, just a couple of atoms.
What is it for, then?
It keeps me dry from the rain.
What is that, rain?
Oh, just a couple of atoms.
"
>Julian V. Noble
--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
One man-hour to invent,
One man-week to implement,
One lawyer-year to patent.