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

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

OOP packages

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

Contents

  OOP packages hwfwguy@gmail.com - 2012-05-08 09:31 -0700
    Re: OOP packages "Elizabeth D. Rather" <erather@forth.com> - 2012-05-08 09:10 -1000
      Re: OOP packages stephenXXX@mpeforth.com (Stephen Pelc) - 2012-05-08 20:17 +0000
        Re: OOP packages hwfwguy@gmail.com - 2012-05-08 18:26 -0700
        Re: OOP packages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-09 11:34 +0000
          Re: OOP packages Doug Hoffman <glidedog@gmail.com> - 2012-05-09 08:00 -0400
            Re: OOP packages Bernd Paysan <bernd.paysan@gmx.de> - 2012-05-09 19:49 +0200
            Re: OOP packages anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-10 11:39 +0000
              Re: OOP packages Doug Hoffman <glidedog@gmail.com> - 2012-05-10 12:48 -0400
            Re: OOP packages Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-05-10 02:26 -0700
    Re: OOP packages BruceMcF <agila61@netscape.net> - 2012-05-08 12:39 -0700
    Re: OOP packages Doug Hoffman <glidedog@gmail.com> - 2012-05-08 15:56 -0400
    Re: OOP packages hwfwguy@gmail.com - 2012-05-10 17:04 -0700
      Re: OOP packages Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-05-11 02:02 -0700
      Re: OOP packages Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-05-15 10:32 +0000
      Re: OOP packages Doug Hoffman <glidedog@gmail.com> - 2012-05-15 08:35 -0400
        Re: OOP packages mhx@iae.nl (Marcel Hendrix) - 2012-05-15 20:37 +0200
          Re: OOP packages Doug Hoffman <glidedog@gmail.com> - 2012-05-15 15:22 -0400
          Re: OOP packages Doug Hoffman <glidedog@gmail.com> - 2012-05-15 21:50 -0400
            Re: OOP packages mhx@iae.nl (Marcel Hendrix) - 2012-05-17 08:11 +0200
              Re: OOP packages Doug Hoffman <glidedog@gmail.com> - 2012-05-17 08:55 -0400
                Re: OOP packages Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2012-05-22 08:39 +0100
                  Re: OOP packages Doug Hoffman <glidedog@gmail.com> - 2012-05-22 07:02 -0400
                    Re: OOP packages Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2012-05-22 13:14 +0100
                    Re: OOP packages Coos Haak <chforth@hccnet.nl> - 2012-05-22 18:11 +0200
                      Re: OOP packages Doug Hoffman <glidedog@gmail.com> - 2012-05-22 14:23 -0400
                        Re: OOP packages Coos Haak <chforth@hccnet.nl> - 2012-05-23 19:47 +0200
                          Re: OOP packages Doug Hoffman <glidedog@gmail.com> - 2012-05-23 14:58 -0400
                    Re: OOP packages Doug Hoffman <glidedog@gmail.com> - 2012-05-31 07:43 -0400
              Re: OOP packages "Peter Knaggs" <pjk@bcs.org.uk> - 2012-05-17 19:31 +0100
                Re: OOP packages Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-05-17 21:59 -0700
                  Re: OOP packages digital.wilderness@googlemail.com - 2012-05-18 01:51 -0700

Page 1 of 2  [1] 2  Next page →

#11988 — OOP packages

Hi All,

Which OOP packages are common to both the VFX and SwiftForth communities? I know of SWOOP but there could be others.

-Brad

[toc] | [next] | [standalone]

#11991

On 5/8/12 6:31 AM, hwfwguy@gmail.com wrote:
> Hi All,
>
> Which OOP packages are common to both the VFX and SwiftForth communities? I know of SWOOP but there could be others.
>
> -Brad

SWOOP is only in SwiftForth. VFX's OOP is quite different.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#11996

On Tue, 08 May 2012 09:10:00 -1000, "Elizabeth D. Rather"
<erather@forth.com> wrote:

>> Which OOP packages are common to both the VFX and SwiftForth
>> communities? I know of SWOOP but there could be others.
>
>SWOOP is only in SwiftForth. VFX's OOP is quite different.

With Leon's permission, there are versions of SWOOP for both
SwiftForth and VFX at FLAG
  http://soton.mpeforth.com/flag/

FLAG also has Doug Hoffman's FMS, which is probably the most
widely ported OOP system of them all.

Stephen


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

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

#12010

On Tuesday, May 8, 2012 1:17:42 PM UTC-7, Stephen Pelc wrote:
> FLAG also has Doug Hoffman's FMS, which is probably the most
> widely ported OOP system of them all.

