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

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

Message-not-understood and stack effects

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

Contents

  Message-not-understood and stack effects anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-17 13:16 +0000
    Re: Message-not-understood and stack effects "A. K." <akk@nospam.org> - 2012-04-17 18:20 +0200
      Re: Message-not-understood and stack effects anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-17 16:37 +0000
        Re: Message-not-understood and stack effects vandys@vsta.org - 2012-04-17 17:43 +0000
        Re: Message-not-understood and stack effects Alex McDonald <blog@rivadpm.com> - 2012-04-17 10:40 -0700
    Re: Message-not-understood and stack effects Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-17 12:41 -0500
      Re: Message-not-understood and stack effects anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-18 09:48 +0000
        Re: Message-not-understood and stack effects Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-18 05:59 -0500
          Re: Message-not-understood and stack effects John Passaniti <john.passaniti@gmail.com> - 2012-04-18 08:52 -0700
          Re: Message-not-understood and stack effects anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-19 11:47 +0000
            Re: Message-not-understood and stack effects Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-19 07:50 -0500
              Re: Message-not-understood and stack effects John Passaniti <john.passaniti@gmail.com> - 2012-04-19 07:14 -0700
                Re: Message-not-understood and stack effects Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-19 09:31 -0500
              Re: Message-not-understood and stack effects Bernd Paysan <bernd.paysan@gmx.de> - 2012-04-19 19:31 +0200
              Re: Message-not-understood and stack effects anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-20 10:17 +0000
                Re: Message-not-understood and stack effects John Passaniti <john.passaniti@gmail.com> - 2012-04-20 07:52 -0700
                  Re: Message-not-understood and stack effects anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-20 15:26 +0000
                    Re: Message-not-understood and stack effects John Passaniti <john.passaniti@gmail.com> - 2012-04-24 06:09 -0700
                      Re: Message-not-understood and stack effects anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-24 16:52 +0000
                        Re: Message-not-understood and stack effects John Passaniti <john.passaniti@gmail.com> - 2012-04-28 18:38 -0700
                          Re: Message-not-understood and stack effects "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-29 00:19 -0400
                            Re: Message-not-understood and stack effects John Passaniti <john.passaniti@gmail.com> - 2012-04-29 11:16 -0700
                              Re: Message-not-understood and stack effects "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-29 21:55 -0400
                                Re: Message-not-understood and stack effects John Passaniti <john.passaniti@gmail.com> - 2012-05-01 14:44 -0700
                                  Re: Message-not-understood and stack effects "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-05-02 05:35 -0400
                                    Re: Message-not-understood and stack effects Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-02 06:29 -0500
                                      Re: Message-not-understood and stack effects anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-02 12:23 +0000
                                        Re: Message-not-understood and stack effects Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-02 08:43 -0500
                                          Re: Message-not-understood and stack effects Doug Hoffman <glidedog@gmail.com> - 2012-05-02 11:06 -0400
                                            Re: Message-not-understood and stack effects Bernd Paysan <bernd.paysan@gmx.de> - 2012-05-03 18:41 +0200
                                              Re: Message-not-understood and stack effects Doug Hoffman <glidedog@gmail.com> - 2012-05-03 13:07 -0400
                                                Re: Message-not-understood and stack effects Bernd Paysan <bernd.paysan@gmx.de> - 2012-05-04 02:46 +0200
                                                  Re: Message-not-understood and stack effects Doug Hoffman <glidedog@gmail.com> - 2012-05-03 22:09 -0400
                                          Re: Message-not-understood and stack effects anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-03 09:14 +0000
                                            Re: Message-not-understood and stack effects Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-03 04:33 -0500
                                    Re: Message-not-understood and stack effects Mark Wills <markrobertwills@yahoo.co.uk> - 2012-05-02 12:58 -0700
                                      Re: Message-not-understood and stack effects vandys@vsta.org - 2012-05-02 20:43 +0000
                                        Re: Message-not-understood and stack effects Mark Wills <markrobertwills@yahoo.co.uk> - 2012-05-02 13:48 -0700
                                    Re: Message-not-understood and stack effects John Passaniti <john.passaniti@gmail.com> - 2012-05-03 10:42 -0700
                          TypoForth (was: Message-not-understood and stack effects) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-30 13:47 +0000
                            Re: TypoForth (was: Message-not-understood and stack effects) BruceMcF <agila61@netscape.net> - 2012-04-30 08:38 -0700
                              Re: TypoForth (was: Message-not-understood and stack effects) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-30 16:23 +0000
                                Re: TypoForth (was: Message-not-understood and stack effects) BruceMcF <agila61@netscape.net> - 2012-04-30 09:41 -0700
                            Re: TypoForth (was: Message-not-understood and stack effects) John Passaniti <john.passaniti@gmail.com> - 2012-05-01 14:53 -0700
    Re: Message-not-understood and stack effects anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-21 12:34 +0000

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

