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

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

Status of OO in Forth?

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

Contents

  Status of OO in Forth? "A. K." <akk@nospam.org> - 2012-04-07 14:27 +0200
    Re: Status of OO in Forth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-08 16:29 +0000
      Re: Status of OO in Forth? Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-08 12:17 -0700
        Re: Status of OO in Forth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-09 09:26 +0000
          Re: Status of OO in Forth? Doug Hoffman <glidedog@gmail.com> - 2012-04-09 08:08 -0400
            Re: Status of OO in Forth? Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-09 05:58 -0700
              Re: Status of OO in Forth? Doug Hoffman <glidedog@gmail.com> - 2012-04-09 15:01 -0400
              Re: Status of OO in Forth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-10 08:22 +0000
                Re: Status of OO in Forth? Doug Hoffman <glidedog@gmail.com> - 2012-04-10 08:00 -0400
                  Re: Status of OO in Forth? Doug Hoffman <glidedog@gmail.com> - 2012-04-10 08:35 -0400
                  Re: Status of OO in Forth? "David N. Williams" <williams@umich.edu> - 2012-04-10 08:42 -0400
        Re: Status of OO in Forth? Doug Hoffman <glidedog@gmail.com> - 2012-04-24 08:55 -0400
          Re: Status of OO in Forth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-24 09:52 -0500
            Re: Status of OO in Forth? Doug Hoffman <glidedog@gmail.com> - 2012-04-24 10:58 -0400
              Re: Status of OO in Forth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-24 11:43 -0500
                Re: Status of OO in Forth? Doug Hoffman <glidedog@gmail.com> - 2012-04-25 08:41 -0400
                  Re: Status of OO in Forth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-25 07:52 -0500
                    Re: Status of OO in Forth? Doug Hoffman <glidedog@gmail.com> - 2012-04-25 09:47 -0400
                      Re: Status of OO in Forth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-25 10:37 -0500
                        Re: Status of OO in Forth? Doug Hoffman <glidedog@gmail.com> - 2012-04-25 12:18 -0400
                          Re: Status of OO in Forth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-25 11:39 -0500
                  Re: Status of OO in Forth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-25 15:16 +0000
                    Re: Status of OO in Forth? Paul Rubin <no.email@nospam.invalid> - 2012-04-25 08:33 -0700
                    Re: Status of OO in Forth? Doug Hoffman <glidedog@gmail.com> - 2012-04-25 11:52 -0400
                      Re: Status of OO in Forth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-26 16:26 +0000
                        Re: Status of OO in Forth? Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-26 13:09 -0700
                          Re: Status of OO in Forth? "Elizabeth D. Rather" <erather@forth.com> - 2012-04-26 14:20 -1000
                          Re: Status of OO in Forth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-27 09:21 +0000
                        Re: Status of OO in Forth? Doug Hoffman <glidedog@gmail.com> - 2012-04-26 21:42 -0400
            Re: Status of OO in Forth? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-24 16:47 +0000
              Re: Status of OO in Forth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-24 12:02 -0500

Page 1 of 2  [1] 2  Next page →

#10982 — Status of OO in Forth?

I do NOT want to start a discussion about OO implementation variants in 
Forth.

I am just curious whether there is a standardization proposal "under 
way" or had it been abandoned completely? And at least IMO it is closely 
connected to the libraries issue that had been discussed some years ago.

Andreas

[toc] | [next] | [standalone]

#10997

"A. K." <akk@nospam.org> writes:
>I am just curious whether there is a standardization proposal "under 
>way"

No.

> or had it been abandoned completely?

No.  There are some people who want a standard OO system for Forth.

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

#11000

On Apr 8, 5:29 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> "A. K." <a...@nospam.org> writes:
> >I am just curious whether there is a standardization proposal "under
> >way"
>
> No.
>
> > or had it been abandoned completely?
>
> No.  There are some people who want a standard OO system for Forth.
>
> - 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/

I'd like to see one, too. One that doesn't rely on the somewhat hacky
'vocabulary sealing' technique.

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

#11027

Mark Wills <markrobertwills@yahoo.co.uk> writes:
>I'd like to see one, too. One that doesn't rely on the somewhat hacky
>'vocabulary sealing' technique.