That's a enough good endorsement for me, seeing that Doug is no Johnny Come Lately. I'll have a look.

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

#12028

stephenXXX@mpeforth.com (Stephen Pelc) writes:
>FLAG also has Doug Hoffman's FMS, which is probably the most
>widely ported OOP system of them all.

On what evidence do you base this claim?

- 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 2011: http://www.euroforth.org/ef11/

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

#12033

On 5/9/12 7:34 AM, Anton Ertl wrote:
> stephenXXX@mpeforth.com (Stephen Pelc) writes:
>> FLAG also has Doug Hoffman's FMS, which is probably the most
>> widely ported OOP system of them all.
>
> On what evidence do you base this claim?

Stephen properly qualified the statement with "probably".
It's a reasonable statement, given that implementation-specific build 
harnesses are provided for each Forth mentioned along with a generic 
build harness.  Over 15 pre-defined classes are provided (collections, 
object containers, strings, arrays, balanced tree) along with a Hayes 
test harness to exercise them all, with the test harness tuned to each 
Forth.

If someone has done something similar with another full featured objects 
extension (encapsulation, late binding, etc.) they should speak up.

-Doug

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

#12041

Doug Hoffman wrote:
> If someone has done something similar with another full featured
> objects extension (encapsulation, late binding, etc.) they should
> speak up.

Well, BerndOOF is available as plain ANS Forth source, without any 
harness needed (part of Gforth).  It does not come with a predefined set 
of classes, though.

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

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

#12060

Doug Hoffman <glidedog@gmail.com> writes:
>On 5/9/12 7:34 AM, Anton Ertl wrote:
>> stephenXXX@mpeforth.com (Stephen Pelc) writes:
>>> FLAG also has Doug Hoffman's FMS, which is probably the most
>>> widely ported OOP system of them all.
>>
>> On what evidence do you base this claim?
>
>Stephen properly qualified the statement with "probably".

Do you mean that no evidence is needed then?  Why not?

>It's a reasonable statement, given that implementation-specific build 
>harnesses are provided for each Forth mentioned along with a generic 
>build harness.

Why does it need implementation-specific build harnesses?

>If someone has done something similar with another full featured objects 
>extension (encapsulation, late binding, etc.) they should speak up.

No implementation-specific build harnesses for objects.fs, it's just
written in standard Forth, i.e., it is portable.

- 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 2011: http://www.euroforth.org/ef11/

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

#12066

On 5/10/12 7:39 AM, Anton Ertl wrote:

> Why does it need implementation-specific build harnesses?

User convenience mostly.  Needed?  No.  I found it cleaner to use 
separate files.  Could have used conditional compilation like s" gforth" 
environment? [if] ...

It seems Forths use different file load schemes, e.g.,
  - include %idir%/fmsHarnxxx.f , invoke from console menu
  - or myfolder.include" fmsHarnxxx.f"
  - or include fmsHarnxxx.f , invoke from console menu
  - or include e:\<pathname>\fmsBuildxx.f , invoke by paste to console 
or place all files in a default diectory

One of the Forths prefers a USER variable instead of a VALUE for a 
specific variable.

Some Forth's have issue with the maximum number of wordlists available 
for SET-ORDER.  If objects.fs provided a library of classes along with a 
comprehensive Hayes testing suite it may also have bumped into this 
issue if also tested on that Forth.

At least one Forth needs a specific utility file loaded to support DEFER.

Having a build file also consolidates the FMS options to one place for 
things like the following:
  - Turn error checking on/off  (array indexes and 
message-not-understood handling).
  - Run the Hayes test suite or not.

Other issues like the above.


> No implementation-specific build harnesses for objects.fs, it's just
> written in standard Forth, i.e., it is portable.

FMS is written in standard Forth and FMS is portable.

-Doug

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

#12128

On May 9, 6:00 am, Doug Hoffman <glide...@gmail.com> wrote:
> On 5/9/12 7:34 AM, Anton Ertl wrote:
>
> > stephen...@mpeforth.com (Stephen Pelc) writes:
> >> FLAG also has Doug Hoffman's FMS, which is probably the most
> >> widely ported OOP system of them all.
>
> > On what evidence do you base this claim?
>
> Stephen properly qualified the statement with "probably".
> It's a reasonable statement, given that implementation-specific build
> harnesses are provided for each Forth mentioned along with a generic
> build harness.  Over 15 pre-defined classes are provided (collections,
> object containers, strings, arrays, balanced tree) along with a Hayes
> test harness to exercise them all, with the test harness tuned to each
> Forth.
>
> If someone has done something similar with another full featured objects
> extension (encapsulation, late binding, etc.) they should speak up.
>
> -Doug

