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

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

ColorForth - another dead end?

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

Contents

  ColorForth - another dead end? borota@gmail.com - 2015-05-24 12:22 -0700
    Re: ColorForth - another dead end? hughaguilar96@gmail.com - 2015-05-24 14:00 -0700
      Re: ColorForth - another dead end? borota@gmail.com - 2015-05-24 16:18 -0700
        Re: ColorForth - another dead end? hughaguilar96@gmail.com - 2015-05-24 16:45 -0700
        Re: ColorForth - another dead end? "Elizabeth D. Rather" <erather@forth.com> - 2015-05-24 14:50 -1000
          Re: ColorForth - another dead end? hughaguilar96@gmail.com - 2015-05-24 18:12 -0700
            Re: ColorForth - another dead end? onewhohopes@gmail.com - 2015-05-28 13:00 -0700
              Re: ColorForth - another dead end? hughaguilar96@gmail.com - 2015-05-28 18:55 -0700
              Re: ColorForth - another dead end? Howerd <howerdo@yahoo.co.uk> - 2015-05-29 00:49 -0700
                Re: ColorForth - another dead end? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-29 07:56 -0700
                  Re: ColorForth - another dead end? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-29 15:04 +0000
                    Re: ColorForth - another dead end? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-29 10:03 -0700
                      Re: ColorForth - another dead end? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-29 10:15 -0700
                    Re: ColorForth - another dead end? hughaguilar96@gmail.com - 2015-05-29 19:28 -0700
                      Re: ColorForth - another dead end? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-30 12:34 +0000
                  Re: ColorForth - another dead end? hughaguilar96@gmail.com - 2015-05-29 19:19 -0700
                    Re: ColorForth - another dead end? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-29 22:30 -0700
                  Re: ColorForth - another dead end? "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-30 00:14 -0400
                    Re: ColorForth - another dead end? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-29 22:22 -0700
                      Re: ColorForth - another dead end? "Alex McDonald" <blog@rivadpm.com> - 2015-05-30 09:27 +0100
                        Re: ColorForth - another dead end? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-30 02:05 -0700
                          Re: ColorForth - another dead end? "Alex McDonald" <blog@rivadpm.com> - 2015-05-30 10:21 +0100
                            Re: ColorForth - another dead end? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-30 04:08 -0700
                              Re: ColorForth - another dead end? hughaguilar96@gmail.com - 2015-05-30 07:43 -0700
                                Re: ColorForth - another dead end? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-30 09:42 -0700
                                  Re: ColorForth - another dead end? hughaguilar96@gmail.com - 2015-05-30 10:25 -0700
                                    Re: ColorForth - another dead end? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-30 22:36 -0700
                                      Re: ColorForth - another dead end? hughaguilar96@gmail.com - 2015-05-31 16:38 -0700
                              Re: ColorForth - another dead end? "Alex McDonald" <blog@rivadpm.com> - 2015-05-31 09:11 +0100
                              Re: ColorForth - another dead end? humptydumpty <ouatubi@gmail.com> - 2015-05-31 11:31 -0700
                                Re: ColorForth - another dead end? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-01 13:21 +0000
                                  Re: ColorForth - another dead end? humptydumpty <ouatubi@gmail.com> - 2015-06-01 08:18 -0700
                                  Re: ColorForth - another dead end? humptydumpty <ouatubi@gmail.com> - 2015-06-01 09:07 -0700
                                  Re: ColorForth - another dead end? humptydumpty <ouatubi@gmail.com> - 2015-06-01 23:31 -0700
                                    Field name overloading (was: ColorForth - another dead end?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-02 09:47 +0000
                                      Re: Field name overloading (was: ColorForth - another dead end?) humptydumpty <ouatubi@gmail.com> - 2015-06-02 13:07 -0700
                                Re: ColorForth - another dead end? humptydumpty <ouatubi@gmail.com> - 2015-06-01 08:20 -0700
                      Re: ColorForth - another dead end? "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-30 15:34 -0400
                  Re: ColorForth - another dead end? hughaguilar96@gmail.com - 2015-05-29 22:55 -0700
                    Re: ColorForth - another dead end? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-30 00:54 -0700
                Re: ColorForth - another dead end? stephen@mpeforth.com (Stephen Pelc) - 2015-05-30 17:20 +0000
                  Re: ColorForth - another dead end? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-31 15:17 +0000
          Re: ColorForth - another dead end? Hannu Vuolasaho <vuokkosetae@gmail.com> - 2015-05-25 10:06 +0300
          Re: ColorForth - another dead end? Jason Damisch <jasondamisch@yahoo.com> - 2015-05-25 11:11 -0700
            Re: ColorForth - another dead end? rickman <gnuarm@gmail.com> - 2015-05-25 14:22 -0400
              Re: ColorForth - another dead end? "Elizabeth D. Rather" <erather@forth.com> - 2015-05-25 14:57 -1000
                Re: ColorForth - another dead end? borota@gmail.com - 2015-05-25 20:42 -0700
                Re: ColorForth - another dead end? hughaguilar96@gmail.com - 2015-05-29 19:46 -0700
                  Re: ColorForth - another dead end? "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-30 00:03 -0400
    Re: ColorForth - another dead end? Howerd <howerdo@yahoo.co.uk> - 2015-05-24 21:51 -0700
      Re: ColorForth - another dead end? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-25 11:17 +0000
    Re: ColorForth - another dead end? Mark Wills <markwills1970@gmail.com> - 2015-05-25 01:50 -0700
      Re: ColorForth - another dead end? Howerd <howerdo@yahoo.co.uk> - 2015-05-25 02:11 -0700
    Re: ColorForth - another dead end? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-25 14:11 +0000

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

#39255 — ColorForth - another dead end?

Hello everybody,

I am Greg. This is my first post here.

I was searching the web about ColorForth and I saw a lot of activity around it some good years ago and then lately almost nothing. Lots of people who put effort into it seem to have completely abandoned it lately.

So my question is why? Did people investigate it and then found out it doesn't give you as much for the buck as initially thought? 

My Forth expertise is at the Starting Forth level (reading it a second time). I was thinking to try to figure out ColorForth after that. Even on this list, I see people showing interest in it couple of years back, but almost nothing about it in later years.

I have read that Chuck admitted "sourceless" programming was a dead end and he completely abandoned it. Is ColorForth another dead-end too?

[toc] | [next] | [standalone]

#39256

On Sunday, May 24, 2015 at 12:22:28 PM UTC-7, bor...@gmail.com wrote:
> Hello everybody,
> 
> I am Greg. This is my first post here.
> 
> I was searching the web about ColorForth and I saw a lot of activity around it some good years ago and then lately almost nothing. Lots of people who put effort into it seem to have completely abandoned it lately.
> 
> So my question is why? Did people investigate it and then found out it doesn't give you as much for the buck as initially thought? 
> 
> My Forth expertise is at the Starting Forth level (reading it a second time). I was thinking to try to figure out ColorForth after that. Even on this list, I see people showing interest in it couple of years back, but almost nothing about it in later years.
> 
> I have read that Chuck admitted "sourceless" programming was a dead end and he completely abandoned it. Is ColorForth another dead-end too?

I don't know what Charles Moore may have been referring to in regard to "sourceless programming" --- that sounds like what they do in Visual Basic.

I don't really know enough about ColorForth to comment on it --- all of what Charles Moore does is pretty far out and funky, and not very practical --- I don't really pay much attention to it.

If you want to learn ANS-Forth, you can start with my novice package:
http://www.forth.org/novice.html

None of the books from Forth Inc., including "Starting Forth," describe how to implement structs. I didn't even know what structs were until I learned C, and then I brought the idea over to Forth (see FIELD in the novice-package). For any kind of actual programming in Forth, you are going to need the novice-package or something very similar --- reading Forth Inc. books will never take you beyond writing baby programs.

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

#39259

His sourceless from what I could understand was of very different kind than VB :) Oversimplified: Write/edit your programs directly in binary, even assembly was too much...

