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

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

TclForth Notes: Always Compiling, Forth without STATE

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

Contents

  TclForth Notes: Always Compiling, Forth without STATE Wolf Wejgaard <wolf@holonforth.com> - 2014-10-08 11:40 +0200
    Re: TclForth Notes: Always Compiling, Forth without STATE albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-08 11:53 +0000
    Re: TclForth Notes: Always Compiling, Forth without STATE Wolf Wejgaard <wolf@holonforth.com> - 2014-10-08 17:41 +0200
      Re: TclForth Notes: Always Compiling, Forth without STATE Joachim Merkel <jm@7fun.de> - 2014-11-30 22:20 +0100
        Re: TclForth Notes: Always Compiling, Forth without STATE Wolf Wejgaard <wolf@holonforth.com> - 2014-12-04 16:54 +0100
          Re: TclForth Notes: Always Compiling, Forth without STATE m.a.m.hendrix@tue.nl - 2014-12-05 00:05 -0800
            Re: TclForth Notes: Always Compiling, Forth without STATE "Elizabeth D. Rather" <erather@forth.com> - 2014-12-04 22:47 -1000
              Re: TclForth Notes: Always Compiling, Forth without STATE Bernd Paysan <bernd.paysan@gmx.de> - 2014-12-05 19:04 +0100
                Re: TclForth Notes: Always Compiling, Forth without STATE Wolf Wejgaard <wejgaard@gmail.com> - 2015-01-21 02:23 -0800
            Re: TclForth Notes: Always Compiling, Forth without STATE Wolf Wejgaard <wolf@holonforth.com> - 2014-12-06 08:53 +0100
              Re: TclForth Notes: Always Compiling, Forth without STATE mhx@iae.nl - 2014-12-06 00:21 -0800
          Re: TclForth Notes: Always Compiling, Forth without STATE Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-12-05 03:16 -0600
            Re: TclForth Notes: Always Compiling, Forth without STATE Wolf Wejgaard <wolf@holonforth.com> - 2014-12-06 09:31 +0100
              Re: TclForth Notes: Always Compiling, Forth without STATE Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-12-06 04:16 -0600
              Re: TclForth Notes: Always Compiling, Forth without STATE albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-12-06 10:40 +0000
              Re: TclForth Notes: Always Compiling, Forth without STATE anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-06 12:42 +0000
                Re: TclForth Notes: Always Compiling, Forth without STATE Wolf Wejgaard <wejgaard@gmail.com> - 2015-01-21 02:26 -0800
              Re: TclForth Notes: Always Compiling, Forth without STATE Joachim Merkel <jm412@gmx.de> - 2014-12-06 18:11 +0100
                Re: TclForth Notes: Always Compiling, Forth without STATE Joachim Merkel <jm@g7up.de> - 2014-12-06 18:25 +0100
                Re: TclForth Notes: Always Compiling, Forth without STATE Joachim Merkel <jm@7up.de> - 2014-12-06 18:42 +0100
              Re: TclForth Notes: Always Compiling, Forth without STATE mix <mix@test.net> - 2014-12-15 18:55 +0000
                Re: TclForth Notes: Always Compiling, Forth without STATE Coos Haak <chforth@hccnet.nl> - 2014-12-16 01:27 +0100
                  Re: TclForth Notes: Always Compiling, Forth without STATE Coos Haak <chforth@hccnet.nl> - 2014-12-16 01:50 +0100
                  Re: TclForth Notes: Always Compiling, Forth without STATE mix <mix@test.net> - 2014-12-16 05:04 +0000
                    Re: TclForth Notes: Always Compiling, Forth without STATE Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-12-16 04:08 -0600
                      Re: TclForth Notes: Always Compiling, Forth without STATE mix <mix@test.net> - 2014-12-16 23:32 +0000
                        Re: TclForth Notes: Always Compiling, Forth without STATE "Elizabeth D. Rather" <erather@forth.com> - 2014-12-16 14:45 -1000
                          Re: TclForth Notes: Always Compiling, Forth without STATE mix <mix@test.net> - 2014-12-17 06:01 +0000
                            Re: TclForth Notes: Always Compiling, Forth without STATE "Elizabeth D. Rather" <erather@forth.com> - 2014-12-16 22:21 -1000
                            Re: TclForth Notes: Always Compiling, Forth without STATE Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-12-17 02:24 -0600
                              Re: TclForth Notes: Always Compiling, Forth without STATE "Elizabeth D. Rather" <erather@forth.com> - 2014-12-16 23:07 -1000
                                Re: TclForth Notes: Always Compiling, Forth without STATE Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-12-17 08:21 -0600
                                  Re: TclForth Notes: Always Compiling, Forth without STATE "Elizabeth D. Rather" <erather@forth.com> - 2014-12-17 08:57 -1000
                              Re: TclForth Notes: Always Compiling, Forth without STATE JennyB <jennybrien@googlemail.com> - 2014-12-17 04:52 -0800
                            Re: TclForth Notes: Always Compiling, Forth without STATE anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-17 09:58 +0000
                              Re: TclForth Notes: Always Compiling, Forth without STATE mix <mix@test.net> - 2014-12-18 04:11 +0000
                                Re: TclForth Notes: Always Compiling, Forth without STATE mix <mix@test.net> - 2014-12-18 04:16 +0000
                        Re: TclForth Notes: Always Compiling, Forth without STATE Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-12-17 02:11 -0600
                    Re: TclForth Notes: Always Compiling, Forth without STATE stephen@mpeforth.com (Stephen Pelc) - 2014-12-17 13:17 +0000
                      Re: TclForth Notes: Always Compiling, Forth without STATE Mark Wills <markwills1970@gmail.com> - 2014-12-17 06:24 -0800
          Re: TclForth Notes: Always Compiling, Forth without STATE Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-12-05 03:19 -0600
            Re: TclForth Notes: Always Compiling, Forth without STATE Wolf Wejgaard <wolf@holonforth.com> - 2014-12-06 09:31 +0100
              Re: TclForth Notes: Always Compiling, Forth without STATE Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-12-06 04:19 -0600
              Re: TclForth Notes: Always Compiling, Forth without STATE rickman <gnuarm@gmail.com> - 2014-12-08 01:14 -0500
    Re: TclForth Notes: Always Compiling, Forth without STATE the_gavino_himself <visphatesjava@gmail.com> - 2014-12-17 05:42 -0800

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

