bug report Bernd Paysan's bigForth v231 v240

[Rod Pemberton]

Bernd Paysan,

I know you're not fond of my statements, but I'm probably helping you out
with this bug report. Are you aware of the following issue?

I noticed an interesting bug with your ANS bigForth v2.3.1 and v2.4.0.
bigForth is overwriting data in some words. Apparently, it's writing parsed
data to DP or HERE, like the fig-Forth code does. However, the DP
dictionary-pointer or HERE is not being adjusted via an ALLOT.


These are two of my test sequences which work for GForth and Win32Forth:

CREATE GRAPES 1 , GRAPES @ .

CREATE ORANGES 1 ORANGES ! ORANGES @ .


The GRAPES example works because DP is adjusted via the , COMMA.

CREATE GRAPES
1 ,
GRAPES @ .


The ORANGE example fails because DP isn't moved after storing the number.
The number is being overwritten with parsed data.

CREATE ORANGES
1 ORANGES !
ORANGES @ .


If one ALLOTS, replacing ORANGE with PEARS to prevent a name collision, then
the second sequence works.

CREATE PEARS
1 PEARS 1 CELLS ALLOT !
PEARS @ .


How do I know all this? My fig-Forth based interpreter is doing the exactly
same thing ... The adjustment via ALLOT is the same too. Apparently, there
is a difference in where some Forths copy their parsed data. fig-Forth code
copies straight to DP or HERE. Unfortunately, the one fig-Forth for DOS I
tested had some other failure recognizing CREATE words. I'll attempt to
test on another fig-Forth to see if fig-Forth actually has the issue. I may
not report the results here though ...

At least you now know what the issue is and can fix it ...


Rod Pemberton

[Brad]

On Jan 24, 4:26 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:

> The ORANGE example fails because DP isn't moved after storing the number.
> The number is being overwritten with parsed data.
>
> CREATE ORANGES
> 1 ORANGES !
> ORANGES @ .
>

What I get from this is: Don't trust memory beyond HERE, or any
unallocated memory. It can get clobbered any number of different ways.

CREATE ORANGES creates a data structure zero bytes long. Why should it
be safe to write to?

-Brad

[Elizabeth D. Rather]

On 1/24/12 1:26 PM, Rod Pemberton wrote:
> Bernd Paysan,
>
> I know you're not fond of my statements, but I'm probably helping you out
> with this bug report. Are you aware of the following issue?
>
> I noticed an interesting bug with your ANS bigForth v2.3.1 and v2.4.0.
> bigForth is overwriting data in some words. Apparently, it's writing parsed
> data to DP or HERE, like the fig-Forth code does. However, the DP
> dictionary-pointer or HERE is not being adjusted via an ALLOT.
>
>
> These are two of my test sequences which work for GForth and Win32Forth:
>
> CREATE GRAPES 1 , GRAPES @ .
>
> CREATE ORANGES 1 ORANGES ! ORANGES @ .

It might coincidentally work, but it certainly isn't guaranteed to,
since you're storing into space that hasn't been ALLOTted.

> The GRAPES example works because DP is adjusted via the , COMMA.
>
> CREATE GRAPES
> 1 ,
> GRAPES @ .
>
>
> The ORANGE example fails because DP isn't moved after storing the number.
> The number is being overwritten with parsed data.

DP isn't supposed to be affected by ! in any way. If it were, that
would be a bug.

> CREATE ORANGES
> 1 ORANGES !
> ORANGES @ .
>
>
> If one ALLOTS, replacing ORANGE with PEARS to prevent a name collision, then
> the second sequence works.
>
> CREATE PEARS
> 1 PEARS 1 CELLS ALLOT !
> PEARS @ .

That is correct (though clumsy) usage. Properly speaking, one should do
the ALLOT right after the CREATE in order to properly reserve the space.

> How do I know all this? My fig-Forth based interpreter is doing the exactly
> same thing ... The adjustment via ALLOT is the same too. Apparently, there
> is a difference in where some Forths copy their parsed data. fig-Forth code
> copies straight to DP or HERE. Unfortunately, the one fig-Forth for DOS I
> tested had some other failure recognizing CREATE words. I'll attempt to
> test on another fig-Forth to see if fig-Forth actually has the issue. I may
> not report the results here though ...
>
> At least you now know what the issue is and can fix it ...

There is nothing to fix. Bigforth is working as it should.

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."
==================================================

[Peter Knaggs]

Rod Pemberton wrote:
>
> CREATE ORANGES 1 ORANGES ! ORANGES @ .
>

...

>
> The ORANGE example fails because DP isn't moved after storing the number.
> The number is being overwritten with parsed data.
>
> CREATE ORANGES
> 1 ORANGES !
> ORANGES @ .

Well, my system throws a "Invalid memory address" for this, at the !.
Because you are attempting to access memory that has not been allocated
to the Forth memory model.

> If one ALLOTS, replacing ORANGE with PEARS to prevent a name collision,
> then the second sequence works.
>
> CREATE PEARS
> 1 PEARS 1 CELLS ALLOT !
> PEARS @ .

This overcomes the problem because allot extends the Forth memory model
to include the additional cell. In my system this has nothing what so
ever to do with parsing. The parsing happens in a completely separate
area of the memory space and is only copied into the Forth memory space
when required by the parsing words.

> How do I know all this?

I am not sure you do. bigForth may well act in the manner you describe,
but I have just pointed to a completely different cause for you error.
I would also say that I do not consider this to be an error. A standard
program should not be able to access memory it has not allocated, or
caused to be allocated (via a parsing word). To do so would be an
environmental dependency. The oranges example is just such a dependency.

--
Peter Knaggs

[David Kuehling]

