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

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

A short history of the stages of development and status of RP's Forth interpreter.

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

Contents

  A short history of the stages of development and status of RP's Forth interpreter. "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-03-22 19:16 -0400
    Re: A short history of the stages of development and status of RP's Forth interpreter. jacko <jackokring@gmail.com> - 2012-03-23 00:38 -0700
      Re: A short history of the stages of development and status of RP's Forth interpreter. jacko <jackokring@gmail.com> - 2012-03-23 00:56 -0700
    Re: A short history of the stages of development and status of RP's For  interpreter. Nomen Nescio <nobody@dizum.com> - 2012-03-23 12:53 +0100
      Re: A short history of the stages of development and status of RP's For  interpreter. "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-03-23 20:44 -0400
        Re: A short history of the stages of development and status of RP's For  interpreter. Nomen Nescio <nobody@dizum.com> - 2012-03-25 10:30 +0200
          Re: A short history of the stages of development and status of RP's For  interpreter. "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-03-25 06:05 -0400
            Re: A short history of the stages of development and status of RP's Nomen Nescio <nobody@dizum.com> - 2012-03-27 03:03 +0200
              Re: A short history of the stages of development and status of RP's "Elizabeth D. Rather" <erather@forth.com> - 2012-03-26 15:39 -1000
                Re: A short history of the stages of development and status of RP's Fritz Wuehler <fritz@spamexpire-201203.rodent.frell.theremailer.net> - 2012-03-28 11:18 +0200
                  Re: A short history of the stages of development and status of RP's "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-03-30 07:04 -0400
                    Re: A short history of the stages of development and status of RP's Fritz Wuehler <fritz@spamexpire-201203.rodent.frell.theremailer.net> - 2012-03-30 19:24 +0200
                      Re: A short history of the stages of development and status of RP's Paul Rubin <no.email@nospam.invalid> - 2012-03-30 13:00 -0700
                        Re: A short history of the stages of development and status of RP's Nomen Nescio <nobody@dizum.com> - 2012-04-04 16:09 +0200
                      Re: A short history of the stages of development and status of RP's "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-03-30 18:06 -0400
                        Re: A short history of the stages of development and status of RP's Fritz Wuehler <fritz@spamexpire-201204.rodent.frell.theremailer.net> - 2012-04-02 16:39 +0200
                          Re: A short history of the stages of development and status of RP's Paul Rubin <no.email@nospam.invalid> - 2012-04-02 15:37 -0700
                            Re: A short history of the stages of development and status of RP's BruceMcF <agila61@netscape.net> - 2012-04-02 16:59 -0700
                            Re: A short history of the stages of development and status of RP's kenney@cix.compulink.co.uk - 2012-04-03 17:15 -0500
                              Re: A short history of the stages of development and status of RP's "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-04 05:23 -0400
                                Re: A short history of the stages of development and status of RP's Nomen Nescio <nobody@dizum.com> - 2012-04-04 15:58 +0200
                                  Re: A short history of the stages of development and status of RP's "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-05 09:57 -0400
                                    Re: A short history of the stages of development and status of RP's Fritz Wuehler <fritz@spamexpire-201204.rodent.frell.theremailer.net> - 2012-04-11 21:23 +0200
                                      Re: A short history of the stages of development and status of RP's "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-11 19:13 -0400
                                        Re: A short history of the stages of development and status of RP's jacko <jackokring@gmail.com> - 2012-04-11 18:22 -0700
                                      Re: A short history of the stages of development and status of RP's hwfwguy@gmail.com - 2012-04-13 09:37 -0700
                            Re: A short history of the stages of development and status of RP's Fritz Wuehler <fritz@spamexpire-201204.rodent.frell.theremailer.net> - 2012-04-05 11:21 +0200
            Re: A short history of the stages of development and status of RP's Fritz Wuehler <fritz@spamexpire-201203.rodent.frell.theremailer.net> - 2012-03-27 13:08 +0200
        Re: A short history of the stages of development and status of RP's For  interpreter. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-03-26 08:58 +0000
    Re: A short history of the stages of development and status of RP's Forth interpreter. Fanzo <cristianof6@gmail.com> - 2012-03-25 15:32 +0200
    Re: A short history of the stages of development and status of RP's Forth interpreter. "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-03-30 18:05 -0400
      Re: A short history of the stages of development and status of RP's Forth interpreter. "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-02 05:08 -0400
        Re: A short history of the stages of development and status of RP's Forth interpreter. "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-10 11:07 -0400
          Re: A short history of the stages of development and status of RP's Forth interpreter. "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-11 19:00 -0400
            Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-11 19:24 -0700
              Re: A short history of the stages of development and status of RP's Forth interpreter. "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-12 14:03 -0400
                Re: A short history of the stages of development and status of RP's Forth interpreter. "Elizabeth D. Rather" <erather@forth.com> - 2012-04-12 08:19 -1000
                  Re: A short history of the stages of development and status of RP's Forth interpreter. "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-14 17:21 -0400
                    Re: A short history of the stages of development and status of RP's Forth interpreter. Coos Haak <chforth@hccnet.nl> - 2012-04-15 00:11 +0200
                    Re: A short history of the stages of development and status of RP's Forth interpreter. "Elizabeth D. Rather" <erather@forth.com> - 2012-04-14 13:48 -1000
                      Re: A short history of the stages of development and status of RP's Forth interpreter. "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-15 13:09 -0400
                        Re: A short history of the stages of development and status of RP's Forth interpreter. "Elizabeth D. Rather" <erather@forth.com> - 2012-04-15 08:06 -1000
                          Re: A short history of the stages of development and status of RP's Forth interpreter. Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-04-16 09:45 +0000
                            Re: A short history of the stages of development and status of RP's Forth interpreter. jacko <jackokring@gmail.com> - 2012-04-16 05:26 -0700
                        Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-15 11:10 -0700
                          Re: A short history of the stages of development and status of RP's Forth interpreter. "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-15 17:57 -0400
                            Re: A short history of the stages of development and status of RP's Forth interpreter. "Elizabeth D. Rather" <erather@forth.com> - 2012-04-15 12:22 -1000
                            Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-15 19:35 -0700
                              Re: A short history of the stages of development and status of RP's Forth interpreter. "Elizabeth D. Rather" <erather@forth.com> - 2012-04-15 16:58 -1000
                              Re: A short history of the stages of development and status of RP's Forth interpreter. "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-16 15:50 -0400
                                Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-16 13:24 -0700
                                Re: A short history of the stages of development and status of RP's Forth interpreter. "Elizabeth D. Rather" <erather@forth.com> - 2012-04-16 11:17 -1000
                    Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-14 17:07 -0700
                      Re: A short history of the stages of development and status of RP's Forth interpreter. Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-14 22:37 -0700
                        Re: A short history of the stages of development and status of RP's Forth interpreter. "Elizabeth D. Rather" <erather@forth.com> - 2012-04-14 20:54 -1000
                          Re: A short history of the stages of development and status of RP's Forth interpreter. Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-15 00:22 -0700
                        Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-15 07:00 -0700
                Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-12 12:45 -0700
                  Re: A short history of the stages of development and status of RP's Forth interpreter. Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-12 13:29 -0700
                    Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-12 13:56 -0700
                    Re: A short history of the stages of development and status of RP's Forth interpreter. "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-13 10:25 -0400
                      Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-13 08:12 -0700
                        Re: A short history of the stages of development and status of RP's Forth interpreter. "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-14 17:22 -0400
                          Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-14 16:10 -0700
                            Re: A short history of the stages of development and status of RP's Forth interpreter. "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-15 12:53 -0400
                              Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-15 11:01 -0700
                      Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-13 08:23 -0700
            Re: A short history of the stages of development and status of RP's Forth interpreter. "Elizabeth D. Rather" <erather@forth.com> - 2012-04-11 17:27 -1000
            Re: A short history of the stages of development and status of RP's Forth interpreter. Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-12 00:19 -0700
              Re: A short history of the stages of development and status of RP's Forth interpreter. "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-12 13:54 -0400
                Re: A short history of the stages of development and status of RP's Forth interpreter. Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-12 13:43 -0700
            Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-12 06:45 -0700
              Re: A short history of the stages of development and status of RP's  Forth interpreter. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-12 15:01 +0000
                Re: A short history of the stages of development and status of RP's  Forth interpreter. "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-12 13:54 -0400
                Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-12 10:49 -0700
                  Re: A short history of the stages of development and status of RP's Forth interpreter. "Elizabeth D. Rather" <erather@forth.com> - 2012-04-12 08:40 -1000
                    Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-12 12:38 -0700
                      Re: A short history of the stages of development and status of RP's Forth interpreter. "Elizabeth D. Rather" <erather@forth.com> - 2012-04-12 13:58 -1000
                  Re: A short history of the stages of development and status of RP's  Forth interpreter. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-13 10:42 +0000
                    Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-13 08:34 -0700
                      Re: A short history of the stages of development and status of RP's  Forth interpreter. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-13 15:48 +0000
                        Re: A short history of the stages of development and status of RP's  Forth interpreter. "Elizabeth D. Rather" <erather@forth.com> - 2012-04-13 08:25 -1000
                        Re: A short history of the stages of development and status of RP's  Forth interpreter. stephenXXX@mpeforth.com (Stephen Pelc) - 2012-04-13 22:08 +0000
                          Re: A short history of the stages of development and status of RP's  Forth interpreter. "Elizabeth D. Rather" <erather@forth.com> - 2012-04-13 12:26 -1000
                            Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-13 16:14 -0700
                              Re: A short history of the stages of development and status of RP's Forth interpreter. jacko <jackokring@gmail.com> - 2012-04-14 09:04 -0700
                                Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-14 15:59 -0700
                                  Re: A short history of the stages of development and status of RP's Forth interpreter. Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-04-15 10:50 +0000
                                    Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-15 07:06 -0700
                            XT only or XT+NT (was: A short history ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-14 14:06 +0000
                              Re: XT only or XT+NT (was: A short history ...) Alex McDonald <blog@rivadpm.com> - 2012-04-16 02:39 -0700
                    Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-13 08:46 -0700
              Re: A short history of the stages of development and status of RP's Forth interpreter. "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-12 13:53 -0400
            Re: A short history of the stages of development and status of RP's Forth interpreter. "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-19 17:06 -0400

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#11324

"Elizabeth D. Rather" <erather@forth.com> wrote in message
news:VZydnbeCxIolkRfSnZ2dnUVZ_rGdnZ2d@supernews.com...
> On 4/14/12 11:21 AM, Rod Pemberton wrote:
> > "Elizabeth D. Rather"<erather@forth.com>  wrote in message
> > news:NOqdnX8yHNVSgRrSnZ2dnUVZ_smdnZ2d@supernews.com...
...

> > FYI, this definition for SET won't work in a colon definition.  ANS' TO
> > which is used for VALUEs apparently does work in colon definitions, but
> > CONSTANT and VARIABLE don't.
>
> Of course not. This SET is a defining word, like CONSTANT and VARIABLE.
> Defining words are not used in definitions, they *are* definitions
> themselves ( : is one of many defining words).
>

Many other Forth words work for both interactively and in definitions.  So,
could they (CONSTANT, VARIABLE, etc.) be rewritten to do so?  From
what I've seen of other definitions, I think they could be.  I'd also think
that CONSTANTs inside definitions would be useful.

> Frankly, I don't understand the description of SET that you posted:
>
> SET        16b addr
>      A defining word executed in the form:
>             16b addr SET <name>
>      Defines a word <name> which, when executed, will cause the
>      value 16b to be stored at addr.
>
> If the point of SET is to define a word associated with an address that
> will store a given value in the address, why does the defining word take
> two arguments?

Bruce McFarland also thinks similarly.  Two fixed arguments is clearly least
useful (address and value both fixed).  One fixed argument is arguably more
useful (address fixed, takes value from stack).  Zero arguments is even more
useful (takes both from stack).  It's named ! (store).  However, as I
understand the syntax, the point is to define a word associated with both an
address and a value that will store the value at the address.  I.e., two
arguments, both fixed at the time SET is used.  (See Mark Wills post.)

Unless there is something I missed in the syntax or the definition to
indicate which arguments are fixed and which aren't, then my understanding
is valid even if it's not ...  Interpretation is a common problem with
abstracting syntax from implementation.  Everyone knows how something works
when the specification was written, but someone comes along later and says
or thinks: "That's not specified."  And, of course, it wasn't, and so they
did it differently ...  and maybe break code too ...

> > PS.  How does one text mark changes, like me inserting SET above when
> > [ ] are used for paraphrasing are also used in Forth notation?
>
> Sorry, don't understand the question.

If I insert text into another person's words to clarify them, English uses
brackets [ "inserted text" ] to mark those changes.  Forth also uses
brackets [ ] to indicate compiler mode changes and compiler words.  So, if I
inserted "I" into your last sentence:

> Sorry, [I] don't understand the question.

Does "[I]" mean "I" as in you or is it a Forth compile word [I] (bracket-I)?
This one is determinable from context.  [SET] didn't seem to be.

HTH,


Rod Pemberton

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

#11326

On 4/15/12 7:09 AM, Rod Pemberton wrote:
> "Elizabeth D. Rather"<erather@forth.com>  wrote in message
> news:VZydnbeCxIolkRfSnZ2dnUVZ_rGdnZ2d@supernews.com...
>> On 4/14/12 11:21 AM, Rod Pemberton wrote:
>>> "Elizabeth D. Rather"<erather@forth.com>   wrote in message
>>> news:NOqdnX8yHNVSgRrSnZ2dnUVZ_smdnZ2d@supernews.com...
> ...
>
>>> FYI, this definition for SET won't work in a colon definition.  ANS' TO
>>> which is used for VALUEs apparently does work in colon definitions, but
>>> CONSTANT and VARIABLE don't.
>>
>> Of course not. This SET is a defining word, like CONSTANT and VARIABLE.
>> Defining words are not used in definitions, they *are* definitions
>> themselves ( : is one of many defining words).
>>
>
> Many other Forth words work for both interactively and in definitions.  So,
> could they (CONSTANT, VARIABLE, etc.) be rewritten to do so?  From
> what I've seen of other definitions, I think they could be.  I'd also think
> that CONSTANTs inside definitions would be useful.

You're pining for locals, which is normal for folks coming to Forth from 
other languages. Yes, there are some Forth words (particularly in 
figForth) that have been defined as "state smart" with one behavior in 
compile mode and another in interpret mode, but that practice diminished 
in the late 80's, as it was found to be confusing and impractical.

Forth defining words all make standalone definitions. That's the way 
they work.

>> Frankly, I don't understand the description of SET that you posted:
>>
>> SET        16b addr
>>       A defining word executed in the form:
>>              16b addr SET<name>
>>       Defines a word<name>  which, when executed, will cause the
>>       value 16b to be stored at addr.
>>
>> If the point of SET is to define a word associated with an address that
>> will store a given value in the address, why does the defining word take
>> two arguments?
>
> Bruce McFarland also thinks similarly.  Two fixed arguments is clearly least
> useful (address and value both fixed).  One fixed argument is arguably more
> useful (address fixed, takes value from stack).  Zero arguments is even more
> useful (takes both from stack).  It's named ! (store).  However, as I
> understand the syntax, the point is to define a word associated with both an
> address and a value that will store the value at the address.  I.e., two
> arguments, both fixed at the time SET is used.  (See Mark Wills post.)

I think it's likely the definition was just garbled, and because nobody 
was really interested in this word no one caught the problem.

...

>>> PS.  How does one text mark changes, like me inserting SET above when
>>> [ ] are used for paraphrasing are also used in Forth notation?
>>
>> Sorry, don't understand the question.
>
> If I insert text into another person's words to clarify them, English uses
> brackets [ "inserted text" ] to mark those changes.  Forth also uses
> brackets [ ] to indicate compiler mode changes and compiler words.  So, if I
> inserted "I" into your last sentence:
>
>> Sorry, [I] don't understand the question.
>
> Does "[I]" mean "I" as in you or is it a Forth compile word [I] (bracket-I)?
> This one is determinable from context.  [SET] didn't seem to be.

Parens work pretty well. But in the case of SET (and other Forth words) 
using capitals is usually adequate.

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]