#34935

Wolf Wejgaard <wolf@holonforth.com> wrote:
> Am 05.12.14 10:16, schrieb Andrew Haley:
>> Wolf Wejgaard <wolf@holonforth.com> wrote:
>>> 
>>> TclForth thus works without a STATE variable, which makes me wonder
>>> if this is a general solution for a Forth system. After all,
>>> classical Forth takes great care in handling and discussing words
>>> that depend on a STATE.
>> 
>> Forth as such doesn't need STATE, and there were STATEless Forths in
>> use 30 years ago.  The only reason it's necessary is for standards
>> compatibility, but everyone would have to agree.
>> 
>> Andrew.
>> 
> 
> Thank you! That's what I wanted to know.
> 
> I searched for "Stateless Forth" and found Christopher Lavarenne's
> stateless Freeforth. It proves the point.
> 
> And since Elizabeth doesn't object either, I feel ok to ignore the
> obsolete layer of STATE complexity.
> 
> In TclForth it feels natural to compile the command line (and thus handle
> compiling words) because Tcl does it as well for Tcl structures. And, I
> suppose, so do all other interpreter languages. At least those that I
> have checked (Python, PHP, JS). Their consoles accept and execute loop
> structures. Only the classical/standard interpreter language Forth doesn't.
> 
> How do you explain this to a friend who is interested in Forth?

All modern Forth translators that I'm aware of have [DO] and [LOOP]
implemented. Since programmers always know which state Forth is in at any
point of time, there should be no confusion.

Standard Forth is just minimal set of words, programmer always work with
specific translator, not with ANS standard.

I'm not sure that always-compiling Forth is really a solution.

> (You can always show him TclForth, or FreeForth! :).
> 
> Wolf


-- 
mix x

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

#34944

Op Mon, 15 Dec 2014 18:55:46 +0000 (UTC) schreef mix:

