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 1 of 3  [1] 2 3  Next page →

#33748 — TclForth Notes: Always Compiling, Forth without STATE

Classic (standard) Forth systems are remarkably consistent in using 
techniques invented 40 years ago. For instance, the classic interpreter 
still executes command lines word by word. I wonder why. Of course, it 
works and everyone is used to it. But it does not have to be that way.

TclForth compiles the command line and then executes the compiled line. 
If the command line is compiled it can handle immediate words. You can 
enter lines like this

    1 begin dup 10 < if "*" else "&" then . 1+ dup 20 > until drop


TclForth always compiles. Interpret is Compile and Execute.

If you need to calculate a value while compiling a definition, enclose 
the calculation in square brackets as usual. The code inside the 
brackets is compiled, then executed by ']' .

There are just two moments in the interpreter when code is executed: 
end-of-command-line and ']'. Thus, STATE is obsolete, it is not tested.

And if there is no STATE to test, the immediate bit also makes little 
sense. TclForth replaces immediate by Compiler.

Immediate words are now Compiler words that execute native Tcl code. - 
Example:

    Compiler if
        appendcode "if \[pop\]  \{\n"

Code and Colon words compile a call to their execution semantics. 
Compiler words perform their compilation semantics.

--

I am still struggling with the text and welcome comments to clarify it.

Anyway: TclForth works and is available for inspection.

-- 
Wolf Wejgaard
http://holonforth.com

[toc] | [next] | [standalone]

#33751

In article <m130qf$lb2$1@speranza.aioe.org>,
Wolf Wejgaard  <wolf@holonforth.com> wrote:
>Classic (standard) Forth systems are remarkably consistent in using
>techniques invented 40 years ago. For instance, the classic interpreter
>still executes command lines word by word. I wonder why. Of course, it
>works and everyone is used to it. But it does not have to be that way.
>
>TclForth compiles the command line and then executes the compiled line.
>If the command line is compiled it can handle immediate words. You can
>enter lines like this
>
>    1 begin dup 10 < if "*" else "&" then . 1+ dup 20 > until drop
>
>
>TclForth always compiles. Interpret is Compile and Execute.

The above phrase works in ciforth after replacing . by $. and
   WANT -scripting-  WANT CASE-INSENSITIVE   WANT $.
   CASE-INSENSITIVE
Allowing this is a sensible extension (or I wouldn't have implemented it).
It can be implemented in a few lines.

>
>If you need to calculate a value while compiling a definition, enclose
>the calculation in square brackets as usual. The code inside the
>brackets is compiled, then executed by ']' .
>
>There are just two moments in the interpreter when code is executed:
>end-of-command-line and ']'. Thus, STATE is obsolete, it is not tested.
>
>And if there is no STATE to test, the immediate bit also makes little
>sense. TclForth replaces immediate by Compiler.

This can be an improvement in design, but its result is not ISO, e.g.
    : test [ 1 2 + . ] ] ." We gaan naar Rome" ;
This is allowed in ISO, the superfluous extra ] is a problem in your system.

>
>Immediate words are now Compiler words that execute native Tcl code. -
>Example:
>
>    Compiler if
>        appendcode "if \[pop\]  \{\n"
>
>Code and Colon words compile a call to their execution semantics.
>Compiler words perform their compilation semantics.

The attractive thing about Forth is the extensible compiler.
Will I have to learn tcl to extend your compiler?

>
>--
>
>I am still struggling with the text and welcome comments to clarify it.
>
>Anyway: TclForth works and is available for inspection.
>
>--
>Wolf Wejgaard

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]

#33762

Am 08.10.14 13:53, schrieb Albert van der Horst:
 > In article <m130qf$lb2$1@speranza.aioe.org>,
 > Wolf Wejgaard  <wolf@holonforth.com> wrote:
...

 >> TclForth compiles the command line and then executes the compiled line.
 >> If the command line is compiled it can handle immediate words. You can
 >> enter lines like this
 >>
 >>     1 begin dup 10 < if "*" else "&" then . 1+ dup 20 > until drop
 >>
 >>
 >> TclForth always compiles. Interpret is Compile and Execute.
 >
 > The above phrase works in ciforth after replacing . by $. and
 >     WANT -scripting-  WANT CASE-INSENSITIVE   WANT $.
 >     CASE-INSENSITIVE
 > Allowing this is a sensible extension (or I wouldn't have implemented 
it).
 > It can be implemented in a few lines.
 >

Nice

 >>
 >> If you need to calculate a value while compiling a definition, enclose
 >> the calculation in square brackets as usual. The code inside the
 >> brackets is compiled, then executed by ']' .
 >>
 >> There are just two moments in the interpreter when code is executed:
 >> end-of-command-line and ']'. Thus, STATE is obsolete, it is not tested.
 >>
 >> And if there is no STATE to test, the immediate bit also makes little
 >> sense. TclForth replaces immediate by Compiler.
 >
 > This can be an improvement in design, but its result is not ISO, e.g.
 >      : test [ 1 2 + . ] ] ." We gaan naar Rome" ;
 > This is allowed in ISO, the superfluous extra ] is a problem in your 
system.
 >

There is no extra ] needed, the final ] of the expression executes the 
script in the brackets. Actually the Forth script is compiled to a Tcl 
script and evaluated by Tcl. I just tested it -- and learned that '[' 
and ']' are still missing in TclForth source V052 -- so I added them 
with these two lines.