#11363 — Message-not-understood and stack effects

As some may have read, I am working on objects2.fs, an update of
objects.fs.  One of the features it will have is that if a method
selector S is called for a class C that does not understand S, this
will result in calling the method NOT-UNDERSTOOD for the class (and
the xt of S is passed as additional argument).

This would allow such things as having a generic array class for which
you can call any method selector, and it passes the call on towards
each array element, without you having to define a method for this
selector.

The problem with this scenario is how to deal with the stack effect of
S.  When calling S with an object of class C, it should have the same
stack effect.  But if the NOT-UNDERSTOOD method for C calls S several
times, how does it ensure that?  The NOT-UNDERSTOOD method does not
know what the stack effect of S is (and different method selectors
have different stack effects).

One approach would be to only use this trick for selectors that have a
stack effect ( i*x1 object -- i*x2 ), i.e, where the stack effect
stays the same, apart from removing the object.  One could add a
generic method S-BALANCED with such a stack effect that is a wrapper
around S with a balanced stack effect.  E.g.:

:: draw-balanced ( x y object -- x y )
  2dup this draw ;;
\ where DRAW has ( x y object -- )

We then would need a feature to define S-BALANCED for all classes that
have S defined, but I could add such a feature to objects2.fs

As an extension of that, one could define

:: draw ( x y object -- )
  this draw-balanced 2drop ;;

for all classes that have neither DRAW nor DRAW-BALANCED defined so
that NOT-UNDERSTOOD sees DRAW-BALANCED rather than DRAW.

What do you think of this solution?  Is there a
better one?

Or is the whole problem not important enough to warrant any effort in
that direction?  After all, in many cases we call S just once from
NOT-UNDERSTOOD, and in the generic array case mentioned above one
could call a FOREACH word directly and pass it a balanced word instead
of going through the NOT-UNDERSTOOD mechanism.

The exception would be when the generic array is part of some other
object (perhaps another array), where the calls to S (or S-BALANCED)
percolate down through the data structure; then it would be useful if
the generic array could handle such method selectors.

Yes, I know that this is totally un-Forth-like in worrying about
problems that other people might have in the future instead of solving
the problem at hand, but the whole objects2.fs thing is such an
exercise.

- 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] | [next] | [standalone]

#11364

On 17.04.2012 15:16, Anton Ertl wrote:
> The problem with this scenario is how to deal with the stack effect of
> S.  When calling S with an object of class C, it should have the same
> stack effect.  But if the NOT-UNDERSTOOD method for C calls S several
> times, how does it ensure that?  The NOT-UNDERSTOOD method does not
> know what the stack effect of S is (and different method selectors
> have different stack effects).

I am not sure if I understand the problem correctly. But wouldn't it be 
a case for an exception handler to make sure that unresolved calls don't 
climb through the whole inheritance chain?

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

#11365

"A. K." <akk@nospam.org> writes:
>On 17.04.2012 15:16, Anton Ertl wrote:
>> The problem with this scenario is how to deal with the stack effect of
>> S.  When calling S with an object of class C, it should have the same
>> stack effect.  But if the NOT-UNDERSTOOD method for C calls S several
>> times, how does it ensure that?  The NOT-UNDERSTOOD method does not
>> know what the stack effect of S is (and different method selectors
>> have different stack effects).
>
>I am not sure if I understand the problem correctly. But wouldn't it be 
>a case for an exception handler to make sure that unresolved calls don't 
>climb through the whole inheritance chain?

If a class does not define a NOT-UNDERSTOOD method, then the default
method will be called which throws an exception indeed.

But the issue here is if and how we can make good use of the
possibility to define a NOT-UNDERSTOOD method to let the class
understand method selectors that were not directly defined for it.