#11347

In article <5cydnfw6483ZkxbSnZ2dnUVZ_rGdnZ2d@supernews.com>,
Elizabeth D. Rather <erather@forth.com> wrote:
>On 4/15/12 7:09 AM, Rod Pemberton wrote:
>> "Elizabeth D. Rather"<erather@forth.com>  wrote in message
>> news:VZydnbeCxIolkRfSnZ2dnUVZ_rGdnZ2d@supernews.com...
>>> On 4/14/12 11:21 AM, Rod Pemberton wrote:
>>>> "Elizabeth D. Rather"<erather@forth.com>   wrote in message
>>>> news:NOqdnX8yHNVSgRrSnZ2dnUVZ_smdnZ2d@supernews.com...
>> ...
>>
>>>> FYI, this definition for SET won't work in a colon definition.  ANS' TO
>>>> which is used for VALUEs apparently does work in colon definitions, but
>>>> CONSTANT and VARIABLE don't.
>>>
>>> Of course not. This SET is a defining word, like CONSTANT and VARIABLE.
>>> Defining words are not used in definitions, they *are* definitions
>>> themselves ( : is one of many defining words).
>>>
>>
>> Many other Forth words work for both interactively and in definitions.  So,
>> could they (CONSTANT, VARIABLE, etc.) be rewritten to do so?  From
>> what I've seen of other definitions, I think they could be.  I'd also think
>> that CONSTANTs inside definitions would be useful.
>
>You're pining for locals, which is normal for folks coming to Forth from
>other languages. Yes, there are some Forth words (particularly in
>figForth) that have been defined as "state smart" with one behavior in
>compile mode and another in interpret mode, but that practice diminished
>in the late 80's, as it was found to be confusing and impractical.
>
>Forth defining words all make standalone definitions. That's the way
>they work.