Compiler [  appendcode \[

Compiler ]  appendcode "\] "

The Forth script
     : test { -- } [ 1 2 + . ] ." We gaan naar Rome" ;

is compiled to the Tcl script
     proc test {} {
        [push 1 ; push 2 ;  + ;  .. ; ] push "We gaan naar Rome" ;
        print [pop] ;
     }
and later passed to Tcl for execution.

ok> test
3 We gaan naar Romeok>

 >>
 >> Immediate words are now Compiler words that execute native Tcl code. -
 >> Example:
 >>
 >>     Compiler if
 >>         appendcode "if \[pop\]  \{\n"
 >>
 >> Code and Colon words compile a call to their execution semantics.
 >> Compiler words perform their compilation semantics.
 >
 > The attractive thing about Forth is the extensible compiler.
 > Will I have to learn tcl to extend your compiler?
 >

Yes, the compiler words are defined in Tcl script.

Regards, Wolf

 >>
 >> --
 >>
 >> I am still struggling with the text and welcome comments to clarify it.
 >>
 >> Anyway: TclForth works and is available for inspection.
 >>
 >> --
 >> Wolf Wejgaard
 >
 > Groetjes Albert
 >

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

#34727

Hi,

sorry for late posting.

Wolf Wejgaard wrote 08 Oct. 2014:

> [...] I just tested it -- and learned that
> '[' and ']' are still missing in TclForth source V052 -- so I added
> them with these two lines.

> Compiler [  appendcode \[

> Compiler ]  appendcode "\] "

> The Forth script
>      : test { -- } [ 1 2 + . ] ." We gaan naar Rome" ;

> is compiled to the Tcl script
>      proc test {} {
>         [push 1 ; push 2 ;  + ;  .. ; ] push "We gaan naar Rome" ;
>         print [pop] ;
>      }
> and later passed to Tcl for execution.


Trying with TclForth V052:

ok> Compiler [  appendcode \[
ok> Compiler ]  appendcode "\] "
ok> : test { -- } [ 1 2 + . ] ." We gaan naar Rome" ;
ok> test
3 ? invalid command name ""
ok>


BTW. I like HolonU and it's intensively in use here understanding
my old PowerBasic-programs again after fine-grain modularizing them.
Nice Work indeed, I'm very thankful you've shared your work.

Now I puzzle about tcl/tk over a year and try to understand
TclForth too. I'm not going to be a script-kid, but deeper
understanding of this stuff seems valuable to me and makes fun. 

Salut
 _)oachim

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

#34776

On 2014-11-30 21:20:00 +0000, Joachim Merkel said:

> ...
> 
> Trying with TclForth V052:
> 
> ok> Compiler [  appendcode \[
> ok> Compiler ]  appendcode "\] "
> ok> : test { -- } [ 1 2 + . ] ." We gaan naar Rome" ;
> ok> test
> 3 ? invalid command name ""
> ok>

Yes, it doesn't work as intended. I found the true solution later (see below).

The TclForth command line also handles compiling words, example:

  ok> 8 1 do I . loop
  1 2 3 4 5 6 7 ok> 
  ok>

TclForth does not interpret the line word by word but compiles the full 
command line
and then executes it. The result is the same.

One question remained, which I tried to solve in the previous post:  If 
the interpreter
compiles the full line, how can it handle the immediate execution of a 
part enclosed
in [ ] brackets for a result that is needed for compiling the rest of the line?

Solution: Compile and execute the bracketed part.

Let me illustrate with examples from the TclForth console:

  ok> 1 [ 2 ] 3
  (2 1 3) ok>

  ok> "first" . "second" . [ "third" . ] "fourth" .
  third first second fourth ok> 
  ok>

During compilation the immediate part is separately compiled and 
executed, and removed
from the script, which is then further compiled and and executed.

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.  So far TclForth 
does fine
without.

----------

I have moved the TclForth systems to GitHub for better version control 
and change
management, and eventual cooperation.

         https://github.com/wolfwejgaard/tclforth

The current version 0.56 includes the compiler update described above.


-----------


> BTW. I like HolonU and it's intensively in use here understanding
> my old PowerBasic-programs again after fine-grain modularizing them.
> Nice Work indeed, I'm very thankful you've shared your work.

:) - Welcome to the club!

> 
> Now I puzzle about tcl/tk over a year and try to understand
> TclForth too. I'm not going to be a script-kid, but deeper
> understanding of this stuff seems valuable to me and makes fun.

What fascinates me: Forth is usually built on a very low or less low 
level language,
mostly assembler or C. You have to create all the useful high-level 
stuff yourself,
although there is by now a large body of solutions to draw on.

Now, if instead you base your Forth on a rich mature interpreter 
language like Tcl as
your native language, you have all the features of classical Forth - 
and much more -
available with a small grab down for whatever you need.  Moreover, with 
Tcl you also
get an inner interpreter ready made for Forth.

And you get a fresh view on classical Forth in comparison. I think it's 
worth it.

The price is some knowledge of Tcl - instead of assembler and C and C 
libraries which
you can duly ignore.

Wolf

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

#34784

On Thursday, December 4, 2014 4:54:41 PM UTC+1, Wolf Wejgaard wrote:
[..]
> What fascinates me: Forth is usually built on a very low or less low 
> level language, mostly assembler or C. You have to create all the 
> useful high-level stuff yourself, [..]
 
I don't see how this can be true. Most modern Forths are able to 
call foreign code, and all C, Fortran, audio, video, database and 
whatever libraries are available that way. Moreover, you can also 
call interpreted languages or utilities (e.g. I use Matlab, Scilab, 
gnuplot, Tcl/Tk, bash, and Excel that way on a day-to-day basis).

What could be true of course (although very hard to believe), 
is that in TclForth it is much easier to call Tcl (and I assume 
Tk) than it would be in vanilla Forth. Then, if performance is 
unimportant, to have only Tcl to fall back on would be no 
disadvantage at all.  Of course, having a Forth written in 
assembly language is absolutely no guarantee it is high 
performance.  In such a case you would have only have 
advantages :-)

-marcel

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

#34785

On 12/4/14 10:05 PM, m.a.m.hendrix@tue.nl wrote:
> On Thursday, December 4, 2014 4:54:41 PM UTC+1, Wolf Wejgaard wrote:
> [..]
>> What fascinates me: Forth is usually built on a very low or less low
>> level language, mostly assembler or C. You have to create all the
>> useful high-level stuff yourself, [..]
>
> I don't see how this can be true. Most modern Forths are able to
> call foreign code, and all C, Fortran, audio, video, database and
> whatever libraries are available that way. Moreover, you can also
> call interpreted languages or utilities (e.g. I use Matlab, Scilab,
> gnuplot, Tcl/Tk, bash, and Excel that way on a day-to-day basis).

Not only that, but professional Forth as well as the most popular free 
ones also now have a fair body of library code included with them.

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]

