Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #11860 > unrolled thread

Distinguishing DOES>

Back to article view | Back to comp.lang.forth

Contents

  Distinguishing DOES> JennyB <jennybrien@googlemail.com> - 2012-05-03 08:59 -0700
    Re: Distinguishing DOES> Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-05-03 17:23 -0700
      Re: Distinguishing DOES> Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-05-04 10:47 +0100
        Re: Distinguishing DOES> Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-04 05:12 -0500
          Re: Distinguishing DOES> anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-04 11:33 +0000
            Re: Distinguishing DOES> Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-04 08:11 -0500
              Re: Distinguishing DOES> anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-04 16:18 +0000
                Re: Distinguishing DOES> Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-05 02:02 -0500
                  Re: Distinguishing DOES> anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-05 14:16 +0000
                    Re: Distinguishing DOES> Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-06 02:53 -0500
                  Re: Distinguishing DOES> anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-05 14:25 +0000
                    Re: Distinguishing DOES> BruceMcF <agila61@netscape.net> - 2012-05-05 08:07 -0700
                      Re: Distinguishing DOES> Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-05-08 06:23 -0700
                        Re: Distinguishing DOES> Bernd Paysan <bernd.paysan@gmx.de> - 2012-05-09 00:25 +0200
                          Re: Distinguishing DOES> Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-05-09 01:26 -0700
                          Re: Distinguishing DOES> Mark Wills <markrobertwills@yahoo.co.uk> - 2012-05-09 03:18 -0700
                            Re: Distinguishing DOES> Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-09 05:29 -0500
                            Re: Distinguishing DOES> "Elizabeth D. Rather" <erather@forth.com> - 2012-05-09 07:11 -1000
                          Re: Distinguishing DOES> Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-05-09 22:48 +0100
                            Re: Distinguishing DOES> Bernd Paysan <bernd.paysan@gmx.de> - 2012-05-09 23:22 +0200
                              Re: Distinguishing DOES> Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-05-09 23:43 +0100
                                Re: Distinguishing DOES> Bernd Paysan <bernd.paysan@gmx.de> - 2012-05-10 00:49 +0200
                                  Re: Distinguishing DOES> Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-05-10 11:33 +0100
                              Re: Distinguishing DOES> Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-05-10 10:02 +0000
                                Re: Distinguishing DOES> Bernd Paysan <bernd.paysan@gmx.de> - 2012-05-10 15:13 +0200
                              Re: Distinguishing DOES> Mark Wills <markrobertwills@yahoo.co.uk> - 2012-05-10 05:07 -0700
                                Re: Distinguishing DOES> Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-05-10 22:57 -0700
    Re: Distinguishing DOES> Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-05-04 12:37 +0000
    Re: Distinguishing DOES> Doug Hoffman <glidedog@gmail.com> - 2012-05-04 10:14 -0400
      Re: Distinguishing DOES> humptydumpty <ouatubi@gmail.com> - 2012-05-04 20:27 +0000
        Re: Distinguishing DOES> Doug Hoffman <glidedog@gmail.com> - 2012-05-05 06:16 -0400
          Re: Distinguishing DOES> JennyB <jennybrien@googlemail.com> - 2012-05-05 07:19 -0700
            Re: Distinguishing DOES> anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-05 14:55 +0000
              Re: Distinguishing DOES> JennyB <jennybrien@googlemail.com> - 2012-05-07 07:24 -0700
            Re: Distinguishing DOES> Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-05-06 11:04 +0000
            Re: Distinguishing DOES> Doug Hoffman <glidedog@gmail.com> - 2012-05-06 07:47 -0400
          Re: Distinguishing DOES> ward@megawolf.com - 2012-05-08 04:39 -0700
            Re: Distinguishing DOES> Doug Hoffman <glidedog@gmail.com> - 2012-05-08 07:50 -0400
    Re: Distinguishing DOES> Hans Bezemer <the.beez.speaks@gmail.com> - 2012-05-05 14:24 +0200
      Re: Distinguishing DOES> Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-05-06 11:09 +0000

Page 1 of 2  [1] 2  Next page →

#11860 — Distinguishing DOES>