If we ever were to extend Forth to accept nested definitions,
then we should go all the way, like ALGOL.
So within a colon definition we should have VARIABLE CONSTANTS
and other colon definition. Not LOCALS with a totally different
syntax compared to VARIABLE's.

<SNIP>

>Cheers,
>Elizabeth

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

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

#11349

With a linked list based language such as ScriptLanguage, there is no need to have the issue of nesting definitions. But I chose not to allow them, as it is then possible to not need immediate words at all.

"2*" make [ 2 times ]

0 "var" create

"locals-here" stack

And locals-here behaves as a push/pop variable with TO prefix for push.

Cheers Jacko 

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

#11327

On Apr 15, 1:09 pm, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
wrote:
> Many other Forth words work for both interactively and in definitions.  So,
> could they (CONSTANT, VARIABLE, etc.) be rewritten to do so?

In the most common type of Forth with mingle dictionary, data and code
space, no, of course not. CONSTANT VARIABLE and alike *create a
dictionary entry*. The colon definition is not set up to have a
dictionary entry just embedded in it at any random spot.

And more to the point, there's not all that much *benefit* to it. The
point of the words (SET included, whatever its semantics) is to create
a word to be used later. *That created word* can be used either
directly on the command line or by compiling it into a definition.
> From
> what I've seen of other definitions, I think they could be.  I'd also think
> that CONSTANTs inside definitions would be useful.