My novice package provides a crude step toward OOP. I don't have
polymorphism. I basically just have inheritance. It is possible to
clone data structures, even if they contain a variety of data types
(that is the whole point of ALLOCATION). It is pretty simple, but it
works well for me. It is also quite fast.

The 2 predefined classes that I have are lists and balanced trees (I
use lists for pretty much everything). I also have arrays, but that
isn't really OOP, as every element is the same data type (they pretty
much have to be, with arrays).

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

#11993

On May 8, 12:31 pm, hwfw...@gmail.com wrote:
> Hi All,
>
> Which OOP packages are common to both the VFX and SwiftForth communities? I know of SWOOP but there could be others.
>
> -Brad

I know that Mini-OOF, included with gforth, is Forth94 and works with
both VFX and Swiftforth ~ gforth also includes OOF and objects that
are both advertised as "written in ANS Forth and can be used with any
other ANS Forth", though I've never tested that out.

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

#11994

On 5/8/12 12:31 PM, hwfwguy@gmail.com wrote:

> Which OOP packages are common to both the VFX and SwiftForth communities? I know of SWOOP but there could be others.

FMS is ANS compatible and has been thoroughly tested on VFX, SwiftForth, 
Gforth, iForth, Win32Forth, and Carbon MacForth.

http://soton.mpeforth.com/flag/fms/index.html

-Doug

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

#12134

On Tuesday, May 8, 2012 9:31:39 AM UTC-7, hwf...@gmail.com wrote:
> Hi All,
> 
> Which OOP packages are common to both the VFX and SwiftForth communities? I know of SWOOP but there could be others.
> 
> -Brad

I may have asked the wrong question. It's hard to evaluate the many OOPs out there. Maybe what I'm looking for is a sample problem that is solved in several dialects of OOP. That would provide some metrics.

Having spent the day in C#, the object.method syntax is starting to grow on me. But that's just encapsulation. A Forth could take a foo.bar syntax to mean "look for bar only in the foo wordlists". After all, Foo can have more than one wordlist depending on its ancestry. AFAIK some of the OOPs support FOO.BAR as FOO BAR to avoid patching the interpreter.

The base class could have some toolkit words: foo.words lists the words in the foo wordlist(s), foo.help lists a glossary, or foo.edit opens the source in an editor.

Maybe I'm oversimpifying. Many OOP features are less important to supply in Forth because load order and CREATE DOES> provide much of their functionality already. 

The primary use of OOP seems to be encapsulation, followed by its cousin polymorphism. Rather than adopt an OOP with hundreds of LOC, I might adopt one with tens of lines.

But that takes me back to Stephen's point that nobody can write OOP-based libraries because of the Babel of OOPs. I'm looking for one to emerge from the primordial soup. Something that doesn't eat up a lot of RAM in an embedded system, for starters.

-Brad

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

#12138

On May 10, 5:04 pm, hwfw...@gmail.com wrote:
> I may have asked the wrong question. It's hard to evaluate the many OOPs out there. Maybe what I'm looking for is a sample problem that is solved in several dialects of OOP. That would provide some metrics.

Use this sample problem:
https://groups.google.com/group/comp.lang.forth/browse_thread/thread/dd8e30fcc7589749?hl=en#

That is a simple example of inheritance --- I have classes derived
from SEQ or SSEQ in there.

> I'm looking for one to emerge from the primordial soup. Something that doesn't eat up a lot of RAM in an embedded system, for starters.

Mine is crude, but it is very simple --- it would work on a micro-
controller with little RAM --- all you need is enough for a heap,
which could be as little as 4K.

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

#12178

In article <11255290.346.1336694692356.JavaMail.geo-discussion-forums@vbjb10>,
 <hwfwguy@gmail.com> wrote:
 <SNIP>
>
>Maybe I'm oversimpifying. Many OOP features are less important to supply in=
> Forth because load order and CREATE DOES> provide much of their functional=
>ity already.=20
>
>The primary use of OOP seems to be encapsulation, followed by its cousin po=
>lymorphism. Rather than adopt an OOP with hundreds of LOC, I might adopt on=
>e with tens of lines.
>
>But that takes me back to Stephen's point that nobody can write OOP-based l=
>ibraries because of the Babel of OOPs. I'm looking for one to emerge from t=
>he primordial soup. Something that doesn't eat up a lot of RAM in an embedd=
>ed system, for starters.