I have often seen implementation-dependent code to test if a given xt belongs to the child of a particular defining work. It seems to me that, given sufficient carnal knowledge, this should be possible in any Forth. The most usual technique is to define a prototype and then compare the contents of the xts.

So in any Forth it should be possible to write:

: HUMAN CREATE  ... DOES> ... ;

Human ALICE
' Bob ' Alice like?  \ true if Bob is HUMAN

Is it?
Is it possible (and worthwhile) to remove the need for a prototype by redefining the defining word?

[toc] | [next] | [standalone]

#11895

On May 3, 9:59 am, JennyB <jennybr...@googlemail.com> wrote:
> I have often seen implementation-dependent code to test if a given xt belongs to the child of a particular defining work. It seems to me that, given sufficient carnal knowledge, this should be possible in any Forth. The most usual technique is to define a prototype and then compare the contents of the xts.
>
> So in any Forth it should be possible to write:
>
> : HUMAN CREATE  ... DOES> ... ;
>
> Human ALICE
> ' Bob ' Alice like?  \ true if Bob is HUMAN
>
> Is it?
> Is it possible (and worthwhile) to remove the need for a prototype by redefining the defining word?

When I was programming for Testra, I still used CREATE DOES> --- I
would just always comma a signature cell in after the CREATE. The
signatures came from a global variable that would get incremented with
every use of CREATE so each defining word had a unique signature. In
my MFX compiler, I had <BUILDS that was distinct from CREATE (CREATE
was just HERE CONSTANT) so I could do stuff like this in <BUILDS
because I knew that this was a defining word. I am very opposed to the
ANS-Forth overloading of CREATE to be used both in defining words (in
conjunction with DOES>) as for defining simple variables (that don't
get a DOES>). I tried to talk the Forth-200x committee into
reintroducing <BUILDS but that worked as well as talking sense into
the Forth-200x committee usually does. In my Straight Forth I will
certainly have <BUILDS for defining words and CREATE for HERE
CONSTANT.

With signatures, you don't need a prototype --- just store the current
signature value into a constant after defining the defining word, and
that constant can then be compared to the signature-cell in the object
to determine if the object is of that type. Of course, you can also
compare the signature-cells of two object as you did in your example
above.

Signatures could be used with structs like I have in the novice
package, although I usually just assume that they are all different
sizes and the size identifies the type (this works when all of the
data types in the program are in a single parent-child chain, which is
pretty common). All of this is pretty crude because it doesn't take
into account inheritance --- the IS-A function in most OOP languages
would return true if the object is a child of the target type. I could
upgrade the novice package to use signatures and to allow for an IS-A
function that took inheritance into account --- maybe I will in the
next release.

I don't use CREATE DOES> (or <BUILDS DOES>) very much anymore --- I
generally use :NAME now.

[toc] | [prev] | [next] | [standalone]

#11909

In comp.lang.forth, Hugh Aguilar wrote:

> [..] I had <BUILDS that was distinct from CREATE (CREATE
> was just HERE CONSTANT) so I could do stuff like this in <BUILDS
> because I knew that this was a defining word. I am very opposed to the
> ANS-Forth overloading of CREATE to be used both in defining words (in
> conjunction with DOES>) as for defining simple variables (that don't
> get a DOES>).

Why? What's so special about <BUILDS ?

In an old handbook I've found, that <BUILDS can be defined just as:

: <BUILDS   0 CONSTANT ;

What were/are its supposed advantages(?) over CREATE ? Does it make any
significant difference, whether somewhere will be 0 or HERE inserted, when
it shall be replaced during DOES> phase anyway?
-- 
Forth is a preserver of health (Hippocrates)

[toc] | [prev] | [next] | [standalone]

#11911

Zbiggy <zbigniew2011REMOVE@gmail.remove.com> wrote:
> In comp.lang.forth, Hugh Aguilar wrote:
> 
>> [..] I had <BUILDS that was distinct from CREATE (CREATE
>> was just HERE CONSTANT) so I could do stuff like this in <BUILDS
>> because I knew that this was a defining word. I am very opposed to the
>> ANS-Forth overloading of CREATE to be used both in defining words (in
>> conjunction with DOES>) as for defining simple variables (that don't
>> get a DOES>).
> 
> Why? What's so special about <BUILDS ?
> 
> In an old handbook I've found, that <BUILDS can be defined just as:
> 
> : <BUILDS   0 CONSTANT ;
> 
> What were/are its supposed advantages(?) over CREATE ? Does it make
> any significant difference, whether somewhere will be 0 or HERE
> inserted, when it shall be replaced during DOES> phase anyway?

