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

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

objects build up from other objects

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

Contents

  objects build up from other  objects Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-04 14:44 +0000
    Re: objects build up from other  objects franck.bensusan@gmail.com - 2015-11-04 09:17 -0800
      Re: objects build up from other objects Doug Hoffman <glidedog@gmail.com> - 2015-11-05 10:07 -0500
        Re: objects build up from other objects Hans Bezemer <the.beez.speaks@gmail.com> - 2015-11-05 18:34 +0100
          Re: objects build up from other objects Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-06 00:09 +0000
          Re: objects build up from other objects Doug Hoffman <glidedog@gmail.com> - 2015-11-05 21:47 -0500
            Re: objects build up from other objects Hans Bezemer <the.beez.speaks@gmail.com> - 2015-11-06 09:37 +0100
              Re: objects build up from other objects Doug Hoffman <glidedog@gmail.com> - 2015-11-06 04:52 -0500
                Re: objects build up from other objects Hans Bezemer <the.beez.speaks@gmail.com> - 2015-11-06 12:36 +0100
                  Re: objects build up from other objects Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-06 12:13 +0000
              Re: objects build up from other objects hughaguilar96@gmail.com - 2015-11-06 15:32 -0800
        Re: objects build up from other objects hughaguilar96@gmail.com - 2015-11-05 13:15 -0800
          Re: objects build up from other objects franck.bensusan@gmail.com - 2015-11-05 15:19 -0800
            Re: objects build up from other objects hughaguilar96@gmail.com - 2015-11-05 22:10 -0800
              Re: objects build up from other objects franck.bensusan@gmail.com - 2015-11-07 07:50 -0800
                Re: objects build up from other objects hughaguilar96@gmail.com - 2015-11-07 13:46 -0800
                  Re: objects build up from other objects franck.bensusan@gmail.com - 2015-11-07 14:46 -0800
          Re: objects build up from other objects Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-06 00:20 +0000
            Re: objects build up from other objects Ron Aaron <rambamist@gmail.com> - 2015-11-06 07:39 +0200
    Re: objects build up from other objects Doug Hoffman <glidedog@gmail.com> - 2015-11-04 15:33 -0500
    Re: objects build up from other  objects Chris Curl <ccurl609@gmail.com> - 2015-11-06 06:31 -0800
      Re: objects build up from other  objects Hans Bezemer <the.beez.speaks@gmail.com> - 2015-11-06 18:48 +0100
      Re: objects build up from other objects "Elizabeth D. Rather" <erather@forth.com> - 2015-11-06 08:15 -1000
      Re: objects build up from other objects Doug Hoffman <glidedog@gmail.com> - 2015-11-06 13:44 -0500
        Re: objects build up from other objects "Elizabeth D. Rather" <erather@forth.com> - 2015-11-06 11:10 -1000
          Re: objects build up from other objects josv@planet.nl - 2015-11-06 15:19 -0800
            Re: objects build up from other objects "Elizabeth D. Rather" <erather@forth.com> - 2015-11-06 14:54 -1000
              Re: objects build up from other objects anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-07 16:57 +0000
                Re: objects build up from other objects "Elizabeth D. Rather" <erather@forth.com> - 2015-11-07 08:13 -1000
            Re: objects build up from other objects Chris Curl <ccurl609@gmail.com> - 2015-11-06 19:31 -0800
              Re: objects build up from other objects hughaguilar96@gmail.com - 2015-11-06 20:03 -0800
              Re: objects build up from other objects josv@planet.nl - 2015-11-07 01:43 -0800
          Re: objects build up from other objects "HAA" <someone@microsoft.com> - 2015-11-07 15:03 +1100
            Re: objects build up from other objects hughaguilar96@gmail.com - 2015-11-06 20:42 -0800
          Re: objects build up from other objects Doug Hoffman <glidedog@gmail.com> - 2015-11-07 10:12 -0500
            Re: objects build up from other objects Chris Curl <ccurl609@gmail.com> - 2015-11-07 10:01 -0800
              Re: objects build up from other objects Doug Hoffman <glidedog@gmail.com> - 2015-11-08 08:22 -0500
                Re: objects build up from other objects Chris Curl <ccurl609@gmail.com> - 2015-11-08 06:37 -0800
              Re: objects build up from other objects "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-11-08 15:01 -0500
                Re: objects build up from other objects Doug Hoffman <glidedog@gmail.com> - 2015-11-09 07:27 -0500
            Re: objects build up from other objects "Elizabeth D. Rather" <erather@forth.com> - 2015-11-07 08:20 -1000
              Re: objects build up from other objects franck.bensusan@gmail.com - 2015-11-08 23:44 -0800
                Re: objects build up from other objects "Elizabeth D. Rather" <erather@forth.com> - 2015-11-08 21:58 -1000
                  Re: objects build up from other objects Mark Wills <markwills1970@gmail.com> - 2015-11-09 01:57 -0800
                    Re: objects build up from other objects Ron Aaron <rambamist@gmail.com> - 2015-11-09 12:46 +0200
                      Re: objects build up from other objects Mark Wills <markwills1970@gmail.com> - 2015-11-09 03:04 -0800
                        Re: objects build up from other objects hughaguilar96@gmail.com - 2015-11-09 23:14 -0800
                    Re: objects build up from other objects - even Forth? Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-11-09 12:15 +0000
                      Re: objects build up from other objects - even Forth? franck.bensusan@gmail.com - 2015-11-09 12:25 -0800
                        Re: objects build up from other objects - even Forth? Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-11-10 10:48 +0000
                          Re: objects build up from other objects - even Forth? franck.bensusan@gmail.com - 2015-11-10 04:31 -0800
                            Re: objects build up from other objects - even Forth? hughaguilar96@gmail.com - 2015-11-10 18:06 -0800
                              Re: objects build up from other objects - even Forth? franck.bensusan@gmail.com - 2015-11-11 00:49 -0800
                                Re: objects build up from other objects - even Forth? Paul Rubin <no.email@nospam.invalid> - 2015-11-11 01:13 -0800
                                  Re: objects build up from other objects - even Forth? franck.bensusan@gmail.com - 2015-11-11 01:52 -0800
                                    Re: objects build up from other objects - even Forth? hughaguilar96@gmail.com - 2015-11-11 15:54 -0800
                                      Re: objects build up from other objects - even Forth? stephen@mpeforth.com (Stephen Pelc) - 2015-11-12 11:01 +0000
                                        Re: objects build up from other objects - even Forth? hughaguilar96@gmail.com - 2015-11-12 11:07 -0800
                                    Re: objects build up from other objects - even Forth? Paul Rubin <no.email@nospam.invalid> - 2015-11-11 15:55 -0800
                                      Re: objects build up from other objects - even Forth? Mark Wills <markwills1970@gmail.com> - 2015-11-12 00:50 -0800
                                        Re: objects build up from other objects - even Forth? Paul Rubin <no.email@nospam.invalid> - 2015-11-12 18:21 -0800
                    Re: objects build up from other objects anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-09 12:16 +0000
                      Re: objects build up from other objects Doug Hoffman <glidedog@gmail.com> - 2015-11-09 07:38 -0500
                  Re: objects build up from other objects franck.bensusan@gmail.com - 2015-11-09 04:15 -0800
                  Re: objects build up from other objects Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-09 15:29 +0000
                    Re: objects build up from other objects "Elizabeth D. Rather" <erather@forth.com> - 2015-11-09 09:09 -1000
                  Re: objects build up from other objects hughaguilar96@gmail.com - 2015-11-09 22:41 -0800
        Re: objects build up from other objects Chris Curl <ccurl609@gmail.com> - 2015-11-06 19:14 -0800
          Re: objects build up from other objects hughaguilar96@gmail.com - 2015-11-06 19:39 -0800
          Re: objects build up from other objects Doug Hoffman <glidedog@gmail.com> - 2015-11-07 09:04 -0500
    Re: objects build up from other  objects lehs <skydda.barnen@gmail.com> - 2015-11-06 09:20 -0800
    Re: objects build up from other objects Doug Hoffman <glidedog@gmail.com> - 2015-11-08 06:12 -0500

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