"Climbing through the inheritance chain" appears to refer to some
specific implementation technique, that does not play a role here,
because: 1) The problem is conceptual and already present in the
absence of inheritance (note that no inheritance occured in my
description).  2) My implementation does not work that way.

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

#11367

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> But the issue here is if and how we can make good use of the
> possibility to define a NOT-UNDERSTOOD method to let the class
> understand method selectors that were not directly defined for it.

The Smalltalk folks have thoroughly explored this concept, and it has proven
sound.  (ForthOS's OO extensions also used it without negative impact.)  In
ForthOS the not-understood selector (not using that name, but same idea) was
passed the selector not understood (a symbol, basically a unique token
corresponding to a string) and an array of the arguments to that selector.
Because of the argument marshaling, in ForthOS it wouldn't be suitable to
be used in high performance method invocations/redirections.  But of course
it side steps the calling convention issues, since the invocation is fully
parameterised to not-understood.

-- 
Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html

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

#11368

On Apr 17, 5:37 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> "A. K." <a...@nospam.org> writes:
> >On 17.04.2012 15:16, Anton Ertl wrote:
> >> The problem with this scenario is how to deal with the stack effect of
> >> S.  When calling S with an object of class C, it should have the same
> >> stack effect.  But if the NOT-UNDERSTOOD method for C calls S several
> >> times, how does it ensure that?  The NOT-UNDERSTOOD method does not
> >> know what the stack effect of S is (and different method selectors
> >> have different stack effects).
>
> >I am not sure if I understand the problem correctly. But wouldn't it be
> >a case for an exception handler to make sure that unresolved calls don't
> >climb through the whole inheritance chain?
>
> If a class does not define a NOT-UNDERSTOOD method, then the default
> method will be called which throws an exception indeed.
>
> But the issue here is if and how we can make good use of the
> possibility to define a NOT-UNDERSTOOD method to let the class
> understand method selectors that were not directly defined for it.
>
> "Climbing through the inheritance chain" appears to refer to some
> specific implementation technique, that does not play a role here,
> because: 1) The problem is conceptual and already present in the
> absence of inheritance (note that no inheritance occured in my
> description).  2) My implementation does not work that way.
>
> - 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/

Then the message NOT-UNDERSTOOD should be considered NOT-IMPLEMENTED,
and the end user (as is usual with Forth) might be expected to
maintain sufficient information (or at least have an understanding of
the stack effects) to do something meaningful.

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

#11366

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> As some may have read, I am working on objects2.fs, an update of
> objects.fs.  One of the features it will have is that if a method
> selector S is called for a class C that does not understand S, this
> will result in calling the method NOT-UNDERSTOOD for the class (and
> the xt of S is passed as additional argument).
> 
> This would allow such things as having a generic array class for which
> you can call any method selector, and it passes the call on towards
> each array element, without you having to define a method for this
> selector.

I don't think that this is really an appropriate use of
NOT-UNDERSTOOD, which is more typically used for proxies.  Having said
that, it's easy enough to mark the depth of the stack and save the
args on the R-stack.  This is the sort of thing that an APPLY or
REDUCE method can do.

> Or is the whole problem not important enough to warrant any effort
> in that direction?  After all, in many cases we call S just once
> from NOT-UNDERSTOOD, and in the generic array case mentioned above
> one could call a FOREACH word directly and pass it a balanced word
> instead of going through the NOT-UNDERSTOOD mechanism.

I think that this is really just the wrong way to be using
NOT-UNDERSTOOD.

Andrew.

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

#11374

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> This would allow such things as having a generic array class for which
>> you can call any method selector, and it passes the call on towards
>> each array element, without you having to define a method for this
>> selector.
>
>I don't think that this is really an appropriate use of
>NOT-UNDERSTOOD, which is more typically used for proxies.

Why do you think so?  Why would it be appropriate for proxies, but not
for collections?

>Having said
>that, it's easy enough to mark the depth of the stack and save the
>args on the R-stack.

How many args?  And it's a little harder to save stuff from the FP
stack.  And it looks inelegant and inefficient, although maybe not
worse than the other things I am considering.

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

#11375

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> This would allow such things as having a generic array class for which
>>> you can call any method selector, and it passes the call on towards
>>> each array element, without you having to define a method for this
>>> selector.
>>
>>I don't think that this is really an appropriate use of
>>NOT-UNDERSTOOD, which is more typically used for proxies.
> 
> Why do you think so?  Why would it be appropriate for proxies, but not
> for collections?