Assuming a fairly conventional threaded implementation, <BUILDS wastes
a cell, CREATE doesn't.  CREATE replaced <BUILDS in DOES> words for
that reason: it's a superior implementation technique.

Andrew.

[toc] | [prev] | [next] | [standalone]

#11913

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Assuming a fairly conventional threaded implementation, <BUILDS wastes
>a cell, CREATE doesn't.

You are comparing two different implementation techniques for DOES>
(or, in colloquial English, you are comparing apples and oranges).
For context, consider this example:

: constant <builds , does> ( handler ) @ ;
5 constant foo

The two implementation techniques are:

1) The header of FOO looks as follows:

Name field, link field
dodoes (code field)
handler (points where HANDLER is in the code above)
5      (data)

Here we have DODOES to know how to treat the word on the machine code
level and HANDLER to find the high-level code.

2) The header of FOO looks as follows:

Name field, link field
handler-5 (or so)
5

and at HANDLER-5 we have

jsr dodoes (or somesuch)

Here the JSR pushes HANDLER on the return stack and DODOES finds it
there.


Using the first technique with CREATE would mean that every CREATEd
word would need cell containing the handler, just in case a DOES>
comes along.  Therefore, people introduced BUILDS> so that they would
not have this overhead for other CREATEd words.  So, if you use that
technique, letting DOES> work with CREATE (instead of just with
<BUILDS) costs an extra cell for every DOES>-less created word.

With the second technique <BUILDS is just the same as CREATE, so
<BUILDS was left away in systems employing this technique.

>CREATE replaced <BUILDS in DOES> words for
>that reason: it's a superior implementation technique.

You mean that the second technique above is superior.  For some
settings that is the case, for others it isn't (e.g., Gforth uses
technique 1, and there are good reasons for that; and every code field
has an extra cell).  In any case, the second implementation technique
is completely compatible with <BUILDS, just define

: <BUILDS CREATE ;

- 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/

[toc] | [prev] | [next] | [standalone]

#11919

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:

>> Assuming a fairly conventional threaded implementation, <BUILDS
>> wastes a cell, CREATE doesn't.
> 
> You are comparing two different implementation techniques for DOES>
> (or, in colloquial English, you are comparing apples and oranges).

Not at all: the older techniqure required <BUILDS, the newer didn't.

> For context, consider this example:

> : constant <builds , does> ( handler ) @ ;
> 5 constant foo
> 
> The two implementation techniques are:
> 
> 1) The header of FOO looks as follows:
> 
> Name field, link field
> dodoes (code field)
> handler (points where HANDLER is in the code above)
> 5      (data)
> 
> Here we have DODOES to know how to treat the word on the machine code
> level and HANDLER to find the high-level code.
> 
> 2) The header of FOO looks as follows:
> 
> Name field, link field
> handler-5 (or so)
> 5
> 
> and at HANDLER-5 we have
> 
> jsr dodoes (or somesuch)
> 
> Here the JSR pushes HANDLER on the return stack and DODOES finds it
> there.
> 
> Using the first technique with CREATE would mean that every CREATEd
> word would need cell containing the handler, just in case a DOES>
> comes along.  Therefore, people introduced BUILDS> so that they
> would not have this overhead for other CREATEd words.  So, if you
> use that technique, letting DOES> work with CREATE (instead of just
> with <BUILDS) costs an extra cell for every DOES>-less created word.

Indeed it does.

> With the second technique <BUILDS is just the same as CREATE, so
> <BUILDS was left away in systems employing this technique.

That's exactly right: there no longer was any need for CREATE and
<BUILDS to be different, so BUILDS> was dropped.  There certainly was
no need to keep BUILDS> as an alias for CREATE because BUILDS> only
existed because the older implementation technique forced it to be
different from CREATE.