Thanks for the link. It answers my question after reading Starting Forth once. All cool but how about some data structures and more serious programming?

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

#39260

On Sunday, May 24, 2015 at 4:18:30 PM UTC-7, bor...@gmail.com wrote:
> His sourceless from what I could understand was of very different kind than VB :) Oversimplified: Write/edit your programs directly in binary, even assembly was too much...

That reminds me of those monitor programs for the 6502. I think this was the Apple-II that I'm remembering. It was an assembler in the sense that the programmer entered assembly-language instructions, but there was no source-code. The instructions got assembled directly into memory, and what the programmer was looking at was a disassembly of memory rather than a source-code file. Backwards branches were easy because you could see the code already written and know what the address of your destination was. Forward branches were trickier --- you had to put in a dummy value and then go back and fill it in when you knew your destination address. There was a command for moving a block of memory ahead, so you could insert code, but if you did this all of your branches got messed up. 

Writing a program using a monitor was a painful process. People who did this would typically write their program with pencil-and-paper, then study the heck out of it mentally, then type it into the monitor program and expect it to run correctly. The monitor allowed single-stepping through programs, and it would display register values as you went, so it was possible to debug like this.

The monitor was mostly used for testing short snippets of code --- mostly for twiddling the bits on an I/O port to see what happens. It is actually much easier to use a Forth system for this kind of testing, but the monitor programs were a first step in the direction of interactive programming.

MS-DOS had a DEBUG program that was essentially a monitor --- I don't know if it is still available --- maybe if you point-and-click enough in that control-panel stuff, you eventually find yourself in DEBUG mode.

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

#39265

On 5/24/15 1:18 PM, borota@gmail.com wrote:
> His sourceless from what I could understand was of very different
> kind than VB :) Oversimplified: Write/edit your programs directly
> in binary, even assembly was too much...
>
> Thanks for the link. It answers my question after reading Starting
> Forth once. All cool but how about some data structures and more
> serious programming?
>

Unfortunately, Starting Forth presents a very simplified view of the 
state of Forth 30 years ago, which even more unrepresentative of Forth 
today than K&R is of the current state of C programming (K&R was at 
least aimed at professional programmers). If you are interested in Forth 
I highly recommend some more recent and more technical books on the 
language, of which there are several. My book, the Forth Programmer's 
Handbook, is available from Amazon as well as a free pdf included with 
the evaluation version of FORTH, Inc.'s SwiftForth (windows, Linux, OSX) 
and SwiftX (interactive cross-compiler for popular microcontrollers) in 
addition to extensive documentation of these respective implementations. 
Both SwiftForth and SwiftX have been used in major software projects: 
SwiftX, for example, runs communication multiplexors that manage much of 
the electric power grid in North America.

Forth takes a unique approach to data structures. It provides some 
simple ones, but more importantly provides a mechanism for defining 
application-specific data structures. In other words, instead of having 
to express your application data in some pre-defined kind of structure, 
there's a very simple way of defining exactly what you need that behaves 
exactly how you need it to. This mechanism, using the words CREATE and 
DOES>, lets you in effect design a new class of words with a specified 
compile-time behavior and run-time behavior. Examples have included 
automatically index circular tables of coefficients (every time you 
invoke a reference to a table you get the next element), data "objects" 
that actually read a value from an I/O port and scale it appropriately, 
multi-dimensional arrays, arrays and tables that range-check index 
parameters, objects that "live" in a file or in flash, and many more. In 
your search for matrices, you've found one example; believe me, that's 
just the beginning!