I think that you should be explicit: if you want to invoke a method to
every element of an array you should say so.  Simply invoking NEGATE,
say, on a collection doesn't seem to me to be such a great idea.
Sure, it's cute, but what is the real purpose?

>>Having said that, it's easy enough to mark the depth of the stack
>>and save the args on the R-stack.
> 
> How many args?

Either all of them, or all of them up to a limit.

> And it's a little harder to save stuff from the FP stack.  And it
> looks inelegant and inefficient, although maybe not worse than the
> other things I am considering.

It's not at all inefficient as long as you don't try to do it
portably.

Andrew.

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

#11377

On Apr 18, 6:59 am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> >>I don't think that this is really an appropriate use of
> >>NOT-UNDERSTOOD, which is more typically used for proxies.
>
> > Why do you think so?  Why would it be appropriate for
> > proxies, but not for collections?
>
> I think that you should be explicit: if you want to invoke a
> method to every element of an array you should say so.  Simply
> invoking NEGATE, say, on a collection doesn't seem to me to
> be such a great idea. Sure, it's cute, but what is the real
> purpose?

I agree, and this explicitness is common advice in every language I've
ever used that has implemented some notion of the Smalltalk-style
"doesNotUnderstand" method.  A container object may certainly have
defined methods on it to explicitly iterate, map, reduce, and other
related operations.  But I can't see the need (and don't find it at
all natural) to expect that you would ever want something so general
as a "apply every unknown message to every member of the collection"
operation.

I can certainly come up with contrived use cases where this might be
useful.  Hey, how about a collection of GUI objects; I can avoid
having to code an explicit "draw" method on the container that
forEach's over the collection and invokes "draw" by having a more
general facility that dispatches any unknown message.  Ummm, ick.

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

#11402

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> This would allow such things as having a generic array class for which
>>>> you can call any method selector, and it passes the call on towards
>>>> each array element, without you having to define a method for this
>>>> selector.
>>>
>>>I don't think that this is really an appropriate use of
>>>NOT-UNDERSTOOD, which is more typically used for proxies.
>> 
>> Why do you think so?  Why would it be appropriate for proxies, but not
>> for collections?
>
>I think that you should be explicit: if you want to invoke a method to
>every element of an array you should say so.

Why require explicitness only for collections?  One might also require
it for proxies; then, instead of calling say, DRAW, for a generic
proxy, one might just be explicit and call it with DO-PROXY, and pass
the xt of DRAW as an argument.  Of course, such explicitness means
that you cannot use the NOT-UNDERSTOOD mechanism for proxies nor for
collections.

>  Simply invoking NEGATE,
>say, on a collection doesn't seem to me to be such a great idea.

Why not (apart from the fact that NEGATE is not a method)?

>Sure, it's cute, but what is the real purpose?

The same as for proxies: It allows the proxy and the collection to
walk and quack like a duck, without having to define WALK and QUACK
methods for these generic classes (writing such methods would just add
repetetive code that does not provide any benefit over the implicit
approach).  As a result, you can use collections as well as proxies in
places that expect something that can WALK and QUACK.

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

#11403

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>> This would allow such things as having a generic array class for which
>>>>> you can call any method selector, and it passes the call on towards
>>>>> each array element, without you having to define a method for this
>>>>> selector.
>>>>
>>>>I don't think that this is really an appropriate use of
>>>>NOT-UNDERSTOOD, which is more typically used for proxies.
>>> 
>>> Why do you think so?  Why would it be appropriate for proxies, but not
>>> for collections?
>>
>>I think that you should be explicit: if you want to invoke a method to
>>every element of an array you should say so.
> 
> Why require explicitness only for collections?  One might also
> require it for proxies; then, instead of calling say, DRAW, for a
> generic proxy, one might just be explicit and call it with DO-PROXY,
> and pass the xt of DRAW as an argument.  Of course, such
> explicitness means that you cannot use the NOT-UNDERSTOOD mechanism
> for proxies nor for collections.

Because it ges against the very idea of a proxy.  A proxy is a class
that can stand in for another class: to an outsider it has the same
properties as the class it's proxying for.  A collection does not have
this property.  A vector is not a proxy for a scalar.