Andrew.

[toc] | [prev] | [next] | [standalone]

#11924

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>
>>> Assuming a fairly conventional threaded implementation, <BUILDS
>>> wastes a cell, CREATE doesn't.
>> 
>> You are comparing two different implementation techniques for DOES>
>> (or, in colloquial English, you are comparing apples and oranges).
>
>Not at all: the older techniqure required <BUILDS

It doesn't, as is demonstrated by Gforth, which uses the older
technique without <BUILDS.

> the newer didn't.

But it doesn't prohibit <BUILDS, either.  So, either technique can be
used with or without <BUILDS, and your statement about <BUILDS wasting
a cell is just wrong.

>> With the second technique <BUILDS is just the same as CREATE, so
>> <BUILDS was left away in systems employing this technique.
>
>That's exactly right: there no longer was any need for CREATE and
><BUILDS to be different, so BUILDS> was dropped.  There certainly was
>no need to keep BUILDS> as an alias for CREATE because BUILDS> only
>existed because the older implementation technique forced it to be
>different from CREATE.

It didn't.  And removing <BUILDS removed the implementation option of
using that technique without using the extra cell for all CREATEd
words, so if allowing different implementation options is good, that
removal was bad.  But of course CREATE...DOES> was standardized in
Forth-79, while implementation options was a principle for Forth-94.

- 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/

[toc] | [prev] | [next] | [standalone]

#11932

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>
>>>> Assuming a fairly conventional threaded implementation, <BUILDS
>>>> wastes a cell, CREATE doesn't.
>>> 
>>> You are comparing two different implementation techniques for DOES>
>>> (or, in colloquial English, you are comparing apples and oranges).
>>
>>Not at all: the older techniqure required <BUILDS
> 
> It doesn't, as is demonstrated by Gforth, which uses the older
> technique without <BUILDS.

That only changes the name of the word, not what it does.  <BUILDS
DOES> is the older technique, CREATE DOES> the newer one; this is a
matter of historical fact.  Of course you can redefine a word to do
anything.  Of course you can rename CREATE to perform the function
historically performed by <BUILDS, in which case CREATE wastes a cell
too.

>> the newer didn't.
> 
> But it doesn't prohibit <BUILDS, either.  So, either technique can be
> used with or without <BUILDS, and your statement about <BUILDS wasting
> a cell is just wrong.

Historically, <BUILDS was used with the extra cell.  It would have
been possible to use the name CREATE to indicate the function of
<BUILDS, but only at the cost of wasting a cell for every child of
CREATE .  Back then, no reasonable person would have wanted to do such
a thing; today, people don't worry so much.

>>> With the second technique <BUILDS is just the same as CREATE, so
>>> <BUILDS was left away in systems employing this technique.
>>
>>That's exactly right: there no longer was any need for CREATE and
>><BUILDS to be different, so BUILDS> was dropped.  There certainly was
>>no need to keep BUILDS> as an alias for CREATE because BUILDS> only
>>existed because the older implementation technique forced it to be
>>different from CREATE.
> 
> It didn't. 

I'm surprised that you can argue with this, since it's a matter of
fact: it is the only reason that <BUILDS existed.

> And removing <BUILDS removed the implementation option of using that
> technique without using the extra cell for all CREATEd words, so if
> allowing different implementation options is good,

I don't think that anyone maintains that allowing different
implementation options is always good.  For example, see the
discussion about the floating-point stack, where one such option was
deleted in order to improve the language.

> that removal was bad.

Andrew.

[toc] | [prev] | [next] | [standalone]

#11938

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> It doesn't, as is demonstrated by Gforth, which uses the older
>> technique without <BUILDS.
>
>That only changes the name of the word, not what it does.

CREATE in Gforth does what the standard says CREATE should do.

><BUILDS
>DOES> is the older technique, CREATE DOES> the newer one; this is a
>matter of historical fact.  Of course you can redefine a word to do
>anything.

Yes, and you have redefined CREATE and <BUILDS to be implementation
techniques, not word names.  Humpty Dumpty would be proud of you:-).

>I don't think that anyone maintains that allowing different
>implementation options is always good.

Often the "this allows different implementation options" argument
is used as if it justified everything.