#43233 — objects build up from other objects

I've stood up to the challenge to show how ciforth's mini-OO (with current
object) can be used to build larger objects.
REGRESS is a new invention, it is like the { <- } of
Hopkins test suite. In my system it aborts if the test fails,
but you can see it as a stack diagram by example.

Once you have a class Point (a defining word) you get also
^Point  :contains the pointer to the current Point)
BUILD-Point : lay down a data structure in memory, leave its address.

There is no current object per se. Only current Point, current Rectangle
etc.

There are no fields. Offsets into an objects data are hidden.
In this example you only have x (a getter) and x! (a setter)

I've commented out y^ which would be the closest thing to a field.

Unlike CREATE DOES> the code precedes the creation of the data.
Like create DOES> the code is started with the address of its data on
the data stack.
Unlike CREATE DOES> code can work on an arbitrary offset of the
data.

_ is don't care data.

Note that unless the current rectangle is filled in ( ^Rectangle
contains an address) words like diagonal will crash.

BUILD-something can be used to make an array of somethings.

\ --------------------------------------------------------
WANT class
WANT SQRT
WANT SQ
WANT INCLUDE
WANT REGRESS

\ Calculates the distance between two points. (hypothenusa).
: HYP  ROT - SQ ROT ROT - SQ + SQRT ;
REGRESS 10 10 14 13 HYP S: 5

class Point   \ ( -- ) unitialised
    M: x @ M;
    M: x! ! M;    _ ,
\    M: y^ M;
    M: y @ M;
    M: y! ! M;    _ ,
endclass
REGRESS Point Q FORGET Q S:

class Rectangle
   M: upper-left-corner ^Point ! M;   BUILD-Point DROP
   M: lower-right-corner ^Point ! M;   BUILD-Point DROP
endclass
REGRESS Rectangle Q S:

\ Store X1 Y1 X2 Y2 into a Rectangle
: init-Rect lower-right-corner y! x! upper-left-corner y! x! ;
REGRESS 10 10 40 50 Q init-Rect S:

\ Return the LENGTH of the diagonal of the current Rectangle
: diagonal   upper-left-corner x y lower-right-corner x y HYP ;
REGRESS Q diagonal S: 50

\ -------------------------- some test code ---------------------

Rectangle this-mine-self

this-mine-self    10 10 40 50 init-Rect

Rectangle other-rect

other-rect  upper-left-corner x CR . \ expect garbage

CR
|Expect 50 :" TYPE
this-mine-self    diagonal .     CR

\--------------------------------------------------

It would be interesting to see how composing objects
works in other OO's.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [next] | [standalone]

#43236

Le mercredi 4 novembre 2015 15:44:19 UTC+1, Albert van der Horst a écrit :
> I've stood up to the challenge to show how ciforth's mini-OO (with current
> object) can be used to build larger objects.
> REGRESS is a new invention, it is like the { <- } of
> Hopkins test suite. In my system it aborts if the test fails,
> but you can see it as a stack diagram by example.
> 
> Once you have a class Point (a defining word) you get also
> ^Point  :contains the pointer to the current Point)
> BUILD-Point : lay down a data structure in memory, leave its address.
> 
> There is no current object per se. Only current Point, current Rectangle
> etc.
> 
> There are no fields. Offsets into an objects data are hidden.
> In this example you only have x (a getter) and x! (a setter)
> 
> I've commented out y^ which would be the closest thing to a field.
> 
> Unlike CREATE DOES> the code precedes the creation of the data.
> Like create DOES> the code is started with the address of its data on
> the data stack.
> Unlike CREATE DOES> code can work on an arbitrary offset of the
> data.
> 
> _ is don't care data.
> 
> Note that unless the current rectangle is filled in ( ^Rectangle
> contains an address) words like diagonal will crash.
> 
> BUILD-something can be used to make an array of somethings.
> 
> \ --------------------------------------------------------
> WANT class
> WANT SQRT
> WANT SQ
> WANT INCLUDE
> WANT REGRESS
> 
> \ Calculates the distance between two points. (hypothenusa).
> : HYP  ROT - SQ ROT ROT - SQ + SQRT ;
> REGRESS 10 10 14 13 HYP S: 5
> 
> class Point   \ ( -- ) unitialised
>     M: x @ M;
>     M: x! ! M;    _ ,
> \    M: y^ M;
>     M: y @ M;
>     M: y! ! M;    _ ,
> endclass
> REGRESS Point Q FORGET Q S:
> 
> class Rectangle
>    M: upper-left-corner ^Point ! M;   BUILD-Point DROP
>    M: lower-right-corner ^Point ! M;   BUILD-Point DROP
> endclass
> REGRESS Rectangle Q S:
> 
> \ Store X1 Y1 X2 Y2 into a Rectangle
> : init-Rect lower-right-corner y! x! upper-left-corner y! x! ;
> REGRESS 10 10 40 50 Q init-Rect S:
> 
> \ Return the LENGTH of the diagonal of the current Rectangle
> : diagonal   upper-left-corner x y lower-right-corner x y HYP ;
> REGRESS Q diagonal S: 50
> 
> \ -------------------------- some test code ---------------------
> 
> Rectangle this-mine-self
> 
> this-mine-self    10 10 40 50 init-Rect
> 
> Rectangle other-rect
> 
> other-rect  upper-left-corner x CR . \ expect garbage
> 
> CR
> |Expect 50 :" TYPE
> this-mine-self    diagonal .     CR
> 
> \--------------------------------------------------
> 
> It would be interesting to see how composing objects
> works in other OO's.
> 
> Groetjes Albert
> -- 
> Albert van der Horst, UTRECHT,THE NETHERLANDS
> Economic growth -- being exponential -- ultimately falters.
> albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst


I prefer this "unamed" model than the previous one.

Here is Oforth version : 

Object Class new: Point(x, y)      // new Point class, subclass of Object
Point method: initialize  := x := y ;  // y x -- 
Point method: x @x ;    // aPoint -- x
Point method: y @y ;	// aPoint -- y

Object Class new: Rectangle(ulc, lrc)

Rectangle method: initialize := lrc := ulc ; // p2 p1 -- 

Rectangle method: diagonal	// aRectangle -- x
   @ulc x @lrc x - sq
   @ulc y @lrc y - sq
   + sqrt ;

Point new(14, 13) Point new(10, 10) Rectangle new diagonal .
5 ok

Franck

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

#43253 — Re: objects build up from other objects

On 11/4/15 12:17 PM, franck.bensusan@gmail.com wrote:
> I prefer this "unamed" model than the previous one.
>
> Here is Oforth version :
>
> Object Class new: Point(x, y)      // new Point class, subclass of Object
> Point method: initialize  := x := y ;  // y x --
> Point method: x @x ;    // aPoint -- x
> Point method: y @y ;	// aPoint -- y
>
> Object Class new: Rectangle(ulc, lrc)
>
> Rectangle method: initialize := lrc := ulc ; // p2 p1 --
>
> Rectangle method: diagonal	// aRectangle -- x
>     @ulc x @lrc x - sq
>     @ulc y @lrc y - sq
>     + sqrt ;
>
> Point new(14, 13) Point new(10, 10) Rectangle new diagonal .
> 5 ok

Very nice. One can mix in floats with exactly the same Oforth code:

Point new(14.8, 13) Point new(10, 10.5) Rectangle new diagonal .
5.41202365109392

Slick. I suspect that one could bend some FMS or other classic Forth oo
classes to do something like that, but it would take some more work and
perhaps be a bit messy.

-Doug

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

#43255 — Re: objects build up from other objects

Doug Hoffman wrote:

> Very nice. One can mix in floats with exactly the same Oforth code:
> 
> Point new(14.8, 13) Point new(10, 10.5) Rectangle new diagonal .
> 5.41202365109392
> 
> Slick. I suspect that one could bend some FMS or other classic Forth oo
> classes to do something like that, but it would take some more work and
> perhaps be a bit messy.
True, the elegance of oForth with OO is hard to beat with "classic" Forth.
This is the FOOS variant - which is much "wordier". If one would like to
make it FP, it would require changing all the words involved (F!, FSQRT,
FFIELD: etc.) The initialization is taken from the oForth version, that is
create two new point objects, then assign them to a new rectangle.

Hans Bezemer

---8<---
include lib/memcell.4th                \ for ALLOCATE
include lib/isqrt.4th                  \ for ISQRT
include 4pp/lib/foos.4pp               \ for Object orientation

: sq ( n -- n^2 ) dup * ;
: hyp ( x1 y1 x2 y2 -- hyp )
  rot - sq rot rot - sq + isqrt ;

:: point
   class
     field: x
     field: y
   end-class {

     :method put {                     ( x y -- )
        this -> y ! this -> x !
     } ;method

     :method get {                     ( -- x y )
        this ->  x @ this -> y @
     } ;method

     this -> put                       \ constructor
   }
;

:: rectangle
   class
     field: ulc
     field: lrc
   end-class {

     :method diagonal {                ( -- diag )
        this -> ulc @ -> get
        this -> lrc @ -> get hyp
     } ;method

     :method rput {                    ( a1 a2 -- )
        this -> lrc !
        this -> ulc !
     } ;method

     :method destroy {                 \ destruction of embedded points
        this -> ulc @ free
        this -> lrc @ free or abort" Unable to free memory"
     } ;method

     this -> rput                      \ constructor
   }
;

\ named rectangle in dictionary
20 20 new point 50 50 new point static rectangle r
r -> diagonal . cr

\ nameless rectangle in heap
10 10 new point 13 14 new point instance rectangle hr
hr -> diagonal . cr

\ must manually garbage collect
hr -> destroy
hr free abort" Unable to free memory"

\ if you want message-less access to instance variables
r -> ulc @ -> x ? cr
r -> ulc @ -> y ? cr
r -> lrc @ -> x ? cr
r -> lrc @ -> y ? cr
---8<---

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

#43260 — Re: objects build up from other objects

Hans Bezemer <the.beez.speaks@gmail.com> writes:

>Doug Hoffman wrote:

>> Very nice. One can mix in floats with exactly the same Oforth code:
>>
>> Point new(14.8, 13) Point new(10, 10.5) Rectangle new diagonal .
>> 5.41202365109392
>>
>> Slick. I suspect that one could bend some FMS or other classic Forth oo
>> classes to do something like that, but it would take some more work and
>> perhaps be a bit messy.
>True, the elegance of oForth with OO is hard to beat with "classic" Forth.
>This is the FOOS variant - which is much "wordier". If one would like to
>make it FP, it would require changing all the words involved (F!, FSQRT,
>FFIELD: etc.) The initialization is taken from the oForth version, that is
>create two new point objects, then assign them to a new rectangle.

>Hans Bezemer

>---8<---
>include lib/memcell.4th                \ for ALLOCATE
>include lib/isqrt.4th                  \ for ISQRT
>include 4pp/lib/foos.4pp               \ for Object orientation

>: sq ( n -- n^2 ) dup * ;
>: hyp ( x1 y1 x2 y2 -- hyp )
>  rot - sq rot rot - sq + isqrt ;

>:: point
>   class
>     field: x
>     field: y
>   end-class {

>     :method put {                     ( x y -- )
>        this -> y ! this -> x !
>     } ;method

>     :method get {                     ( -- x y )
>        this ->  x @ this -> y @
>     } ;method

>     this -> put                       \ constructor
>   }
>;