AFAIR the standard allows to use the memory at HERE, even without
ALLOTing it. You only have to keep in mind, that it might be shared
with PAD, the text interpreter (input buffer), the number output
conversion (. <# # etc.), and any defining words.

david
--
GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk.gpg
Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40

[Mark Wills]

No it doesn't. It creates a word in the dictionary such that, when the
word is executed, it returns the address of a single cell allocated
for data storage. In old FIG/ITC parlence one would call that cell the
PFA (parameter field address) though that term isn't directly relevant
in more modern compilers, as I understand it.

[Mark Wills]

On Jan 24, 11:26 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:

GRAPES and ORANGES both worked in my Forth system. But why do you
think that ! should adjust DP? ! is a poke - it's not a concatenating
action.

[Mark Wills]

>
> That is correct (though clumsy) usage. Properly speaking, one should do
> the ALLOT right after the CREATE in order to properly reserve the space.
>

Ah... Yes. That's interesting. I should have tested more throughly
before posting.

On my system:

CREATE FRED
: TEST 1 2 3 ;
100 FRED !
FRED
ERROR: FRED NOT FOUND

Because the link-field of the word TEST got compiled into the 'body'
of FRED. When 100 was written to the same location, the dictionary
linkage broke.

Hmmm... I wonder if the definition of CREATE should include a 1 CELLS
ALLOT within it?

Mark

[Mark Wills]

On Jan 24, 11:26 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:

Yep... Rod, that's definately not a bug, mate!

[Mark Wills]

Actually, no. It shouldn't, should it? Because then lists would be
busted:

CREATE FRED 1 , 2 , 3 , 4 ,

If CREATE alloted a cell then that would make the above somewhat
awkward.

Ok. I understand what is going on now! Ignore me!

[BruceMcF]

On Jan 24, 6:26 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:

> Apparently, there is a difference in where some Forths copy their
> parsed data.

Not only that, but BigForth is allowed to copy its parsed data where
it is ~ the bug is in ORANGES since an implementation is *permitted*
to use the transitory data space at HERE for its word interpreter, and
ORANGES is not portable to an implementation that does that.

An implementation is, of course, allowed to parse to a fixed buffer if
it wishes. ORANGES will work on such an interpreter until something
else is done that uses that space.

CREATE ORANGES 1 HERE !
CREATE GRAPES ORANGES @ .

... will probably not show 1

[Rod Pemberton]

"Elizabeth D. Rather" <era...@forth.com> wrote in message
news:ifadnSBOusMN2oLS...@supernews.com...

> On 1/24/12 1:26 PM, Rod Pemberton wrote:
> > Bernd Paysan,
> >
> > I know you're not fond of my statements, but I'm probably helping you
> > out with this bug report. Are you aware of the following issue?
> >
> > I noticed an interesting bug with your ANS bigForth v2.3.1 and v2.4.0.
> > bigForth is overwriting data in some words. Apparently, it's writing
> > parsed data to DP or HERE, like the fig-Forth code does. However,
> > the DP dictionary-pointer or HERE is not being adjusted via an ALLOT.
> >
> >
> > These are two of my test sequences which work for GForth and Win32Forth:
> >
> > CREATE GRAPES 1 , GRAPES @ .
> >
> > CREATE ORANGES 1 ORANGES ! ORANGES @ .
>
> It might coincidentally work, but it certainly isn't guaranteed to,
> since you're storing into space that hasn't been ALLOTted.
>

I just tested 21 Forths. 13 work. 6 fail. 2 have other issues. Standard
behavior seems to be to not overwrite dictionary space when parsing.

> > The GRAPES example works because DP is adjusted via the , COMMA.
> >
> > CREATE GRAPES
> > 1 ,
> > GRAPES @ .
> >
> >
> > The ORANGE example fails because DP isn't moved after storing the
> > number. The number is being overwritten with parsed data.
>
> DP isn't supposed to be affected by ! in any way. If it were, that
> would be a bug.
>

I didn't say that DP should be adjusted. The bigForth issue is not with the
lack of an ALLOT, COMMA, or adjustment to HERE or DP. The issue is with
bigForth's parsing related data overwriting the user data stored in a
definition. As you've stated, storing a value "into space that hasn't been
ALLOTted" "isn't guaranteed to" work, but does that relate to 1) just
storing the value and say a COMMA storing another value there thereby
changing the originally stored value, or 2) does that apply to something
else corrupting a definition, e.g., parsing? The latter is what is going on
in bigForth. Gforth and Win32Forth do not update DP either. They don't
corrupt the stored value in the definition. They do overwrite the initial
value with another when someone uses a COMMA, or permanently allocate the
initial value when someone uses ALLOT.

> There is nothing to fix. Bigforth is working as it should.
>

I think you misunderstood what I said.


Rod Pemberton

[Rod Pemberton]

"Mark Wills" <markrob...@yahoo.co.uk> wrote in message
news:b84391c8-556a-4b83...@i25g2000vbt.googlegroups.com...

> On Jan 24, 11:26 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:

...

> > The ORANGE example fails because DP isn't moved after storing
> > the number. The number is being overwritten with parsed data.
>

[...]

> GRAPES and ORANGES both worked in my Forth system. But why do you
> think that ! should adjust DP? ! is a poke - it's not a concatenating
> action.

I don't. I don't "think that ! should adjust DP". Apparently, I wasn't
clear enough since Ms. Rather thought I said the same. When DP isn't moved
and Forth parsing writes to HERE or DP, then the ORANGE example fails for
bigForth. It suceeds for Win32Forth and GForth. This indicates they use a
different location or buffer instead of writing parsed output to HERE or DP.


Rod Pemberton

[Rod Pemberton]

"Mark Wills" <markrob...@yahoo.co.uk> wrote in message

news:66478a3e-d8f8-4aed...@cf6g2000vbb.googlegroups.com...
...

> Yep... Rod, that's definately not a bug, mate!

The bug is that bigForth has parsing data overwriting the dictionary space,
which in this case is the initially the stored number. Neither Gforth nor
Win32Forth adjust HERE or DP or ALLOT or COMMA either. They don't
corrupt the initially stored value as long as nothing else is stored in the
dictionary. Once something is stored in the dictionary, they overwrite the
initially stored value. The actual allocation of the space stored into can
occur at some later point in time, either by a , COMMA or by an ALLOT.

See for yourself:


bigFORTH 1.4.0
CREATE ORANGE ok
1 ORANGE ! ok
ORANGE @ . 1092632577 ok
5 , ok
ORANGE @ . 5 ok

Gforth 0.7.0
CREATE ORANGE ok
1 ORANGE ! ok
ORANGE @ . 1 ok
5 , ok
ORANGE @ . 5 ok

Win32Forth 6.14.00
CREATE ORANGE ok
1 ORANGE !
ORANGE @ . 1 ok
5 , ok
ORANGE @ . 5 ok

I just tested 21 Forths. 13 work. 6 fail. 2 have other issues. Standard
behavior seems to be to not overwrite dictionary space when parsing.

Rod Pemberton

[Doug Hoffman]

On 1/25/12 11:02 AM, Rod Pemberton wrote:

> CREATE ORANGE ok
> 1 ORANGE ! ok

... more defs
orange @ . => undefined

I don't know anything about fig-Forth (which you mentioned in your first
post).

It is clear, at least to me, in reading the ANS docs that the above code
should not be expected to give reliable results in ANS Forth.

The following should work for all ANS Forths (have no idea what happens
on non-ANS):

create orange 55 ,
100 , \ or parse some text or whatever
orange @ . => 55
orange cell+ @ . => 100

\ or
create orange' 1 cells allot
65 orange' !
200 , \ or parse some text or whatever
orange' @ . => 65
orange' cell+ @ . => 200

-Doug

[Mark Wills]

On Jan 25, 4:02 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> "Mark Wills" <markrobertwi...@yahoo.co.uk> wrote in message

I see what you mean, Rod. However, I still don't think it is a bug.
I'll try to explain why. Sometimes it's difficult to explain things in
a text only environment such as this. If this was down the pub then it
would be on the back of beer mats, and consequently much easier!

Let's look at this:

CREATE FRED 99 ,

What you end up with, on an ITC system, is something like this:

HERE
------+---------+----+----+ v
FRED | DO_PUSH | 0* | 99 |
------+---------+----+----+

Here, comma compiled in the value 99 and advanced HERE. Consequently,
HERE is pointing to the cell after 99.

Now, if we look at just CREATE FRED