>> Simply invoking NEGATE,
>> say, on a collection doesn't seem to me to be such a great idea.
> 
> Why not (apart from the fact that NEGATE is not a method)?

It might be.

>>Sure, it's cute, but what is the real purpose?
> 
> The same as for proxies: It allows the proxy and the collection to
> walk and quack like a duck, without having to define WALK and QUACK
> methods for these generic classes (writing such methods would just add
> repetetive code that does not provide any benefit over the implicit
> approach).  As a result, you can use collections as well as proxies in
> places that expect something that can WALK and QUACK.

But a collection doesn't have the same properties as a scalar.  What
you're suggesting doesn't make any sense.  Proxies are useful; this
isn't.  Consider a collection that is a row vector.  NEGATE might make
sense.  But what would  +  do?

Andrew.

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

#11406

On Apr 19, 8:50 am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> But a collection doesn't have the same properties as a scalar.
> What you're suggesting doesn't make any sense.  Proxies are
> useful; this isn't.  Consider a collection that is a row
> vector.  NEGATE might make sense.  But what would  +  do?

I wouldn't go so far as to say that what Anton is suggesting isn't
useful.  I think it's always going to be possible to find narrow, odd,
or contrived cases where it is useful.  What I would suggest-- and I
know this goes against the very grain of this newsgroup-- is to
consider what programmers in other languages that offer similar
mechanisms do.  But more than what they do, find out *why* they do
it.  Smalltalk and Self are two obvious languages, but this kind of
thing could also be implemented in the more common dynamic languages
that allow interception of method lookup (Python, Perl, Ruby, Lua,
etc.).

The same arguments that Anton makes for the usefulness of what he
describes would apply equally well in those languages as well.  And
yet, I can't recall any container object that has these kinds of
semantics.  My guess as to the reason why in languages like Smalltalk
and Self is that "doesNotUnderstand" is normally treated as part of an
exception mechanism and as such may have performance penalties.  In
languages that let you intercept or redefine method lookup, that's not
so much the case, so it's probably more driven by thinking it's bad
style to blindly dispatch unknown messages to items of a collection.
A proxy?  Sure, as the purpose of a proxy is to forward messages.  A
collection?  Who has that expectation?

Regardless, it certainly doesn't feel natural to me.  If I wanted a
collection that dispatched unknown messages to items in a collection,
that is behavior I would not treat as a default, but as a specific
documented property of a specialized collection.  So I might derive a
ForwardingCollection from a Collection and specifically document this
behavior.  But probably not.

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

#11407

John Passaniti <john.passaniti@gmail.com> wrote:
> On Apr 19, 8:50?am, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
>> But a collection doesn't have the same properties as a scalar.
>> What you're suggesting doesn't make any sense. Proxies are
>> useful; this isn't. Consider a collection that is a row
>> vector. NEGATE might make sense. But what would + do?
> 
> I wouldn't go so far as to say that what Anton is suggesting isn't
> useful.  I think it's always going to be possible to find narrow, odd,
> or contrived cases where it is useful.

I accept that correction.

> What I would suggest-- and I know this goes against the very grain
> of this newsgroup-- is to consider what programmers in other
> languages that offer similar mechanisms do.

Go against the grain?  I think not!  We wouldn't be talking about OO
if we we'ren't considering what other languages do.

I agree with everything else you wrote...

Andrew.

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

#11415

Andrew Haley wrote:
> Because it ges against the very idea of a proxy.  A proxy is a class
> that can stand in for another class: to an outsider it has the same
> properties as the class it's proxying for.  A collection does not have
> this property.  A vector is not a proxy for a scalar.

Yes, normally you should use an iterator (map, foreach) in a collection 
to do things like that.  This takes a quotation as argument, and the 
quotation sends messages to the elements.

BTW: The implementation of generic proxies (which proxy every other 
object, and only define the protocol how to do so) is greatly helped by 
having a signature for each method available to the system (we *can* do 
that in Forth, it would mean that the stack effect for a method is not 
just a comment, but information that is stored with the selector).  If 
the proxy talks to a remote object, you also need serialization for 
whatever data you send to that object, and to do that, some sort of type 
information is needed (e.g. addr len would be preferrable to addr u, 
because with that information, the proxy can know that it has to send 
len bytes starting at addr to the destination).

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

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