>:: rectangle
>   class
>     field: ulc
>     field: lrc
>   end-class {

>     :method diagonal {                ( -- diag )
>        this -> ulc @ -> get
>        this -> lrc @ -> get hyp
>     } ;method

>     :method rput {                    ( a1 a2 -- )
>        this -> lrc !
>        this -> ulc !
>     } ;method

>     :method destroy {                 \ destruction of embedded points
>        this -> ulc @ free
>        this -> lrc @ free or abort" Unable to free memory"
>     } ;method

>     this -> rput                      \ constructor
>   }
>;

>\ named rectangle in dictionary
>20 20 new point 50 50 new point static rectangle r
>r -> diagonal . cr

>\ nameless rectangle in heap
>10 10 new point 13 14 new point instance rectangle hr
>hr -> diagonal . cr

>\ must manually garbage collect
>hr -> destroy
>hr free abort" Unable to free memory"

>\ if you want message-less access to instance variables
>r -> ulc @ -> x ? cr
>r -> ulc @ -> y ? cr
>r -> lrc @ -> x ? cr
>r -> lrc @ -> y ? cr
>---8<---

In this OO I understand where the allocation takes place, it is
with new.

Can you create a hexagon without, for each instance, explicity having
six news for its six edges for each instance?

(In my OO I have at most 6 BUILD-Point 's in the create part
of the Hexagon class. With -scripting- , interpretative control
structures, I can do `` 6 0 DO BUILD-Point ''  in the create body of
a  class.)

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#43262 — Re: objects build up from other objects

On 11/5/15 12:34 PM, Hans Bezemer wrote:

> This is the FOOS variant
> The initialization is ...
> create two new point objects, then assign them to a new rectangle.

I can't run your code because I only have a few ANS Forths that run on 
my Macintosh.  So a couple questions about your code below:

> :: point
>     class
>       field: x
>       field: y
>     end-class {
>
>       :method put {                     ( x y -- )
>          this -> y ! this -> x !
>       } ;method
>
>       :method get {                     ( -- x y )
>          this ->  x @ this -> y @
>       } ;method
>
>       this -> put                       \ constructor
>     }
> ;
>
> :: rectangle
>     class
>       field: ulc
>       field: lrc
>     end-class {
>
>       :method diagonal {                ( -- diag )
>          this -> ulc @ -> get
>          this -> lrc @ -> get hyp
>       } ;method
>
>       :method rput {                    ( a1 a2 -- )
>          this -> lrc !
>          this -> ulc !
>       } ;method
>
>       :method destroy {                 \ destruction of embedded points
>          this -> ulc @ free
>          this -> lrc @ free or abort" Unable to free memory"
>       } ;method
>
>       this -> rput                      \ constructor
>     }
> ;
>
> \ named rectangle in dictionary
> 20 20 new point 50 50 new point static rectangle r

Are the two points above created in the heap or the dictionary?  If in 
the heap, where is that memory freed?  I don't see an operation that 
frees them from r.

> r -> diagonal . cr


> \ nameless rectangle in heap
> 10 10 new point 13 14 new point instance rectangle hr
> hr -> diagonal . cr
>
> \ must manually garbage collect
> hr -> destroy
> hr free abort" Unable to free memory"

Note that with FMS we only need " hr <free ".  This frees all memory 
allocated for the hr object, including the two embedded points, no 
destroy method needed.

-Doug

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

#43267 — Re: objects build up from other objects

Doug Hoffman wrote:
> I can't run your code because I only have a few ANS Forths that run on
> my Macintosh.  So a couple questions about your code below:
Well, that won't help you because FOOS is bound to 4tH - which in some kind
of Darwin port does run on the Mac though.

>> \ named rectangle in dictionary
>> 20 20 new point 50 50 new point static rectangle r
> 
> Are the two points above created in the heap or the dictionary?  If in
> the heap, where is that memory freed?  I don't see an operation that
> frees them from r.
In FOOS there are three ways to create an object

static CLASS NAME (creates a named object "in the dictionary")
new CLASS (creates an unnamed object on the heap, returns a pointer)
instance CLASS NAME (creates an named object on the heap)

Since FOOS doesn't come with destructors, you have to create one yourself.
So, usually, it I decided I wanted my objects to live on the heap (and
consequently wouldn't use static ones) I'd create something like this:

     :method destroy {                 \ destruction of embedded points
        this -> ulc @ free
        this -> lrc @ free
        this free or or abort" Unable to free memory"
     } ;method

And hence use it like this:

hr -> destroy

I wouldn't do static objects for the simple reason the "destroy" method
wouldn't do much good ;-) BTW, I'd probably use an interface with virtual
methods for that.

Sure, consequently I could make static points as well - there is nothing
that prevents that. In FOOS you're unable to tell after instantiation
whether an object is allocated on the heap or static, so doing
things "automatic" would prove to be a bit difficult.

Hans Bezemer

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

#43268 — Re: objects build up from other objects

On 11/6/15 3:37 AM, Hans Bezemer wrote:
> Doug Hoffman wrote:

>>> \ named rectangle in dictionary
>>> 20 20 new point 50 50 new point static rectangle r
>>
>> Are the two points above created in the heap or the dictionary?  If in
>> the heap, where is that memory freed?  I don't see an operation that
>> frees them from r.

> new CLASS (creates an unnamed object on the heap, returns a pointer)

OK, so the points in the dictionary object r are created in the heap.
You didn't show code that freed the memory for those two points in r.

So I assume the missing code was:
r -> destroy  \ gc required for for dictionary object r

Seems like 20 20 static point 50 50 static point static rectangle r
would have made more sense.

> In FOOS you're unable to tell after instantiation
> whether an object is allocated on the heap or static, so doing
> things "automatic" would prove to be a bit difficult.

Not difficult in FMS.  It works "automatic" and as expected.

\ named rectangle in dictionary
rectangle r  \ => no gc needed, entire object is allotted

\ nameless rectangle in heap
heap> rectangle value hr
hr <free   \ => very simple gc, entire object is allocated

-Doug

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

#43269 — Re: objects build up from other objects

Doug Hoffman wrote:
 
> OK, so the points in the dictionary object r are created in the heap.
> You didn't show code that freed the memory for those two points in r.
True, they weren't freed in this example. Note they also weren't freed in
either the ANS or oForth example.. 
 
> So I assume the missing code was:
> r -> destroy  \ gc required for for dictionary object r
Yes, that would totally work.

> Seems like 20 20 static point 50 50 static point static rectangle r
> would have made more sense.
Depends on what you intend to do. IF you were pretty sure that those points
would never change, yes, I'd totally do it that way (needs a slightly
different way to declare, but ok..) However, if those points change, I'd
probably go for a dynamic allocation. But that's just me having an
ontological question to answer. It would work both ways.