The core of objects.fs works without any vocabularies, so I guess it
does not rely on "vocabulary sealing", whatever that may be.  There is
a bit of wordlist stuff for allowing the same name for (different)
instance variables of different classes, though; that's because the
classic prefix approach for avoiding name collisions does not work
well with inheritance.

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

#11034

On 4/9/12 5:26 AM, Anton Ertl wrote:
> Mark Wills<markrobertwills@yahoo.co.uk>  writes:
>> I'd like to see one, too. One that doesn't rely on the somewhat hacky
>> 'vocabulary sealing' technique.
>
> The core of objects.fs works without any vocabularies, so I guess it
> does not rely on "vocabulary sealing", whatever that may be.  There is
> a bit of wordlist stuff for allowing the same name for (different)
> instance variables of different classes, though; that's because the
> classic prefix approach for avoiding name collisions does not work
> well with inheritance.

The same applies to FMS.  There is one extra wordlist to hide the 
non-user definitions, but that can be removed in about 30 seconds.

-Doug

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

#11035

On Apr 9, 1:08 pm, Doug Hoffman <glide...@gmail.com> wrote:
> On 4/9/12 5:26 AM, Anton Ertl wrote:
>
> > Mark Wills<markrobertwi...@yahoo.co.uk>  writes:
> >> I'd like to see one, too. One that doesn't rely on the somewhat hacky
> >> 'vocabulary sealing' technique.
>
> > The core of objects.fs works without any vocabularies, so I guess it
> > does not rely on "vocabulary sealing", whatever that may be.  There is
> > a bit of wordlist stuff for allowing the same name for (different)
> > instance variables of different classes, though; that's because the
> > classic prefix approach for avoiding name collisions does not work
> > well with inheritance.
>
> The same applies to FMS.  There is one extra wordlist to hide the
> non-user definitions, but that can be removed in about 30 seconds.
>
> -Doug

I'd be interested to know (in both FMS and objects.fs) how (for
example) methods that belong to one class are prevented from being
visible to another (unrelated) class.

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

#11048

On 4/9/12 8:58 AM, Mark Wills wrote:

> I'd be interested to know (in ... FMS ...) how (for
> example) methods that belong to one class are prevented from being
> visible to another (unrelated) class.

Many ways to do this.  In FMS I show two:

1) Each message is a unique number (in this case a unique address). 
Each object has a class identifier in its first cell.  The method xt is 
searched for in a linked-list.  The class identifier determines which 
list to search and the message is the search key.

2) Each message is a unique integer offset.  Each object has a class 
identifier in its first cell.  The class identifier is the address of a 
lookup table.  Add the message to the address and you have the address 
of the method xt.  This is faster than 1) with the only downside being 
somewhat larger code size for each class (table compression is used so 
it's not a significant issue).

But an FMS implementation could use any technique as long as the other 
requirements are met.  Or you could bend FMS to behave pretty much any 
way you want since it's written in essentially all ANS Forth and the 
complete source is provided.  Though I think it would be hard to bend it 
into a prototype-based extension.  Maybe not.  I haven't tried.

-Doug

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

#11091

Mark Wills <markrobertwills@yahoo.co.uk> writes:
>I'd be interested to know (in both FMS and objects.fs) how (for
>example) methods that belong to one class are prevented from being
>visible to another (unrelated) class.

For objects.fs, they aren't.  This is Forth.  It's the programmer's
responsibility to use the right words with the right things being on
the stack.

For FMS, I guess they are not, either.  First, this is Forth; see
above.  Second, it meets Smalltalk (the S in FMS).  A feature of
Smalltalk that Doug Hoffman very much likes is that you can send any
message to any object of any class; two classes might understand a
message even if none of their common ancestors are able to understand
it.  This is the basis for duck typing.

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

#11104

On 4/10/12 4:22 AM, Anton Ertl wrote:
> Mark Wills<markrobertwills@yahoo.co.uk>  writes:
>> I'd be interested to know (in both FMS and objects.fs) how (for
>> example) methods that belong to one class are prevented from being
>> visible to another (unrelated) class.
>
> For objects.fs, they aren't.  This is Forth.  It's the programmer's
> responsibility to use the right words with the right things being on
> the stack.
>
> For FMS, I guess they are not, either.  First, this is Forth; see
> above.  Second, it meets Smalltalk (the S in FMS).  A feature of
> Smalltalk that Doug Hoffman very much likes is that you can send any
> message to any object of any class; two classes might understand a
> message even if none of their common ancestors are able to understand
> it.  This is the basis for duck typing.