- 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/

[toc] | [prev] | [next] | [standalone]

#11944

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> It doesn't, as is demonstrated by Gforth, which uses the older
>>> technique without <BUILDS.
>>
>>That only changes the name of the word, not what it does.
> 
> CREATE in Gforth does what the standard says CREATE should do.
> 
>><BUILDS DOES> is the older technique, CREATE DOES> the newer one;
>>this is a matter of historical fact.  Of course you can redefine a
>>word to do anything.
> 
> Yes, and you have redefined CREATE and <BUILDS to be implementation
> techniques, not word names.  Humpty Dumpty would be proud of you:-).

I haven't redefined them, though: I have been using them correctly in
their historical context.  We have never had names for the two
techniques, so the names that the words had at the time have to
suffice.

>> I don't think that anyone maintains that allowing different
>> implementation options is always good.
> 
> Often the "this allows different implementation options" argument is
> used as if it justified everything.

It's a pretty powerful argument, but it doesn't trump everything.

Andrew.

[toc] | [prev] | [next] | [standalone]

#11939

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>That's exactly right: there no longer was any need for CREATE and
>>><BUILDS to be different, so BUILDS> was dropped.  There certainly was
>>>no need to keep BUILDS> as an alias for CREATE because BUILDS> only
>>>existed because the older implementation technique forced it to be
>>>different from CREATE.
>> 
>> It didn't. 
>
>I'm surprised that you can argue with this, since it's a matter of
>fact: it is the only reason that <BUILDS existed.

It is probably the reason that <BUILDS existed, but the technique does
not force CREATE to be different from <BUILDS (Gforth demonstrates
that).  There is a difference between allowing something and forcing
something.  <BUILDS existed, because it allowed CREATE to be different
and consume less space.

- 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/

[toc] | [prev] | [next] | [standalone]

#11941

On May 5, 10:25 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:

> <BUILDS existed, because it allowed CREATE to be different
> and consume less space.

And in that *system* "CREATE ... DOES>" did not work, because "DOES>"
assumed a preceding "<BUILD".

Having a single defining word that works as CREATE and also works as
<BUILDS is a different system than having one defining word that works
as CREATE and a different word that is paired with DOES> ... call that
different word paired with DOES> what you will, <CREATE if you wish.

"CREATE ... DOES>" code from a system in which there is one such
defining word and DOES> works on the most recently created word does
not work on a system in which DOES> is paired with <BUILDS and CREATE
is not.

As was nearly hashed out recently, in some instances the
implementation technique that allowed the more compact CREATE to also
be paired with DOES> rendering the original implementation of <BUILDS
incompatible with DOES> is not always feasible, in which case to it is
necessary to use the original <BUILDS implementation technique. But it
remains the single defining word system, not the system with two
distinct defining words.

[toc] | [prev] | [next] | [standalone]

#11980

On May 5, 9:07 am, BruceMcF <agil...@netscape.net> wrote:
> On May 5, 10:25 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
> wrote:
>
> > <BUILDS existed, because it allowed CREATE to be different
> > and consume less space.
>
> And in that *system* "CREATE ... DOES>" did not work, because "DOES>"
> assumed a preceding "<BUILD".
>
> Having a single defining word that works as CREATE and also works as
> <BUILDS is a different system than having one defining word that works
> as CREATE and a different word that is paired with DOES> ... call that
> different word paired with DOES> what you will, <CREATE if you wish.
>
> "CREATE ... DOES>" code from a system in which there is one such
> defining word and DOES> works on the most recently created word does
> not work on a system in which DOES> is paired with <BUILDS and CREATE
> is not.
>
> As was nearly hashed out recently, in some instances the
> implementation technique that allowed the more compact CREATE to also
> be paired with DOES> rendering the original implementation of <BUILDS
> incompatible with DOES> is not always feasible, in which case to it is
> necessary to use the original <BUILDS implementation technique. But it
> remains the single defining word system, not the system with two
> distinct defining words.

You must have read my RfD, or at least, were the only one to
understand it.