#11469

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> The same as for proxies: It allows the proxy and the collection to
>> walk and quack like a duck, without having to define WALK and QUACK
>> methods for these generic classes (writing such methods would just add
>> repetetive code that does not provide any benefit over the implicit
>> approach).  As a result, you can use collections as well as proxies in
>> places that expect something that can WALK and QUACK.
>
>But a collection doesn't have the same properties as a scalar.

That's always the case for different classes.  If we only applied
methods to objects with the same properties, we would not need
polymorphism.

> Proxies are useful; this
>isn't.  Consider a collection that is a row vector.  NEGATE might make
>sense.  But what would  +  do?

Not every selector makes sense for every object, so if you eventually
find one that doesn't for collections, that does not prove anything.

That being said, let's see what a + method might do: It might have the
stack effect ( n1 object -- n2 ) and n2 is the sum of n1 and the value
of the object.  Now, if the object is a collection and the collection
applies + to each element, n2 is the sum of n1 and the sum of all the
values in the collection.  With n1=0, n2 is the sum of all elements in
the collection.  Looks pretty useful to me.

Now you might say that you can also do this explicitly, but what if
some of the elements of the collection are also collections?  Then the
collection should understand +.

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

#11472

On Apr 20, 6:17 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> Now you might say that you can also do this explicitly, but
> what if some of the elements of the collection are also
> collections?  Then the collection should understand +.

I would expect that any object system that is added to Forth wouldn't
fundamentally change the expectations of a Forth programmer.  In
Forth, I see a simple language that doesn't try to speculate about the
intent of the programmer.  Everything is explicit and the direct
responsibility of the programmer.  Every time people talk about high-
level "do what I mean" languages in this newsgroup, the point that
someone always makes is, "but what if the language gets the intent
wrong?"  So why would your object system violate this principle?  Why
would it make sense to you to veer away from the explicitness of
Forth?

A collection object that by default doesn't respond to unknown
messages with some kind of error isn't like any collection class I've
ever used.  I can certainly accept there will be use cases where the
behavior you describe could make sense.  So in those cases, why
wouldn't I use the very tools that object orientation provides me to
explicitly add that behavior.  If I want a collection class that sub-
dispatches unknown messages, why wouldn't I simply specialize a
collection class with that behavior?  Is creating derivations in your
object system so painful that instead of speculating about what the
user may possibly want, you start simply and let them create their own
objects that do what they want?

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

#11475

John Passaniti <john.passaniti@gmail.com> writes:
>On Apr 20, 6:17=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>wrote:
>> Now you might say that you can also do this explicitly, but
>> what if some of the elements of the collection are also
>> collections? =A0Then the collection should understand +.
>
>I would expect that any object system that is added to Forth wouldn't
>fundamentally change the expectations of a Forth programmer.  In
>Forth, I see a simple language that doesn't try to speculate about the
>intent of the programmer.  Everything is explicit and the direct
>responsibility of the programmer.  Every time people talk about high-
>level "do what I mean" languages in this newsgroup, the point that
>someone always makes is, "but what if the language gets the intent
>wrong?"  So why would your object system violate this principle?  Why
>would it make sense to you to veer away from the explicitness of
>Forth?

Any OO system veers away from some understanding of explicitness,
because it automatically selects the method.  I don't consider this
DWIM, though.  It's the programmer's responsibility to write the
program so that the right method is called, and to take appropriate
measures so that he can still understand what's going on.

OTOH, one might also consider the implicit approach I suggest here in
the spirit of Forth.  After all, Chuck Moore said "If I want to add 1
to the letter A, it's none of the compiler's business to tell me I
can't."  Some languages would require explicit conversion, Forth is
implicit here.  So, analogously, if I want to call "SUM" for a
collection, is it the OO extension author's business to tell me that I
can't?

>A collection object that by default doesn't respond to unknown
>messages with some kind of error isn't like any collection class I've
>ever used.  I can certainly accept there will be use cases where the
>behavior you describe could make sense.  So in those cases, why
>wouldn't I use the very tools that object orientation provides me to
>explicitly add that behavior.

Yes, that's the idea.

>If I want a collection class that sub-
>dispatches unknown messages, why wouldn't I simply specialize a
>collection class with that behavior?

Yes, that's one possibility.

The question in my original posting is: If you do that, what do you do
about the stack?