>> In FOOS you're unable to tell after instantiation
>> whether an object is allocated on the heap or static, so doing
>> things "automatic" would prove to be a bit difficult.
> 
> Not difficult in FMS.  It works "automatic" and as expected.
Not very helpful this way. Can't implement a spec that says "it just
works" ;-)

Hans Bezemer

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

#43270 — Re: objects build up from other objects

Hans Bezemer <the.beez.speaks@gmail.com> writes:

>Doug Hoffman wrote:
>
>> OK, so the points in the dictionary object r are created in the heap.
>> You didn't show code that freed the memory for those two points in r.
>True, they weren't freed in this example. Note they also weren't freed in
>either the ANS or oForth example..
>
>> So I assume the missing code was:
>> r -> destroy  \ gc required for for dictionary object r
>Yes, that would totally work.

My dictionary space is at 8Gbyte. If that is exhausted, and swapping
into the 128 Gbyte swap space leads to problems, I'll start thinking
about garbage collecting objects.

I know, dogmatic application of functional programming principles
leads to vast amounts of memory usage. Instead of filling in
a field in an object, a copy of the object is created with a different
field. If I bought into that, my projecteuler (math) solutions
would not finish in all eternity.

Only in my disassembler I felt the need for polymorphism.
I did it the primitive way, by hand filling in fields that contain
xt's. Still waiting for someone to inspire me/convince me that
more abstraction is needed.

>> Seems like 20 20 static point 50 50 static point static rectangle r
>> would have made more sense.
>Depends on what you intend to do. IF you were pretty sure that those points
>would never change, yes, I'd totally do it that way (needs a slightly
>different way to declare, but ok..) However, if those points change, I'd
>probably go for a dynamic allocation. But that's just me having an
>ontological question to answer. It would work both ways.

Even the need to decide between static and new would be offputting
to me. The Forth way is knowing how objects are made and having
the ability -- if it is really necessary -- to put them in ALLOCATE
area. I mean really-really, not "they have it, let us have it." or
"they will laugh at us".

>>> In FOOS you're unable to tell after instantiation
>>> whether an object is allocated on the heap or static, so doing
>>> things "automatic" would prove to be a bit difficult.
>>
>> Not difficult in FMS.  It works "automatic" and as expected.
>Not very helpful this way. Can't implement a spec that says "it just
>works" ;-)

Helpful for users. They only need to follow instructions, I can
see that. That is not enough to get me over the bump to start trying
it though.

>Hans Bezemer
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#43279 — Re: objects build up from other objects

On Friday, November 6, 2015 at 1:36:42 AM UTC-7, The Beez wrote:
> I wouldn't do static objects for the simple reason the "destroy" method
> wouldn't do much good ;-) BTW, I'd probably use an interface with virtual
> methods for that.
> 
> Sure, consequently I could make static points as well - there is nothing
> that prevents that. In FOOS you're unable to tell after instantiation
> whether an object is allocated on the heap or static, so doing
> things "automatic" would prove to be a bit difficult.
> 
> Hans Bezemer

In the novice-package I have wrappers around ALLOCATE RESIZE and FREE that allow ALLOCATION to work --- this was done to support CLONE-NODE.

Also, I have CONCRETE-ALLOCATE (somewhat of an awkward name) that is like ALLOCATE except in the dictionary rather than the heap. FREE can tell the difference between a memory-block on the heap (from ALLOCATE) or in the dictionary (from CONCRETE-ALLOCATE). If the memory-block is in the dictionary, FREE doesn't do anything, but if the memory-block is in the heap then FREE calls the low-level FREE on it.

In my slide-rule program I originally built each scale list when it was called for. Later on I realized that some scale lists are almost always needed (such as A and C) so I changed the program so that these would be built at compile-time rather than run-time. It is possible to easily switch from using the heap to using the dictionary --- this can be done at a late date in the program development, with no need to rewrite a lot of code.

Your FOOS might benefit from being written on top of the novice-package. I can't say for sure because I haven't examined FOOS, but it seems likely from what you said above. I'm not much interested in Forth OOP packages as I pretty much agree with Chris Curl that trying to turn Forth into C++ is a bad idea --- I wouldn't be opposed to having an OOP package written on top of the novice-package however, and I would put it in the next upgrade if it was good (it was originally my intention that the novice package would be the base for other people's code-libaries).

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

#43257 — Re: objects build up from other objects

On Thursday, November 5, 2015 at 8:07:17 AM UTC-7, Doug Hoffman wrote:
> On 11/4/15 12:17 PM, franck.bensusan@gmail.com wrote:
> > I prefer this "unamed" model than the previous one.
> >
> > Here is Oforth version :
> >
> > Object Class new: Point(x, y)      // new Point class, subclass of Object
> > Point method: initialize  := x := y ;  // y x --
> > Point method: x @x ;    // aPoint -- x
> > Point method: y @y ;	// aPoint -- y
> >
> > Object Class new: Rectangle(ulc, lrc)
> >
> > Rectangle method: initialize := lrc := ulc ; // p2 p1 --
> >
> > Rectangle method: diagonal	// aRectangle -- x
> >     @ulc x @lrc x - sq
> >     @ulc y @lrc y - sq
> >     + sqrt ;
> >
> > Point new(14, 13) Point new(10, 10) Rectangle new diagonal .
> > 5 ok
> 
> Very nice. One can mix in floats with exactly the same Oforth code:
> 
> Point new(14.8, 13) Point new(10, 10.5) Rectangle new diagonal .
> 5.41202365109392
> 
> Slick. I suspect that one could bend some FMS or other classic Forth oo
> classes to do something like that, but it would take some more work and
> perhaps be a bit messy.
> 
> -Doug

The price of all this slickness is that dynamic-OOP is inherently inefficient. Functions such as + have to have a switch inside that does different things depending upon the tags attached to each datum that it is working with. Polymorphism doesn't really do anything for you that can't be done otherwise --- it is just a convenience, and it is an expensive convenience --- also, it is in conflict with Charles Moore's proverb: "Let the dictionary do the deciding."

I'm not saying that oForth is bad --- I'm just saying that oForth is one of many dynamic-OOP languages that are mostly used for scripting and web-servers and other applications in which speed is not important --- by comparison, my FloatForth does not have tagged data and it is for applications in which speed is important (of course, FloatForth is still vaporware, which makes its speed somewhat irrelevant).

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

#43259 — Re: objects build up from other objects

Le jeudi 5 novembre 2015 22:15:12 UTC+1, hughag...@gmail.com a écrit :
> 
> The price of all this slickness is that dynamic-OOP is inherently inefficient. Functions such as + have to have a switch inside that does different things depending upon the tags attached to each datum that it is working with. Polymorphism doesn't really do anything for you that can't be done otherwise --- it is just a convenience, and it is an expensive convenience --- also, it is in conflict with Charles Moore's proverb: "Let the dictionary do the deciding."
> 
> I'm not saying that oForth is bad --- I'm just saying that oForth is one of many dynamic-OOP languages that are mostly used for scripting and web-servers and other applications in which speed is not important --- by comparison, my FloatForth does not have tagged data and it is for applications in which speed is important (of course, FloatForth is still vaporware, which makes its speed somewhat irrelevant).

Hi,

Yes, dynamic-OOP costs. But how much does it really costs ? Did you test it ?

Let's test it using the count iteration test used into 
Chris Curl "Stocked" topic.

Times are microseconds, using Oforth 32bit running on a Core I7 2.6 Ghz 
laptop on Windows 8.1 : 

The "-" method used in test1 & test2 : 
1) Is a polymorphic call.
2) For integers, works with arbitrary precision integers.