*Using* the thing *defined by* CONSTANT is useful. *Compiling*
CONSTANT into a word to execute when the word executes, that is
useful. But *executing* CONSTANT in the middle of defining a word ...
what is the extra benefit of being able to do that? Just create that
constant before the colon definition starts.

> If I insert text into another person's words to clarify them, English uses
> brackets [ "inserted text" ] to mark those changes.  Forth also uses
> brackets [ ] to indicate compiler mode changes and compiler words.  So, if
> I inserted "I" into your last sentence:

> > Sorry, [I] don't understand the question.

> Does "[I]" mean "I" as in you or is it a Forth compile word [I]
> bracket-I)? This one is determinable from context.  [SET] didn't seem
> to be.

Use a space delimited token and note what it means "inserts indicated
by [{] ... [}]"

In code, you can:

: [{] ; IMMEDIATE \ used to mark the start of an addition
: [}] ; IMMEDIATE \ used to mark the end of an addition

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

#11334

"BruceMcF" <agila61@netscape.net> wrote in message
news:9469577e-eca5-4990-b310-4748e97d3979@v1g2000yqm.googlegroups.com...
> On Apr 15, 1:09 pm, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
> wrote:
...

> > Many other Forth words work for both interactively and in definitions.
> > So, could they (CONSTANT, VARIABLE, etc.) be rewritten to do so?
>
> In the most common type of Forth with mingle dictionary, data and code
> space, no, of course not.