I'm still fond of my two screen OOP. It served me quite well in the
MANX (playing tunes on metallophones) and ciasdis projects.
Doesn't cost much resources.
It is certainly lightweight: 2 screens in ciforth.

>
>-Brad

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]

#12188

On 5/10/12 8:04 PM, hwfwguy@gmail.com wrote:

 > I may have asked the wrong question. It's hard to evaluate the many
 > OOPs out there. Maybe what I'm looking for is a sample problem that
 > is solved in several dialects of OOP. That would provide some
 > metrics.

It helps to know exactly what you want.  Everyone seems to have their 
own definition of what constitutes a minimum set of behaviors for object 
programming.

 > Having spent the day in C#, the object.method syntax is starting to
 > grow on me.

 > The primary use of OOP seems to be encapsulation, followed by its
 > cousin polymorphism. Rather than adopt an OOP with hundreds of LOC, I
 > might adopt one with tens of lines.

~40 lines or less? (compiles to 1652 bytes on Carbon MacForth)

-Doug


\ micro-FMS Douglas B. Hoffman	05/15/12 largely untested

\ Full encapsulation of data and methods.
\ Polymorphism with no restrictions on inheritance order.
\ Dynamic (late) binding of methods.
\ Duck typing.
\ Instantiate objects in the dictionary or the heap.

0 value self
0 value ^class
: dfa  1 cells + ;
: sfa  2 cells + ;
: wida 3 cells + ;
4 cells constant classSize
: find-method  ( sel class -- xt)
   begin @ dup while 2dup cell+ @ = if 2 cells + nip @ exit then
   repeat throw ;
: execute-method ( o xt --) self >r swap to self execute r>  to self ;
create object classSize here over allot swap erase
: set-search-order ^class >r get-order begin r@ wida @ swap 1+
   r> sfa @ >r  r@ object = until r> drop set-order ;
: :class ( "name" --) create ;
: <super ( -- wn..w1 n)
   here to ^class classSize allot ' >body dup ^class classSize move
   ^class sfa !  get-order wordlist ^class wida ! set-search-order ;
: ;class ( wn..w1 n --) set-order ;
: send ( o sel --) over 1 cells - @  find-method execute-method ;
: selector  ( "name" --) create does> send ;
: getselect  ( -- sel) >in @  bl word find
   if >body nip else drop >in ! selector here then ;
: :m  ( "name" -- a xt) forth-wordlist set-current
   getselect align ^class here over @ , swap ! , here 0 , :noname ;
: ;m ( a xt --) postpone ; swap ! ; immediate
: super ( "name" --) ' >body ^class sfa @ find-method compile, ; immediate
: (ivar) ( "name" -- a) create immediate ,
   does> @ postpone literal postpone self postpone + ;
: bytes ( n "name" --) align ^class wida @ set-current
   ^class dfa @ (ivar) ^class dfa +! ;
: pre-obj ( ^class -- n class n+cell) dup dfa @ swap over cell+ ;
: post-obj ( n class o -- o) dup cell+ >r ! r@ swap erase r> ;
defer allotocate ( n+cell -- o)
: makeobj  ( class -- o) pre-obj allotocate post-obj ;
: dict-allot ( n+cell -- o) align here swap ( n ) allot ;
: heap-allocate ( n+cell -- o) allocate throw ;
: make ( xt -- o) is allotocate ' >body state @
   if postpone literal postpone makeobj else makeobj then ;