As far as colorFORTH is concerned, it represents a direction that Chuck 
Moore has been pursuing for some years now that is quite divergent from 
mainstream Forth. Although it embodies some interesting ideas, it has 
not really caught on among programmers using Forth professionally.

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]

#39266

On Sunday, May 24, 2015 at 5:50:56 PM UTC-7, Elizabeth D. Rather wrote:
> On 5/24/15 1:18 PM, borota@gmail.com wrote:
> > His sourceless from what I could understand was of very different
> > kind than VB :) Oversimplified: Write/edit your programs directly
> > in binary, even assembly was too much...
> >
> > Thanks for the link. It answers my question after reading Starting
> > Forth once. All cool but how about some data structures and more
> > serious programming?
> >
> 
> Unfortunately, Starting Forth presents a very simplified view of the 
> state of Forth 30 years ago, which even more unrepresentative of Forth 
> today than K&R is of the current state of C programming (K&R was at 
> least aimed at professional programmers). If you are interested in Forth 
> I highly recommend some more recent and more technical books on the 
> language, of which there are several. My book, the Forth Programmer's 
> Handbook, is available from Amazon as well as a free pdf included with 
> the evaluation version of FORTH, Inc.'s SwiftForth (windows, Linux, OSX) 
> and SwiftX (interactive cross-compiler for popular microcontrollers) in 
> addition to extensive documentation of these respective implementations. 
> Both SwiftForth and SwiftX have been used in major software projects: 
> SwiftX, for example, runs communication multiplexors that manage much of 
> the electric power grid in North America.
> 
> Forth takes a unique approach to data structures. It provides some 
> simple ones, but more importantly provides a mechanism for defining 
> application-specific data structures. In other words, instead of having 
> to express your application data in some pre-defined kind of structure, 
> there's a very simple way of defining exactly what you need that behaves 
> exactly how you need it to. This mechanism, using the words CREATE and 
> DOES>, lets you in effect design a new class of words with a specified 
> compile-time behavior and run-time behavior. Examples have included 
> automatically index circular tables of coefficients (every time you 
> invoke a reference to a table you get the next element), data "objects" 
> that actually read a value from an I/O port and scale it appropriately, 
> multi-dimensional arrays, arrays and tables that range-check index 
> parameters, objects that "live" in a file or in flash, and many more. In 
> your search for matrices, you've found one example; believe me, that's 
> just the beginning!

As I said, none of the Forth Inc. books describe how to implement a struct, which is the foundation of all data-structures. I have never seen any evidence to indicate that Elizabeth Rather knows what a struct is.

CREATE DOES> also has serious problems --- I don't use it in the novice-package.

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

#39391

On Sunday, May 24, 2015 at 9:12:13 PM UTC-4, hughag...@gmail.com wrote:
> On Sunday, May 24, 2015 at 5:50:56 PM UTC-7, Elizabeth D. Rather wrote:
> > On 5/24/15 1:18 PM, borota@gmail.com wrote:
> > > His sourceless from what I could understand was of very different
> > > kind than VB :) Oversimplified: Write/edit your programs directly
> > > in binary, even assembly was too much...
> > >
> > > Thanks for the link. It answers my question after reading Starting
> > > Forth once. All cool but how about some data structures and more
> > > serious programming?
> > >
> > 
> > Unfortunately, Starting Forth presents a very simplified view of the 
> > state of Forth 30 years ago, which even more unrepresentative of Forth 
> > today than K&R is of the current state of C programming (K&R was at 
> > least aimed at professional programmers). If you are interested in Forth 
> > I highly recommend some more recent and more technical books on the 
> > language, of which there are several. My book, the Forth Programmer's 
> > Handbook, is available from Amazon as well as a free pdf included with 
> > the evaluation version of FORTH, Inc.'s SwiftForth (windows, Linux, OSX) 
> > and SwiftX (interactive cross-compiler for popular microcontrollers) in 
> > addition to extensive documentation of these respective implementations. 
> > Both SwiftForth and SwiftX have been used in major software projects: 
> > SwiftX, for example, runs communication multiplexors that manage much of 
> > the electric power grid in North America.
> > 
> > Forth takes a unique approach to data structures. It provides some 
> > simple ones, but more importantly provides a mechanism for defining 
> > application-specific data structures. In other words, instead of having 
> > to express your application data in some pre-defined kind of structure, 
> > there's a very simple way of defining exactly what you need that behaves 
> > exactly how you need it to. This mechanism, using the words CREATE and 
> > DOES>, lets you in effect design a new class of words with a specified 
> > compile-time behavior and run-time behavior. Examples have included 
> > automatically index circular tables of coefficients (every time you 
> > invoke a reference to a table you get the next element), data "objects" 
> > that actually read a value from an I/O port and scale it appropriately, 
> > multi-dimensional arrays, arrays and tables that range-check index 
> > parameters, objects that "live" in a file or in flash, and many more. In 
> > your search for matrices, you've found one example; believe me, that's 
> > just the beginning!
> 
> As I said, none of the Forth Inc. books describe how to implement a struct, which is the foundation of all data-structures. I have never seen any evidence to indicate that Elizabeth Rather knows what a struct is.
> 
> CREATE DOES> also has serious problems --- I don't use it in the novice-package.

Could you elaborate on this?  How is the concept of a C struct not a subset of the functionality provided by CREATE DOES>?  Or are you referring to the syntax of being able to refer to parts of a struct by name (this.that)?

What are the serious problems with CREATE DOES> that you mention?  I am still quite a novice Forther, so perhaps coming from C to Forth is keeping me from seeing what you are talking about.

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