Why not?

> CONSTANT VARIABLE and alike *create a dictionary entry*.
>

Yes, they do, but they aren't IMMEDIATE.  So, there is no corruption of the
current word being compiled if used inside a definition, if that's what you
meant.

If extended to do word for both modes and compiled into a definition, they
would both CREATE at run-time, yes?  Something like so ...

: T VARIABLE X ;
X <not found>
T
X .  <xxxxxxxx>

: V 5 CONSTANT Y ;
Y <not found>
V
Y .  <nnnnnnnn>

> > I'd also think that CONSTANTs inside definitions would be useful.
>
> *Using* the thing *defined by* CONSTANT is useful.

Yes.

> *Compiling* CONSTANT into a word to execute when the word
> executes, that is useful. But *executing* CONSTANT in the middle
> of defining a word ... what is the extra benefit of being able to do that?

Um ...

Was CONSTANT supposed to be an IMMEDIATE?  That makes sense if
CONSTANT is IMMEDIATE.  Mine is not IMMEDIATE.  I must've
misunderstood you.  Example?


Rod Pemberton

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

#11336

On 4/15/12 11:57 AM, Rod Pemberton wrote:
> "BruceMcF"<agila61@netscape.net>  wrote in message
> news:9469577e-eca5-4990-b310-4748e97d3979@v1g2000yqm.googlegroups.com...
>> On Apr 15, 1:09 pm, "Rod Pemberton"<do_not_h...@notemailnot.cmm>
>> wrote:
> ...
>
>>> Many other Forth words work for both interactively and in definitions.
>>> So, could they (CONSTANT, VARIABLE, etc.) be rewritten to do so?
>>
>> In the most common type of Forth with mingle dictionary, data and code
>> space, no, of course not.

It's equally true with segregated code & data space.

> Why not?
>
>> CONSTANT VARIABLE and alike *create a dictionary entry*.
>>
>
> Yes, they do, but they aren't IMMEDIATE.  So, there is no corruption of the
> current word being compiled if used inside a definition, if that's what you
> meant.
>
> If extended to do word for both modes and compiled into a definition, they
> would both CREATE at run-time, yes?  Something like so ...
>
> : T VARIABLE X ;
> X<not found>
> T
> X .<xxxxxxxx>
>
> : V 5 CONSTANT Y ;
> Y<not found>
> V
> Y .<nnnnnnnn>

The problem is that defining words parse the input stream for the name 
when they are *executed*.  In your above examples, the error of not 
finding X or Y will prevent the definition of T or V from being 
successfully compiled.

A word like:

: Z  VARIABLE ;

...will execute VARIABLE when you execute Z, so you could say:

Z X

...and define X. Z is now a synonym for VARIABLE. But there's no way you 
can force VARIABLE to parse the input stream when it's just compiled and 
not executed, and when it's executed it will parse the input stream 
*then* not at the previous time when the word was defined.

>>> I'd also think that CONSTANTs inside definitions would be useful.
>>
>> *Using* the thing *defined by* CONSTANT is useful.
>
> Yes.
>
>> *Compiling* CONSTANT into a word to execute when the word
>> executes, that is useful. But *executing* CONSTANT in the middle
>> of defining a word ... what is the extra benefit of being able to do that?
>
> Um ...
>
> Was CONSTANT supposed to be an IMMEDIATE?  That makes sense if
> CONSTANT is IMMEDIATE.  Mine is not IMMEDIATE.  I must've
> misunderstood you.  Example?

No. Defining words are never IMMEDIATE.

Example:

: .CONSTANT ( x -- )   DUP CONSTANT . ;

100 .CONSTANT XY 100 ok
XY . 100 ok

Note that CONSTANT doesn't parse the input stream for a name till it's 
executed.

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]

#11342

On Apr 15, 5:57 pm, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
wrote:
> Was CONSTANT supposed to be an IMMEDIATE?  That makes sense if
> CONSTANT is IMMEDIATE.  Mine is not IMMEDIATE.  I must've
> misunderstood you.  Example?

Yours has to be immediate to be used the way you said you're trying to
use it:
   : T VARIABLE X ;