> Wolf Wejgaard <wolf@holonforth.com> wrote:
>> Am 05.12.14 10:16, schrieb Andrew Haley:
>>> Wolf Wejgaard <wolf@holonforth.com> wrote:
>>>> 
>>>> TclForth thus works without a STATE variable, which makes me wonder
>>>> if this is a general solution for a Forth system. After all,
>>>> classical Forth takes great care in handling and discussing words
>>>> that depend on a STATE.
>>> 
>>> Forth as such doesn't need STATE, and there were STATEless Forths in
>>> use 30 years ago.  The only reason it's necessary is for standards
>>> compatibility, but everyone would have to agree.
>>> 
>>> Andrew.
>>> 
>> 
>> Thank you! That's what I wanted to know.
>> 
>> I searched for "Stateless Forth" and found Christopher Lavarenne's
>> stateless Freeforth. It proves the point.
>> 
>> And since Elizabeth doesn't object either, I feel ok to ignore the
>> obsolete layer of STATE complexity.
>> 
>> In TclForth it feels natural to compile the command line (and thus handle
>> compiling words) because Tcl does it as well for Tcl structures. And, I
>> suppose, so do all other interpreter languages. At least those that I
>> have checked (Python, PHP, JS). Their consoles accept and execute loop
>> structures. Only the classical/standard interpreter language Forth doesn't.
>> 
>> How do you explain this to a friend who is interested in Forth?
> 
> All modern Forth translators that I'm aware of have [DO] and [LOOP]
> implemented.
Really? Gforth has it, but SwiftForth, ciforth and Win32Forth miss them.
I suppose you mean [IF] [ELSE] [THEN]

> Since programmers always know which state Forth is in at any
> point of time, there should be no confusion.
Agreed.
> 
> Standard Forth is just minimal set of words, programmer always work with
> specific translator, not with ANS standard.
> 
> I'm not sure that always-compiling Forth is really a solution.
And I'm not sure what are the problems it should solve.

-- 
Coos

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

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

#34945

Op Tue, 16 Dec 2014 01:27:55 +0100 schreef Coos Haak:

> Op Mon, 15 Dec 2014 18:55:46 +0000 (UTC) schreef mix:
> 
>> 
>> All modern Forth translators that I'm aware of have [DO] and [LOOP]
>> implemented.
> Really? Gforth has it, but SwiftForth, ciforth and Win32Forth miss them.
> I suppose you mean [IF] [ELSE] [THEN]

Correction, ciforth uses another method, where one can use the normal words
without brackets.

want -scripting-
 OK
11 1 do i . loop
1 2 3 4 5 6 7 8 9 10  OK

-- 
Coos

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

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

#34950

Coos Haak <chforth@hccnet.nl> wrote:
> Op Mon, 15 Dec 2014 18:55:46 +0000 (UTC) schreef mix:
> 
>> Wolf Wejgaard <wolf@holonforth.com> wrote:
>>> Am 05.12.14 10:16, schrieb Andrew Haley:
>>>> Wolf Wejgaard <wolf@holonforth.com> wrote:
>>>>> 
>>>>> TclForth thus works without a STATE variable, which makes me wonder
>>>>> if this is a general solution for a Forth system. After all,
>>>>> classical Forth takes great care in handling and discussing words
>>>>> that depend on a STATE.
>>>> 
>>>> Forth as such doesn't need STATE, and there were STATEless Forths in
>>>> use 30 years ago.  The only reason it's necessary is for standards
>>>> compatibility, but everyone would have to agree.
>>>> 
>>>> Andrew.
>>>> 
>>> 
>>> Thank you! That's what I wanted to know.
>>> 
>>> I searched for "Stateless Forth" and found Christopher Lavarenne's
>>> stateless Freeforth. It proves the point.
>>> 
>>> And since Elizabeth doesn't object either, I feel ok to ignore the
>>> obsolete layer of STATE complexity.
>>> 
>>> In TclForth it feels natural to compile the command line (and thus handle
>>> compiling words) because Tcl does it as well for Tcl structures. And, I
>>> suppose, so do all other interpreter languages. At least those that I
>>> have checked (Python, PHP, JS). Their consoles accept and execute loop
>>> structures. Only the classical/standard interpreter language Forth doesn't.
>>> 
>>> How do you explain this to a friend who is interested in Forth?
>> 
>> All modern Forth translators that I'm aware of have [DO] and [LOOP]
>> implemented.
> Really? Gforth has it, but SwiftForth, ciforth and Win32Forth miss them.
> I suppose you mean [IF] [ELSE] [THEN]