#34797

Elizabeth D. Rather wrote:

> On 12/4/14 10:05 PM, m.a.m.hendrix@tue.nl wrote:
>> On Thursday, December 4, 2014 4:54:41 PM UTC+1, Wolf Wejgaard wrote:
>> [..]
>>> What fascinates me: Forth is usually built on a very low or less low
>>> level language, mostly assembler or C. You have to create all the
>>> useful high-level stuff yourself, [..]
>>
>> I don't see how this can be true. Most modern Forths are able to
>> call foreign code, and all C, Fortran, audio, video, database and
>> whatever libraries are available that way. Moreover, you can also
>> call interpreted languages or utilities (e.g. I use Matlab, Scilab,
>> gnuplot, Tcl/Tk, bash, and Excel that way on a day-to-day basis).
> 
> Not only that, but professional Forth as well as the most popular free
> ones also now have a fair body of library code included with them.

And with Gerald's swig effort, you can generate bindings for Gforth, VFX 
extern interface and SwiftForth by just parsing the C header files.

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

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

#35942

Am Freitag, 5. Dezember 2014 19:04:31 UTC+1 schrieb Bernd Paysan:
> Elizabeth D. Rather wrote:
> 
> > On 12/4/14 10:05 PM, m.a.m....@tue.nl wrote:
> >> On Thursday, December 4, 2014 4:54:41 PM UTC+1, Wolf Wejgaard wrote:
> >> [..]
> >>> What fascinates me: Forth is usually built on a very low or less low
> >>> level language, mostly assembler or C. You have to create all the
> >>> useful high-level stuff yourself, [..]
> >>
> >> I don't see how this can be true. Most modern Forths are able to
> >> call foreign code, and all C, Fortran, audio, video, database and
> >> whatever libraries are available that way. Moreover, you can also
> >> call interpreted languages or utilities (e.g. I use Matlab, Scilab,
> >> gnuplot, Tcl/Tk, bash, and Excel that way on a day-to-day basis).
> > 
> > Not only that, but professional Forth as well as the most popular free
> > ones also now have a fair body of library code included with them.
> 
> And with Gerald's swig effort, you can generate bindings for Gforth, VFX 
> extern interface and SwiftForth by just parsing the C header files.

Thanks. - But in Tcl I already have a wealth of libraries available ready to use with a simple "package require ...". 

The Tcl group has built an impressive collection of packages that offer at least all I would ever need. The Tcl runtime kit in TclForth already comes with an OO package, the GUI toolkit Tk, a serious database engine (Metakit - which has managed source code in HolonForth now for ten years without a glitch), as well as a virtual file system (implemented with Metakit, available to pack the source code of your app inside the executable). 

In addition you have the packages that are integrated into Tcl: strings, lists, arrays, dicts, sockets, regexp, threads, ... This all is based on a huge library of C functions that make the Tcl commands work on every desktop platform in exactly the same way. - I guess you understand why I am not crazy about C headers. I never really touched C, I wrote my Forth systems in assembler and in Forth. And now in Tcl, which is high-level C, so here we actually meet, in a way.

Wolf

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

#34811