: test1  while( true ) [ dup ifZero: [ drop return ] 1 - ] ;
#[ 100000000 test1 ] bench 
427428

: test2  while( dup ) [ 1 - ] drop ;
#[ 100000000 test2 ] bench 
363660

: test3  | i | loop: i [ ] ;
#[ 100000000 test3 ] bench 
177896


Now what is the cost of a polymorphic method call compared to a word call ?

: aword 1 + drop ;

Integer method: amethod  self 1 + drop ; 
List    method: amethod  self size drop ;

: test4 | i | loop: i [ i aword ] ;
#[ 100000000 test4 ] bench
468064

: test5 | i | loop: i [ i amethod ] ;
#[ 100000000 test5 ] bench
639780

So yes, ok, polymorphism costs. Does it costs so much that it becomes
totally inefficient ? I don't think so.

Franck

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

#43264 — Re: objects build up from other objects

On Thursday, November 5, 2015 at 4:19:16 PM UTC-7, franck....@gmail.com wrote:
> So yes, ok, polymorphism costs. Does it costs so much that it becomes
> totally inefficient ? I don't think so.
> 
> Franck

I'm not saying that oForth is bad. I think that it is a good language. As I said in private email earlier though, we already have myriad languages with dynamic-OOP (Lisp, Racket, Factor, Python, Ruby, etc.). You are entering an already over-crowded field.

By comparison, my FloatForth will not be as convenient as oForth in some ways, but it is not intended to be used for writing quick scripts. I want FloatForth to be used for pretty heavy-duty number-crunching --- I really can't have + - * / etc. checking the tags on their data every time that they execute --- arithmetic has to be very fast when you are working with large quantities of numeric data. I effectively have polymorphism between integers and floats, because integers are just a subset of floats and so all the arithmetic operators work on both without having to know if the number has a fractional part or not --- I do not use + for concatenating strings however, as that is a totally different concept and hence deserves a different function name.

By the way --- do you know R?

My OOP in FloatForth is going to be super-simple --- pretty much the same as what I have in the novice-package right now. I will have TSRs and generators (I borrowed the name "generator" from Icon) --- I don't actually think that generators are very useful --- I mostly added generators just to keep with Raimond and his LFTforth.

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

#43303 — Re: objects build up from other objects

Le vendredi 6 novembre 2015 07:10:03 UTC+1, hughag...@gmail.com a écrit :
> I'm not saying that oForth is bad. I think that it is a good language. As I said in private email earlier though, we already have myriad languages with dynamic-OOP (Lisp, Racket, Factor, Python, Ruby, etc.). You are entering an already over-crowded field.

And as I answered : yes, I know :)

But most dynamic languages I know (Python, Ruby, ...) don't have Forth
interpreter principles (RPN, immediate words, ...) that allow to compile
definitions on the flow (source is executable). When Oforth have read a 
definition, it is native code, not bytecode. There is no comparison in 
term of speed.

> By comparison, my FloatForth will not be as convenient as oForth in some ways, but it is not intended to be used for writing quick scripts. 

Yes, Oforth can write scripts. But, of course, Oforth is not limited to that.

> I want FloatForth to be used for pretty heavy-duty number-crunching --- I really can't have + - * / etc. checking the tags on their data every time that they execute

Sorry, I really don't understand your tagged data and checking tags at runtime.
It seems that you refer to how a language is working, but I don't know this
kind of language.

Of course, there is no + method with a switch for all data that support it
and a test to call the correct code. This way you could not add a new + 
for another new data type (complexs, for instance) and this would be
awfully slow.

Oforth, like all languages I know, uses a vtable to hold the xts : 
data -> index -> xt = vtable[index] -> call xt

 --- arithmetic has to be very fast when you are working with large quantities of numeric data. I effectively have polymorphism between integers and floats, because integers are just a subset of floats and so all the arithmetic operators work on both without having to know if the number has a fractional part or not --- I do not use + for concatenating strings however, as that is a totally different concept and hence deserves a different function name.
> 

If you can manage a polymorphism between integers and floats, this would be 
great. You need 64bits for this, no ?
Oforth is not very good with floats. With 64 bits version, I could try this too.

> By the way --- do you know R?
> 

Nope.

Franck

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

#43326 — Re: objects build up from other objects

On Saturday, November 7, 2015 at 8:50:17 AM UTC-7, franck....@gmail.com wrote:
> Le vendredi 6 novembre 2015 07:10:03 UTC+1, hughag...@gmail.com a écrit :
> > I want FloatForth to be used for pretty heavy-duty number-crunching --- I really can't have + - * / etc. checking the tags on their data every time that they execute
> 
> Sorry, I really don't understand your tagged data and checking tags at runtime.
> It seems that you refer to how a language is working, but I don't know this
> kind of language.
> 
> Of course, there is no + method with a switch for all data that support it
> and a test to call the correct code. This way you could not add a new + 
> for another new data type (complexs, for instance) and this would be
> awfully slow.
> 
> Oforth, like all languages I know, uses a vtable to hold the xts : 
> data -> index -> xt = vtable[index] -> call xt

My understanding of this is that you are using the tag as an index into the vtable to obtain the vector to the code that works with that type of data. This is essentially the same as the SWITCH in C (or HLA or almost any other language) that uses the datum as an index into a table of vectors.