Yes, I was thinking mostly of gforth when I wrote that, because I use it on
everyday basis. I thought other Forths I know of also have these words. I
guess my memory is not that good, thank you for correction.

>> Since programmers always know which state Forth is in at any
>> point of time, there should be no confusion.
> Agreed.
>> 
>> Standard Forth is just minimal set of words, programmer always work with
>> specific translator, not with ANS standard.
>> 
>> I'm not sure that always-compiling Forth is really a solution.
> And I'm not sure what are the problems it should solve.

Problem was specified in previous message:

>>> Their consoles accept and execute loop
>>> structures. Only the classical/standard interpreter language Forth doesn't.
>>> 
>>> How do you explain this to a friend who is interested in Forth?

In my opinion, [DO] and [LOOP] seem to be good solution for that.

I don't think that STATE is actually a problem. Moreover, it could be an
advantage. At least one use case I can think of is to generate some data in
interpretation state and process it using compiled words.

-- 
mix x

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

#34956

mix <mix@test.net> wrote:
> 
> In my opinion, [DO] and [LOOP] seem to be good solution for that.
> 
> I don't think that STATE is actually a problem. Moreover, it could
> be an advantage. At least one use case I can think of is to generate
> some data in interpretation state and process it using compiled
> words.

Sure, and that's not unusual, but you don't need STATE to do that.

Andrew.

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

#34967

Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
> mix <mix@test.net> wrote:
>> 
>> In my opinion, [DO] and [LOOP] seem to be good solution for that.
>> 
>> I don't think that STATE is actually a problem. Moreover, it could
>> be an advantage. At least one use case I can think of is to generate
>> some data in interpretation state and process it using compiled
>> words.
> 
> Sure, and that's not unusual, but you don't need STATE to do that.
> 
> Andrew.

Andrew, can you please clarify: 

In stateless Forth words "123 VALUE testValue testValue" will compile not
only VALUE code to HERE, but also the code which puts testValue on the top
of stack?

-- 
mix x

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

#34968

On 12/16/14 1:32 PM, mix wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
>> mix <mix@test.net> wrote:
>>>
>>> In my opinion, [DO] and [LOOP] seem to be good solution for that.
>>>
>>> I don't think that STATE is actually a problem. Moreover, it could
>>> be an advantage. At least one use case I can think of is to generate
>>> some data in interpretation state and process it using compiled
>>> words.
>>
>> Sure, and that's not unusual, but you don't need STATE to do that.
>>
>> Andrew.
>
> Andrew, can you please clarify:
>
> In stateless Forth words "123 VALUE testValue testValue" will compile not
> only VALUE code to HERE, but also the code which puts testValue on the top
> of stack?
>

The code hat puts testValue on the stack is part of the definition of 
VALUE. The new definition testValue, which is constructed by VALUE, 
references that code. STATE has nothing to do with it, whether the 
underlying Forth uses STATE or not. STATE is only relevant in colon 
definitions.

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]

#34979

"Elizabeth D. Rather" <erather@forth.com> wrote:
> On 12/16/14 1:32 PM, mix wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
>>> mix <mix@test.net> wrote:
>>>> 
>>>> In my opinion, [DO] and [LOOP] seem to be good solution for that.
>>>> 
>>>> I don't think that STATE is actually a problem. Moreover, it could
>>>> be an advantage. At least one use case I can think of is to generate
>>>> some data in interpretation state and process it using compiled
>>>> words.
>>> 
>>> Sure, and that's not unusual, but you don't need STATE to do that.
>>> 
>>> Andrew.
>> 
>> Andrew, can you please clarify:
>> 
>> In stateless Forth words "123 VALUE testValue testValue" will compile not
>> only VALUE code to HERE, but also the code which puts testValue on the top
>> of stack?
>> 
> 
> The code hat puts testValue on the stack is part of the definition of
> VALUE. The new definition testValue, which is constructed by VALUE,
> references that code. STATE has nothing to do with it, whether the
> underlying Forth uses STATE or not. STATE is only relevant in colon definitions.
> 
> Cheers,
> Elizabeth