Yes.  I do prefer duck typing.

Distinguishing messages from methods, they are two different things, it 
is not possible in FMS for an object to see the wrong *method* unless 
the programmer does something grossly wrong such as attempting to force 
an early bind via CLASS_AS> using an incompatible class.  If a message 
is sent that is not understood by the object then the FMS system throws 
up an error "Message not understood".

-Doug

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

#11105

On 4/10/12 8:00 AM, Doug Hoffman wrote:
> On 4/10/12 4:22 AM, Anton Ertl wrote:
>> Mark Wills<markrobertwills@yahoo.co.uk> writes:
>>> I'd be interested to know (in both FMS and objects.fs) how (for
>>> example) methods that belong to one class are prevented from being
>>> visible to another (unrelated) class.
>>
>> For objects.fs, they aren't. This is Forth. It's the programmer's
>> responsibility to use the right words with the right things being on
>> the stack.
>>
>> For FMS, I guess they are not, either. First, this is Forth; see
>> above. Second, it meets Smalltalk (the S in FMS). A feature of
>> Smalltalk that Doug Hoffman very much likes is that you can send any
>> message to any object of any class; two classes might understand a
>> message even if none of their common ancestors are able to understand
>> it. This is the basis for duck typing.
>
> Yes. I do prefer duck typing.
>
> Distinguishing messages from methods, they are two different things, it
> is not possible in FMS for an object to see the wrong *method* unless
> the programmer does something grossly wrong such as attempting to force
> an early bind via CLASS_AS> using an incompatible class. If a message is
> sent that is not understood by the object then the FMS system throws up
> an error "Message not understood".

Or perhaps I misread the question from Mark Wills.  If so, sorry, and 
Anton's response would be correct in the sense that any *class* could be 
forced to use (see) methods from any other unrelated *class*.  Not the 
common thing to do but certainly possible.

-Doug

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

#11106

On 4/10/12 8:00 AM, Doug Hoffman wrote:
 > [...]
>
> Yes. I do prefer duck typing.

Hmm!  I just looked this up in Wikipedia, and
was surprised to learn that it's not the 'strine
pronunciation of "duct taping".

-- David

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

#11564

On 4/8/12 3:17 PM, Mark Wills wrote:
> On Apr 8, 5:29 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
> wrote:
>> "A. K."<a...@nospam.org>  writes:
>>> I am just curious whether there is a standardization proposal "under
>>> way"
>>
>> No.
>>
>>> or had it been abandoned completely?
>>
>> No.  There are some people who want a standard OO system for Forth.

> I'd like to see one, too. One that doesn't rely on the somewhat hacky
> 'vocabulary sealing' technique.

Actually, it's pretty easy to write an objects extension that uses no 
vocabularies (wordlists) at all, anywhere, if you think using 
vocabularies is 'hacky'.  It's straightforward if you are willing to 
accept a message-object ordering.  Some Forth programmers won't care but 
others will refuse to use it.  Each message in a method definition 
simply parses the following word and checks it against an ivar list for 
that class.  This is how Neon did it.  There are some ANS compatible 
examples of this technique available.

-Doug

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

#11566

Doug Hoffman <glidedog@gmail.com> wrote:
> On 4/8/12 3:17 PM, Mark Wills wrote:
>> On Apr 8, 5:29 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>> wrote:
>>> "A. K."<a...@nospam.org>  writes:
>>>> I am just curious whether there is a standardization proposal "under
>>>> way"
>>>
>>> No.
>>>
>>>> or had it been abandoned completely?
>>>
>>> No.  There are some people who want a standard OO system for Forth.
> 
>> I'd like to see one, too. One that doesn't rely on the somewhat hacky
>> 'vocabulary sealing' technique.
> 
> Actually, it's pretty easy to write an objects extension that uses no 
> vocabularies (wordlists) at all, anywhere, if you think using 
> vocabularies is 'hacky'.  It's straightforward if you are willing to 
> accept a message-object ordering.

