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

#39451

sâmbătă, 30 mai 2015, 11:27:45 UTC+3, Alex McDonald a scris:
> 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.

I don't known what NEON/MOPS is. Give me some examples in some commonly
used forths, Win32forth, gforth, VFX. Structures to use by a forth programmer
in a forth application.
As I said, maybe I'm behind regarding the latest technologies in forth.

All I have seen for gforth and win32forth were classical examples with
global field scopes and naming convention by appending the struct name
to the fields. This works fine for me but the whole point was how to
make the fields associated with the object.

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

#39452

on 30/05/2015 10:05:48, Raimond Dragomir wrote:
> sâmbata, 30 mai 2015, 11:27:45 UTC+3, Alex McDonald a scris:
>> 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.
> 
> I don't known what NEON/MOPS is. Give me some examples in some
> commonly used forths, Win32forth, gforth, VFX. Structures to use by a
> forth programm er
> in a forth application.
> As I said, maybe I'm behind regarding the latest technologies in
> forth.
> 
> All I have seen for gforth and win32forth were classical examples with
> global field scopes and naming convention by appending the struct name
> to the fields. This works fine for me but the whole point was how to
> make the fields associated with the object.
> 

http://www.bradrodriguez.com/papers/oofs.htm
http://www.complang.tuwien.ac.at/forth/objects/objects.html
http://bernd-paysan.de/mini-oof.html

and so on.

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

#39453

sâmbătă, 30 mai 2015, 12:21:24 UTC+3, Alex McDonald a scris:
> on 30/05/2015 10:05:48, Raimond Dragomir wrote:
> > sâmbata, 30 mai 2015, 11:27:45 UTC+3, Alex McDonald a scris:
> >> 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.
> > 
> > I don't known what NEON/MOPS is. Give me some examples in some
> > commonly used forths, Win32forth, gforth, VFX. Structures to use by a
> > forth programm er
> > in a forth application.
> > As I said, maybe I'm behind regarding the latest technologies in
> > forth.
> > 
> > All I have seen for gforth and win32forth were classical examples with
> > global field scopes and naming convention by appending the struct name
> > to the fields. This works fine for me but the whole point was how to
> > make the fields associated with the object.
> > 
> 
> http://www.bradrodriguez.com/papers/oofs.htm
> http://www.complang.tuwien.ac.at/forth/objects/objects.html
> http://bernd-paysan.de/mini-oof.html
> 
> and so on.

You cannot convince me like this.
Let me give you another example:

struct mystruct
  field x
  field y
endstruct

mystruct obj1
variable x

: foo   obj1 x @ x @ + ;

Do you think the above foo is working?
Suppose mystruct created an wordlist for the fields, and the fields are
put in this wordlist.
obj1 may put the mystruct wordlist on top of the search order.
Who is taking it back from the search order?
The second x has this problem. Who is x? the variable or the x field?


This in C should be something like return obj1.x + x;

How can you do that in Forth?
Not to say that if you must pass object pointers on the data stack, you loose
any type information that a clever implementation may carry.

I say that in Forth it's impossible because this behaviour is strong
related to a typing system. And Forth is an untyped language.

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

#39459

On Saturday, May 30, 2015 at 4:08:47 AM UTC-7, Raimond Dragomir wrote:
> sâmbătă, 30 mai 2015, 12:21:24 UTC+3, Alex McDonald a scris:
> > on 30/05/2015 10:05:48, Raimond Dragomir wrote:
> > > sâmbata, 30 mai 2015, 11:27:45 UTC+3, Alex McDonald a scris:
> > >> 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.
> > > 
> > > I don't known what NEON/MOPS is. Give me some examples in some
> > > commonly used forths, Win32forth, gforth, VFX. Structures to use by a
> > > forth programm er
> > > in a forth application.
> > > As I said, maybe I'm behind regarding the latest technologies in
> > > forth.
> > > 
> > > All I have seen for gforth and win32forth were classical examples with
> > > global field scopes and naming convention by appending the struct name
> > > to the fields. This works fine for me but the whole point was how to
> > > make the fields associated with the object.
> > > 
> > 
> > http://www.bradrodriguez.com/papers/oofs.htm
> > http://www.complang.tuwien.ac.at/forth/objects/objects.html
> > http://bernd-paysan.de/mini-oof.html
> > 
> > and so on.
> 
> You cannot convince me like this.

I don't recommend polymorphism in Forth --- if this is what you want, then just program in C++ or some such language (Forth isn't for every program or for every programmer).

In my novice package I have inheritance --- this is the only aspect of OOP that I consider worthwhile for Forth.

> Let me give you another example:
> 
> struct mystruct
>   field x
>   field y
> endstruct
> 
> mystruct obj1
> variable x
> 
> : foo   obj1 x @ x @ + ;
> 
> Do you think the above foo is working?
> Suppose mystruct created an wordlist for the fields, and the fields are
> put in this wordlist.
> obj1 may put the mystruct wordlist on top of the search order.
> Who is taking it back from the search order?
> The second x has this problem. Who is x? the variable or the x field?
> 
> 
> This in C should be something like return obj1.x + x;
> 
> How can you do that in Forth?
> Not to say that if you must pass object pointers on the data stack, you loose
> any type information that a clever implementation may carry.
> 
> I say that in Forth it's impossible because this behaviour is strong
> related to a typing system. And Forth is an untyped language.

Well, this is mostly a naming-convention issue.