#39396

On Thursday, May 28, 2015 at 1:00:30 PM UTC-7, onewh...@gmail.com wrote:
> On Sunday, May 24, 2015 at 9:12:13 PM UTC-4, hughag...@gmail.com wrote:
> > As I said, none of the Forth Inc. books describe how to implement a struct, which is the foundation of all data-structures. I have never seen any evidence to indicate that Elizabeth Rather knows what a struct is.
> > 
> > CREATE DOES> also has serious problems --- I don't use it in the novice-package.
> 
> Could you elaborate on this?  How is the concept of a C struct not a subset of the functionality provided by CREATE DOES>?  Or are you referring to the syntax of being able to refer to parts of a struct by name (this.that)?

I'm referring to the feature of obtaining the field address from the struct address --- see FIELD in the novice package (http://www.forth.org/novice.html).

> What are the serious problems with CREATE DOES> that you mention?  I am still quite a novice Forther, so perhaps coming from C to Forth is keeping me from seeing what you are talking about.

There are three major problems with CREATE DOES> in Forth:

1.) There is only one action associated with the word. This can be worked around with >BODY but the result is some pretty awkward source-code.

2.) Data is being fetched out of memory at run-time by the DOES> code which is inefficient in the majority of the cases in which this data is known at compile-time and is immutable; it would be much more efficient that this data could be compiled as literal.

3.) The language and the compiler are over-complicated because CREATE is overloaded to be used for two unrelated purposes. In my own cross-compiler, I defined CREATE like this:
    : create  here constant ;
I also had <BUILDS that defined a word that had to be fixed up by DOES> (if <BUILDS didn't have a corresponding DOES> then that was an error).

This is discussed here:
https://groups.google.com/forum/#!searchin/comp.lang.forth/hugh$20use$20create$20does/comp.lang.forth/TTvONOrHvI4/X63CXcZYaPgJ

In here, regarding the #2 objection above, Stephen Pelc describes how CREATE DOES> in VFX is able to compile code with the immutable data as literals rather than fetch it from memory at run-time. He wouldn't provide the source-code for his example however! Finally he did provide it, and it wasn't ANS-Forth --- VFX has a work-around for the bug in ANS-Forth design (some directives that the programmer inserts into his code to indicate that data is immutable), but this is highly non-standard --- by comparison, my :NAME workaround for the same problem is ANS-Forth compliant, so I have more loyalty to ANS-Forth than Stephen Pelc does, but I also have more honesty in describing its problems.

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

#39398

On Thursday, May 28, 2015 at 9:00:30 PM UTC+1, onewh...@gmail.com wrote:
> On Sunday, May 24, 2015 at 9:12:13 PM UTC-4, hughag...@gmail.com wrote:
> > On Sunday, May 24, 2015 at 5:50:56 PM UTC-7, Elizabeth D. Rather wrote:
> > > On 5/24/15 1:18 PM, bor...@gmail.com wrote:
> > > > His sourceless from what I could understand was of very different
> > > > kind than VB :) Oversimplified: Write/edit your programs directly
> > > > in binary, even assembly was too much...
> > > >
> > > > Thanks for the link. It answers my question after reading Starting
> > > > Forth once. All cool but how about some data structures and more
> > > > serious programming?
> > > >
> > > 
> > > Unfortunately, Starting Forth presents a very simplified view of the 
> > > state of Forth 30 years ago, which even more unrepresentative of Forth 
> > > today than K&R is of the current state of C programming (K&R was at 
> > > least aimed at professional programmers). If you are interested in Forth 
> > > I highly recommend some more recent and more technical books on the 
> > > language, of which there are several. My book, the Forth Programmer's 
> > > Handbook, is available from Amazon as well as a free pdf included with 
> > > the evaluation version of FORTH, Inc.'s SwiftForth (windows, Linux, OSX) 
> > > and SwiftX (interactive cross-compiler for popular microcontrollers) in 
> > > addition to extensive documentation of these respective implementations. 
> > > Both SwiftForth and SwiftX have been used in major software projects: 
> > > SwiftX, for example, runs communication multiplexors that manage much of 
> > > the electric power grid in North America.
> > > 
> > > Forth takes a unique approach to data structures. It provides some 
> > > simple ones, but more importantly provides a mechanism for defining 
> > > application-specific data structures. In other words, instead of having 
> > > to express your application data in some pre-defined kind of structure, 
> > > there's a very simple way of defining exactly what you need that behaves 
> > > exactly how you need it to. This mechanism, using the words CREATE and 
> > > DOES>, lets you in effect design a new class of words with a specified 
> > > compile-time behavior and run-time behavior. Examples have included 
> > > automatically index circular tables of coefficients (every time you 
> > > invoke a reference to a table you get the next element), data "objects" 
> > > that actually read a value from an I/O port and scale it appropriately, 
> > > multi-dimensional arrays, arrays and tables that range-check index 
> > > parameters, objects that "live" in a file or in flash, and many more. In 
> > > your search for matrices, you've found one example; believe me, that's 
> > > just the beginning!
[snip]
> 
> Could you elaborate on this?  How is the concept of a C struct not a subset of the functionality provided by CREATE DOES>?  Or are you referring to the syntax of being able to refer to parts of a struct by name (this.that)?
> 
> What are the serious problems with CREATE DOES> that you mention?  I am still quite a novice Forther, so perhaps coming from C to Forth is keeping me from seeing what you are talking about.

Hi,

Something like C structs can be implemented using CREATE ... DOES> , with a  slightly different syntax.

I found some code in my Win32Forth folder, under ePost, ( so its probably from Jos van der Ven ) that does this - I've posted it here : www.inventio.co.uk/STRUCT.F