My point is that in ANS-Forth, CREATE is overloaded --- CREATE by
itself and CREATE with a DOES> are two entirely different concepts.
The Forth-way is that each word should do only one thing. It makes
sense to have CREATE and <BUILDS as distinct words, because they are
distinct concepts --- it is a philosophical issue.

If <BUILDS is used, and it does not get fixed-up with a DOES> prior to
the next definition, then that is an error. If CREATE is used, and it
does get a DOES> after it, then that is also an error. In either case,
compilation aborts with an error message.

If you assume that headers are not mixed in with data (and this is
assumed in Straight Forth), then CREATE can be defined like this:
: CREATE  HERE CONSTANT ;
In most implementations, the value of the constant does not take up
memory on the target platform. There is no place that you can find it
in target memory. Constants just compile as literals wherever they are
referenced.

Defining <BUILDS is more complicated. I won't go into that here. I
will say however, that this is somewhat simplified by the fact that
you know ahead of time that there is going to be a DOES> --- you don't
have to allow for both possibilities, that there is a DOES>
(references will be a CALL to the DOES> code) or that there is no
DOES> (references will be a compilation of a literal).

Implementation is always simplified when each word does only one
thing. Remember the "universal processor" (word, data, food) in the
"Thinking Forth" book? We want to avoid that. Right now, CREATE is
used for both both simple variables that just return an address and
complex variables that execute the attached DOES> code. The situation
could be worse though! Imagine if CREATE were used instead of colon to
define functions, and the semi-colon had to fix-up the CREATE for this
case (similar to the way that DOES> fixes-up CREATE for its case).
That would be similar to what we already have with CREATE defining two
kinds of words, but worse, as CREATE would define three kinds of
words. That would be taking the current line of thinking to its
extreme!

[toc] | [prev] | [next] | [standalone]

#12006

Hugh Aguilar wrote:
> Implementation is always simplified when each word does only one
> thing. Remember the "universal processor" (word, data, food) in the
> "Thinking Forth" book? We want to avoid that.

To be honest, sometimes I even have to agree with you.  I want my words 
uniform - see the header discussion - so it is not complicated to change 
a CREATE to a <BUILDS word (replace the COMPILE,-action, fill in the 
DODOES field), but the concept indeed feels like the word/data/food 
processor.

The rationale to throw out <BUILDS was that an implementation technique 
existed where CREATE and <BUILDS do the same thing.  This would be the 
rationale to throw out COMPILE, - because there is an implementation 
technique where , does the same thing.  The reason why Forth-83 felt 
inclined to do so is that Forth-83 actually mandated an implementation 
technique.  That was its biggest mistake.