HERE
------+---------+----+--v-+
FRED | DO_PUSH | 0* | |
------+---------+----+----+

At this point, HERE is pointing to the body of the CREATEd word, ready
for a value to be "comma'd" in. If it didn't do that (i.e. if CREATE
itself advance HERE then you'd waste a cell when compiling an array/
list:

CREATE LIST 1 , 2 , 3 ,

-----+---------+----+---------+---+---+---+
LIST | DO_PUSH | 0* | <empty> | 1 | 2 | 3 |
-----+---------+----+---------+---+---+---+

In this case, in order to access the first value in the list, one
would need to do:

LIST 1 CELLS + @

Not nice.

So, it seems, with bigForth, that it's using HERE for something, and
it's tripping you up, because you didn't compile a value into the body
of the word you created as was expected.

You should find that the following works:

CREATE APPLES 1 CELLS ALLOT

EXACTLY the same thing happens on my system as in bigForth, and I can
see why (though it confused me at first).

Did you try the code I posted earlier?

CREATE FRED
: TEST 1 2 3 ;

FRED
error: FRED not found

This is because, what gets compiled, is this:

BODY
-----+---------+----+------+-------+-----+---+-----+---+------+
FRED | DO_PUSH | 0* | TEST | LIT 1 | LIT | 2 | LIT | 3 | EXIT |
-----+---------+----+------+-------+-----+---+-----+---+------+
^--------------------+

So, the *body* of FRED actually has a part of the definition of TEST
in it.

Whereas:

CREATE FRED 1 CELLS ALLOT
: TEST 1 2 3 ;

Works. Because the following is compiled:

BODY
-----+---------+----+------+------+-------+-----+---+-----+---+------+
FRED | DO_PUSH | 0* | <??> | TEST | LIT 1 | LIT | 2 | LIT | 3 | EXIT |
-----+---------+----+------+------+-------+-----+---+-----+---+------+
^---------------------------+

The <??> is un-initialised memory, since ALLOT skipped over it.

Does that make sense?



* The zero is normally compiled just in case a CREATEd word is
subsequently modified by DOES> - it reserves space for an address if
required. If a CREATEd word is modified by DOES> then the DO_PUSH
(which just pushes the address of the body of the created word) is
replace with DO_DOES and the 0 in front of it is replaced with the
address of the code just after DOES> in the parent word.

HTH.

Mark

[Mark Wills]

> bigFORTH 1.4.0
> CREATE ORANGE ok
> 1 ORANGE ! ok
> ORANGE @ . 1092632577 ok
> 5 , ok
> ORANGE @ . 5 ok
>
> Gforth 0.7.0
> CREATE ORANGE ok
> 1 ORANGE ! ok
> ORANGE @ . 1 ok
> 5 , ok
> ORANGE @ . 5 ok
>
> Win32Forth 6.14.00
> CREATE ORANGE ok
> 1 ORANGE !
> ORANGE @ . 1 ok
> 5 , ok
> ORANGE @ . 5 ok
>
> I just tested 21 Forths.  13 work.  6 fail.  2 have other issues.  Standard
> behavior seems to be to not overwrite dictionary space when parsing.
>
> Rod Pemberton

This is purely because bigForth is using HERE for some sort of crunch
buffer. Maybe it's the conversion of numbers from string form to
binary form, or something like that. In my system, the buffers are
static.

[BruceMcF]

On Jan 25, 11:02 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:

> The bug is that bigForth has parsing data overwriting the dictionary
> space, which in this case is the initially the stored number.

But its not a bug: a implementation is *permitted* to use that space
in that way.

> Neither Gforth nor Win32Forth adjust HERE or DP or ALLOT or COMMA
> either.  They don't corrupt the initially stored value as long as
> nothing else is stored in the dictionary.

Implementations are not *required* to use the space at HERE for their
text interpreter, but its certainly allowed.

> Once something is stored in the dictionary, they overwrite the
> initially stored value.

Of course: any data stored there is transitory and *may* be
overwritten by a set of actions laid out quite clearly in the
standard.

> The actual allocation of the space stored into can
> occur at some later point in time, either by a , COMMA or by an ALLOT.

Except if an implementation uses that space for its text interpreter,
*which it is explicitly allowed to do*, then for *those*
implementations you need to reserve the space first.
CREATE ORANGES HERE 1 CELLS ALLOT 1 !

... though obviously the most concise portable way to do it is:
CREATE ORANGES 1 ,

... where the "," is interpreter, and then *when it executes* it
stores the 1 and allots the space.

> I just tested 21 Forths.  13 work.  6 fail.  2 have other issues.

> Standard behavior seems to be to not overwrite dictionary space
> when parsing.

The most common behavior is to use some other buffer, or else to use a
buffer at some offset. A large number, however, do use that space as
permitted under the standard.

Calling it "non-standard" behavior even though the standard explicitly
allows it is a misleading use of language.

[Elizabeth D. Rather]

Whether they do or not doesn't change the principle: there is no
protection whatever for space that hasn't been ALLOTted, and you
shouldn't expect any.

Traditionally, all Forths parsed to HERE, because when you're compiling
there's a strong likelihood that the word will become a name field of a
new definition and it saves a MOVE. So this is entirely accepted,
normal practice.

You should never store or move anything into a space that you haven't
previously reserved using ALLOT or the equivalent.

[Elizabeth D. Rather]

On 1/25/12 6:02 AM, Rod Pemberton wrote:
> "Mark Wills"<markrob...@yahoo.co.uk> wrote in message
> news:66478a3e-d8f8-4aed...@cf6g2000vbb.googlegroups.com...
> ...
>
>> Yep... Rod, that's definately not a bug, mate!
>
> The bug is that bigForth has parsing data overwriting the dictionary space,
> which in this case is the initially the stored number. Neither Gforth nor
> Win32Forth adjust HERE or DP or ALLOT or COMMA either. They don't
> corrupt the initially stored value as long as nothing else is stored in the
> dictionary. Once something is stored in the dictionary, they overwrite the
> initially stored value. The actual allocation of the space stored into can
> occur at some later point in time, either by a , COMMA or by an ALLOT.
>
> See for yourself:

...

>
> I just tested 21 Forths. 13 work. 6 fail. 2 have other issues. Standard
> behavior seems to be to not overwrite dictionary space when parsing.

It is not a bug. Systems are entitled to use that space. Whether they do
or not, it is still a requirement that you ALLOT space *before* writing
into it if you expect your data to survive.

[Elizabeth D. Rather]

Wrong. CREATE defines a word that will return the address of the next
location. It doesn't *allocate* any space at that location. The reason
is that the user can then allocate as much space as desired, in any
number of different ways. But until data space is actually allocated,
none has been reserved, and there is no protection for that space.

Cheers,
Ellizabeth

[Elizabeth D. Rather]

On 1/25/12 2:40 AM, Mark Wills wrote:
...

> Hmmm... I wonder if the definition of CREATE should include a 1 CELLS
> ALLOT within it?

No, because then if you said,

CREATE STUFF 10 CELLS ALLOT