IIRC Stephen Pelc has  powerful C-like struct support in VFX, and these are very useful when interfacing to Windows etc.

Hugh Aguilar's Novice package provides this functionality :

: field ( offset size -- new-offset )           \ stream: name      
    create  
        over ,  +
    does> ( struct-adr base-adr -- field-adr )
        @ + ;

I like this simple definition, which I think does the same thing :

: struct ( a c -- a' )    over  CONSTANT + ;

I snipped Hugh's comment about "> CREATE DOES> also has serious problems" because it is not relevant to structs, and another line because it is rude.
I will let Hugh explain this.

Best regards,
Howerd

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

#39420

> IIRC Stephen Pelc has  powerful C-like struct support in VFX, and these are very useful when interfacing to Windows etc.

C structs are powerful, the fields are associated with the object. In forth 
you cannot have this, fields are global. Forth structs are not so powerful.

Maybe I'm missing something here and VFX found a way to implement C structs?

> 
> Hugh Aguilar's Novice package provides this functionality :
> 
> : field ( offset size -- new-offset )           \ stream: name      
>     create  
>         over ,  +
>     does> ( struct-adr base-adr -- field-adr )
>         @ + ;
> 
This is a classical example of inefficiency (like also the CONSTANT example implemented with create does>). The field word will do @ + at RUNTIME even if the offsets are well known at compile time, and this is a very common situation!.

There is a solution to this though. First, you need to delay literal compiling
in order to have a chance to do constant folding (or any other mechanism)
Second you need a smart + which should be immediate and perform a + if there
are at least two literals pending, or compile the + otherwise;
And third, you need to make the defined word immediate.
In this situation, when the field word is encountered, it is executed at compile time (it is immediate). It performs @ fetching the offset value - ok, the offset is always known at compile time. Then it performs the +. + sees at least one literal on the stack - the offset just fetched. If it sees at least one more literal (supposed to be based address) it adds them at compile time, leaving the computed address on the stack. Otherwise it compiles the + (this will trigger compiling first the offset as a literal).
Simple :)

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

#39424

Raimond Dragomir <raimond.dragomir@gmail.com> writes:
[Someone:]
>> : field ( offset size -- new-offset )           \ stream: name     =20
>>     create =20
>>         over ,  +
>>     does> ( struct-adr base-adr -- field-adr )
>>         @ + ;
>>=20
>This is a classical example of inefficiency (like also the CONSTANT example=
> implemented with create does>). The field word will do @ + at RUNTIME even=
> if the offsets are well known at compile time, and this is a very common s=
>ituation!.
>
>There is a solution to this though. First, you need to delay literal compil=
>ing
>in order to have a chance to do constant folding (or any other mechanism)
>Second you need a smart + which should be immediate and perform a + if ther=
>e
>are at least two literals pending, or compile the + otherwise;
>And third, you need to make the defined word immediate.
>In this situation, when the field word is encountered, it is executed at co=
>mpile time (it is immediate). It performs @ fetching the offset value - ok,=
> the offset is always known at compile time. Then it performs the +. + sees=
> at least one literal on the stack - the offset just fetched. If it sees at=
> least one more literal (supposed to be based address) it adds them at comp=
>ile time, leaving the computed address on the stack. Otherwise it compiles =
>the + (this will trigger compiling first the offset as a literal).
>Simple :)

Not simple, and pretty wrong.  The fields defined by the word above are
not defined as immediate, and if you define them as immediate, they would
not do the required thing.

The problem with the definition above is that the body of the field
can be changed later with >BODY !, so the best a compiler can do is to
inline the DOES> part as

<addr> @ +

A simple, but somewhat unusual way to avoid this problem is to define
this as

: +FIELD ( n1 n2 "<spaces>name" -- n3 )
  over >r + 
  : r> postpone literal postpone + postpone ;
;

(+FIELD is the Forth-2012 name of this word).

Let's compare the compiled code:

4 4 field f1 \ with the FIELD above
4 4 +field f2
create x 8 allot
: foo1 x f1 @ + ;
: foo2 x f2 @ + ;

with VFX Forth 4.71:
see foo1 
FOO1 
( 080C09E0    8B1560090C08 )          MOV       EDX, [080C0960]
( 080C09E6    039AB0090C08 )          ADD       EBX, [EDX+080C09B0]
( 080C09EC    C3 )                    NEXT,
( 13 bytes, 3 instructions )
 ok
see foo2 
FOO2 
( 080C0A10    031DB4090C08 )          ADD       EBX, [080C09B4]
( 080C0A16    C3 )                    NEXT,
( 7 bytes, 2 instructions )

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

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

#39427

vineri, 29 mai 2015, 19:07:07 UTC+3, Anton Ertl a scris:
> Raimond Dragomir <raimond.dragomir@gmail.com> writes:
> [Someone:]
> >> : field ( offset size -- new-offset )           \ stream: name     =20
> >>     create =20
> >>         over ,  +
> >>     does> ( struct-adr base-adr -- field-adr )
> >>         @ + ;
> >>=20
> >This is a classical example of inefficiency (like also the CONSTANT example=
> > implemented with create does>). The field word will do @ + at RUNTIME even=
> > if the offsets are well known at compile time, and this is a very common s=
> >ituation!.
> >
> >There is a solution to this though. First, you need to delay literal compil=
> >ing
> >in order to have a chance to do constant folding (or any other mechanism)
> >Second you need a smart + which should be immediate and perform a + if ther=
> >e
> >are at least two literals pending, or compile the + otherwise;
> >And third, you need to make the defined word immediate.
> >In this situation, when the field word is encountered, it is executed at co=
> >mpile time (it is immediate). It performs @ fetching the offset value - ok,=
> > the offset is always known at compile time. Then it performs the +. + sees=
> > at least one literal on the stack - the offset just fetched. If it sees at=
> > least one more literal (supposed to be based address) it adds them at comp=
> >ile time, leaving the computed address on the stack. Otherwise it compiles =
> >the + (this will trigger compiling first the offset as a literal).
> >Simple :)
> 
> Not simple, and pretty wrong.  The fields defined by the word above are
> not defined as immediate, and if you define them as immediate, they would
> not do the required thing.