*that* is clearly trying to perform the *action* of VARIABLE at
compile time, because parsing X and creating a variable with that name
is the *action* of VARIABLE.

If you want to execute VARIABLE when "T" executes, as any normal Forth
would do, then "X" wouldn't follow VARIABLE it would follow T:

: T VARIABLE ;
T X
3 X !
X @ .

... works and prints "3" in gforth, and would do on any Forth I've
ever used.

Of course, that's just a different name for Variable, so let it do
something in addition to VARIABLE ... lets count how many times T was
used to create a variable.

VARIABLE TCOUNT
0 TCOUNT !

: T VARIABLE 1 TCOUNT +! ;
T X
3 X !
X @ .
TCOUNT @ .

... should print 3 for the content of X and 1 for the content of
tcount.

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

#11344

On 4/15/12 4:35 PM, BruceMcF wrote:
> On Apr 15, 5:57 pm, "Rod Pemberton"<do_not_h...@notemailnot.cmm>
> wrote:
>> Was CONSTANT supposed to be an IMMEDIATE?  That makes sense if
>> CONSTANT is IMMEDIATE.  Mine is not IMMEDIATE.  I must've
>> misunderstood you.  Example?
>
> Yours has to be immediate to be used the way you said you're trying to
> use it:
>     : T VARIABLE X ;
>
> *that* is clearly trying to perform the *action* of VARIABLE at
> compile time, because parsing X and creating a variable with that name
> is the *action* of VARIABLE.

Correct. And consider what the consequences of doing that might be on 
your nice ITC dictionary:

| head of T | docol | head of X | dovar | value of X | exit |

To make that work at all, you'd have to have the IMMEDIATE version of 
VARIABLE "know" if it's compiling, and compile some kind of branch over 
X. Everything would get excessively messy, and all for no conceivable 
benefit. It's even worse with compile-to-code implementations.

Trust us, all defining words must be non-immediate and make individual 
standalone definitions of whatever kind!

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]

#11357

"BruceMcF" <agila61@netscape.net> wrote in message
news:d78854f9-3944-4924-8b4c-9412d6c578e2@w7g2000vbg.googlegroups.com...
> On Apr 15, 5:57 pm, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
> wrote:
...

> > Was CONSTANT supposed to be an IMMEDIATE? That makes sense if
> > CONSTANT is IMMEDIATE. Mine is not IMMEDIATE. I must've
> > misunderstood you. Example?
>
> Yours has to be immediate to be used the way you said you're trying to
> use it:
>    : T VARIABLE X ;

No, I was not *trying* to do anything.  I was *asking* if VARIABLE
(or CONSTANT) could be extended to use VARIABLE in colon-definitions
just like it is used interactively.  As I envisioned it, VARIABLE would
still be non-IMMEDIATE, i.e, at run-time of T then variable X gets created,
but not before then.  There are quite a few words that are STATE aware.
There are also quite a few which parse words themselves, but they are
IMMEDIATEs, although immediacy doesn't usually seem to affect words that are
used interactively.  So, yes, on the one hand, figuring out how to parse or
skip over parsing of X as the name for VARIABLE is an issue for
non-IMMEDIATE.  On the other hand, VARIABLE is not currently useable in
colon definitions, so extending it could be done by making it IMMEDIATE,
using STATE with a conditional to select appropriate logic, i.e., do
nothing, or parse name and store it for when it creates it.

>    : T VARIABLE X ;
> *that* is clearly trying to perform the *action* of VARIABLE at
> compile time, because parsing X and creating a variable with that name
> is the *action* of VARIABLE.

As VARIABLE is *currently* implemented, *clearly*, yes.


Rod Pemberton

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

#11358

On Apr 16, 3:50 pm, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
wrote:

> No, I was not *trying* to do anything.  I was *asking* if VARIABLE
> (or CONSTANT) could be extended to use VARIABLE in colon-definitions
> just like it is used interactively.

Make it immediate, and it will *look* the same both in colon
definitions and in the interpreter ... because it needs the token in
the input stream when it *acts*.

And if it is not immediate, then in the compiler, it does not act
until the word it is compiled into is executed.

Except if it is immediate, you are creating a dictionary entry in the
middle of the word, unless you happen to have a model where dictionary
entries are separated ~ and you are creating your data space in the
middle of the word, unless you happen to have a model where code space
and data space are separated.

And there's no benefit to making it immediate, since you can also
create the variable immediate before starting the word definition.

If you want to do "VARIABLE X" when T executes, you would do:

: T S" VARIABLE X" EVALUATE ;

... but then each time T executes, its a new variable X blocking
access to the old variable X in the dictionary, so you'd be sure
that's the effect you want when doing that.

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

#11359