...you'd get 11 cells. If you want one cell, you should use VARIABLE as
your defining word.

[Mark Wills]

> Los Angeles, CA 90045http://www.forth.com

>
> "Forth-based products and Services for real-time
> applications since 1973."
> ==================================================

Indeed. Much better wording. Thank-you.

Mark

[Coos Haak]

Op Wed, 25 Jan 2012 11:00:53 -0500 schreef Rod Pemberton:

Look how WORD is implemented in bigForth. Mayby, like as in Figforth, it
places the parsed as a counted string at HERE. WORD is regularly used in
the interpreter. Other implementations may place the string somewhere else,
like Gforth and Win32Forth so the string is not placed at HERE and does not
interfere with what you expected after doing CREATE without ALLOT or comma.

--
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html

[Coos Haak]

Op Wed, 25 Jan 2012 04:40:58 -0800 (PST) schreef Mark Wills:

Hey, you discovered a possible definition of VARIABLE!

: VARIABLE CREATE 0 , ;

> Mark

[Albert van der Horst]

In article <jfp955$87t$1...@speranza.aioe.org>,

Defining standard behaviour by taking a majority vote.
A new and interesting perspective!

>
>
>Rod Pemberton

Groetjes Albert

--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[Anton Ertl]

"Rod Pemberton" <do_no...@noavailemail.cmm> writes:
>The issue is with
>bigForth's parsing related data overwriting the user data stored in a
>definition.

A standard system is allowed to do that, and classic Forth
implementations (e.g., fig-Forth) usually did that. So, unless
bigForth guarantees that it does not do that, it's not a bug; you can
consider it a quality-of-implementation issue.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2011: http://www.euroforth.org/ef11/

[Arnold Doray]

On Wed, 25 Jan 2012 08:38:33 -0800, Mark Wills wrote:


>
> EXACTLY the same thing happens on my system as in bigForth, and I can
> see why (though it confused me at first).
>
> Did you try the code I posted earlier?
>
> CREATE FRED : TEST 1 2 3 ;
> FRED error: FRED not found
>

Is this true in general or just for bigForth & TurboForth? On GForth I
get this:

Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
create fred : test 1 2 3 ; ok
fred ok
.S <1> 4538600280 ok
test ok
.S <4> 4538600280 1 2 3 ok

> This is because, what gets compiled, is this:
>
> BODY
> -----+---------+----+------+-------+-----+---+-----+---+------+
> FRED | DO_PUSH | 0* | TEST | LIT 1 | LIT | 2 | LIT | 3 | EXIT |
> -----+---------+----+------+-------+-----+---+-----+---+------+
> ^--------------------+
>
> So, the *body* of FRED actually has a part of the definition of TEST in
> it.
>

You lost me there... Shouldn't the : (COLON) create a new dictionary
entry for TEST, thereby ending FRED's definition?

But even assuming that your diagram is right, why is FRED "not found"?

Thanks,
Arnold

[Anton Ertl]

Coos Haak <chf...@hccnet.nl> writes:
>Look how WORD is implemented in bigForth. Mayby, like as in Figforth, it
>places the parsed as a counted string at HERE. WORD is regularly used in
>the interpreter. Other implementations may place the string somewhere else,
>like Gforth and Win32Forth so the string is not placed at HERE and does not
>interfere with what you expected after doing CREATE without ALLOT or comma.

In Gforth WORD places the string HERE, but the text interpreter does
not use WORD. Indeed the text interpreter does not copy the string
anywhere, so it never performs more MOVEs than classic Forths and in
many cases performs fewer MOVEs; e.g., in the frequent case when the
text interpreter just looks up the word to perform its interpretation
or compilation semantics (which is probably the vast majority of
what parsing is used for in Forth).

[Coos Haak]

Op Thu, 26 Jan 2012 15:37:48 GMT schreef Anton Ertl:

> Coos Haak <chf...@hccnet.nl> writes:
>>Look how WORD is implemented in bigForth. Mayby, like as in Figforth, it
>>places the parsed as a counted string at HERE. WORD is regularly used in
>>the interpreter. Other implementations may place the string somewhere else,
>>like Gforth and Win32Forth so the string is not placed at HERE and does not
>>interfere with what you expected after doing CREATE without ALLOT or comma.
>
> In Gforth WORD places the string HERE, but the text interpreter does
> not use WORD. Indeed the text interpreter does not copy the string
> anywhere, so it never performs more MOVEs than classic Forths and in
> many cases performs fewer MOVEs; e.g., in the frequent case when the
> text interpreter just looks up the word to perform its interpretation
> or compilation semantics (which is probably the vast majority of
> what parsing is used for in Forth).
>
> - anton

The same here. My text interpreter doesn't use WORD and FIND either. Like
as in Gforth I leave the parsed string alone in the input line, by using
PARSE-NAME. I have WORD as a loadable extension
Another reason to work this way is that counted strings are more difficult
to use than address and length pairs on the stack.

[Coos Haak]

Op Thu, 26 Jan 2012 00:54:12 +0000 (UTC) schreef Arnold Doray:

CREATE FRED created the definion and finished it at the same instant.
The colon has nothing to do with it, it started the definition TEST

>
> But even assuming that your diagram is right, why is FRED "not found"?

FRED is found, you typed it in and Gforth answered with its data address,
4538600280

>
> Thanks,
> Arnold

[Arnold Doray]

I was refering to Mark's diagram and explanations. I don't understand his
explanations for FRED and TEST. GForth's behaviour is what I expect any
Forth to do, and is unsurprising. -AD

[Mark Wills]

Actually Arnold, you're right.

I just tried it again in TurboForth and it worked fine. I don't know
what I was thinking.

However, my explanation regarding what happens in the dictionary (or
rather, what the memory looks like after compilation) is correct:

CREATE FRED
: TEST 1 2 3 ;

FRED @ $.
>> A2EA ok:0
' TEST >LINK @ $.
>> A2EA ok:0

So... What's that 0xA2EA value in FRED? When we do FRED @ we get A2EA.
Where did that come from? It's the value stored in the *back pointer
field* of *dictionary entry* of *TEST*! In other words, TESTs back
pointer points to A2EA, which is the beginning of FREDs dictionary
entry!

So, when you do CREATE FRED memory looks like this:

-----+---------+---+
FRED | DO_PUSH | *-----HERE
-----+---------+---+