Why does it require a message-object ordering?  There's no need for
compile-time parsing: all a system has to do is find a handler for the
method and jump to that handler.

Andrew.

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

#11568

On 4/24/12 10:52 AM, Andrew Haley wrote:
> Doug Hoffman<glidedog@gmail.com>  wrote:
>> On 4/8/12 3:17 PM, Mark Wills wrote:
>>> On Apr 8, 5:29 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>>> wrote:
>>>> "A. K."<a...@nospam.org>   writes:
>>>>> I am just curious whether there is a standardization proposal "under
>>>>> way"
>>>>
>>>> No.
>>>>
>>>>> or had it been abandoned completely?
>>>>
>>>> No.  There are some people who want a standard OO system for Forth.
>>
>>> I'd like to see one, too. One that doesn't rely on the somewhat hacky
>>> 'vocabulary sealing' technique.
>>
>> Actually, it's pretty easy to write an objects extension that uses no
>> vocabularies (wordlists) at all, anywhere, if you think using
>> vocabularies is 'hacky'.  It's straightforward if you are willing to
>> accept a message-object ordering.
>
> Why does it require a message-object ordering?  There's no need for
> compile-time parsing: all a system has to do is find a handler for the
> method and jump to that handler.

It's just one way to do it, not a requirement.  Now you have mentioned 
another way sans wordlists.  Do you have a link for such an extension?

-Doug

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

#11572

Doug Hoffman <glidedog@gmail.com> wrote:
> On 4/24/12 10:52 AM, Andrew Haley wrote:
>> Doug Hoffman<glidedog@gmail.com>  wrote:
>>> On 4/8/12 3:17 PM, Mark Wills wrote:
>>>> On Apr 8, 5:29 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>>>> wrote:
>>>>> "A. K."<a...@nospam.org>   writes:
>>>>>> I am just curious whether there is a standardization proposal "under
>>>>>> way"
>>>>>
>>>>> No.
>>>>>
>>>>>> or had it been abandoned completely?
>>>>>
>>>>> No.  There are some people who want a standard OO system for Forth.
>>>
>>>> I'd like to see one, too. One that doesn't rely on the somewhat hacky
>>>> 'vocabulary sealing' technique.
>>>
>>> Actually, it's pretty easy to write an objects extension that uses no
>>> vocabularies (wordlists) at all, anywhere, if you think using
>>> vocabularies is 'hacky'.  It's straightforward if you are willing to
>>> accept a message-object ordering.
>>
>> Why does it require a message-object ordering?  There's no need for
>> compile-time parsing: all a system has to do is find a handler for the
>> method and jump to that handler.
> 
> It's just one way to do it, not a requirement.  Now you have
> mentioned another way sans wordlists.  Do you have a link for such
> an extension?

No.  I'm still thinking.  Will write it up if I get time.

Andrew.

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

#11608

On 4/24/12 12:43 PM, Andrew Haley wrote:
> Doug Hoffman<glidedog@gmail.com>  wrote:
>> On 4/24/12 10:52 AM, Andrew Haley wrote:
>>> Doug Hoffman<glidedog@gmail.com>   wrote:

>>>> Actually, it's pretty easy to write an objects extension that uses no
>>>> vocabularies (wordlists) at all, anywhere, if you think using
>>>> vocabularies is 'hacky'.  It's straightforward if you are willing to
>>>> accept a message-object ordering.
>>>
>>> Why does it require a message-object ordering?  There's no need for
>>> compile-time parsing: all a system has to do is find a handler for the
>>> method and jump to that handler.
>>
>> It's just one way to do it, not a requirement.  Now you have
>> mentioned another way sans wordlists.  Do you have a link for such
>> an extension?
>
> No.  I'm still thinking.  Will write it up if I get time.

Sorry, I didn't mean for you to write up something special.  A simple 
explanation of how your technique handles instance variable name 
encapsulation is all I was interested in.  That was the context of this 
part of the thread.  (Not to disparage Mini-OOF, because it is a very 
clever piece of code, but ivar name encapsulation in Mini-OOF is 
seriously broken, IMO.)

-Doug

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

#11609