I guess I was not really clear. If Forth is stateless (always compiling in
case of TclForth) how it would handle words which are not suppose to be
compiled in traditional Forths?

Here is example:

123 VALUE testValue
 ok
HERE .
4374119608  ok
testValue
 ok
HERE .
4374119608  ok

The word testValue was processed by translator while Forth was in
interpretation state, thus it didn't change HERE. What will always
compiling Forth do? It would be strange to see HERE growing with any new
word entered. I have some assumptions, but it would be good to hear the
answer from someone else.

-- 
mix x

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

#34984

On 12/16/14 8:01 PM, mix wrote:
> "Elizabeth D. Rather" <erather@forth.com> wrote:
>> On 12/16/14 1:32 PM, mix wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
>>>> mix <mix@test.net> wrote:
>>>>>
>>>>> In my opinion, [DO] and [LOOP] seem to be good solution for that.
>>>>>
>>>>> I don't think that STATE is actually a problem. Moreover, it could
>>>>> be an advantage. At least one use case I can think of is to generate
>>>>> some data in interpretation state and process it using compiled
>>>>> words.
>>>>
>>>> Sure, and that's not unusual, but you don't need STATE to do that.
>>>>
>>>> Andrew.
>>>
>>> Andrew, can you please clarify:
>>>
>>> In stateless Forth words "123 VALUE testValue testValue" will compile not
>>> only VALUE code to HERE, but also the code which puts testValue on the top
>>> of stack?
>>>
>>
>> The code hat puts testValue on the stack is part of the definition of
>> VALUE. The new definition testValue, which is constructed by VALUE,
>> references that code. STATE has nothing to do with it, whether the
>> underlying Forth uses STATE or not. STATE is only relevant in colon definitions.
>>
>> Cheers,
>> Elizabeth
>
> I guess I was not really clear. If Forth is stateless (always compiling in
> case of TclForth) how it would handle words which are not suppose to be
> compiled in traditional Forths?
>
> Here is example:
>
> 123 VALUE testValue
>   ok
> HERE .
> 4374119608  ok
> testValue
>   ok
> HERE .
> 4374119608  ok
>
> The word testValue was processed by translator while Forth was in
> interpretation state, thus it didn't change HERE. What will always
> compiling Forth do? It would be strange to see HERE growing with any new
> word entered. I have some assumptions, but it would be good to hear the
> answer from someone else.

Well, you may get some responses, but here's what I know: In some of 
these systems, some kind of "definition" or executable code is compiled 
during command line processing and executed when the Enter key is 
detected. In others, compiling only occurs when compiler dirctives such 
as DO or IF are encountered. If a command line includes (for example) 
conditional or looping words, they switch to compile mode (which doesn't 
require STATE, there are other methods) and compile code that will be 
executed and then discarded when the Enter key is detected.

I have never found this capability to be essential, so have never 
implemented it, but others (e.g. Opern Firmware) have followed the above 
approaches.

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]

#34985

mix <mix@test.net> wrote:
> "Elizabeth D. Rather" <erather@forth.com> wrote:
>> 
>> The code hat puts testValue on the stack is part of the definition of
>> VALUE. The new definition testValue, which is constructed by VALUE,
>> references that code. STATE has nothing to do with it, whether the
>> underlying Forth uses STATE or not. STATE is only relevant in colon definitions.
> 
> I guess I was not really clear. If Forth is stateless (always
> compiling in case of TclForth) how it would handle words which are
> not suppose to be compiled in traditional Forths?

STATEless forth doesn't necessarily always compile: it can compile or
interpret.  The colon compiler is just a word which is called from the
interpreter.  It parses the input stream itself, generating code.
When the colon compiler parses ; it exits, returning control to the
intepreter.  It really is very simple.  So, there is nothing special
about the colon compiler, it's just a word that you can call.  There's
no possibility of STATE-smart words because there is no STATE
variable.  In particular it's a much easier system in which to do
metaprogramming.

Andrew.

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

#34986