For one thing, I recommend the dot prefix for field names. In the novice-package style, you could have this (my example is a child of LIST whereas your example didn't have a parent function):

list   \ name of parent class you are inheriting from, or 0 if there is no parent class
    field .x
    field .y
constant point   \ name of this class

: init-point ( x y node -- node )
    init-list >r  \ the >R of the node is my convention (don't use stack jugglers)
    r@ .y !
    r@ .x !
    r> ;

: new-point ( x y -- node )
    point alloc
    init-point ;

variable x

: foo ( obj1 -- adjusted-x )
    .x @  x @ + ;

If you use this naming convention, you can avoid name clashes between field names and global variables etc.. The only problem remaining is if you have several structs with the same field names. This doesn't usually happen, as most programs don't have very many different data types, and what they do have are all in the same inheritance chain. If they are in the same inheritance chain then they are going to clash anyway --- I don't remember how C++ resolves field name clashes between a child class and a parent class --- this is really just something to be avoided!

If you have so many classes of data that you can't avoid field name clashes, then you can use this naming convention:

list   \ name of parent class you are inheriting from, or 0 if there is no parent class
    field point.x
    field point.y
constant point   \ name of this class

: init-point ( x y node -- node )
    init-list >r  \ the >R of the node is my convention
    r@ point.y !
    r@ point.x !
    r> ;

: new-point ( x y -- node )
    point alloc
    init-point ;

variable x

: foo ( obj1 -- adjusted-x )
    point.x @  x @ + ;

This should give you all of the capability that you would have in C --- the source-code becomes somewhat bloated though --- I only recommend this naming convention in gigantic complicated programs in which the simple naming convention is inadequate.

Getting back to the subject of inheritance, our POINT struct inherited the fields of the LIST struct, so all of the LIST method functions (such as EACH and FIND-NODE etc.) will work with a list of POINT structs. It is possible to define child structs of POINT too. Using the simple naming-convention, we have:

point
    field .r
    field .area
constant circle

: init-circle ( radius x y node -- node )
    init-point >r
    dup                r@ .r !
    dup *  355 113 */  r@ .area !
    r> ;

: new-circle ( radius x y -- node )
    circle alloc
    init-circle ;

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

#39462

> I don't recommend polymorphism in Forth --- if this is what you want, then just program in C++ or some such language (Forth isn't for every program or for every programmer).
> 
Hugh, I'm using the same structs as you do (in fact there's only the word FIELD)
This is so simple and elegant that I really don't understand why it was not standardized years before (in the tentative 20xy standard there is an
obfuscated version of structures IMO).

I only responded here to a post whith "powerfull C like structs in VFX".
I pointed out that the forth structs are not so powerfull like the C ones.
This is just a fact. Every language has pluses and minuses.
And it seems that it is not me who is trying hard to make the forth 
look like C. Alex McDonald gave a lot of links here.

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

#39466

On Saturday, May 30, 2015 at 9:42:38 AM UTC-7, Raimond Dragomir wrote:
> > I don't recommend polymorphism in Forth --- if this is what you want, then just program in C++ or some such language (Forth isn't for every program or for every programmer).
> > 
> Hugh, I'm using the same structs as you do (in fact there's only the word FIELD)

What do STRUCT and ENDSTRUCT do? I have never seen those before. We need to have the size stored somewhere, which is what my CONSTANT does.

> This is so simple and elegant that I really don't understand why it was not standardized years before (in the tentative 20xy standard there is an
> obfuscated version of structures IMO).