In some languages (Racket) there is a 2-bit tag, meaning that there are 4 data-types. A dinary function such as + then has 16 possible permutations, so the vtable is 16 vectors. In other languages (Factor) the tag is 3-bit, meaning that there are 8 data-types, and a dinary function has 64 possible permutations.

Some languages (Common Lisp) allow the programmer to use compile-time directives that indicate what type each datum is, so the vtable look-up doesn't have to be done, but the correct code can be known at compile-time and compiled. The problem with this is that all these directives bloat out the source-code making it difficult to read.

I haven't studied oForth in depth; I'm assuming that it is a pretty typical dynamic-OOP system with tagged data (your comment about the vtable seems to confirm this). Am I missing something here? Is there more to oForth than I'm aware of?

You generate machine-code (so does Factor), which is good --- also, you have support for multi-core computers, which is also good --- so I'm interested in oForth, but I don't think it is similar to FloatForth at all.

>  --- arithmetic has to be very fast when you are working with large quantities of numeric data. I effectively have polymorphism between integers and floats, because integers are just a subset of floats and so all the arithmetic operators work on both without having to know if the number has a fractional part or not --- I do not use + for concatenating strings however, as that is a totally different concept and hence deserves a different function name.
> 
> If you can manage a polymorphism between integers and floats, this would be 
> great. You need 64bits for this, no ?
> Oforth is not very good with floats. With 64 bits version, I could try this too.

Yes, FloatForth will require a 64-bit wide stack. Here is a quote from my FloatForth document (not released yet):

----------------------------------------------------------------------------
FloatForth is for use only on desktop-computers and is not for use on micro-controllers --- FloatForth can be used as a host for a cross-compiler for a micro-controller Forth --- standardization is not all that important with micro-controller Forths because the programs aren't going to be portable anyway due a lot of direct access of I/O and other resources.

The data-stack in FloatForth is required to be 64 bits wide. There are two versions of FloatForth differing in their definition of what a number is:
1.) fixed-version       A number is a signed 64-bit fixed-point with unity assumed to be 2^32.
2.) float-version       A number is an IEEE-754 double-precision float (64 bit total size, with a 56-bit significand).

It is possible that other versions may be introduced later with their own definition of what a number is --- BCD (binary-coded-decimal) would be a possibility --- so long as the number fits in 64 bits and it supports integers in the range +-2GB for use as addresses, then it should be fine.