Different selectors have different stack effects.  If NOT-UNDERSTOOD
calls the selector only once (as a proxy likely does), one can arrange
that the stack effect of calling the selector for the
not-understanding class is derived from the stack effect of calling it
from NOT-UNDERSTOOD.  But if NOT-UNDERSTOOD calls it 0 times or more
than once, as is likely to happen for such a collection, we have to do
something else.  But what?

>Is creating derivations in your
>object system so painful that instead of speculating about what the
>user may possibly want, you start simply and let them create their own
>objects that do what they want?

Sorry, I fail to understand what you are getting at here.

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

#11565

On Apr 20, 11:26 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> Any OO system veers away from some understanding of
> explicitness, because it automatically selects the method.

I guess that's one way to view it, but I find that statement very
strange.  In every object system I'm aware of, when you create an
object (define a class, clone/modify a prototype, insert a delegate,
etc.) you are *explicitly* defining how you want that object to
behave.  The language and/or object system may provide nice syntax and
mechanism to help you avoid tedious repetition of intent (for example,
referencing a base class or parent object).  But the end result would
be the same as if the language didn't force you to type all that.  On
the caller's side, the context (provided by the object itself and/or
it's type) is in my mind equally explicit; when I do this call in
another language...

    foo:draw()

... I am certainly thinking "I want the draw method on foo I
previously assigned" or "I want the draw method on foo that comes as a
result of being of class bar."  When I created that object, I had a
very explicit understanding of what "draw" would do when I called it
because that is part of defining the object.  So saying that the
object system "automatically selects the method" is weird.  When I
create a deferred word in Forth and and then call it, do you consider
that in any sense the target word is "automatically selected"?  All
we're talking about in any object system is one or more layers of
indirection to the code or data.  How is that "automatic."

> OTOH, one might also consider the implicit approach I suggest
> here in the spirit of Forth.  After all, Chuck Moore said "If
> I want to add 1 to the letter A, it's none of the compiler's
> business to tell me I can't."  Some languages would require
> explicit conversion, Forth is implicit here.  So, analogously,
> if I want to call "SUM" for a collection, is it the OO
> extension author's business to tell me that I can't?