I think you don't understand. The scheme that I described works in my system 
like a charm. Here it is my sources (sorry it is a forth dialect):

\ optimized macro words with constant folding
[ state @ 0> ] def compiling?
\ EVAL-XT-CF ( n -- ) constant folding level
[ depth u>= compiling? and if compile, else execute then ] def eval-xt-cf
[ -1 eval-xt-cf ] def eval-xt       \ no constant folding
[  2 eval-xt-cf ] def eval-xt-cf1   \ constant folding 1 level
[  3 eval-xt-cf ] def eval-xt-cf2   \ constant folding 2 levels
[  4 eval-xt-cf ] def eval-xt-cf3   \ constant folding 3 levels

[ ' drop eval-xt-cf1 ] idef drop
[ ' nip  eval-xt-cf2 ] idef nip
[ ' swap eval-xt-cf2 ] idef swap
[ ' rot  eval-xt-cf3 ] idef rot
[ ' and  eval-xt-cf2 ] idef and
[ ' or   eval-xt-cf2 ] idef or
[ ' xor  eval-xt-cf2 ] idef xor
[ ' -    eval-xt-cf2 ] idef -
[ ' /    eval-xt-cf2 ] idef /

\ do not compile 0 +
[ depth 2 < compiling? and if
    depth 1 < if
      ' + compile,
    else \ depth is 1
      dup if \ and x is not 0
        ' + compile,
      else drop then
    then
  else + then
] idef +

\ do not compile 1 *
[ depth 2 < compiling? and if
    depth 1 < if
      ' * compile,
    else \ depth is 1
      dup 1 <> if \ and x is not 1
        ' * compile,
      else drop then
    then
  else * then
] idef *

\ FIELD ( "name" offset size -- offset+size ) name: ( x -- x+offset )
[ [ @ compile + ] ibuild over , + ] def field

Some explanations:
[ ] compiles anonymous code (I name them quotes). Can be nested. Top level 
quote leaves it's address on the stack at compile time, nested quotes leave 
their address on the stack at runtime.

def makes a dictionary entry
idef makes an immediate dictionary entry
buid builds a building word :) something like create does
ibuild builds an immediate building word.
state is in fact the nesting level of quotes, otherwise is like standard forth state.
Another important thing which is internal and cannot be seen is that
all literals are delayed in compiling (they stay on the data stack until
either they are used by smart words like +, - etc, or are "flushed"
on the compiled code by a normal word).

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

#39428

vineri, 29 mai 2015, 20:03:17 UTC+3, Raimond Dragomir a scris:
> vineri, 29 mai 2015, 19:07:07 UTC+3, Anton Ertl a scris:
> > Raimond Dragomir <raimond.dragomir@gmail.com> writes:
> > [Someone:]
> > >> : field ( offset size -- new-offset )           \ stream: name     =20
> > >>     create =20
> > >>         over ,  +
> > >>     does> ( struct-adr base-adr -- field-adr )
> > >>         @ + ;
> > >>=20
> > >This is a classical example of inefficiency (like also the CONSTANT example=
> > > implemented with create does>). The field word will do @ + at RUNTIME even=
> > > if the offsets are well known at compile time, and this is a very common s=
> > >ituation!.
> > >
> > >There is a solution to this though. First, you need to delay literal compil=
> > >ing
> > >in order to have a chance to do constant folding (or any other mechanism)
> > >Second you need a smart + which should be immediate and perform a + if ther=
> > >e
> > >are at least two literals pending, or compile the + otherwise;
> > >And third, you need to make the defined word immediate.
> > >In this situation, when the field word is encountered, it is executed at co=
> > >mpile time (it is immediate). It performs @ fetching the offset value - ok,=
> > > the offset is always known at compile time. Then it performs the +. + sees=
> > > at least one literal on the stack - the offset just fetched. If it sees at=
> > > least one more literal (supposed to be based address) it adds them at comp=
> > >ile time, leaving the computed address on the stack. Otherwise it compiles =
> > >the + (this will trigger compiling first the offset as a literal).
> > >Simple :)
> > 
> > Not simple, and pretty wrong.  The fields defined by the word above are
> > not defined as immediate, and if you define them as immediate, they would
> > not do the required thing.
> 
> I think you don't understand. The scheme that I described works in my system 
> like a charm. Here it is my sources (sorry it is a forth dialect):
> 
> \ optimized macro words with constant folding
> [ state @ 0> ] def compiling?
> \ EVAL-XT-CF ( n -- ) constant folding level
> [ depth u>= compiling? and if compile, else execute then ] def eval-xt-cf
> [ -1 eval-xt-cf ] def eval-xt       \ no constant folding
> [  2 eval-xt-cf ] def eval-xt-cf1   \ constant folding 1 level
> [  3 eval-xt-cf ] def eval-xt-cf2   \ constant folding 2 levels
> [  4 eval-xt-cf ] def eval-xt-cf3   \ constant folding 3 levels
> 
> [ ' drop eval-xt-cf1 ] idef drop
> [ ' nip  eval-xt-cf2 ] idef nip
> [ ' swap eval-xt-cf2 ] idef swap
> [ ' rot  eval-xt-cf3 ] idef rot
> [ ' and  eval-xt-cf2 ] idef and
> [ ' or   eval-xt-cf2 ] idef or
> [ ' xor  eval-xt-cf2 ] idef xor
> [ ' -    eval-xt-cf2 ] idef -
> [ ' /    eval-xt-cf2 ] idef /
> 
> \ do not compile 0 +
> [ depth 2 < compiling? and if
>     depth 1 < if
>       ' + compile,
>     else \ depth is 1
>       dup if \ and x is not 0
>         ' + compile,
>       else drop then
>     then
>   else + then
> ] idef +
> 
> \ do not compile 1 *
> [ depth 2 < compiling? and if
>     depth 1 < if
>       ' * compile,
>     else \ depth is 1
>       dup 1 <> if \ and x is not 1
>         ' * compile,
>       else drop then
>     then
>   else * then
> ] idef *
> 
> \ FIELD ( "name" offset size -- offset+size ) name: ( x -- x+offset )
> [ [ @ compile + ] ibuild over , + ] def field
> 
> Some explanations:
> [ ] compiles anonymous code (I name them quotes). Can be nested. Top level 
> quote leaves it's address on the stack at compile time, nested quotes leave 
> their address on the stack at runtime.
> 
> def makes a dictionary entry
> idef makes an immediate dictionary entry
> buid builds a building word :) something like create does
> ibuild builds an immediate building word.
> state is in fact the nesting level of quotes, otherwise is like standard forth state.
> Another important thing which is internal and cannot be seen is that
> all literals are delayed in compiling (they stay on the data stack until
> either they are used by smart words like +, - etc, or are "flushed"
> on the compiled code by a normal word).

compile is used to compile immediate words if that is not clear. 
In the field definition, + is immediate so it is compiled by compile

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

#39440

On Friday, May 29, 2015 at 9:07:07 AM UTC-7, Anton Ertl wrote:
> Raimond Dragomir <raimond.dragomir@gmail.com> writes:
> >Simple :)
> 
> Not simple, and pretty wrong.  The fields defined by the word above are
> not defined as immediate, and if you define them as immediate, they would
> not do the required thing.
> 
> The problem with the definition above is that the body of the field
> can be changed later with >BODY !, so the best a compiler can do is to
> inline the DOES> part as
> 
> <addr> @ +
> 
> A simple, but somewhat unusual way to avoid this problem is to define
> this as
> 
> : +FIELD ( n1 n2 "<spaces>name" -- n3 )
>   over >r + 
>   : r> postpone literal postpone + postpone ;
> ;
> 
> (+FIELD is the Forth-2012 name of this word).

Nope, still not correct (you're not special-casing the first field, so you are compiling code to add zero).

I have the answer in my novice package (since 2009). 

BTW: I think it is quite humorous that you awkwardly work around the bug in ANS-Forth in which the control-flow stack is the same as the data-stack (your use of >R and R> above) --- but you refuse to just fix the problem in Forth-200x --- you aren't going to fix the problem until Leon Wagner gives you permission.

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

#39455

hughaguilar96@gmail.com writes:
>On Friday, May 29, 2015 at 9:07:07 AM UTC-7, Anton Ertl wrote:
>> A simple, but somewhat unusual way to avoid this problem is to define
>> this as
>>=20
>> : +FIELD ( n1 n2 "<spaces>name" -- n3 )
>>   over >r +=20
>>   : r> postpone literal postpone + postpone ;
>> ;
>>=20
>> (+FIELD is the Forth-2012 name of this word).
>
>Nope, still not correct (you're not special-casing the first field, so you =
>are compiling code to add zero).

On VFX Forth 4.71:
0 1 cells +field f3
see f3 
F3 
( 080BF340    C3 )                    NEXT,
( 1 bytes, 1 instructions )

But of course, if you don't want to rely on the sophistication of the
Forth system, you can special-case the n1=0 case.

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

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

#39439

On Friday, May 29, 2015 at 7:56:05 AM UTC-7, Raimond Dragomir wrote:
> > IIRC Stephen Pelc has  powerful C-like struct support in VFX, and these are very useful when interfacing to Windows etc.
> 
> C structs are powerful, the fields are associated with the object. In forth 
> you cannot have this, fields are global. Forth structs are not so powerful.
> 
> Maybe I'm missing something here and VFX found a way to implement C structs?

I doubt it that VFX or any other Forth implements C structs --- it is pretty much impossible in Forth because there is no way to know what data-type a pointer --- it might be possible to declare a data-type for a parameter and have a statically typed language, but you might as well just use C rather than Forth as rpn-C is pretty much what you are going to end up with.

> > Hugh Aguilar's Novice package provides this functionality :
> > 
> > : field ( offset size -- new-offset )           \ stream: name      
> >     create  
> >         over ,  +
> >     does> ( struct-adr base-adr -- field-adr )
> >         @ + ;
> > 
> This is a classical example of inefficiency (like also the CONSTANT example implemented with create does>). The field word will do @ + at RUNTIME even if the offsets are well known at compile time, and this is a very common situation!.

Yes, that is exactly the inefficiency problem that I described --- I don't know why we are going over this same point again and again --- I feel like Sisyphus, eternally pushing that stone up the hill only to have it roll down again...

> There is a solution to this though. First, you need to delay literal compiling
> in order to have a chance to do constant folding (or any other mechanism)
> Second you need a smart + which should be immediate and perform a + if there
> are at least two literals pending, or compile the + otherwise;
> And third, you need to make the defined word immediate.
> In this situation, when the field word is encountered, it is executed at compile time (it is immediate). It performs @ fetching the offset value - ok, the offset is always known at compile time. Then it performs the +. + sees at least one literal on the stack - the offset just fetched. If it sees at least one more literal (supposed to be based address) it adds them at compile time, leaving the computed address on the stack. Otherwise it compiles the + (this will trigger compiling first the offset as a literal).
> Simple :)

Nope, not correct.

I have the answer in my novice package (since 2009).

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

#39446

sâmbătă, 30 mai 2015, 05:19:37 UTC+3, hughag...@gmail.com a scris:
> On Friday, May 29, 2015 at 7:56:05 AM UTC-7, Raimond Dragomir wrote:
> > > IIRC Stephen Pelc has  powerful C-like struct support in VFX, and these are very useful when interfacing to Windows etc.
> > 
> > C structs are powerful, the fields are associated with the object. In forth 
> > you cannot have this, fields are global. Forth structs are not so powerful.
> > 
> > Maybe I'm missing something here and VFX found a way to implement C structs?
> 
> I doubt it that VFX or any other Forth implements C structs --- it is pretty much impossible in Forth because there is no way to know what data-type a pointer --- it might be possible to declare a data-type for a parameter and have a statically typed language, but you might as well just use C rather than Forth as rpn-C is pretty much what you are going to end up with.
> 
> > > Hugh Aguilar's Novice package provides this functionality :
> > > 
> > > : field ( offset size -- new-offset )           \ stream: name      
> > >     create  
> > >         over ,  +
> > >     does> ( struct-adr base-adr -- field-adr )
> > >         @ + ;
> > > 
> > This is a classical example of inefficiency (like also the CONSTANT example implemented with create does>). The field word will do @ + at RUNTIME even if the offsets are well known at compile time, and this is a very common situation!.
> 
> Yes, that is exactly the inefficiency problem that I described --- I don't know why we are going over this same point again and again --- I feel like Sisyphus, eternally pushing that stone up the hill only to have it roll down again...
> 
> > There is a solution to this though. First, you need to delay literal compiling
> > in order to have a chance to do constant folding (or any other mechanism)
> > Second you need a smart + which should be immediate and perform a + if there
> > are at least two literals pending, or compile the + otherwise;
> > And third, you need to make the defined word immediate.
> > In this situation, when the field word is encountered, it is executed at compile time (it is immediate). It performs @ fetching the offset value - ok, the offset is always known at compile time. Then it performs the +. + sees at least one literal on the stack - the offset just fetched. If it sees at least one more literal (supposed to be based address) it adds them at compile time, leaving the computed address on the stack. Otherwise it compiles the + (this will trigger compiling first the offset as a literal).
> > Simple :)
> 
> Nope, not correct.
> 
> I have the answer in my novice package (since 2009).

See above post, it's entirely correct.
I admit, you have the answer for ANS forth.
My system is not ANS maybe not forth at all - but I may say it's 90% forth 
though - enough for me :D

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

#39444

On Fri, 29 May 2015 10:56:04 -0400, Raimond Dragomir  
<raimond.dragomir@gmail.com> wrote:

>> IIRC Stephen Pelc has  powerful C-like struct support in VFX,
>> and these are very useful when interfacing to Windows etc.
>
> C structs are powerful,

...

> C structs are powerful, the fields are associated with the object.

You must specify the struct name and field in C to access the field.
That's true with both of the component selection operators in C:
'.' and '->'

So, what do you mean by "the fields are associated with the object?"

> In forth you cannot have this, fields are global.
> Forth structs are not so powerful.

In C, every data type, struct, union, maps onto an array of bytes.

So, in Forth, you're just accessing structs at the array level,
without the compiler computing offsets for you.


Rod Pemberton
-- 
If fewer guns reduced murders, how does one explain
Moscow, Chicago, New York, and South Africa?

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

#39445

> > C structs are powerful, the fields are associated with the object.
> 
> You must specify the struct name and field in C to access the field.
> That's true with both of the component selection operators in C:
> '.' and '->'
> 
> So, what do you mean by "the fields are associated with the object?"

No you don't specify the struct name, you specify the object name which happens to have the type of that struct.

struct mystruct1 { int x; int y; }
struct mystruct2 { int y; int x; }
struct mystruct1 obj1;
struct mystruct2 obj2;
obj1.x
obj2.x

Tell me how can you do that in Forth. The big problem is that first x has 
offset 0 and second x has offset of sizeof(int). Still, C has no problem in 
seeing this.

As Hugh says, in Forth it's just impossible. Probably you have to do this:

0 cell field mystruct1.x
  cell field mystruct1.y
constant mystruct1
0 cell field mystruct2.y
  cell field mystruct2.x
constant mystruct2
mystruct1 var obj1
mystruct2 var obj2

obj1 mystruct1.x @
obj2 mystruct2.x @

Not very fancy, more verbose and error prone.

This is a price that Forth has to pay for it's simplicity.

> 
> > In forth you cannot have this, fields are global.
> > Forth structs are not so powerful.
> 
> In C, every data type, struct, union, maps onto an array of bytes.
> 
> So, in Forth, you're just accessing structs at the array level,
> without the compiler computing offsets for you.
> 
> 
> Rod Pemberton
> -- 
> If fewer guns reduced murders, how does one explain
> Moscow, Chicago, New York, and South Africa?

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

#39450

on 30/05/2015 06:22:27, Raimond Dragomir wrote:
> Tell me how can you do that in Forth. The big problem is that first x
> has offset 0 and second x has offset of sizeof(int). Still, C has no
> problem in seeing this.
> 
> As Hugh says, in Forth it's just impossible. 

In Forth it's always possible. Consider using a wordlist as an object
container; then X in one can be distinct from the X in another. This is
how the NEON/MOPS object systems, an example of which is in Win32Forth,
provides scope for its private variables.

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

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

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

csiph-web