Forth-83 made a number of incompatible decisions, and though some 
decisions by themselves are good ideas (like -1 as TRUE or to have a 
one's complement called NOT), but they broke code.  Maybe the idea was 
that Forth programs are not maintainable (or intented to be maintained), 
anyways, and will be quickly rewritten to the then-current standard.  
Chuck Moore is even more radical with breaking code, when designing his 
next system.

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

[toc] | [prev] | [next] | [standalone]

#12016

On May 8, 4:25 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> The rationale to throw out <BUILDS was that an implementation technique
> existed where CREATE and <BUILDS do the same thing.  This would be the
> rationale to throw out COMPILE, - because there is an implementation
> technique where , does the same thing.  The reason why Forth-83 felt
> inclined to do so is that Forth-83 actually mandated an implementation
> technique.  That was its biggest mistake.

To a large extent, the purpose of a standard is to abstractify
implementation.

On the other hand, being wishy-washy isn't the same thing as
abstractification. For example, I've pointed out that the ANS-Forth
standard says that locals may or may not be held on the return stack.
This doesn't help! In a case like this, it really is necessary to
specify where the locals are, and to put them somewhere that makes
sense (not on the return stack!). When the standard is wishy-washy
like this, then the user has to assume the worst-case scenario (that
they are on the return stack) so that his code will work on any
standard-compliant system --- this is really no better than if the
standard specified the worst-case scenario --- he can't really use >R
R> R@ etc. in conjunction with locals, because this may not work on
some compliant compilers.

Abstractification is a good thing. For example, COMPILE, was a huge
step up from using comma, as this abstractified compilation and
allowed any kind of threading scheme to be used (including the
generation of machine code, which is what everybody wants to do with
the modern processors). Being wishy-washy is a bad thing. For example,
the standard should say that locals are on their own stack, as this
allows >R R> R@ etc. to be used in a function whether locals are being
used in that function or not.

Note that in Straight Forth I'm not going to support >R R> R@ etc. at
all (because they are ugly and error-prone), so it makes no difference
to me where the locals are.

Straight Forth will specify that the locals get destroyed when the
function exits. This means that they can be on the return stack (as
opposed to the heap), although they might have their own stack
(because some processors don't provided indexed addressing of the
return stack). This is abstractification --- so long as the locals
behave in the expected way, then they can be implemented in any way
that is convenient for the compiler-writer.

> Forth-83 made a number of incompatible decisions, and though some
> decisions by themselves are good ideas (like -1 as TRUE or to have a
> one's complement called NOT), but they broke code.  Maybe the idea was
> that Forth programs are not maintainable (or intented to be maintained),
> anyways, and will be quickly rewritten to the then-current standard.
> Chuck Moore is even more radical with breaking code, when designing his
> next system.

The point of Straight Forth is that it makes sense. Breaking legacy
code is not a problem for me.

Some companies seem to have a high turnover in programmers (usually
because the boss is a non-programmer). These companies are the ones
that primarily care about not breaking legacy code. They often have a
lot of code that was written by a programmer who has since been fired.
They have no idea how that code works, but they want it to continue
working (because they don't have confidence that any of their current
programmers are capable of rewriting the program from scratch) --- so
they become highly focused on the idea that no new compiler should
ever break legacy code. Companies like this deserve to go out of
business --- I don't care about them --- the name "Straight" means,
among other things, that whiners are not tolerated.

[toc] | [prev] | [next] | [standalone]

#12021

On May 8, 11:25 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Forth-83 made a number of incompatible decisions, and though some
> decisions by themselves are good ideas (like -1 as TRUE or to have a
> one's complement called NOT), but they broke code.

I don't really agree with this. Forth-83 is Forth-83, and Forth-79 is
Forth-79. Did all the Forth-79 code (and compilers) evaporate into
thin air when the Forth-83 standard was released? Of course not. Did
all the Forth-79 code suddenly cease to function? Of course not.

I just don't see the problem! With each new standard is the
opportunity to take the language in new directions, add new features,
and correct short-comings identified in the previous standard.
However, it doesn't have to be an incremental change. It's a new
standard!

We had ANS-94 and we're working towards 200x. Should we not simply
rename 200x as "ANS-94 Rev 1, 2012" - because *that's* what it really
is.

I think it would have been much more exciting, and more beneficial if
the 200x standard was a 'rip it up and start again' rather than an
update to the previous standard. A new standard doesn't invalidate a
previous standard. ANS-94 will still be there if people don't want to
move to the new standard. They run in parallel.

But, what I do know?! Enough ranting!

[toc] | [prev] | [next] | [standalone]

#12023

Mark Wills <markrobertwills@yahoo.co.uk> wrote:

> We had ANS-94 and we're working towards 200x. Should we not simply
> rename 200x as "ANS-94 Rev 1, 2012" - because *that's* what it
> really is.
> 
> I think it would have been much more exciting, and more beneficial
> if the 200x standard was a 'rip it up and start again' rather than
> an update to the previous standard.

It would certainly have been much more exciting.

There's a problem with this: languages designed by committees aren't
usually very good.  So, it makes more sense for someone with a vision
to design their new language, campaign for its adoption, and get that
standardized when it's stable enough.

Andrew.

[toc] | [prev] | [next] | [standalone]

#12039

On 5/9/12 12:18 AM, Mark Wills wrote:
> On May 8, 11:25 pm, Bernd Paysan<bernd.pay...@gmx.de>  wrote:
>> Forth-83 made a number of incompatible decisions, and though some
>> decisions by themselves are good ideas (like -1 as TRUE or to have a
>> one's complement called NOT), but they broke code.
>
> I don't really agree with this. Forth-83 is Forth-83, and Forth-79 is
> Forth-79. Did all the Forth-79 code (and compilers) evaporate into
> thin air when the Forth-83 standard was released? Of course not. Did
> all the Forth-79 code suddenly cease to function? Of course not.
>
> I just don't see the problem! With each new standard is the
> opportunity to take the language in new directions, add new features,
> and correct short-comings identified in the previous standard.
> However, it doesn't have to be an incremental change. It's a new
> standard!
>
> We had ANS-94 and we're working towards 200x. Should we not simply
> rename 200x as "ANS-94 Rev 1, 2012" - because *that's* what it really
> is.
>
> I think it would have been much more exciting, and more beneficial if
> the 200x standard was a 'rip it up and start again' rather than an
> update to the previous standard. A new standard doesn't invalidate a
> previous standard. ANS-94 will still be there if people don't want to
> move to the new standard. They run in parallel.
>
> But, what I do know?! Enough ranting!

With most standards bodies (ANSI, ISO, IEEE, etc.) the convention is 
that new standards *do* invalidate old ones, after a transition period. 
And the new standard seeks to minimize that transition period and 
minimize the cost of transitioning, by doing such things as respecting 
existing practice wherever practical. In the case of programming 
languages, including Forth, there are users maintaining programs with 
thousands of lines of code and thousands of systems in the field. They 
can (and will) be updated to some extent, but radical changes are out of 
the question.

It might be fun to 'rip it up and start again,' but the result should 
get a new name.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

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

[toc] | [prev] | [next] | [standalone]

#12047

In comp.lang.forth, Bernd Paysan wrote:

> [..] but they broke code.  Maybe the idea was 
> that Forth programs are not maintainable (or intented to be maintained), 
> anyways, and will be quickly rewritten to the then-current standard.  
> Chuck Moore is even more radical with breaking code, when designing his 
> next system.

There's nothing wrong with dropping "backward compatibility", if this is
reasonable. For example: keeping the x86-line of processors still backward
compatible made their instructions list more than 1000 positions long:

  http://www.agner.org/optimize/blog/read.php?i=25

It costs programming time. It costs efficiency. It costs energy.
Let's compare this to about 100 (or maybe less?) instructions of ARM...

Yes, Microsoft grew up exactly by assuring backward compatibility of their
software, but it was different situation "back in the day": when the computers
were expensive, of course everyone preferred to keep both the old and new
versions of software running on the same machine. Today the gear is so
cheap - and powerful at the same time - that it isn't a problem to keep old
machine for old programs (in fact, there could be a problem to sell such old
machine... nobody wants it), or - if anyone will see it as inconvenience - to
use software emulator, until new version of some software will be released.

My guess is, that it wasn't "Forth programs are not maintainable" approach -
but rather an expectation, that for that older programs the older version of
interpreters can be still used, and even the newer versions of such programs
can be still developed according to older standard (why not?), if someone is
afraid of messing the well-tested code. But quite new - "fresh" - programs
can use new standard.
-- 
Forth is a preserver of health (Hippocrates)

[toc] | [prev] | [next] | [standalone]

#12048

Zbiggy wrote:
> There's nothing wrong with dropping "backward compatibility", if this
> is reasonable.

This comment was clearly tongue-in-check ;-).

But I disagree that the x86 ISA is so long because of backward 
compatibility.  Intel had a chance to demonstrate how a new ISA, 
developed from scratch, would look like, and they came up with IA64.  
Intel instruction sets are so lengthy, because they are designed by 
committees.  x86 is actually good look for all of us, because the main 
ISA design team at that time designed i432, and only a few people were 
left to create the x86 ISA (two, IIRC).  Therefore, x86 is pretty clean 
and straight-forward, even considering the time it was designed (height 
of the CISC age), and that it came from Intel.  And the two modes added 
later (386 mode and amd64 mode) are cleanups, which make the ISA more 
orthogonal and useful.  Additions like MMX and 3DNow! are phased out and 
declared obsolesent (and AMD stopps to implement 3DNow!).  It's not that 
awful.  The worst things from Intel all died.

The ARM ISA is designed by one person, and even then it is one of the 
more byzantine RISC ISAs, with lots of things cobbled together in one 
instruction - shifts, conditional execution, normal operations.

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.forth

csiph-web