Am 05.12.14 09:05, schrieb m.a.m.hendrix@tue.nl:
> On Thursday, December 4, 2014 4:54:41 PM UTC+1, Wolf Wejgaard wrote:
> [..]
>> What fascinates me: Forth is usually built on a very low or less low
>> level language, mostly assembler or C. You have to create all the
>> useful high-level stuff yourself, [..]
>
> I don't see how this can be true. Most modern Forths are able to
> call foreign code, and all C, Fortran, audio, video, database and
> whatever libraries are available that way. Moreover, you can also
> call interpreted languages or utilities (e.g. I use Matlab, Scilab,
> gnuplot, Tcl/Tk, bash, and Excel that way on a day-to-day basis).
>
> What could be true of course (although very hard to believe),
> is that in TclForth it is much easier to call Tcl (and I assume
> Tk) than it would be in vanilla Forth. Then, if performance is
> unimportant, to have only Tcl to fall back on would be no
> disadvantage at all.  Of course, having a Forth written in
> assembly language is absolutely no guarantee it is high
> performance.  In such a case you would have only have
> advantages :-)
>
> -marcel
>

TclForth _is_ Tcl, with a layer of Forth to handle postscript notation. 
Forth source is compiled to Tcl proc's and further processed in the Tcl 
engine. See http://wiki.tcl.tk/37199 .

There is no calling Tcl/Tk from apart, like iForth. I had hoped to 
demonstrate it in the TclForth version of your extended example in the 
thread last year
https://groups.google.com/d/msg/comp.lang.forth/UKUKX7OGRH8/aUD0hjglTGoJ

The graphics toolkit Tk is a part of the native language of TclForth :)

Wolf

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

#34812

On Saturday, December 6, 2014 8:53:46 AM UTC+1, Wolf Wejgaard wrote:
> Am 05.12.14 09:05, schrieb m.a.m.hendrix@tue.nl:
> > On Thursday, December 4, 2014 4:54:41 PM UTC+1, Wolf Wejgaard wrote:
> > [..]
[..]
> There is no calling Tcl/Tk from apart, like iForth. I had hoped to 
> demonstrate it in the TclForth version of your extended example in the 
> thread last year
> https://groups.google.com/d/msg/comp.lang.forth/UKUKX7OGRH8/aUD0hjglTGoJ

Wolf, thanks for the link. I had completely forgotten about it, 
but it expresses and illustrates exactly the thoughts that I was
starting to formulate again :-)

-marcel

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

#34786

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.

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

#34813

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?

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

Wolf

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

#34816

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

Why should she?  It was Elizabeth's company's product, polyFORTH, that
I was referring to.

Andrew.

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

#34818

In article <m5uet1$vjl$1@speranza.aioe.org>,
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?

When I started trying to do scripting in Forth
I felt the lack of looping and conditional construct on the command
line.
It was easy enough to add to ciforth. Just redefine the control
words:

\--------------------------------------------
( NEW-IF -scripting-                           ) \ AvdH B2sep21
: NEW-IF ;    \ Get rid!
WANT T]      WANT :2
:2 IF           T] POSTPONE IF                    ; IMMEDIATE
:2 DO           T] POSTPONE DO                    ; IMMEDIATE
:2 ?DO          T] POSTPONE ?DO                   ; IMMEDIATE
:2 BEGIN        T] POSTPONE BEGIN                 ; IMMEDIATE
:2 THEN            POSTPONE THEN      POSTPONE T[ ; IMMEDIATE
:2 LOOP            POSTPONE LOOP      POSTPONE T[ ; IMMEDIATE
:2 +LOOP           POSTPONE +LOOP     POSTPONE T[ ; IMMEDIATE
:2 REPEAT          POSTPONE REPEAT    POSTPONE T[ ; IMMEDIATE
:2 UNTIL           POSTPONE UNTIL     POSTPONE T[ ; IMMEDIATE
:2 AGAIN           POSTPONE AGAIN     POSTPONE T[ ; IMMEDIATE

\ Last scripting block!
\--------------------------------------------

Ignore :2 it just means that no redefinition warnings are given.

T] and T[ Are of course utterly system dependant.

In ciforth I just compile to a scratch area, halfway between
HERE at ~0 and the stack at 8G. A dirty PAD -like trick.
T] uses HERE to put the start of the compilation area on the stack,
T[ uses >R to start interpreting there.

\--------------------------------------------------
( SWAP-DP T] T[ scratch_dictionary_area ) \ AvdH A9mar31
VARIABLE FAR-DP         \ Alternative DP
DSP@ 1 RSHIFT HERE 1 RSHIFT + ALIGNED FAR-DP !
\ Use alternative dictionary area or back.
: SWAP-DP   DP @ FAR-DP @   DP ! FAR-DP ! ;
\ Remove all words from the scratch area.
: TRIM   HERE 'FORGET-VOC FOR-VOCS DROP ;

\ While compiling, T[ just throws away the state pushed by T].
\ Interpreting:
\ Start compiling at temporary place : return START and STATE.
: T] STATE @ 0= IF SWAP-DP HERE THEN STATE @ ] ;
\ Execute code at START dropping STATE, restore dictionary.
: T[ 0= IF POSTPONE (;) SWAP-DP POSTPONE [ >R THEN ; IMMEDIATE

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

Or ciforth. I find it pretty amazing that those fat Forth's
don't have it.

I couldn't help checking in my log. The first mention of NEW-FORTH
is in 2002.

"
2002 jun 18 tue
Coos Haak has found 3 bugs / PFCR's.
- FORGETTING in MEASURE-PRIME is a mess
- $@= returns inverted condition
- ARGC not implemented for MSDOS
  (but required for the compilation in 4.1 !)

The first is solved by using ?LEAVE-BLOCK instead of NEW-IF.
The second by leaving out the word altogether.
The third is filed in todo.txt.
Experimenting with threads. fork works, but for
doesn't fit the bill (copy on write!)
"

Apparently it was a well-known utility already back then.

>
>Wolf
>
>
>
>
>
-- 
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]

#34820

Wolf Wejgaard <wolf@holonforth.com> writes:
>I searched for "Stateless Forth" and found Christopher Lavarenne's 
>stateless Freeforth. It proves the point.

Christophe Lavarenne took the approach of always compiling.  That
resolves some of the state-smartness problems, but produces new
issues.  I only dimly remember what they are (mainly implementing
parsing words IIRC), but in any case, it seems that you cannot
eliminate the problem in this way, only push it around.

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

#35943

Am Samstag, 6. Dezember 2014 13:48:57 UTC+1 schrieb Anton Ertl:
> Wolf Wejgaard writes:
> >I searched for "Stateless Forth" and found Christopher Lavarenne's 
> >stateless Freeforth. It proves the point.
> 
> Christophe Lavarenne took the approach of always compiling.  That
> resolves some of the state-smartness problems, but produces new
> issues.  I only dimly remember what they are (mainly implementing
> parsing words IIRC), but in any case, it seems that you cannot
> eliminate the problem in this way, only push it around.

I kept this on the back burner for a while wondering why there are no problems in the TclForth solution. Now I think I understand. The Forth compiler is fully implemented in the native language Tcl. The 'immedate' words are defined as a separate word type 'Compiler' and the compiler action is written in Tcl script (closures). Tcl is a high-level language in its own right, so it's easy to use for a compiler. Tcl and Forth are intertwined anyway. 

The Forth words  can concentrate on their role in the application. They don't have a double nature. I suppose that this solves the two-state dilemma of classical Forth for TclForth.

Wolf

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

#34822

Am Sat, 06 Dec 2014 09:31:31 +0100
schrieb Wolf Wejgaard <wolf@holonforth.com>:

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

I remember StarForth (Dos) and Quest32 (Win) from Gerry Chanson are
able to do it, he mentioned several times on cls, but it was not much
discussed here.
-- 
Salut
 _)oachim

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

#34823

Am Sat, 6 Dec 2014 18:11:05 +0100
schrieb Joachim Merkel <jm412@gmx.de>:

> cls
clf

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

#34824

Am Sat, 6 Dec 2014 18:11:05 +0100
schrieb Joachim Merkel <jm412@gmx.de>:

sorry

> Gerry Chanson

Gary

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web