On 12/16/14 10:24 PM, Andrew Haley wrote:
> mix <mix@test.net> wrote:
>> "Elizabeth D. Rather" <erather@forth.com> wrote:
>>>
>>> The code hat puts testValue on the stack is part of the definition of
>>> VALUE. The new definition testValue, which is constructed by VALUE,
>>> references that code. STATE has nothing to do with it, whether the
>>> underlying Forth uses STATE or not. STATE is only relevant in colon definitions.
>>
>> I guess I was not really clear. If Forth is stateless (always
>> compiling in case of TclForth) how it would handle words which are
>> not suppose to be compiled in traditional Forths?
>
> STATEless forth doesn't necessarily always compile: it can compile or
> interpret.  The colon compiler is just a word which is called from the
> interpreter.  It parses the input stream itself, generating code.
> When the colon compiler parses ; it exits, returning control to the
> intepreter.  It really is very simple.  So, there is nothing special
> about the colon compiler, it's just a word that you can call.  There's
> no possibility of STATE-smart words because there is no STATE
> variable.  In particular it's a much easier system in which to do
> metaprogramming.

But the colon compiler wasn't invoked here (no colons), so this entire
example would normally just be executed, word-for-word. The two models
I've seen (always compiling and compiling only when a colon is encountered)

It's not really such a different model, it's different factoring. The 
sequence in question *could* always be executed, but one could also 
compile it and execute it when Enter is pressed, and after execution te 
compiled stuff discarded. The result would be the same, although the 
latter seems much ess efficient 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]

#34995

Elizabeth D. Rather <erather@forth.com> wrote:
> On 12/16/14 10:24 PM, Andrew Haley wrote:
>> mix <mix@test.net> wrote:
>>> "Elizabeth D. Rather" <erather@forth.com> wrote:
>>>>
>>>> The code hat puts testValue on the stack is part of the definition of
>>>> VALUE. The new definition testValue, which is constructed by VALUE,
>>>> references that code. STATE has nothing to do with it, whether the
>>>> underlying Forth uses STATE or not. STATE is only relevant in colon definitions.
>>>
>>> I guess I was not really clear. If Forth is stateless (always
>>> compiling in case of TclForth) how it would handle words which are
>>> not suppose to be compiled in traditional Forths?
>>
>> STATEless forth doesn't necessarily always compile: it can compile or
>> interpret.  The colon compiler is just a word which is called from the
>> interpreter.  It parses the input stream itself, generating code.
>> When the colon compiler parses ; it exits, returning control to the
>> intepreter.  It really is very simple.  So, there is nothing special
>> about the colon compiler, it's just a word that you can call.  There's
>> no possibility of STATE-smart words because there is no STATE
>> variable.  In particular it's a much easier system in which to do
>> metaprogramming.
> 
> But the colon compiler wasn't invoked here (no colons), so this entire
> example would normally just be executed, word-for-word.

Indeed not; I was trying to pre-empt the next question.

> The two models I've seen (always compiling and compiling only when a
> colon is encountered)

I wonder if we're talking at cross purposes: I'm talking about the
STATEless design of PolyFORTH II.

Andrew.

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

#35002

On 12/17/14 4:21 AM, Andrew Haley wrote:
> Elizabeth D. Rather <erather@forth.com> wrote:
>> On 12/16/14 10:24 PM, Andrew Haley wrote:
>>> mix <mix@test.net> wrote:
>>>> "Elizabeth D. Rather" <erather@forth.com> wrote:
>>>>>
>>>>> The code hat puts testValue on the stack is part of the definition of
>>>>> VALUE. The new definition testValue, which is constructed by VALUE,
>>>>> references that code. STATE has nothing to do with it, whether the
>>>>> underlying Forth uses STATE or not. STATE is only relevant in colon definitions.
>>>>
>>>> I guess I was not really clear. If Forth is stateless (always
>>>> compiling in case of TclForth) how it would handle words which are
>>>> not suppose to be compiled in traditional Forths?
>>>
>>> STATEless forth doesn't necessarily always compile: it can compile or
>>> interpret.  The colon compiler is just a word which is called from the
>>> interpreter.  It parses the input stream itself, generating code.
>>> When the colon compiler parses ; it exits, returning control to the
>>> intepreter.  It really is very simple.  So, there is nothing special
>>> about the colon compiler, it's just a word that you can call.  There's
>>> no possibility of STATE-smart words because there is no STATE
>>> variable.  In particular it's a much easier system in which to do
>>> metaprogramming.
>>
>> But the colon compiler wasn't invoked here (no colons), so this entire
>> example would normally just be executed, word-for-word.
>
> Indeed not; I was trying to pre-empt the next question.
>
>> The two models I've seen (always compiling and compiling only when a
>> colon is encountered)
>
> I wonder if we're talking at cross purposes: I'm talking about the
> STATEless design of PolyFORTH II.