The FIELD word has been in use since the 1980s --- now Forth-200x has changed the name to +FIELD for some unknown reason (afaik, it is Stephen Pelc's version that was written differently from my FIELD in the novice package but does the same thing).

We have used { to declare locals since the 1980s, but now Forth-200x changed the name to {: because SwiftForth uses { for multi-line comments. Presumably FIELD was changed to +FIELD because SwiftForth uses FIELD for some obscure purpose --- maybe Elizabeth Rather wrote an application program that enumerates a farmer's bean fields and this is why FIELD can't be standardized for struct field definitions --- no; that is impossible: Elizabeth Rather has never written a program in her life...

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

#39477

sâmbătă, 30 mai 2015, 20:25:52 UTC+3, hughag...@gmail.com a scris:
> On Saturday, May 30, 2015 at 9:42:38 AM UTC-7, Raimond Dragomir wrote:
> > > I don't recommend polymorphism in Forth --- if this is what you want, then just program in C++ or some such language (Forth isn't for every program or for every programmer).
> > > 
> > Hugh, I'm using the same structs as you do (in fact there's only the word FIELD)
> 
> What do STRUCT and ENDSTRUCT do? I have never seen those before. We need to have the size stored somewhere, which is what my CONSTANT does.
> 

This was some pseudo code in trying to "implement" Alex's idea of using
wordlists for storing field names. STRUCT was necessary for creating
the wordlist in which the following fields would be put. ENDSTRUCT was
necessary to terminate the struct/field definitions. As I pointed out,
there is a big problem though, if the struct object word put its wordlist
on top of the search order (to make the fields visible) who is supposed to
take it back from the search order? And I gave an example of a variable x
which happen to have the same name as the struct's field x. In that scenario
obj1 x @ works as expected, because obj1 bring the wordlist that has x
defined as the field for the obj1's structure, but the second x @ doesn't
work, because the struct's wordlist is still on top of the search order
and shaddows the plain variable x. 

There might be a possibility here: that the wordlist to be taken out by 
the field word. This also is not working all the times: what if you want
only the object address? in this case you don't use a field after the object
name and oops, the wordlist is still remaining on the top of the search order...

No, I don't use such words. I used plain FIELD and terminate the struct
sometimes with constant but often with just a drop because I need only
the offsets to an existing object (like dictionary entry). Here is for
example my WORDS implemented in high level forth, along with the dictionary
offsets:

\ dictionary offsets
0 cell field dict->link
  cell field dict->addr
  cell field dict->end
  cell field dict->file
  cell field dict->line
  cell field dict->wid
  cell field dict->type
  cell field dict->len
  cell field dict->name
drop
 1 constant DF_NORMAL   \ reserved code for SEARCH
 2 constant DF_IMMED    \ dictionary flag immediate bit
 4 constant DF_ROM      \ dictionary flag ROM bit
 8 constant DF_RAM      \ dictionary flag RAM bit
16 constant DF_DEFER    \ dictionary flag DEFER bit
DF_ROM DF_RAM or constant DF_DATA

\ WID. ( wid -- ) display wid header
[ cr ." *** WID " . ." ***" cr ] def wid.
\ NAME. ( nt -- ) display word name
[ dup dict->name @ swap dict->len @ type space ] def name.

[ get-order \ widn ... wid1 n
  [| wid | wid wid.
    [ ( nt ) name. true ] wid traverse-wordlist
  ] times
] def words ( -- )

[ get-order \ widn ... wid1 n
  [| wid | wid wid.
    [| nt |
      nt dict->type @ DF_IMMED and if nt name. then
      true
    ] wid traverse-wordlist
  ] times
] def iwords ( -- ) \ display only immediate words

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

#39487

On Saturday, May 30, 2015 at 10:36:46 PM UTC-7, Raimond Dragomir wrote:
> sâmbătă, 30 mai 2015, 20:25:52 UTC+3, hughag...@gmail.com a scris:
> > What do STRUCT and ENDSTRUCT do? I have never seen those before. We need to have the size stored somewhere, which is what my CONSTANT does.
> 
> This was some pseudo code in trying to "implement" Alex's idea of using
> wordlists for storing field names. STRUCT was necessary for creating
> the wordlist in which the following fields would be put. ENDSTRUCT was
> necessary to terminate the struct/field definitions. As I pointed out,
> there is a big problem though, if the struct object word put its wordlist
> on top of the search order (to make the fields visible) who is supposed to
> take it back from the search order? 

In the Oberon-2 language, we had WITH blocks:
http://en.wikipedia.org/wiki/Oberon-2_(programming_language)#WITH_statement
In a Forth OOP system, I suppose something similar would be needed. The result is ugly bloated code.

As I said before, if people want OOP they should just program in an OOP language such as C++ or Object Pascal (very similar to Oberon-2) or some such thing.

For the most part, I think of Forth as being a micro-controller language --- trying to contort Forth to compete with desktop-computer programming languages is a waste of time.

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

#39478

on 30/05/2015 12:08:47, Raimond Dragomir wrote:
> sâmbata, 30 mai 2015, 12:21:24 UTC+3, Alex McDonald a scris:
>> on 30/05/2015 10:05:48, Raimond Dragomir wrote:
>> > sâmbata, 30 mai 2015, 11:27:45 UTC+3, Alex McDonald a scris:
>> >> 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 i
> s
>> >> how the NEON/MOPS object systems, an example of which is in Win32Forth
> ,
>> >> provides scope for its private variables.
>> >
>> > I don't known what NEON/MOPS is. Give me some examples in some
>> > commonly used forths, Win32forth, gforth, VFX. Structures to use by a
>> > forth programm er
>> > in a forth application.
>> > As I said, maybe I'm behind regarding the latest technologies in
>> > forth.
>> >
>> > All I have seen for gforth and win32forth were classical examples with
>> > global field scopes and naming convention by appending the struct name
>> > to the fields. This works fine for me but the whole point was how to
>> > make the fields associated with the object.
>> >
>>
>> http://www.bradrodriguez.com/papers/oofs.htm> http://www.complang.tuwien.ac.at/forth/objects/objects.html> http://bernd-paysan.de/mini-oof.html>
>> and so on.
> 
> You cannot convince me like this.

I can't do your research or thinking for you either.

> Let me give you another example:
> 
> struct mystruct
> field x
> field y
> endstruct
> 
> mystruct obj1
> variable x
> 
>: foo   obj1 x @ x @ + ;
> 
> Do you think the above foo is working?
> Suppose mystruct created an wordlist for the fields, and the fields
> are put in this wordlist.
> obj1 may put the mystruct wordlist on top of the search order.
> Who is taking it back from the search order?
> The second x has this problem. Who is x? the variable or the x field?
> 
> 
> This in C should be something like return obj1.x + x;
> 
> How can you do that in Forth?
> Not to say that if you must pass object pointers on the data stack,
> you loo se
> any type information that a clever implementation may carry.
> 
> I say that in Forth it's impossible because this behaviour is strong
> related to a typing system. And Forth is an untyped language.

The behaviour is related to no more than what structures and objects
derived from them do; either at compile time, run time or both. Typing
has nothing to do with it.

struct point
  field x
  field y
end-struct
point x
x :[ 3 x ! 2 y ! ]:
x :[ x @ y @ ]:
 
X is the structure based on POINT, :[ places POINT's wordlist in the
search order, X and Y do what the field X and field Y for POINT
structures do -- applied to the structure X -- and :] removes POINT's
wordlist from the search order. Yes, it's messy since I have done no more
than illustrate a solution, but you should get the idea.

(An aside. With recognizers we could have for example MYPOINT::X (early
binding) or MYPOINT ::X (late binding) and a much simpler parse.)

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

#39482

On Saturday, May 30, 2015 at 2:08:47 PM UTC+3, Raimond Dragomir wrote:
> sâmbătă, 30 mai 2015, 12:21:24 UTC+3, Alex McDonald a scris:
> > on 30/05/2015 10:05:48, Raimond Dragomir wrote:
> > > sâmbata, 30 mai 2015, 11:27:45 UTC+3, Alex McDonald a scris:
> > >> 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.
> > > 
> > > I don't known what NEON/MOPS is. Give me some examples in some
> > > commonly used forths, Win32forth, gforth, VFX. Structures to use by a
> > > forth programm er
> > > in a forth application.
> > > As I said, maybe I'm behind regarding the latest technologies in
> > > forth.
> > > 
> > > All I have seen for gforth and win32forth were classical examples with
> > > global field scopes and naming convention by appending the struct name
> > > to the fields. This works fine for me but the whole point was how to
> > > make the fields associated with the object.
> > > 
> > 
> > http://www.bradrodriguez.com/papers/oofs.htm
> > http://www.complang.tuwien.ac.at/forth/objects/objects.html
> > http://bernd-paysan.de/mini-oof.html
> > 
> > and so on.
> 
> You cannot convince me like this.
> Let me give you another example:
> 
> struct mystruct
>   field x
>   field y
> endstruct
> 
> mystruct obj1
> variable x
> 
> : foo   obj1 x @ x @ + ;
> 
> Do you think the above foo is working?
> Suppose mystruct created an wordlist for the fields, and the fields are
> put in this wordlist.
> obj1 may put the mystruct wordlist on top of the search order.
> Who is taking it back from the search order?
> The second x has this problem. Who is x? the variable or the x field?
> 
> 
> This in C should be something like return obj1.x + x;
> 
> How can you do that in Forth?
> Not to say that if you must pass object pointers on the data stack, you loose
> any type information that a clever implementation may carry.
> 
> I say that in Forth it's impossible because this behaviour is strong
> related to a typing system. And Forth is an untyped language.


Hi!

That is how I would do it in forth. It has reflection and could
be modified to have extensions for structure (excerpt from command-line):

$ gforth -e "include struct.fs"

\ Structure with reflection. To do: extensions.

: make-show-words
        CREATE get-current , DOES> @ wordlist-words ;

warnings OFF
: field                 ( offs size -- offs+size )
        over >R
        : R> ?dup
                IF
                        S>D <# [CHAR] + hold BL hold #S #>
                        postpone SLITERAL postpone EVALUATE
                THEN
        postpone ; IMMEDIATE +
;
: struct
        get-current wordlist dup
        CREATE , base @ , IMMEDIATE set-current 0       ( old-wid 0 )
  DOES>  
        Base @ >R dup cell+ @ Base !
        @ >order parse-name ['] evaluate
                CATCH
        previous R> Base !
                THROW
;
: end-struct            ( old-wid size -- )
        S" CONSTANT SIZEOF" evaluate
        S" make-show-words WORDS" evaluate
        set-current
;
warnings ON

-1 [IF] sh cat struct.fs
struct POS
  cell field X
  cell field Y
end-struct
." POS constituents: " POS WORDS
        VARIABLE X      1 X !
CREATE Ob POS SIZEOF allot
 99 Ob POS X !
101 Ob POS Y !
: testX Ob POS X ? X ? ;
: testY [ Ob POS Y ]L ? X ? ;
see testX see testY
cr testX cr testY
cr .s cr bye
[THEN]

POS constituents: 
WORDS SIZEOF Y X 
: testX  
  Ob ? X ? ;
: testY  
  34389371344 ? X ? ;
99 1 
101 1 
<0> 
$

Could C version have reflection?

Have a nice day,
humptudumpty

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

#39500

humptydumpty <ouatubi@gmail.com> writes:
>: field                 ( offs size -- offs+size )
>        over >R
>        : R> ?dup
>                IF
>                        S>D <# [CHAR] + hold BL hold #S #>
>                        postpone SLITERAL postpone EVALUATE
>                THEN
>        postpone ; IMMEDIATE +
>;

A very nice example of the dangers of EVALUATE-based macros.

decimal 
9 cells 1 cells field x drop
hex 0 x 9 cells = .

prints 0.  The following implementation is both correct and simpler
(and optimizes the 0 offset case):

: +FIELD {: n1 n2 -- n3 :}
  : n1 if 
    n1 postpone literal postpone +
  else
     immediate
  then 
  postpone ; n1 n2 + ;
  
- 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]

#39502

On Monday, June 1, 2015 at 4:37:30 PM UTC+3, Anton Ertl wrote:
> humptydumpty <> writes:
> >: field                 ( offs size -- offs+size )
> >        over >R
> >        : R> ?dup
> >                IF
> >                        S>D <# [CHAR] + hold BL hold #S #>
> >                        postpone SLITERAL postpone EVALUATE
> >                THEN
> >        postpone ; IMMEDIATE +
> >;
> 
> A very nice example of the dangers of EVALUATE-based macros.
> 
> decimal 
> 9 cells 1 cells field x drop
> hex 0 x 9 cells = .
> 
> prints 0.  The following implementation is both correct and simpler
> (and optimizes the 0 offset case):
> 
> : +FIELD {: n1 n2 -- n3 :}
>   : n1 if 
>     n1 postpone literal postpone +
>   else
>      immediate
>   then 
>   postpone ; n1 n2 + ;
>   
> - 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

Hi!

No way! 'field' word is supposed to work inside the scope of the
word created by 'struct'.

I wrote it to be used as whole, not disparaged parts.

Have a nice day,
humptydumpty

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

#39505

luni, 1 iunie 2015, 16:37:30 UTC+3, Anton Ertl a scris:
> humptydumpty <> writes:
> >: field                 ( offs size -- offs+size )
> >        over >R
> >        : R> ?dup
> >                IF
> >                        S>D <# [CHAR] + hold BL hold #S #>
> >                        postpone SLITERAL postpone EVALUATE
> >                THEN
> >        postpone ; IMMEDIATE +
> >;
> 
> A very nice example of the dangers of EVALUATE-based macros.
> 
> decimal 
> 9 cells 1 cells field x drop
> hex 0 x 9 cells = .
> 
> prints 0.  The following implementation is both correct and simpler
> (and optimizes the 0 offset case):
> 
> : +FIELD {: n1 n2 -- n3 :}
>   : n1 if 
>     n1 postpone literal postpone +
>   else
>      immediate
>   then 
>   postpone ; n1 n2 + ;
>   
> - 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

Hi!

'field' word must be used inside the scope of the word
 created by 'struct'.  Package should be used as a whole, not by parts.

As a negative aspect, 'field+' could be used only at compile-time.

I deleted previous post because of poor chosen words for message.
I'm sorry for that.

Have a nice day,
humptydumpty

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

#39513

On Monday, June 1, 2015 at 4:37:30 PM UTC+3, Anton Ertl wrote:
> humptydumpty <> writes:
> >: field                 ( offs size -- offs+size )
> >        over >R
> >        : R> ?dup
> >                IF
> >                        S>D <# [CHAR] + hold BL hold #S #>
> >                        postpone SLITERAL postpone EVALUATE
> >                THEN
> >        postpone ; IMMEDIATE +
> >;
> 
> A very nice example of the dangers of EVALUATE-based macros.
> 
> decimal 
> 9 cells 1 cells field x drop
> hex 0 x 9 cells = .
> 
> prints 0.  The following implementation is both correct and simpler
> (and optimizes the 0 offset case):
> 
> : +FIELD {: n1 n2 -- n3 :}
>   : n1 if 
>     n1 postpone literal postpone +
>   else
>      immediate
>   then 
>   postpone ; n1 n2 + ;
>   
> - 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

Hi!

They do different things (excerpt from command-line):
---
$ gforth -e "include plusfieldtest.fs"
redefined +field with +FIELD  
: +FIELD { n1 n2 -- n3 }
  : n1 if
    n1 postpone literal postpone +
  else
     immediate
  then
  postpone ; n1 n2 + ;

sh cat plusfieldtest.fs

0
cell +field X
cell +field Y
constant /POS

CREATE Ob 99 , 101 ,

: testX Ob X ? ;
: testY [ Ob Y ]L ? ;
: 2testY Ob Y ? ;

see testX   see testY   see 2testY
cr testX testY 2testY

cr .s cr bye

: testX  
  Ob ? ;
: testY  
  34389370120 ? ;
: 2testY  
  Ob Y ? ;
99 101 101 
<0> 
$
$ gforth -e "include mystructtest.fs"

include struct.fs
sh cat mystructtest.fs
4 Base !        \ Just a test for independence of Base content
struct POS
  cell field X
  cell field Y
end-struct
DECIMAL

CREATE Ob POS SIZEOF allot

 99 Ob POS X !
101 Ob POS Y !

: testX Ob POS X ? ;
: testY [ Ob POS Y ]L ? ;
: 2testY Ob POS Y ? ;

see testX   see testY   see 2testY
cr testX testY 2testY

cr .s cr bye

: testX  
  Ob ? ;
: testY  
  34389371624 ? ;
: 2testY  
  Ob 8 + ? ;
99 101 101 
<0> 
$
---

in '+field' version 'see 2testY' shows:
: 2testY  
  Ob Y ? ;

in my struct version 'see 2testY' shows:
: 2testY  
  Ob 8 + ? ;

and also show independence of 'Base' content.

Have a nice day,
humptydumpty 

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

#39516 — Field name overloading (was: ColorForth - another dead end?)

humptydumpty <ouatubi@gmail.com> writes:
>in '+field' version 'see 2testY' shows:
>: 2testY  
>  Ob Y ? ;
>
>in my struct version 'see 2testY' shows:
>: 2testY  
>  Ob 8 + ? ;

And SEE Y shows

: Y  
  8 + ; ok

The behaviour is the same, but admittedly the run-time is slower on
Forth systems that don't inline automatically.

>and also show independence of 'Base' content.

Yes, I took a closer look at your STRUCT and the usage patterns, and
found that you have integrated a workaround for the BASE problem.  An
alternative would be to use a number prefix to make the string BASE
independent.

What is still missing is a workaround that guarantees that the right
"+" will be found.  Counterexample for the current implementation:

struct POS
  cell field X
  cell field Y
end-struct

: + cr ." funny +" cr ;

CREATE Ob POS SIZEOF allot
Ob POS Y .s

After fixing this the result is certainly an interesting solution to
the field (and method?) name overloading resulution problem in the
context of the current standard (you would need to get rid of some
Gforthisms, but that should be possible). The interesting part is in
STRUCT and would work also with the +FIELD I defined (but, as seen
above, there is a difference in inlining).

That problem has led to defining words for STATE-smart words in Bernd
Paysan's OOF and AFAIK other programs.  Other proposed solutions to
the problem go outside the standard: preludes and the dot-parser (the
latter implemented with recognizers).  I think it's cleaner than a
STATE-smart approach.

What you cannot do with it directly is ticking and postponing POS Y,
but you can define

: pos-y POS Y ;

and tick or postpone that.  However, why not just define POS-Y without
overloading right from the start?  Always writing POS Y instead of
POS-Y is not an advantage.

One possible advantage is in the context of inheritance: If you have a
class A with field X and class B and C inherit field X from A, you
don't want to refer to the field with A-X (because that would make
reorganizing the class hierarchy hard); referring to the field with
A X or B X or C X would be possible with a variation of your
technique, and would restrict class reorganizations only as necessary.

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

#39529 — Re: Field name overloading (was: ColorForth - another dead end?)

marți, 2 iunie 2015, 13:42:31 UTC+3, Anton Ertl a scris:
> humptydumpty <> writes:
> >in '+field' version 'see 2testY' shows:
> >: 2testY  
> >  Ob Y ? ;
> >
> >in my struct version 'see 2testY' shows:
> >: 2testY  
> >  Ob 8 + ? ;
> 
> And SEE Y shows
> 
> : Y  
>   8 + ; ok
> 
> The behaviour is the same, but admittedly the run-time is slower on
> Forth systems that don't inline automatically.
> 
> >and also show independence of 'Base' content.
> 
> Yes, I took a closer look at your STRUCT and the usage patterns, and
> found that you have integrated a workaround for the BASE problem.  An
> alternative would be to use a number prefix to make the string BASE
> independent.
> 
> What is still missing is a workaround that guarantees that the right
> "+" will be found.  Counterexample for the current implementation:
> 
> struct POS
>   cell field X
>   cell field Y
> end-struct
> 
> : + cr ." funny +" cr ;
> 
> CREATE Ob POS SIZEOF allot
> Ob POS Y .s
> 
> After fixing this the result is certainly an interesting solution to
> the field (and method?) name overloading resulution problem in the
> context of the current standard (you would need to get rid of some
> Gforthisms, but that should be possible). The interesting part is in
> STRUCT and would work also with the +FIELD I defined (but, as seen
> above, there is a difference in inlining).
> 
> That problem has led to defining words for STATE-smart words in Bernd
> Paysan's OOF and AFAIK other programs.  Other proposed solutions to
> the problem go outside the standard: preludes and the dot-parser (the
> latter implemented with recognizers).  I think it's cleaner than a
> STATE-smart approach.
> 
> What you cannot do with it directly is ticking and postponing POS Y,
> but you can define
> 
> : pos-y POS Y ;
> 
> and tick or postpone that.  However, why not just define POS-Y without
> overloading right from the start?  Always writing POS Y instead of
> POS-Y is not an advantage.
> 
> One possible advantage is in the context of inheritance: If you have a
> class A with field X and class B and C inherit field X from A, you
> don't want to refer to the field with A-X (because that would make
> reorganizing the class hierarchy hard); referring to the field with
> A X or B X or C X would be possible with a variation of your
> technique, and would restrict class reorganizations only as necessary.
> 
> - 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