So, HERE is currently pointing at the BODY of FRED (effectively
waiting for a value to be comma'd in).

However, we don't comma in a value. We begin a new definition:

: TEST 1 2 3 ;

Which gives us (ITC)

------+---------+------+-------+-----+---+-----+---+-----+---+------+
FRED | DO_PUSH | TEST | DOCOL | LIT | 1 | LIT | 2 | LIT | 3 | EXIT |
------+---------+------+-------+-----+---+-----+---+-----+---+------+
^ |
+---------------+

The beginning of the definition of TEST (which in my case is the back
pointer to the previous definition (FRED)) lies in the BODY of FRED.

Such that FRED @ reveals the value in the back-pointer field of TEST -
as evidenced by:

' TEST >LINK @ $.
A2EA ok:0

Confusing, huh!? But it is correct.

However, you *are* correct. There's no reason for the definition of
FRED to be lost. I apologise for misleading you. I just tried it now
in TurboForth and it does work.

[Mark Wills]

If you're interested in trying it in TurboForth then you could visit
www.harmlesslion.com and download Classic99 from here:

http://www.harmlesslion.com/cgi-bin/showprog.cgi?Windows

Classic99 is a TI-99/4A emulator for Windows (not written by me). The
author has included TurboForth (it's embedded in the .exe) and the
util disk which accompanies it.

TurboForth may not be to your taste however, as it's very retro, 80's
style (though it is F83 not FIG).

<Entire CLF community rolls eyes!>

[Arnold Doray]

Thank you for the tip on the Classic99 emulator. I have stopped using
Windows for over a decade now, so I hope it runs on Wine. I will
definitely give it a try.

Do you plan to release your source code? Or is it already on the website?

What made you choose the TI-99/4A?

Cheers,
Arnold

[Arnold Doray]

Thanks again Mark. That was a very clear explanation.

Cheers,
Arnold

[Mark Wills]

> >www.harmlesslion.comand download Classic99 from here:

>
> >http://www.harmlesslion.com/cgi-bin/showprog.cgi?Windows
>
> > Classic99 is a TI-99/4A emulator for Windows (not written by me). The
> > author has included TurboForth (it's embedded in the .exe) and the util
> > disk which accompanies it.
>
> > TurboForth may not be to your taste however, as it's very retro, 80's
> > style (though it is F83 not FIG).
>
> > <Entire CLF community rolls eyes!>
>
> Thank you for the tip on the Classic99 emulator. I have stopped using
> Windows for over a decade now, so I hope it runs on Wine. I will
> definitely give it a try.
>
> Do you plan to release your source code? Or is it already on the website?
>
> What made you choose the TI-99/4A?
>
> Cheers,
> Arnold

Hi Arnold

The source code is available. Currently, it's only available on the
TurboForth mailing list over at Yahoo (see http://turboforth.net/download.htm)
for the mailing address URL.

However, there's no reason why I shouldn't put it up on TurboForth.net
too. I'll try and do that tonight. It's heavily commented code, mostly
in assembly, but it's quite easy to follow.

I chose the TI-99/4A simply because I'm intimately familiar with it's
architecture, and the TMS9900 instruction set. It was the first
computer in my family as a child back in '82/83.

These days, I just can't get the enthusiasm to learn Pentium machine
code on PC's, and I'm not really interested in C anymore. I like
coding on the metal.

I'm currently building a TMS9995 based machine on bread board for
"fun". TurboForth will be ported to it. I'm doing the glue logic with
an FPGA which gives me a chance to do a little VHDL. From there, I'll
probably have a go at a very simple Forth based processor. It's all
just for fun.

Mark

[Mark Wills]

> >www.harmlesslion.comand download Classic99 from here:

>
> >http://www.harmlesslion.com/cgi-bin/showprog.cgi?Windows
>
> > Classic99 is a TI-99/4A emulator for Windows (not written by me). The
> > author has included TurboForth (it's embedded in the .exe) and the util
> > disk which accompanies it.
>
> > TurboForth may not be to your taste however, as it's very retro, 80's
> > style (though it is F83 not FIG).
>
> > <Entire CLF community rolls eyes!>
>
> Thank you for the tip on the Classic99 emulator. I have stopped using
> Windows for over a decade now, so I hope it runs on Wine. I will
> definitely give it a try.
>
> Do you plan to release your source code? Or is it already on the website?
>
> What made you choose the TI-99/4A?
>
> Cheers,
> Arnold

Oh, regarding Classic99 in Wine: Yes it does work. I use it with
Ubuntu and it works just fine.

[Elizabeth D. Rather]

Yes, but I'm surprised that it was necessary. What part of "CREATE
doesn't allocate any data space" is hard to understand?

Mark's example is typical of integrated dictionary/data space
implementations, although exactly what would be found at the first
location of a colon definition will vary. In an implementation in which
data space is segregated, it might just be whatever is left over in an
otherwise unused cell, or one used for some prior purpose.

Cheers,
Elizabeth

[Rod Pemberton]

"Mark Wills" <markrob...@yahoo.co.uk> wrote in message

news:692e810d-4789-456d...@do4g2000vbb.googlegroups.com...
...

> So, it seems, with bigForth, that it's using HERE for something,

Yes.

> and it's tripping you up,

No.

> because you didn't compile a value into the body
> of the word you created

True.

The space is not allocated from Forth's perspective. It's present though.
So, it was allocated for use, just not in the Forth sense. From Forth's
perspective, it still could be allocated at a later time though, e.g.,
ALLOT.

Whether one should or shouldn't use space that is not allocated from Forth's
perspective is apparently open to debate. I've not noticed anything in the
spec's on it, although I haven't fully read them ...

> as was expected.

uh ...


fig-Forth copies parsing data to HERE. It's part of WORD.That should
overwrite what's at HERE when unallocated. I couldn't get the test to work
on actual fig-Forths. CREATE <name> was accepted, but the CREATE-ed word
couldn't be found ... I based my parsing on fig-Forth code. It seems
bigForth is doing the same.

FYI, it turns out it's an easy fix.

Instead of copying every word parsed by ENCLOSE via CMOVE to HERE, you leave
the parsed words in your parsing buffer which is TIB in my case. The code
only copies the name to the name field when CREATE is executed, instead of
copying the parsed token every time WORD is executed. I had to change
FIND and CREATE and WORD You probably won't need to change FIND.

Fixing "the issue" has a few advantages too.

Copying every parsed word in the input stream to HERE slowed down my
interpreter. bigForth seems so slow ... Now, it only copies when CREATE
creates a name field. Copying the parsed stream to HERE also implies the
name field is at the start of the dictionary. I.e., an additional copy is
needed if the name field isn't at the start and you are copying all parsed
to HERE. When not copying all parsed data to HERE, you still need a copy
but you eliminate the unecessary copies to HERE.

> Did you try the code I posted earlier?
>

No, I didn't. I will since you brought it up again.

> CREATE FRED
> : TEST 1 2 3 ;
> FRED
> error: FRED not found

There's no error on mine ... At the moment, it passively does nothing for
unfound words. That's on the TO DO list. I have to ' TICK <name> DUMP to
see if the word is correctly built. DUMP is customized C code which
displays the dictionary header and a fixed bunch of cells, e.g., first
portion of the body or PF area, as hex.

But, from what you said in the other posts, I think you may have meant TEST.
You were probably thinking of something like this:

CREATE FRED
: TEST 1 2 3 ;

4 FRED !
TEST

The store to FRED should've overwritten the first part of the dictionary
structure for TEST. If your name field is first, the name field will be
corrupted, i.e., it shouldn't find TEST. The now fixed version of my
interpreter "blows up" since the link field is first.

> This is because, what gets compiled, is this:
>
> BODY
> -----+---------+----+------+-------+-----+---+-----+---+------+
> FRED | DO_PUSH | 0* | TEST | LIT 1 | LIT | 2 | LIT | 3 | EXIT |
> -----+---------+----+------+-------+-----+---+-----+---+------+
> ^--------------------+
>
> So, the *body* of FRED actually has a part of the definition
> of TEST in it.

My interpreter does the following. I recently removed DOVAR That's been
replaced with an ENTER VAR sequence for now. I've not fixed my DOES> with
an additional field in the header yet either ... FRED returns the address
of TEST.

BODY
-----+---------+-----+------+-------+-----+---+-----+---+------+
FRED | ENTER | VAR | TEST | LIT 1 | LIT | 2 | LIT | 3 | EXIT |
-----+---------+-----+------+-------+-----+---+-----+---+------+
^--------------------+

> [snip]
>
> Does that make sense?

Yes.

I don't have an issue understanding what is happening. I found and brought
up the issue.

> * The zero is normally compiled just in case a CREATEd word is
> subsequently modified by DOES> - it reserves space for an address if
> required. If a CREATEd word is modified by DOES> then the DO_PUSH
> (which just pushes the address of the body of the created word) is
> replace with DO_DOES and the 0 in front of it is replaced with the
> address of the code just after DOES> in the parent word.

It's on the TO DO list ... I have to make sure it doesn't break my
structure addressing words.


Rod Pemberton

[Elizabeth D. Rather]

On 1/27/12 3:21 PM, Rod Pemberton wrote:
> "Mark Wills"<markrob...@yahoo.co.uk> wrote in message
> news:692e810d-4789-456d...@do4g2000vbb.googlegroups.com...
> ...
>
>> So, it seems, with bigForth, that it's using HERE for something,
>
> Yes.
>
>> and it's tripping you up,
>
> No.
>
>> because you didn't compile a value into the body
>> of the word you created
>
> True.
>
> The space is not allocated from Forth's perspective. It's present though.
> So, it was allocated for use, just not in the Forth sense. From Forth's
> perspective, it still could be allocated at a later time though, e.g.,
> ALLOT.

If you're programming in Forth, "the Forth sense" is all that matters, IMO.

> Whether one should or shouldn't use space that is not allocated from Forth's
> perspective is apparently open to debate. I've not noticed anything in the
> spec's on it, although I haven't fully read them ...

I am baffled as to how you think you're entitled to use space that
hasn't been explicitly allocated. The definition of CREATE contains a
notice to the effect that it has not allocated any space. You must do
so. If you have done one of the things that allocates data space (ALLOT,
, C, etc.) then that space is yours. Otherwise, it is the system's
space, to use at it sees fit.

All implementations are different in terms of how they use data space,
so you can get no portable behavior without allocating data space before
using it. People in this thread have noted different system approaches
to using scratch space, but I haven't seen anyone claim that you have
any *entitlement* to expect unallocated space to be preserved, so I do
not think that is "open to debate".

>> as was expected.
>
> uh ...

Exactly!

[BruceMcF]

On Jan 27, 8:21 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:

> Whether one should or shouldn't use space that is not allocated from
> Forth's perspective is apparently open to debate.  I've not noticed
> anything in the spec's on it, although I haven't fully read them ...

-----------------------
3.3.3 Data space
Data space is the only logical area of the dictionary for which
standard words are provided to allocate and access regions of memory.
These regions are: contiguous regions, variables, text-literal
regions, input buffers, and other transient regions, each of which is
described in the following sections. A program may read from or write
into these regions unless otherwise specified.
-----------------------

... and following in 3.3.3.x ...

[Brad]

On Jan 27, 6:21 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:

> Fixing "the issue" has a few advantages too.
>

Getting an error for using data space that you're not entitled to is
not a bug. It's a feature. Crash early and crash often.

Reporting the error is the best thing. Maybe if data space is an
ALLOCATEd region, ALLOT and comma could resize it. Let the OS be the
memory cop. That may not an option for FIG Forth, though.

-Brad

[Rod Pemberton]

"Elizabeth D. Rather" <era...@forth.com> wrote in message

news:_eCdnZLZSrOuxr7S...@supernews.com...

> On 1/27/12 3:21 PM, Rod Pemberton wrote:

...

> > Whether one should or shouldn't use space that is not allocated from
> > Forth's perspective is apparently open to debate. I've not noticed
> > anything in the spec's on it, although I haven't fully read them ...
>
> I am baffled as to how you think you're entitled to use space that
> hasn't been explicitly allocated.
>

I'm not about to use space that isn't allocated (from Forth's perspective).
However, AISI, it's not a matter of entitlement. It's an issue of user
expectation. A user, i.e., a novice programmer, expects Forth words to do
only what they've been told that the Forth words do. They don't expect
anything more or anything less. They don't expect side effects, undefined
behavior, or expect to be required to have an inside knowledge of what is
happening in the Forth parser and compiler. If storing and allocation are
separate, why would the user expect that the order in which they occur is
important? When a value is stored into the dictionary via , COMMA the user
expects that the value is allocated too. They don't expect that a COMMA'd
value could be overwritten. So, when a value is ! STOREd into a variable,
why would a user *expect* that the variable's value could be overwritten?
Wasn't the variable created already? Wasn't space allocated for the
variable when it was created? If no space was allocated for the variable
when it was created, what was the point of creating the variable? Forth is
contrary to *all* other programming languages. Name one other language
where a variable is created but has no space allocated for it by default.
Some languages do provide that ability as a feature, but don't do so by
default. It's only if the user has inside knowledge or understands there is
a side effect to using CREATE that the user would have the expectation
that an ALLOT is required. In essence, there is a hidden constraint placed
upon when or where or how VARIABLE can legally be used with CREATE.


Rod Pemberton

[Alex McDonald]

On Jan 28, 11:18 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:

> "Elizabeth D. Rather" <erat...@forth.com> wrote in messagenews:_eCdnZLZSrOuxr7S...@supernews.com...> On 1/27/12 3:21 PM, Rod Pemberton wrote:
>
> ...
>
> > > Whether one should or shouldn't use space that is not allocated from
> > > Forth's perspective is apparently open to debate.  I've not noticed
> > > anything in the spec's on it, although I haven't fully read them ...
>
> > I am baffled as to how you think you're entitled to use space that
> > hasn't been explicitly allocated.
>
> I'm not about to use space that isn't allocated (from Forth's perspective).
> However, AISI, it's not a matter of entitlement.  It's an issue of user
> expectation.  A user, i.e., a novice programmer, expects Forth words to do
> only what they've been told that the Forth words do.  They don't expect
> anything more or anything less.  They don't expect side effects, undefined
> behavior, or expect to be required to have an inside knowledge of what is
> happening in the Forth parser and compiler.  If storing and allocation are
> separate, why would the user expect that the order in which they occur is
> important?  When a value is stored into the dictionary via , COMMA the user
> expects that the value is allocated too.  They don't expect that a COMMA'd
> value could be overwritten.  So, when a value is ! STOREd into a variable,
> why would a user *expect* that the variable's value could be overwritten?

Because CREATE isn't a variable, that's why.

> Wasn't the variable created already?  Wasn't space allocated for the
> variable when it was created?  If no space was allocated for the variable
> when it was created, what was the point of creating the variable?  Forth is
> contrary to *all* other programming languages.  Name one other language
> where a variable is created but has no space allocated for it by default.

CREATE doesn't create a variable; it creates a name that references
the address at HERE. If you want a variable then say so with VARIABLE.
In C, you might look at struct, and other language also support record
types. Forth's CREATE is no different in that respect.

> Some languages do provide that ability as a feature, but don't do so by
> default.  It's only if the user has inside knowledge or understands there is
> a side effect to using CREATE that the user would have the expectation
> that an ALLOT is required.  In essence, there is a hidden constraint placed
> upon when or where or how VARIABLE can legally be used with CREATE.

The last sentence doesn't make sense.

>
> Rod Pemberton

[Mark Wills]

On Jan 28, 7:18 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:

CREATE doesn't ALLOT space. VARIABLE does.

: VARIABLE CREATE 0 , ; IMMEDIATE

Mark

[Elizabeth D. Rather]

On 1/28/12 9:18 AM, Rod Pemberton wrote:
> "Elizabeth D. Rather"<era...@forth.com> wrote in message
> news:_eCdnZLZSrOuxr7S...@supernews.com...
>> On 1/27/12 3:21 PM, Rod Pemberton wrote:
> ...
>
>>> Whether one should or shouldn't use space that is not allocated from
>>> Forth's perspective is apparently open to debate. I've not noticed
>>> anything in the spec's on it, although I haven't fully read them ...
>>
>> I am baffled as to how you think you're entitled to use space that
>> hasn't been explicitly allocated.
>>
>
> I'm not about to use space that isn't allocated (from Forth's perspective).
> However, AISI, it's not a matter of entitlement. It's an issue of user
> expectation. A user, i.e., a novice programmer, expects Forth words to do
> only what they've been told that the Forth words do. They don't expect
> anything more or anything less. They don't expect side effects, undefined
> behavior, or expect to be required to have an inside knowledge of what is
> happening in the Forth parser and compiler.

Show me one book or manual on Forth that doesn't say explicitly that
CREATE *doesn't* allocate any space. This is certainly not something
that can be considered a "side effect" or require "inside knowledge".

> If storing and allocation are
> separate, why would the user expect that the order in which they occur is
> important? When a value is stored into the dictionary via , COMMA the user
> expects that the value is allocated too. They don't expect that a COMMA'd
> value could be overwritten. So, when a value is ! STOREd into a variable,
> why would a user *expect* that the variable's value could be overwritten?
> Wasn't the variable created already? Wasn't space allocated for the
> variable when it was created? If no space was allocated for the variable
> when it was created, what was the point of creating the variable?

As others have pointed out, CREATE is not a VARIABLE. It is a name
associated with a location in data space. Every description of words
that allocate data space say so, and every description of CREATE (that I
know of) says explicitly that it *does not* allocate any data space.

> Forth is
> contrary to *all* other programming languages. Name one other language
> where a variable is created but has no space allocated for it by default.

Name one language in which programs are entitled to store into
unallocated data space.

> Some languages do provide that ability as a feature, but don't do so by
> default. It's only if the user has inside knowledge or understands there is
> a side effect to using CREATE that the user would have the expectation
> that an ALLOT is required. In essence, there is a hidden constraint placed
> upon when or where or how VARIABLE can legally be used with CREATE.

VARIABLE is not "legally used with CREATE". They are separate and
independent defining words. VARIABLE *can* be defined using CREATE, but
not necessarily. There are no "hidden constraints" or "inside knowledge"
involved in this issue. The behavior of VARIABLE, CREATE, COMMA, and all
other words that involve management of data space is explicitly documented.

You need to read your documentation more.

[Brad]

On Jan 28, 2:42 pm, Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
> CREATE doesn't ALLOT space. VARIABLE does.
>
> : VARIABLE  CREATE 0 , ; IMMEDIATE
>

VARIABLE is not IMMEDIATE.

[BruceMcF]

On Jan 28, 2:18 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:

> If storing and allocation are
> separate, why would the user expect that the order in which
> they occur is important?

Its been a long time since I've been forced to write in C, but as far
as I recall, I had to declare variables, constants, structs, and other
elements that allocated space in advance of using them.

Indeed, why *wouldn't* a user expect that if allocation and storage
are distinct, that you have to allocate first, then store? In the real
world, how often do you store papers in a file folder that you have
not yet fetched from the pack of file folders?

How could anyone see the wide variety of ways that CREATE is used to
define data objects and not grasp that CREATE just creates the
dictionary reference and *all* of the work in building the data object
follows after? That's the *difference* between CREATE and the
functionality of dedicated data definer words like VARIABLE CONSTANT
VALUE and the like.

[Mark Wills]

It is in mine!

[Arnold Doray]

On Sat, 28 Jan 2012 14:18:59 -0500, Rod Pemberton wrote:


>> I am baffled as to how you think you're entitled to use space that
>> hasn't been explicitly allocated.
>>
>>
> I'm not about to use space that isn't allocated (from Forth's
> perspective). However, AISI, it's not a matter of entitlement. It's an
> issue of user expectation. A user, i.e., a novice programmer, expects
> Forth words to do only what they've been told that the Forth words do.
> They don't expect anything more or anything less.

Yes, the principle of "least surprise" as it is known in the Ruby
community is a valid one. However, you have to work within the rules or
the language. As a novice Forth programmer, I had no problem whatsoever
grasping the difference between CREATE and VARIABLE, just from reading
Starting Forth, presumably where most if not all beginning Forth
programmers start off.

> the point of creating the variable? Forth is contrary to *all* other
> programming languages. Name one other language where a variable is
> created but has no space allocated for it by default. Some languages do
> provide that ability as a feature, but don't do so by default.

CREATE is much more than just creating names with no behaviour.

Coupled with DOES> it gives Forth its great flexibility. Very much like
Lisp's macros, but much more simply implemented. Most "hobby" Forths have
CREATE and DOES> but I have not seen any "hobby" lisps/schemes that have
macros.

Also, (IMHO) the Forth way is much more flexible, since CREATE can be
used in other contexts (eg, in conjunction with memory allocation on the
dictionary). It's very simple and very practical. Show me a language that
has something that comes close and I'll show you a Forth.

Cheers,
Arnold

[ken...@cix.compulink.co.uk]

In article
<915329e9-2bd1-4d74...@14g2000vbw.googlegroups.com>,

agi...@netscape.net (BruceMcF) wrote:

> I had to declare variables, constants, structs, and other
> elements that allocated space in advance of using them.

The only language I have come across that allowed the use of undeclared
variables was Basic. All the block structure ones required variables to
be declared at start of scope. I have not used Lisp or Lisp derived
languages much but am under the impression that they required some sort
of data declaration.

Ken Young

[Elizabeth D. Rather]

Why? It isn't supposed to be, and attempting to use it in a colon
definition can cause serious trouble.

[Elizabeth D. Rather]

On 1/28/12 11:18 PM, Arnold Doray wrote:
> CREATE is much more than just creating names with no behaviour.

Oh, it has a default behavior, all right, to return the address of the
next location in data space. It just doesn't have any allocated data
space at that location until you give it some.

[John Passaniti]

On Jan 29, 6:04 am, ken...@cix.compulink.co.uk wrote:
> The only language I have come across that allowed the use
> of undeclared variables was Basic.

I don't think that's a good example; in those BASICs you don't need to
explicitly declare the variable, but you're never accessing
unallocated storage. At the point of use, space for the variable is
allocated and the name is added to a symbol table. So it's an
implicit instead of explicit declaration, but it's still a
declaration.

[BruceMcF]

Whatever for? What is the point of having a dictionary-entry-creating
word execute while compiling another word? If *anything* shouldn't be
immediate, it would be VARIABLE CONSTANT and kin.

[BruceMcF]

On Jan 29, 6:04 am, ken...@cix.compulink.co.uk wrote:

> In article
> <915329e9-2bd1-4d74-a1bb-bd46ce8fc...@14g2000vbw.googlegroups.com>,

> agil...@netscape.net (BruceMcF) wrote:
>> I had to declare variables, constants, structs, and other
>> elements that allocated space in advance of using them.

>  The only language I have come across that allowed the use of
> undeclared variables was Basic.

I think AWK is a better example, but the point is not whether you have
languages that allocate space on their first use, but whether there is
any reason to expect that a language lets you use the space first, and
allocate it after.

[Mark Wills]

Indeed. I checked the F83 spec and my code is in error. Both variable
and constant are immediate. Probably an overhang that I overlooked
from the days when I didn't know better. The code grew rather
organically and was re-written a number of times, as evidenced in
previous hair-pulling posts!

A new release of Turboforth is due sometime soon (V1.2) so it will be
corrected for that.

Glad this came up, really.

[Anton Ertl]

"Elizabeth D. Rather" <era...@forth.com> writes:
>If you have done one of the things that allocates data space (ALLOT,
>, C, etc.) then that space is yours. Otherwise, it is the system's
>space, to use at it sees fit.

No, the standard explicitly enumerates the things in the system that
can destroy the space at here; as long a program does not use any of
these things, it can use the UNUSED space for any purpose. IIRC we
had a discussion about this several months ago, and there is code
which relies on this which would be significantly more cumbersome to
write if this usage were non-standard.

- 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 2011: http://www.euroforth.org/ef11/

[Mark Wills]

On Jan 30, 2:20 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:

From the implementation side, I can empathise. My system has dedicated
areas of memory for most things, so this problem doesn't arise;
however there is one quirk that is specific to my system. If you type
WORDS then the forth code for WORDS is written to HERE and then
executed. That means if you did...

CREATE FRED 100 FRED ! WORDS

...then your 100 has vanished.

So there are 'gotcha's' - however, as Elizabeth said, if you haven't
allocated the memory then you'd have no grounds to complain. CREATE
FRED 1 CELLS ALLOT 100 FRED ! would work just fine.

( though surely one would rather CREATE FRED 100 , )

Mark

[Andrew Haley]

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> "Elizabeth D. Rather" <era...@forth.com> writes:
>>If you have done one of the things that allocates data space (ALLOT,
>>, C, etc.) then that space is yours. Otherwise, it is the system's
>>space, to use at it sees fit.
>
> No, the standard explicitly enumerates the things in the system that
> can destroy the space at here; as long a program does not use any of
> these things, it can use the UNUSED space for any purpose. IIRC we
> had a discussion about this several months ago, and there is code
> which relies on this which would be significantly more cumbersome to
> write if this usage were non-standard.

I think you have to distinguish between good practice (which Elizabeth
has taught for many years) and exploiting the corners of the standard
and/or the way that Forth is traditionally implemented. Elizabeth's
recommendation is simple and safe. Playing with memory at HERE is, at
best, fragile: for example, you can't run it interpretively.

Andrew.

[Anton Ertl]

Mark Wills <markrob...@yahoo.co.uk> writes:
>CREATE FRED 100 FRED ! WORDS
>
>...then your 100 has vanished.

Sure, parsing is one of the things that may destroy the data at HERE.
WORDS itself is not, though, so if you do:

: foo 1000 over ! words @ . ;
create bar here foo

you should see 1000 printed at the end.

>So there are 'gotcha's' - however, as Elizabeth said, if you haven't
>allocated the memory then you'd have no grounds to complain.

If the system claims to be standard and your program does not do any
of the things for which a standard system is allowed to destroy the
data at HERE, and the system does destroy the data, you have grounds
to complain. The system should not be labeled as standard system (it
might be labeled as a "standard system with the environmental
restriction that ...", though).

[Bernd Paysan]

Rod Pemberton wrote:

> Bernd Paysan,
>
> I know you're not fond of my statements, but I'm probably helping you
> out with this bug report. Are you aware of the following issue?

Yes. I may "fix" this by not using WORD for parsing anymore. But I
won't hurry on that one, because there's nothing broken.

I'm glad I did not participate in this discussion, but instead met my
girlfriend in China to celebrate chinese new year. What a waste of time
it would have been otherwise.

It's the novice attitute "I found a heisenbug in my program, which does
not always show up. You must fix your system so that my buggy program
can run!!!1111!eleven!!!"

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[Rod Pemberton]

"Mark Wills" <markrob...@yahoo.co.uk> wrote in message

news:37a07d04-3417-4f10...@dp8g2000vbb.googlegroups.com...
...

> Glad this came up, really.

Heh! Isn't that about three times now? Either you need to ask more
questions, or you need to encourage me to incite them some more ...

My interpreter is coming along nicely now. I should be able to push out all
pre-compiled words into Forth as ASCII text. That'll leave just the
primitives, an single pre-compiled word representing the entire Forth
interpreter reduced into just primitives, and text definitions which should
include redefinitions of the interpreter. There are still some words that
are mostly in C, like FIND, that I need to convert to Forth.

I'm also planning on restructuring the interpreter to work like fig-Forth.
fig-Forth breaks the interpreter into six states, which are reduced by the
logic into four. Mine supports 0xC0 for state, so I can do the STATE
comparison like fig-Forth. The fig-Forth way also requires LITERAL to be
STATE smart. This makes NUMBER LITERAL be either NUMBER or
NUMBER LITERAL There is a "hidden" IF THEN that's STATE aware.
Anyway, the combination of the STATE smart LITERAL and STATE
comparison reduce the IF THENs in the inner interpreter. I implemented
the my inner interpreter following Andrew Haley's method. His method
produces five states. He uses a special word to test for immediacy. His
reverses the traditional order for checks against FIND and STATE, thereby
forcing an additional state into 'compiler' to handle IMMEDIATE words.
I still find that to be awkard. In another thread, E.R. thought it was well
thought out. fig-Forth uses the less-than comparison to force three of
the six states to execute words.

http://groups.google.com/group/comp.lang.forth/msg/68915cdba3b07323


Rod Pemberton