Nothing prevents me from walking into a Starbucks and asking the
hipster barista to make me sushi.  Nothing prevents me asking my cat
to perform surgery (she's got the claws for it).  In both cases, I'm
less than likely to be pleased with the result when I send those
messages to those objects.

Yes, Forth has a principle that it isn't the compiler's role to say
what can and can't be done.  But that same principle doesn't guarantee
that what you want will actually work or even do anything useful.  You
can push a floating point number on the stack and attempt to TYPE it.
For that rare case where that actually makes sense, the compiler won't
prevent you from doing that.  But it also won't mean anything 99.999%
of the time.

Forth has other principles too, such as the single responsibility
principle which says that the definitions you create should be small,
focused, and do one thing.  When I think of a plain container, I don't
have any expectation that the container will do anything more than...
contain.  I don't expect that a container will gleefully take messages
and dispatch them to members.  If I want that behavior, I'll
specialize container to do that.  If it's a generally useful object,
I'll add it to my library.

Another principle of Forth is to not speculate about what the
programmer may want to do with your code.  You could sit down and
write every possible feature in an object system that a programmer
might want.  Or, you could focus on making it simple and fast and
focused.  I fail to see why because you're creating an object system
that that principle gets tossed aside.

> >Is creating derivations in your
> >object system so painful that instead of speculating about what the
> >user may possibly want, you start simply and let them create their own
> >objects that do what they want?
>
> Sorry, I fail to understand what you are getting at here.

Can you show an example of how in your object system you explicitly
add this dispatch-to-members-of-collection behavior?  Is it one line?
Many lines?  Impossible?  If it's not painful for the programmer to
explicitly add this feature when wanted, then why not let that guide
your choices instead of speculation about what the programmer may want?

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

#11576

John Passaniti <john.passaniti@gmail.com> writes:
>On Apr 20, 11:26=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>wrote:
>> Any OO system veers away from some understanding of
>> explicitness, because it automatically selects the method.
>
>I guess that's one way to view it, but I find that statement very
>strange.  In every object system I'm aware of, when you create an
>object (define a class, clone/modify a prototype, insert a delegate,
>etc.) you are *explicitly* defining how you want that object to
>behave.

It's the same with everything I have discussed in this thread.

>  When I created that object, I had a
>very explicit understanding of what "draw" would do when I called it
>because that is part of defining the object.

It's the same with the mechanism discussed in this thread, but for
some reason you found it too implicit.

>  So saying that the
>object system "automatically selects the method" is weird.  When I
>create a deferred word in Forth and and then call it, do you consider
>that in any sense the target word is "automatically selected"?

There is no selection in a deferred word.  In an object system, there
is a selection between different methods of a selector.  If you don't
find it too implicit, fine.  But I wonder why you complained about
implicitness of using the NOT-UNDERSTOOD mechanism for collections.
Everything you wrote above about methods applies there, too.

>  When I think of a plain container, I don't
>have any expectation that the container will do anything more than...
>contain.  I don't expect that a container will gleefully take messages
>and dispatch them to members.  If I want that behavior, I'll
>specialize container to do that.

Then define your containers to behave that way.  This thread is
(intended to be) about how you can do that if you want to, in
particular about how to deal with the stack.

>Another principle of Forth is to not speculate about what the
>programmer may want to do with your code.  You could sit down and
>write every possible feature in an object system that a programmer
>might want.  Or, you could focus on making it simple and fast and
>focused.  I fail to see why because you're creating an object system
>that that principle gets tossed aside.

It gets tossed aside from the start.  I have found simple OO fragments
(smaller even than mini-OOF) good enough for my Forth programming
(although I occasionally missed tool integration that I might get if
we had a standard OO extension).  So if I do more than that, I have
already left the principle above behind.

Others asked for a standard OO thingy for Forth, so I wrote objects.fs
to demonstrate what my ideas are on that, and also to give a useful
library to those who want it.  It was used by some, but it did not
take the world by storm (and neither did any other OO extension).
Maybe we don't need a standard OO extension, or maybe we just cannot
find a consensus on one.

Anyway, more recently there has been some discussion on OO in Forth
again, with requests for duck typing and NOT-UNDERSTOOD handling.  I had
some ideas how to do that, and I am working them out now.

>Can you show an example of how in your object system you explicitly
>add this dispatch-to-members-of-collection behavior?

It would be something like:

\ addr and len are instance variables
:: not-understood ( i*x1 sel-xt array -- i*x2 )
  {: sel-xt :} addr len cells + addr ?do
    i @ sel-xt execute
  1 cells +loop ;

>Is it one line?
>Many lines?  Impossible?  If it's not painful for the programmer to
>explicitly add this feature when wanted, then why not let that guide
>your choices instead of speculation about what the programmer may want?

I think you still miss the issue: It's that the NOT-UNDERSTOOD above
works only for selectors with the stack effect ( i*x3 object -- i*x4
).  E.g., it does not work for DRAW ( x y object -- ), because it
would consume two stack items in each iteration.

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

#11729

On Apr 24, 12:52 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> > When I created that object, I had a very explicit
> > understanding of what "draw" would do when I called
> > it because that is part of defining the object.
>
> It's the same with the mechanism discussed in this thread,
> but for some reason you found it too implicit.

I'm designing a new Forth where the text interpreter works a bit
differently from other Forths.  Whenever a word can't be found in the
dictionary, it will permute characters in the word until it matches or
all permutations are exhausted.  I think this is a fantastic feature
for Forth programmers who are bad typists; for such people it will be
amazingly useful.  For example, here's the top level word in the
infamous washing machine example from Forth, Inc.:

: WASHER ( -- ) WSAH SPNI IRNSE SIPN ;

With old Forth, this example wouldn't even run!  But thanks to
TypoForth, it just works.  Sure it is a bit odd and surprising to
anyone who knows Forth and doesn't expect that behavior.  But that's
how it's going to work, so please don't question the premise and say
that such a feature isn't necessary and isn't beneficial.  Instead,
answer this question:  Would it be better to actually permute the
characters and then look up in the dictionary on each permutation, or
should I encode the dictionary differently to make such lookups fast?

What's that?  You think this is a stupid idea?  I don't understand.
I've just stated that it would be useful for bad typists, so clearly
there is no further discussion possible on this point.  Please put
aside your silly notion that the initial premise can be questioned and
instead just help me find the best solution.

> I think you still miss the issue:

Apparently so.  Apparently the issue is that you don't want to
question your own premise.

So, how exactly should I handle look-up of misspelled Forth words that
are anagrams of each other in TypoForth?

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

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

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

csiph-web