Hi!

A cure for improbable but possible redefinition of '+'
could be:

---
\ Add on top of source
VOCABULARY UNTAINTED
get-current ALSO UNTAINTED DEFINITIONS
    ' + alias +
set-current PREVIOUS

\ Redefine 'struct' as:
: struct
	get-current wordlist
	dup CREATE , base @ , IMMEDIATE set-current 0	( old-wid 0 )
	( Now compile fields in structure-wordlist )
  DOES>
	Base @ >R
	dup cell+ @ Base !
	@ >order ALSO UNTAINTED
	  	 parse-name ['] evaluate
		CATCH
	PREVIOUS previous R> Base !
		THROW
;
---

About syntax, this way I read 'Ob POS Y':
From address 'Ob' using recipe 'POS' get address of meaning 'Y'.

That that I could use other recipe for address 'Ob' is another story.

If I extend 'POS' structure with field 'COLOR', and alias old structure
with name 'PIXEL'  I could have a sort of inheritance..

I think that shortly I'll post a new version of structure-lexicon.

Have a nice day,
humptydumpty

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

#39503

On Sunday, May 31, 2015 at 9:31:41 PM UTC+3, humptydumpty wrote:
> On Saturday, May 30, 2015 at 2:08:47 PM UTC+3, Raimond Dragomir wrote:
> > sâmbătă, 30 mai 2015, 12:21:24 UTC+3, Alex McDonald a scris:
> > > on 30/05/2015 10:05:48, Raimond Dragomir wrote:
> > > > sâmbata, 30 mai 2015, 11:27:45 UTC+3, Alex McDonald a scris:
> > > >> 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.
> > > > 
> > > > I don't known what NEON/MOPS is. Give me some examples in some
> > > > commonly used forths, Win32forth, gforth, VFX. Structures to use by a
> > > > forth programm er
> > > > in a forth application.
> > > > As I said, maybe I'm behind regarding the latest technologies in
> > > > forth.
> > > > 
> > > > All I have seen for gforth and win32forth were classical examples with
> > > > global field scopes and naming convention by appending the struct name
> > > > to the fields. This works fine for me but the whole point was how to
> > > > make the fields associated with the object.
> > > > 
> > > 
> > > http://www.bradrodriguez.com/papers/oofs.htm
> > > http://www.complang.tuwien.ac.at/forth/objects/objects.html
> > > http://bernd-paysan.de/mini-oof.html
> > > 
> > > and so on.
> > 
> > You cannot convince me like this.
> > Let me give you another example:
> > 
> > struct mystruct
> >   field x
> >   field y
> > endstruct
> > 
> > mystruct obj1
> > variable x
> > 
> > : foo   obj1 x @ x @ + ;
> > 
> > Do you think the above foo is working?
> > Suppose mystruct created an wordlist for the fields, and the fields are
> > put in this wordlist.
> > obj1 may put the mystruct wordlist on top of the search order.
> > Who is taking it back from the search order?
> > The second x has this problem. Who is x? the variable or the x field?
> > 
> > 
> > This in C should be something like return obj1.x + x;
> > 
> > How can you do that in Forth?
> > Not to say that if you must pass object pointers on the data stack, you loose
> > any type information that a clever implementation may carry.
> > 
> > I say that in Forth it's impossible because this behaviour is strong
> > related to a typing system. And Forth is an untyped language.
> 
> 
> Hi!
> 
> That is how I would do it in forth. It has reflection and could
> be modified to have extensions for structure (excerpt from command-line):
> 
> $ gforth -e "include struct.fs"
> 
> \ Structure with reflection. To do: extensions.
> 
> : make-show-words
>         CREATE get-current , DOES> @ wordlist-words ;
> 
> warnings OFF
> : field                 ( offs size -- offs+size )
>         over >R
>         : R> ?dup
>                 IF
>                         S>D <# [CHAR] + hold BL hold #S #>
>                         postpone SLITERAL postpone EVALUATE
>                 THEN
>         postpone ; IMMEDIATE +
> ;
> : struct
>         get-current wordlist dup
>         CREATE , base @ , IMMEDIATE set-current 0       ( old-wid 0 )
>   DOES>  
>         Base @ >R dup cell+ @ Base !
>         @ >order parse-name ['] evaluate
>                 CATCH
>         previous R> Base !
>                 THROW
> ;
> : end-struct            ( old-wid size -- )
>         S" CONSTANT SIZEOF" evaluate
>         S" make-show-words WORDS" evaluate
>         set-current
> ;
> warnings ON
> 
> -1 [IF] sh cat struct.fs
> struct POS
>   cell field X
>   cell field Y
> end-struct
> ." POS constituents: " POS WORDS
>         VARIABLE X      1 X !
> CREATE Ob POS SIZEOF allot
>  99 Ob POS X !
> 101 Ob POS Y !
> : testX Ob POS X ? X ? ;
> : testY [ Ob POS Y ]L ? X ? ;
> see testX see testY
> cr testX cr testY
> cr .s cr bye
> [THEN]
> 
> POS constituents: 
> WORDS SIZEOF Y X 
> : testX  
>   Ob ? X ? ;
> : testY  
>   34389371344 ? X ? ;
> 99 1 
> 101 1 
> <0> 
> $
> 
> Could C version have reflection?
> 
> Have a nice day,
> humptudumpty

Hi!

My correction: please substitute 'reflection' with 'inspection'
in my post above.

Thanks,
humptydumpty

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

#39469

On Sat, 30 May 2015 01:22:27 -0400, Raimond Dragomir  
<raimond.dragomir@gmail.com> wrote:

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

I understand what you're saying.

FYI, I refer to mystruct1, mystruct2 as the type of the struct, whereas
obj1, obj2 are the names of the structs.

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

You're familiar with the offsetof() macro for C, yes?

I.e., every C compiler must have one or it's equivalent.
It's usually coded similarly to this:

#define offsetof(s,e) ((int)((char *)&((s *)0)->e-(char *)0))

That casts NULL, represented syntactically as '0' here, to a
pointer to the start of 's' which is used to index 'e'.  The
address of s->e is taken which is relative to NULL and subtracts
NULL the start of the struct to provide the offset of 'e'
relative to the start of the struct.

AIUI, Forth usually creates a bunch of custom words for each
array for each offset.  Those are like offsetof() which have
hardcoded offset value for 'e'.  In C, all objects are mapped
onto an array of bytes.  So, we can use arrays for structs
in Forth, like C, and build up C like functionality from there.

E.g., these take an address for the start of the struct:

: OBJ1 ( a -- a+n ) 0 CELLS + ;
: OBJ2 ( a -- a+n ) 1 CELLS + ;

CREATE MYSTRUCT1 2 CELLS ALLOT
CREATE MYSTRUCT2 2 CELLS ALLOT

MYSTRUCT1 OBJ1 @
MYSTRUCT1 OBJ2 @
MYSTRUCT2 OBJ1 @
MYSTRUCT2 OBJ2 @

Of course, you could put the @ in offset definitions:

: OBJ1 ( a -- i ) 0 CELLS + @ ;
: OBJ2 ( a -- i ) 1 CELLS + @ ;

CREATE MYSTRUCT1 2 CELLS ALLOT
CREATE MYSTRUCT2 2 CELLS ALLOT

MYSTRUCT1 OBJ1
MYSTRUCT1 OBJ2
MYSTRUCT2 OBJ1
MYSTRUCT2 OBJ2

Of course, you can define those to be their own words:

: MYSTRUCTS1.OBJ1 MYSTRUCTS1 OBJ1 ;
: MYSTRUCTS1.OBJ2 MYSTRUCTS1 OBJ2 ;
: MYSTRUCTS2.OBJ1 MYSTRUCTS2 OBJ1 ;
: MYSTRUCTS2.OBJ2 MYSTRUCTS2 OBJ2 ;

MYSTRUCTS1.OBJ1
MYSTRUCTS1.OBJ2
MYSTRUCTS2.OBJ1
MYSTRUCTS2.OBJ2

Creating a more generic version in Forth might go something
like:

: OBJ1 0 ;
: OBJ2 1 ;
: OFFSETOF ( a n -- i ) CELLS + @ ;

MYSTRUCTS1 OBJ1 OFFSETOF
MYSTRUCTS1 OBJ2 OFFSETOF
MYSTRUCTS2 OBJ1 OFFSETOF
MYSTRUCTS2 OBJ2 OFFSETOF

Or, if we rename OFFSETOF to '->' to be more C like:

: -> ( a n -- i ) CELLS + @ ;

MYSTRUCTS1 OBJ1 ->
MYSTRUCTS1 OBJ2 ->
MYSTRUCTS2 OBJ1 ->
MYSTRUCTS2 OBJ2 ->

Of course, those only work for CELL sized objects.  You'd
need to simulate C's sizeof() functionality in Forth to fix
that.  Forth doesn't have a typesystem, so that information
must be hardcoded by you ...

E.g.,

: OBJ1 0 1 ; \ cell size offset 0
: OBJ2 1 1 ; \ cell size offset 1

\ let's do some CHAR's too ...

: OBJC1 1 0 ; \ char size offset of 1
: OBJC2 3 0 ; \ char size offset of 3

The second value is a flag to indicate CELL sized object.

: -> ( a n x -- i ) IF CELLS THEN + @ ;

Of course, that doesn't know if the size of the object
to be fetched is a CELL or a CHAR, and so fetches a CELL
which we probably don't want for a byte sized object,
assuming it's a CHAR.  Technically, Forth doesn't have
type information, but it has two data types: CELL and CHAR.
CELL serves as a large integer and as address pointers.
Strings are passed as addresses.  So, we can assume if
not CELL then CHAR.

: -> ( a n x -- i ) IF CELLS + @ ELSE + C@ THEN ;


In full,

: -> ( a n x -- i ) IF CELLS + @ ELSE + C@ THEN ;

CREATE MYSTRUCT1 2 CELLS ALLOT
CREATE MYSTRUCT2 2 CELLS ALLOT

: OBJ1 0 1 ; \ cell size offset 0
: OBJ2 1 1 ; \ cell size offset 1

: OBJC1 1 0 ; \ byte size offset of 1
: OBJC3 3 0 ; \ byte size offset of 3

: MYSTRUCTS1.OBJ1 MYSTRUCTS1 OBJ1 -> ;
: MYSTRUCTS1.OBJ2 MYSTRUCTS1 OBJ2 -> ;
: MYSTRUCTS2.OBJ1 MYSTRUCTS2 OBJ1 -> ;
: MYSTRUCTS2.OBJ2 MYSTRUCTS2 OBJ2 -> ;

: MYSTRUCTS1.OBJC1 MYSTRUCTS1 OBJC1 -> ; \ char
: MYSTRUCTS1.OBJC3 MYSTRUCTS1 OBJC3 -> ; \ char
: MYSTRUCTS2.OBJC1 MYSTRUCTS2 OBJC1 -> ; \ char
: MYSTRUCTS2.OBJC3 MYSTRUCTS2 OBJC3 -> ; \ char

MYSTRUCTS1.OBJ1
MYSTRUCTS1.OBJ2
MYSTRUCTS2.OBJ1
MYSTRUCTS2.OBJ2

MYSTRUCTS1.OBJC1
MYSTRUCTS1.OBJC3
MYSTRUCTS2.OBJC1
MYSTRUCTS2.OBJC3

If you throw CREATE .. DOES> into the mix, you might be
able to automate the process of creating all or many of
those pre-liminary definitions.  Hopefully, that's easy
to do for someone here who is skilled in Forth.

I.e., you could implement structs in Forth much like
rudimentary arrays with only two possible types for
each item, either CELL or CHAR .  This is what they
are in C but with some sizeof() and offsetof()
information used by the compiler and additional types
thrown in to the mix.

http://www.forth.org/svfig/Len/arrays.htm
http://www.forth.com/starting-forth/sf8/sf8.html

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

Agreed.

As to whatever was going on in the rest of the thread with
Hugh, I haven't really read that.


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

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

#39447

On Friday, May 29, 2015 at 7:56:05 AM UTC-7, Raimond Dragomir wrote:
> Second you need a smart + which should be immediate and perform a + if there
> are at least two literals pending, or compile the + otherwise;

This is the part I saw as being incorrect, and for the same reason that Anton Ertl was incorrect --- you are not considering the case in which one parameter is not a literal, but the other is the literal zero (no addition needed) --- you are only considering the case in which both parameters are literals and they can be folded together into a single literal (do the addition at compile-time).

Maybe I'm misinterpreting your description though --- I didn't actually look at your code, but I only looked at this description.

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

#39449

sâmbătă, 30 mai 2015, 08:55:37 UTC+3, hughag...@gmail.com a scris:
> On Friday, May 29, 2015 at 7:56:05 AM UTC-7, Raimond Dragomir wrote:
> > Second you need a smart + which should be immediate and perform a + if there
> > are at least two literals pending, or compile the + otherwise;
> 
> This is the part I saw as being incorrect, and for the same reason that Anton Ertl was incorrect --- you are not considering the case in which one parameter is not a literal, but the other is the literal zero (no addition needed) --- you are only considering the case in which both parameters are literals and they can be folded together into a single literal (do the addition at compile-time).
> 
> Maybe I'm misinterpreting your description though --- I didn't actually look at your code, but I only looked at this description.

I admit that I missed something here in the description, although I 
explained the internal literal folding mechanism to some degree:

The literals are not compiled directly, they are "delayed". This simply 
means that a literal is just left on the data stack when is encountered
in the source. This leaves the possibility for immediate "smart" words
to do something, constant folding for example. This works with another
mechanism: a normal compilation of any word will "flush" all values on the
data stack first, in fifo order. Probably this was not so clear.

So, in our example: a "smart" + will just execute the + at compile time if 
there are at least two data stack items. Otherwise, the + will be compiled.
This compilation of the + will trigger flushing the existing literals
on the data stack (in this case at most one). This is internal, and cannot
be seen in the sources.

A "smarter" + can compile a "literal +" optimized sequence if there is only
one literal pending. Or it can not compile a 0 + at all, see my source for
this case.

Speacking of it, I have the special case of 0 + and 1 *. 0 + is so common
for struct field, 1 * is for byte sized arrays.

Here is my version of your 1array, 2array and 3array:

\ arrays syntax:
\             dim1 size 1array "name"
\        dim2 dim1 size 2array "name"
\   dim3 dim2 dim1 size 3array "name"
qlib-temp-wordlist set-current
qlib-temp-wordlist forth-wordlist qlib-wordlist 3 set-order

0 cell field ary->base
  cell field ary->size
  cell field ary->dim1
  cell field ary->dim2
drop

[ ary->base @ ] def <ary-base> ( a -- base )
[ ary->size @ ] def <ary-size> ( a -- size )
[ ary->dim1 @ ] def <ary-dim1> ( a -- dim1 )
[ ary->dim2 @ ] def <ary-dim2> ( a -- dim2 )

qlib-wordlist set-current

\ 1ARRAY ( "name" dim size -- )
[ [| pfa |           \ runtime: ix1 [pfa]
    pfa <ary-size> compile *  \ ix1*size
    pfa <ary-base> compile +  \ base + size*ix1
  ] ibuild         \ dim1 size
  ramhere ,                 \ base address
  dup ,                     \ size
  * allot
] def 1array

\ 2ARRAY ( "name" dim2 dim1 size -- )
[| size |
  [| pfa |           \ runtime: ix2 ix1 [pfa]
    pfa <ary-size> compile *  \ ix2 ix1*size
    pfa <ary-base> compile +  \ ix2 ix1*size+base
    compile swap              \ ix1*size ix2
    pfa <ary-size>
    pfa <ary-dim1> compile * compile *
    compile +               \ base + size*ix1 + dim1*size*ix2
  ] ibuild         \ dim2 dim1 [size]
  ramhere ,                 \ base address
  size ,                    \ size
  dup , size *              \ dim1
  * allot
] def 2array

\ 3ARRAY ( "name" dim3 dim2 dim1 size -- )
[| size |
  [| pfa |           \ runtime: ix3 ix2 ix1 [pfa]
    pfa <ary-size> compile *  \ ix3 ix2 ix1*size
    pfa <ary-base> compile +  \ ix3 ix2 ix1*size+base
    compile swap              \ ix3 ix1*size+base ix2
    pfa <ary-size>
    pfa <ary-dim1> compile * compile *
    compile +               \ ix3 ix1*size+ix2*size*dim1
    compile swap            \ ix1*size+ix2*size*dim1 ix3
    pfa <ary-size>
    pfa <ary-dim1>
    pfa <ary-dim2> compile * compile * compile *
    compile +            \ base + size*ix1 + dim1*size*ix2 + ix3*size*dim1*dim2
  ] ibuild        \ dim3 dim2 dim1 [size]
  ramhere ,                 \ base address
  size ,                    \ size
  dup , size * to size      \ dim1
  dup , size *              \ dim2
  * allot
] def 3array

\ we don't need qlib-temp wordlist anymore
forth-wordlist qlib-wordlist 2 set-order


Some notes:
[| ... | is for locals. So, in the 3array definition for example,
size is local to the 3array quote, and pfa is a local to the building
quote. These are stacked initialized locals, in correct order.
I also have [| ... 0 ... | notation where the "0" is not zero but a 
delimiter for zero initialized locals.
As a comparation:
{ x y z | a b c -- ... }
[| x y z 0 a b c |  \ emmebeded -- comments not supported


And a test of an array of structs:

variable x  \ this is used to "simulate" a non-constant array index

0 cell field .x
  cell field .y
  cell field .z
  cell field .color
constant pixel

\ 3ARRAY test
4 4 4 pixel 3array screen

[ 1  0 0 x @ screen .x  !
  2  0 0 x @ screen .y  !
  3  0 0 x @ screen .z  !
  4  0 0 x @ screen .color  !
] def 000!

[ 5  3 3 3 screen .x  !
  6  3 3 3 screen .y  !
  7  3 3 3 screen .z  !
  8  3 3 3 screen .color  !
] def 333!

[ 0 0 0 screen .x  @ .
  0 0 0 screen .y  @ .
  0 0 0 screen .z  @ .
  0 0 0 screen .color  @ .
] def 000@

[ 3 3 3 screen .x  @ .
  3 3 3 screen .y  @ .
  3 3 3 screen .z  @ .
  3 3 3 screen .color  @ .
] def 333@

000! 333! 000@ 333@ cr

[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