Of course. It's just that I thought it was confusing to be talking about 
the colon compiler when the OP was trying to follow an example that 
didn't use it.

We agree: it is quite possible, and very clean, to have a STATEless 
Forth that isn't "always compiling". The colon word starts compiling 
until it gets to a semi-colon or [ (which reverts to executing until a ] 
is encountered). In fact, in this model, ] *is* the compiler, and is 
called by colon. The difference between semi-colon and [ is that 
semi-colon compiles an EXIT equivalent before stopping.

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]

#34989

On Wednesday, 17 December 2014 08:24:24 UTC, Andrew Haley  wrote:
> mix <mix@test.net> wrote:
> > "Elizabeth D. Rather" <erather@forth.com> wrote:
> >> 
> >> The code hat puts testValue on the stack is part of the definition of
> >> VALUE. The new definition testValue, which is constructed by VALUE,
> >> references that code. STATE has nothing to do with it, whether the
> >> underlying Forth uses STATE or not. STATE is only relevant in colon definitions.
> > 
> > I guess I was not really clear. If Forth is stateless (always
> > compiling in case of TclForth) how it would handle words which are
> > not suppose to be compiled in traditional Forths?
> 


I think the question is rather: if your Forth always compiles, how you distinguish between the meanings of VALUE in 

    123 VALUE testvalue

and  : TEST  123 VALUE ;

That's what I couldn't understand when Cristophe tried to explain it to me many years ago, and I came to the conclusion that it was a White Knight problem*

With Standard Forth you can use :NONAME  ...  ; EXECUTE or some sugared variant and just write of the codes pace used.  

Or you could make the whole thing totally transparent, because you are simply adding interpretation semantics to words that don't have them as Standard.

Interpretation behaviour for opening words (BEGIN, DO, >R etc.) 
 Save compiling point, shift to scratch area
 Set flag
 :NONAME
 Execute normal compiling semantics

'Interpretation' behaviour for closing words (UNTIL, LOOP R> etc)
 Execute normal compiling behaviour
 Is flag set?  IF
 Unset it 
  ;  EXECUTE
  Restore compiling point
  THEN
 
Elaborate to add more compiler security and support for nesting levels. :)

* From 'Through the Looking Glass' -

 "But I was thinking of a plan
  To dye my whiskers green
  And always use so large a fan
  That they could not be seen."

> STATEless forth doesn't necessarily always compile: it can compile or
> interpret.  The colon compiler is just a word which is called from the
> interpreter.  It parses the input stream itself, generating code.
> When the colon compiler parses ; it exits, returning control to the
> intepreter.  It really is very simple.  So, there is nothing special
> about the colon compiler, it's just a word that you can call.  There's
> no possibility of STATE-smart words because there is no STATE
> variable.  In particular it's a much easier system in which to do
> metaprogramming.
> 
> Andrew.

Could you expand on that last statement with some examples?

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

#34988

mix <mix@test.net> writes:
>I guess I was not really clear. If Forth is stateless (always compiling in
>case of TclForth) how it would handle words which are not suppose to be
>compiled in traditional Forths?
>
>Here is example:
>
>123 VALUE testValue
> ok
>HERE .
>4374119608  ok
>testValue
> ok
>HERE .
>4374119608  ok
>
>The word testValue was processed by translator while Forth was in
>interpretation state, thus it didn't change HERE. What will always
>compiling Forth do?

They typically compile to a separate buffer.  After executing the
stuff there, the buffer is reused.  I guess they implement HERE as
showing addresses in the dictionary and not in this buffer, otherwise
HERE would be mostly useless.

- 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 2014: http://www.euroforth.org/ef14/

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