So, although the name is FloatForth, the language may not support floating-point. For the most part, FloatForth is intended to be implemented on 64-bit processors. FloatForth can be implemented on a 32-bit processor --- reasonable speed could be obtained if the float-version is used and there is a numeric coprocessor available. Addresses are limited to 32-bit (4GB) whether the processor is 64-bit or 32-bit. Addresses are signed (FloatForth doesn't support unsigned numbers) with the heap being in the negative and the dictionary being in the positive.
----------------------------------------------------------------------------

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

#43334 — Re: objects build up from other objects

Le samedi 7 novembre 2015 22:46:58 UTC+1, hughag...@gmail.com a écrit :

> In some languages (Racket) there is a 2-bit tag, meaning that there are 4 data-types. A dinary function such as + then has 16 possible permutations, so the vtable is 16 vectors. In other languages (Factor) the tag is 3-bit, meaning that there are 8 data-types, and a dinary function has 64 possible permutations.

Oforth can have up to 4096 different data-types.

> Some languages (Common Lisp) allow the programmer to use compile-time directives that indicate what type each datum is, so the vtable look-up doesn't have to be done, but the correct code can be known at compile-time and compiled. The problem with this is that all these directives bloat out the source-code making it difficult to read.

Oforth uses also optimizations at compile time. For instance, if the top of 
the stack is known at compile time, then the xt is retrieved at compile time
into the vtable, and not during runtime.

For instance : 

: t perform ;
#t see
       0 : push 8
       2 : push 0
       4 : mov 2b2134, ebx
       9 : call 401480
       E : add 4(esp), esp
      12 : ret

This is a polymorphic call with vtable look-up.

: u #dup perform ;
>#u see
       0 : push 8
       2 : push 0
       4 : mov 336e40, ecx
       9 : mov ecx, -4(edi)
       C : sub 4, edi
       F : mov ecx, ebp
      11 : call 401B20
      16 : add 4(esp), esp
      1A : ret

Here, the top of the stack is known at compile time, so a direct call is
compiled instead of a polymorphic call and the vtable look-up is not done.
There is nothing to add to the source to enable this.

There are other optimizations used at compile time to limit runtime
tasks. One day, I should write a paper about Oforth compilation...

> I haven't studied oForth in depth; I'm assuming that it is a pretty typical dynamic-OOP system with tagged data (your comment about the vtable seems to confirm this). Am I missing something here? Is there more to oForth than I'm aware of?
> 

Well, there are lots of things. If interested, you can look at the
documentation. Its here :
http://www.oforth.com/doc

Franck

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

#43261 — Re: objects build up from other objects

hughaguilar96@gmail.com writes:

>On Thursday, November 5, 2015 at 8:07:17 AM UTC-7, Doug Hoffman wrote:
>> On 11/4/15 12:17 PM, franck.bensusan@gmail.com wrote:
>> > I prefer this "unamed" model than the previous one.
>> >
>> > Here is Oforth version :
>> >
>> > Object Class new: Point(x, y)      // new Point class, subclass of Obje=
>ct
>> > Point method: initialize  :=3D x :=3D y ;  // y x --
>> > Point method: x @x ;    // aPoint -- x
>> > Point method: y @y ;       // aPoint -- y
>> >
>> > Object Class new: Rectangle(ulc, lrc)
>> >
>> > Rectangle method: initialize :=3D lrc :=3D ulc ; // p2 p1 --
>> >
>> > Rectangle method: diagonal // aRectangle -- x
>> >     @ulc x @lrc x - sq
>> >     @ulc y @lrc y - sq
>> >     + sqrt ;
>> >
>> > Point new(14, 13) Point new(10, 10) Rectangle new diagonal .
>> > 5 ok
>>=20
>> Very nice. One can mix in floats with exactly the same Oforth code:
>>=20
>> Point new(14.8, 13) Point new(10, 10.5) Rectangle new diagonal .
>> 5.41202365109392
>>=20
>> Slick. I suspect that one could bend some FMS or other classic Forth oo
>> classes to do something like that, but it would take some more work and
>> perhaps be a bit messy.
>>=20
>> -Doug

>The price of all this slickness is that dynamic-OOP is inherently inefficie=
>nt. Functions such as + have to have a switch inside that does different th=
>ings depending upon the tags attached to each datum that it is working with=
>. Polymorphism doesn't really do anything for you that can't be done otherw=
>ise --- it is just a convenience, and it is an expensive convenience --- al=
>so, it is in conflict with Charles Moore's proverb: "Let the dictionary do =
>the deciding."

I agree with this. If you want two dimensional points and three
dimensional points, you can't use the same name x for their x-coordinates.
[Well, of course Forth allows this possibilty. You can use + to add floats,
if you must. Just put a wordlist on top of the search order to hide
other uses of +.]
Preventing name clashes has nothing to do with OO. It is a totally
different (orthogonal) issue. And expensive, as you say.
I would add confusing.

x2 y2 etc. apply to the current 2-dim point.
x3 y3! z3  apply to the current 3-dim point object.

So stupid. It must be Forth.

<SNIP>

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#43263 — Re: objects build up from other objects

On 06/11/2015 02:20, Albert van der Horst wrote:
> hughaguilar96@gmail.com writes:
>

>
>> The price of all this slickness is that dynamic-OOP is inherently inefficie=
>> nt. Functions such as + have to have a switch inside that does different th=
>> ings depending upon the tags attached to each datum that it is working with=
>> . Polymorphism doesn't really do anything for you that can't be done otherw=
>> ise --- it is just a convenience, and it is an expensive convenience --- al=
>> so, it is in conflict with Charles Moore's proverb: "Let the dictionary do =
>> the deciding."
>
> I agree with this. If you want two dimensional points and three
> dimensional points, you can't use the same name x for their x-coordinates.
> [Well, of course Forth allows this possibilty. You can use + to add floats,
> if you must. Just put a wordlist on top of the search order to hide
> other uses of +.]
> Preventing name clashes has nothing to do with OO. It is a totally
> different (orthogonal) issue. And expensive, as you say.
> I would add confusing.

I also agree. That's why "classes" in 8th are really just namespaces. 
Such inheritance as there is, is only namespace lookup to parent classes 
(and I don't use that in fact).

So we have a "+" for strings to concatenate, and a "+" for numbers to 
add, and a "+" for arrays to concatenate.  The difference is the class, 
"s:+", "n:+" or "o:+"

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

#43239 — Re: objects build up from other objects

On 11/4/15 9:44 AM, Albert van der Horst wrote:
> I've stood up to the challenge to show how ciforth's mini-OO (with current
> object) can be used to build larger objects.
> REGRESS is a new invention, it is like the { <- } of
> Hopkins test suite. In my system it aborts if the test fails,
> but you can see it as a stack diagram by example.
>
> Once you have a class Point (a defining word) you get also
> ^Point  :contains the pointer to the current Point)
> BUILD-Point : lay down a data structure in memory, leave its address.
>
> There is no current object per se. Only current Point, current Rectangle
> etc.
>
> There are no fields. Offsets into an objects data are hidden.
> In this example you only have x (a getter) and x! (a setter)
>
> I've commented out y^ which would be the closest thing to a field.
>
> Unlike CREATE DOES> the code precedes the creation of the data.
> Like create DOES> the code is started with the address of its data on
> the data stack.
> Unlike CREATE DOES> code can work on an arbitrary offset of the
> data.
>
> _ is don't care data.
>
> Note that unless the current rectangle is filled in ( ^Rectangle
> contains an address) words like diagonal will crash.
>
> BUILD-something can be used to make an array of somethings.
>
> \ --------------------------------------------------------
> WANT class
> WANT SQRT
> WANT SQ
> WANT INCLUDE
> WANT REGRESS
>
> \ Calculates the distance between two points. (hypothenusa).
> : HYP  ROT - SQ ROT ROT - SQ + SQRT ;
> REGRESS 10 10 14 13 HYP S: 5
>
> class Point   \ ( -- ) unitialised
>      M: x @ M;
>      M: x! ! M;    _ ,
> \    M: y^ M;
>      M: y @ M;
>      M: y! ! M;    _ ,
> endclass
> REGRESS Point Q FORGET Q S:
>
> class Rectangle
>     M: upper-left-corner ^Point ! M;   BUILD-Point DROP
>     M: lower-right-corner ^Point ! M;   BUILD-Point DROP
> endclass
> REGRESS Rectangle Q S:
>
> \ Store X1 Y1 X2 Y2 into a Rectangle
> : init-Rect lower-right-corner y! x! upper-left-corner y! x! ;
> REGRESS 10 10 40 50 Q init-Rect S:
>
> \ Return the LENGTH of the diagonal of the current Rectangle
> : diagonal   upper-left-corner x y lower-right-corner x y HYP ;
> REGRESS Q diagonal S: 50
>
> \ -------------------------- some test code ---------------------
>
> Rectangle this-mine-self
>
> this-mine-self    10 10 40 50 init-Rect
>
> Rectangle other-rect
>
> other-rect  upper-left-corner x CR . \ expect garbage
>
> CR
> |Expect 50 :" TYPE
> this-mine-self    diagonal .     CR
>
> \--------------------------------------------------
>
> It would be interesting to see how composing objects
> works in other OO's.

I think Franck Bensusan's Oforth is an important contribution and shows
a lot of potential. He started with a clean sheet Forth and with it a
new model for doing objects in Forth. Well worth studying what he has
done IMO.


Meanwhile, there is this way that works on any ANS Forth:

Needs the FMS-SI library code located in FLAG:
http://soton.mpeforth.com/flag/fms/index.html
include FMS-SI.f

: sq ( n -- n^2 ) dup * ;
: sqrt ( n -- sqrt ) s>f fsqrt f>s ;
: hyp ( x1 y1 x2 y2 -- hyp )
   rot - sq rot rot - sq + sqrt ;

:class point
   cell bytes x
   cell bytes y
   :m put ( x y -- ) y ! x ! ;m
   :m get ( -- x y ) x @ y @ ;m
;class

:class rectangle
   point ulc
   point lrc
   :m diagonal ( -- diag )
      ulc get lrc get hyp ;m
   :m put ( x1 y1 x2 y2 -- )
      lrc put ulc put ;m
;class

\ named rectangle in dictionary
rectangle r
20 20 50 50 r put  r diagonal . 42 ok

\ nameless rectangle in heap
heap> rectangle value hr
10 10 13 14 hr put  hr diagonal . 5
hr <free  ok \ must manually garbage collect

\ if you want message-less access to instance variables
.. r.ulc.x ? 20
.. r.ulc.y ? 20
.. r.lrc.x ? 50
.. r.lrc.y ? 50 ok

-Doug

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

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

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

csiph-web