Doug Hoffman <glidedog@gmail.com> wrote:
> On 4/24/12 12:43 PM, Andrew Haley wrote:
>> Doug Hoffman<glidedog@gmail.com>  wrote:
>>> On 4/24/12 10:52 AM, Andrew Haley wrote:
>>>> Doug Hoffman<glidedog@gmail.com>   wrote:
> 
>>>>> Actually, it's pretty easy to write an objects extension that uses no
>>>>> vocabularies (wordlists) at all, anywhere, if you think using
>>>>> vocabularies is 'hacky'.  It's straightforward if you are willing to
>>>>> accept a message-object ordering.
>>>>
>>>> Why does it require a message-object ordering?  There's no need for
>>>> compile-time parsing: all a system has to do is find a handler for the
>>>> method and jump to that handler.
>>>
>>> It's just one way to do it, not a requirement.  Now you have
>>> mentioned another way sans wordlists.  Do you have a link for such
>>> an extension?
>>
>> No.  I'm still thinking.  Will write it up if I get time.
> 
> Sorry, I didn't mean for you to write up something special.  A simple 
> explanation of how your technique handles instance variable name 
> encapsulation is all I was interested in.

Oh, that's easy.  Object contains a pointer to a table, mesage looks
in that table to find a handler for the message's selector and jumps
to the handler.

> That was the context of this part of the thread.  (Not to disparage
> Mini-OOF, because it is a very clever piece of code, but ivar name
> encapsulation in Mini-OOF is seriously broken, IMO.)

Interesting.  I'll have to have a look to see what the problem is.

Andrew.

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

#11614

On 4/25/12 8:52 AM, Andrew Haley wrote:
> Doug Hoffman<glidedog@gmail.com>  wrote:

>> A simple
>> explanation of how your technique handles instance variable name
>> encapsulation is all I was interested in.
>
> Oh, that's easy.  Object contains a pointer to a table, mesage looks
> in that table to find a handler for the message's selector and jumps
> to the handler.

I'm not following how that explains keeping ivar names private to method 
definitions.  When defining a method how does the method compiler know 
when a word is an ivar name and not a global name?


>> That was the context of this part of the thread.  (Not to disparage
>> Mini-OOF, because it is a very clever piece of code, but ivar name
>> encapsulation in Mini-OOF is seriously broken, IMO.)
>
> Interesting.  I'll have to have a look to see what the problem is.

The problem is ivar definitions have global name scope.  So an ivar name 
can clobber a global name and vice versa.

-Doug

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

#11618

Doug Hoffman <glidedog@gmail.com> wrote:
> On 4/25/12 8:52 AM, Andrew Haley wrote:
>> Doug Hoffman<glidedog@gmail.com>  wrote:
> 
>>> A simple explanation of how your technique handles instance
>>> variable name encapsulation is all I was interested in.
>>
>> Oh, that's easy.  Object contains a pointer to a table, mesage looks
>> in that table to find a handler for the message's selector and jumps
>> to the handler.
> 
> I'm not following how that explains keeping ivar names private to method 
> definitions. 

I know.  Sorry, my reply was a total non sequitur.

> When defining a method how does the method compiler know when a word
> is an ivar name and not a global name?

I don't get it.  Surely an ivar name is just a word, so it does
something like

  does> @ +   
or
  does> @ self +

and the compiler doesn't need to handle it a special way.

>>> That was the context of this part of the thread.  (Not to disparage
>>> Mini-OOF, because it is a very clever piece of code, but ivar name
>>> encapsulation in Mini-OOF is seriously broken, IMO.)
>>
>> Interesting.  I'll have to have a look to see what the problem is.
> 
> The problem is ivar definitions have global name scope.  So an ivar name 
> can clobber a global name and vice versa.

This is always true in Forth, surely: it's not specific to OO or to an
OO package.  There is always a theoretical problem that local names
shadow global ones, as discussed here at fantastic length.  It's
pretty trivial either to put the ivar names in a wordlist or to use a
prefix for all ivar names.

Andrew.

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

#11622

On 4/25/12 11:37 AM, Andrew Haley wrote:

> It's
> pretty trivial either to put the ivar names in a wordlist or to use a
> prefix for all ivar names.

Either a wordlist or a prefix (like a message).  Exactly.

-Doug

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web