#35005

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> mix <mix@test.net> writes:
>> I guess I was not really clear. If Forth is stateless (always compiling in
>> case of TclForth) how it would handle words which are not suppose to be
>> compiled in traditional Forths?
>> 
>> Here is example:
>> 
>> 123 VALUE testValue
>> ok
>> HERE .
>> 4374119608  ok
>> testValue
>> ok
>> HERE .
>> 4374119608  ok
>> 
>> The word testValue was processed by translator while Forth was in
>> interpretation state, thus it didn't change HERE. What will always
>> compiling Forth do?
> 
> They typically compile to a separate buffer.  After executing the
> stuff there, the buffer is reused.  I guess they implement HERE as
> showing addresses in the dictionary and not in this buffer, otherwise
> HERE would be mostly useless.
> 
> - anton

That's what I was thinking. And then code in the buffer can update
dictionary (and HERE) if needed.
-- 
mix x

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

#35006

mix <mix@test.net> wrote:
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> mix <mix@test.net> writes:
>>> I guess I was not really clear. If Forth is stateless (always compiling in
>>> case of TclForth) how it would handle words which are not suppose to be
>>> compiled in traditional Forths?
>>> 
>>> Here is example:
>>> 
>>> 123 VALUE testValue
>>> ok
>>> HERE .
>>> 4374119608  ok
>>> testValue
>>> ok
>>> HERE .
>>> 4374119608  ok
>>> 
>>> The word testValue was processed by translator while Forth was in
>>> interpretation state, thus it didn't change HERE. What will always
>>> compiling Forth do?
>> 
>> They typically compile to a separate buffer.  After executing the
>> stuff there, the buffer is reused.  I guess they implement HERE as
>> showing addresses in the dictionary and not in this buffer, otherwise
>> HERE would be mostly useless.
>> 
>> - anton
> 
> That's what I was thinking. And then code in the buffer can update
> dictionary (and HERE) if needed.

I forgot to add: however, this approach don't really seem to be very
efficient.

-- 
mix x

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

#34982

mix <mix@test.net> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
>> mix <mix@test.net> wrote:
>>> 
>>> In my opinion, [DO] and [LOOP] seem to be good solution for that.
>>> 
>>> I don't think that STATE is actually a problem. Moreover, it could
>>> be an advantage. At least one use case I can think of is to generate
>>> some data in interpretation state and process it using compiled
>>> words.
>> 
>> Sure, and that's not unusual, but you don't need STATE to do that.
> 
> Andrew, can you please clarify: 
> 
> In stateless Forth words "123 VALUE testValue testValue" will compile not
> only VALUE code to HERE, but also the code which puts testValue on the top
> of stack?

Absolutely, yes.  CREATE and its children do what they are supposed to
do.  You don't need to move to an "always compile" model to be
STATEless.  The only difference is when compiling colon definitions.
There are separate loops for compilation and interpretation rather
than just one which tests STATE.

Andrew.

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

#34990

On Tue, 16 Dec 2014 05:04:38 +0000 (UTC), mix <mix@test.net> wrote:

>I don't think that STATE is actually a problem. Moreover, it could be an
>advantage. At least one use case I can think of is to generate some data in
>interpretation state and process it using compiled words.

You (and others) need to distinguish between conventional/classical
Forths implemented without using a STATE variable and Forths that
always compile and then execute text input.

As as I remember, Christope Lavarenne's freeForth is a free
download and it is worth looking at. There are also corner cases
where a compile and execute implementation has to modify
coventional Forth notation.
  http://christophe.lavarenne.free.fr/ff/

In both of these cases, nobody has clearly explained to me
what problem they are trying to solve, why the problem is real,
and why their solution is worth adopting.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#34996

On Wednesday, 17 December 2014 13:17:21 UTC, Stephen Pelc  wrote:
> 
> In both of these cases, nobody has clearly explained to me
> what problem they are trying to solve, why the problem is real,
> and why their solution is worth adopting.
> 
> Stephen

From what I can gather, the only two "problems" that it solves are:

1) State-smart words go away (though there's already a super simple
   solution to that problem: factor your code properly. Problem solved.
2) Anything that could be written in a colon definition (loops etc)
   can be written on the command line.

Neither of the above issues is a show-stopper for me. Other than the
above, I'm not seeing much of an advantage.

Maybe I'm missing something.

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

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

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

csiph-web