On 4/16/12 9:50 AM, Rod Pemberton wrote:
> "BruceMcF"<agila61@netscape.net>  wrote in message
> news:d78854f9-3944-4924-8b4c-9412d6c578e2@w7g2000vbg.googlegroups.com...
>> On Apr 15, 5:57 pm, "Rod Pemberton"<do_not_h...@notemailnot.cmm>
>> wrote:
> ...
>
>>> Was CONSTANT supposed to be an IMMEDIATE? That makes sense if
>>> CONSTANT is IMMEDIATE. Mine is not IMMEDIATE. I must've
>>> misunderstood you. Example?
>>
>> Yours has to be immediate to be used the way you said you're trying to
>> use it:
>>     : T VARIABLE X ;
>
> No, I was not *trying* to do anything.  I was *asking* if VARIABLE
> (or CONSTANT) could be extended to use VARIABLE in colon-definitions
> just like it is used interactively.

The answer is "no".

> As I envisioned it, VARIABLE would
> still be non-IMMEDIATE, i.e, at run-time of T then variable X gets created,
> but not before then.  There are quite a few words that are STATE aware.
> There are also quite a few which parse words themselves, but they are
> IMMEDIATEs, although immediacy doesn't usually seem to affect words that are
> used interactively.

But none of them are defining words. Defining words are special, in that 
they construct dictionary entries. The defining word that is commonly 
found in definitions, CREATE, does execute when the word containing it 
(which is itself a defining word, by virtue of containing CREATE) is 
executed, and parses the input stream at that time.

> So, yes, on the one hand, figuring out how to parse or
> skip over parsing of X as the name for VARIABLE is an issue for
> non-IMMEDIATE.  On the other hand, VARIABLE is not currently useable in
> colon definitions, so extending it could be done by making it IMMEDIATE,
> using STATE with a conditional to select appropriate logic, i.e., do
> nothing, or parse name and store it for when it creates it.
>
>>     : T VARIABLE X ;
>> *that* is clearly trying to perform the *action* of VARIABLE at
>> compile time, because parsing X and creating a variable with that name
>> is the *action* of VARIABLE.
>
> As VARIABLE is *currently* implemented, *clearly*, yes.

Yes. And I don't see any alternative implementations that don't create 
more problems. Nor do I understand why this is something you'd want to do.

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]

#11301

On Apr 14, 5:21 pm, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
wrote:

>   : SET CREATE SWAP , , DOES> DUP @ SWAP CELL+ @ ! ;

Why the swap? If you want to place a predefined cell value at a pre-
defined cell-address, why not:

: SET ( x addr "name" -- ) \ "name" ( -- )
   CREATE , , DOES> 2@ ! ;

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

#11307

On Apr 15, 1:07 am, BruceMcF <agil...@netscape.net> wrote:
> On Apr 14, 5:21 pm, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
> wrote:
>
> >   : SET CREATE SWAP , , DOES> DUP @ SWAP CELL+ @ ! ;
>
> Why the swap? If you want to place a predefined cell value at a pre-
> defined cell-address, why not:
>
> : SET ( x addr "name" -- ) \ "name" ( -- )
>    CREATE , , DOES> 2@ ! ;

He he!

And Lo, did the wise Bruce speak unto his flock. And the people did
see that he was wise.

And it was so.

:-)

It's a bigger, eh Rod? Just when you think you've written some cool
cool someone comes along and shows you how it should be done! This had
happened to me a lot in the Forth world!

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

#11308

On 4/14/12 7:37 PM, Mark Wills wrote:
> On Apr 15, 1:07 am, BruceMcF<agil...@netscape.net>  wrote:
>> On Apr 14, 5:21 pm, "Rod Pemberton"<do_not_h...@notemailnot.cmm>
>> wrote:
>>
>>>    : SET CREATE SWAP , , DOES>  DUP @ SWAP CELL+ @ ! ;
>>
>> Why the swap? If you want to place a predefined cell value at a pre-
>> defined cell-address, why not:
>>
>> : SET ( x addr "name" -- ) \ "name" ( -- )
>>     CREATE , , DOES>  2@ ! ;
>
> He he!
>
> And Lo, did the wise Bruce speak unto his flock. And the people did
> see that he was wise.
>
> And it was so.
>
> :-)
>
> It's a bigger, eh Rod? Just when you think you've written some cool
> cool someone comes along and shows you how it should be done! This had
> happened to me a lot in the Forth world!

Yes, that's perfect assuming you don't want to specify at run-time what 
the value is you want to store in the address.  As I said in my previous 
post, including both the value *and* the address in the definition seems 
less useful to me.

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]

#11309