: dict> ( class --o) ['] dict-allot make ; immediate
: heap> ( class --o) ['] heap-allocate make ; immediate
: <free  ( o --) 1 cells - free throw ;

\ examples

:class var <super object
   1 cells bytes data
  :m !: ( n -- ) data ! ;m
  :m @: ( -- n ) data @ ;m
  :m p: self @: . ;m \ print self
  :m init: 5 self !: ;m
;class

dict> var value x
x init: ok
x p: 5 ok

heap> var value h
55 h !: ok
h p: 55 ok
h <free ok

:class var2 <super var
    1 cells bytes data2
    1 cells bytes data3
:m dump: data dup . @ . data2 dup . @ . data3 dup . @ p: ;m
:m init: super init: dict> var data3 ! ;m \ embed object in ivar
:m test: data3 @ p: ;m
;class

dict> var2 value v2

v2 init: ok

v2 dump:
16864328 5 16864332 0 16864336 0 ok

v2 test: 0 ok

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

#12194

Doug Hoffman <glidedog@gmail.com> writes Re: OOP packages

> On 5/10/12 8:04 PM, hwfwguy@gmail.com wrote:
[..]

> ~40 lines or less? (compiles to 1652 bytes on Carbon MacForth)

FORTH> include class.frt
5
55
19200624 5 19200632 0 19200640 0
0  ok
[9]FORTH> .s
  Data: 5 55 16864328 5 16864332 0 16864336 0 0 ---
System: ---
 Float: --- ok

I think this is correct, but why does the stack have copies
of each printed number?

(I could not fix the source myself in a reasonable amount of time).

-marcel

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

#12196

On 5/15/12 2:37 PM, Marcel Hendrix wrote:
> Doug Hoffman<glidedog@gmail.com>  writes Re: OOP packages
>
>> On 5/10/12 8:04 PM, hwfwguy@gmail.com wrote:
> [..]
>
>> ~40 lines or less? (compiles to 1652 bytes on Carbon MacForth)
>
> FORTH>  include class.frt
> 5
> 55
> 19200624 5 19200632 0 19200640 0
> 0  ok
> [9]FORTH>  .s
>    Data: 5 55 16864328 5 16864332 0 16864336 0 0 ---
> System: ---
>   Float: --- ok
>
> I think this is correct, but why does the stack have copies
> of each printed number?

Hence the meaning of "Largely untested".
Don't know.  It runs fine and without the extra stack items on VFX 
Forth, Gforth, SwiftForth, Alex's w32f, and Carbon MacForth.  I just now 
tried it on iForth and I can't even get it to compile.  I'll take a look 
at it.  I expect it's something not serious.  Thanks for the report.

Another question I have is does this get at the OP's issue?

-Doug

p.s. With this "minimalist" extension one has to be careful about 
message names.  For example if you already have a "dump:" defined for 
something else then that will cause a bug.  Easy to fix with more lines 
of code, which the OP was wanting to avoid.

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

#12204

On 5/15/12 2:37 PM, Marcel Hendrix wrote:
> Doug Hoffman<glidedog@gmail.com>  writes Re: OOP packages
>
>> On 5/10/12 8:04 PM, hwfwguy@gmail.com wrote:
> [..]
>
>> ~40 lines or less? (compiles to 1652 bytes on Carbon MacForth)
>
> FORTH>  include class.frt
> 5
> 55
> 19200624 5 19200632 0 19200640 0
> 0  ok
> [9]FORTH>  .s
>    Data: 5 55 16864328 5 16864332 0 16864336 0 0 ---
> System: ---
>   Float: --- ok
>
> I think this is correct, but why does the stack have copies
> of each printed number?
>
> (I could not fix the source myself in a reasonable amount of time).

try replacing the one DEFER word with a value, then change the two other 
definitions affected (changes in UPPER CASE):

0 VALUE allotocate
: makeobj  ( class -- o) pre-obj allotocate EXECUTE post-obj ;
: make ( xt -- o) TO allotocate ' >body state @
   if postpone literal postpone makeobj else makeobj then ;

This then compiled and ran fine for me on my version of iForth, no 
extraneous stack items.

-Doug

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

#12219

Doug Hoffman <glidedog@gmail.com> wrote Re: OOP packages

> On 5/15/12 2:37 PM, Marcel Hendrix wrote:
>> Doug Hoffman<glidedog@gmail.com>  writes Re: OOP packages
[..]

> try replacing the one DEFER word with a value, then change the two other 
> definitions affected (changes in UPPER CASE):

> 0 VALUE allotocate
> : makeobj  ( class -- o) pre-obj allotocate EXECUTE post-obj ;
> : make ( xt -- o) TO allotocate ' >body state @
>   if postpone literal postpone makeobj else makeobj then ;

> This then compiled and ran fine for me on my version of iForth, no 
> extraneous stack items.

Actually, only one change is necessary: iForth's compiled IS is
written as [IS], like this:

: make ( xt -- o) [is] allotocate ' >body state @
   if postpone literal postpone makeobj else makeobj then ;

The problem with the extra stack items was my test: 
it was based on insufficient understanding of your code. I should
not have pasted the output of your posting verbatim. 

\ Original (wrong) test
dict> var value x
x .s init: \ ok
cr x p: 5  \ ok

\ New test
dict> var value x
x .s init: \ ok
cr x p:    \ 5 ok

Sorry about that.

Conclusion: This OOP package works on all major Forths with only 
a single cosmetic (is DEFER standard already?) change.

-marcel

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web