On Apr 15, 7:54 am, "Elizabeth D. Rather" <erat...@forth.com> wrote:
> On 4/14/12 7:37 PM, Mark Wills wrote:
>
>
>
>
>
>
>
>
>
> > On Apr 15, 1:07 am, BruceMcF<agil...@netscape.net>  wrote:
> >> On Apr 14, 5:21 pm, "Rod Pemberton"<do_not_h...@notemailnot.cmm>
> >> wrote:
>
> >>>    : SET CREATE SWAP , , DOES>  DUP @ SWAP CELL+ @ ! ;
>
> >> Why the swap? If you want to place a predefined cell value at a pre-
> >> defined cell-address, why not:
>
> >> : SET ( x addr "name" -- ) \ "name" ( -- )
> >>     CREATE , , DOES>  2@ ! ;
>
> > He he!
>
> > And Lo, did the wise Bruce speak unto his flock. And the people did
> > see that he was wise.
>
> > And it was so.
>
> > :-)
>
> > It's a bigger, eh Rod? Just when you think you've written some cool
> > cool someone comes along and shows you how it should be done! This had
> > happened to me a lot in the Forth world!
>
> Yes, that's perfect assuming you don't want to specify at run-time what
> the value is you want to store in the address.  As I said in my previous
> post, including both the value *and* the address in the definition seems
> less useful to me.
>
> 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 90045http://www.forth.com
>
> "Forth-based products and Services for real-time
> applications since 1973."
> ==================================================

Agreed. And I have to say, it seems like code snobbery to me! It's
just a fancy "ooh look at me" way of saying something like:

: ToPump ( n -- ) $FFE0 C! ;

or something.

The above would surely be more intuitive/descriptive to the poor guy
having to debug/extend/modify your production code 10 years later!

(Apologies for typo's in previous post - bloody Android phones are a
menace)

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

#11314

On Apr 15, 1:37 am, Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
> And Lo, did the wise Bruce speak unto his flock. And the people did
> see that he was wise.

Isn't sophomore Latin for "a wise fool"? It might be the way to do it,
but I agree with Ms. Rather that I don't see any reason for doing
that.

I can see a word for using a value on a stack to set a specific port.
I can see a word for setting an address on a stack to a specific
value.

In either case, to be useful, you have a lot of things of that kind to
do, and the straightforward:

: PADDLE1-ON ( -- ) TRUE PADDLE1-DIRECTION C! ;

... runs into the factors vs products principle ~ 8 possible settings
of 8 possible ports is 64 distinct "set this port to this" words, but
only 16 words in either a "set this port", or "use this setting"
approach.

But I'd think either it was a game of Whispers, were someone misread a
description of a word, or it was a very implementation-specific thing,
such as having to flip settings of a port in an inner loop with an
implementation with a slow VM, so SET involved a primitive (SET) that
performed it faster. For instance, in a 6502 indirect threaded
implementation (very slow because of the 6502's very slow 16-bit
dereferencing), W pointing directly to the CFA of the defined SET word
which points to, followed by (target-4) followed by the value:

DOSET:
        LDY #0
        LDA (W),Y
        STA W+2
        INY
        LDA (W),Y
        STA W+3
        INY
        LDA (W),Y
        STA (W+2),Y
        INY
        LDA (W),Y
        STA (W+2),Y
        JMP NEXT

... the tr3s k3wl trick being the (address-4bytes) bit, and the SET
applying that trick at definition time. But the case-specific benefit
of that is a long, long way from being something to include as a
standard part of the language.

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

#11217

On Apr 12, 2:03 pm, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
wrote:

> > There is no SET in either the Forth79 or Forth83 required
> > word sets.  What is the behavior supposed to be?

> Forth-79 - part of "Reference Word Set"

> "
> SET         n addr  --
>     A defining word used in the form:
>          n  addr  SET  <name>
>     Defines a word <name> which, when executed, will cause the
>     value  n  to be stored at address.
> "

Aha. So you can have:

: SET ( x "name" -- ) \ "name" ( addr -- ) store x at addr
   CREATE , DOES> @ SWAP ! ;

And then instead of:

: ON ( addr -- ) TRUE SWAP ! ;
   \ G* store TRUE at address

: OFF ( addr -- ) 0 SWAP ! ;
   \ G* store 0 at address

... you can do:

TRUE SET ON
   \ G* store TRUE at address
0 SET OFF
   \ G* store 0 at address

Doesn't strike me as something I'd feel any pressing need to include
in an implementation.

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

#11218

> SET         n addr  --
>     A defining word used in the form:
>          n  addr  SET  <name>
>     Defines a word <name> which, when executed, will cause the
>     value  n  to be stored at address.
> "

Oh my goodness! That's just gratuitous code-snobbery!

So:

100 $A000 SET FRED

Creates a word called FRED that writes 100 to 0xB000

What, you mean like:

: FRED 100 $B000 ! ;

LOL!

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

#11221

On Apr 12, 4:29 pm, Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
> > SET         n addr  --
> >     A defining word used in the form:
> >          n  addr  SET  <name>
> >     Defines a word <name> which, when executed, will cause the
> >     value  n  to be stored at address.
> > "
>
> Oh my goodness! That's just gratuitous code-snobbery!
>
> So:
>
> 100 $A000 SET FRED
>
> Creates a word called FRED that writes 100 to 0xB000

No, 1000 SET 100% creates a word called FRED that writes 1000 to
whatever address you give it.

So you have an integer that is zoom in hundredths.

250 SET 2.5x
200 SET 2x
150 SET 1.5x
100 SET 1x
75 SET 0.75x
50 SET 0.50x
25 SET 0.25x
...

variable vertical
variable horizontal

vertical 1.5x
horizontal 2x

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

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

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

csiph-web