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

Groups > comp.lang.forth > #16347

Re: EuroForth 2012 proceedings

Show all headers | View raw

Doug Hoffman <glidedog@gmail.com> writes:
>So couldn't the number of cells used be reduced to four?:
>
>Figure 1':
>       object  A    A1   B
>
>foo           xt   xt   xt
>bar                xt
>
>
>I believe I understand that the other xts are intended to be used for 
>two purposes:
>1) Provide a "message not understood" development debugging mechanism.
>2) Allow for a possible default method in the case of a not understood 
>message.
>
>But 1) could be done by maintaining a count of methods for each class 
>and checking that count during method execution.

Purpose 2) could also be done with such a check and a small additional
change.

>This check is 
>analogous to an array check and would only be done during development. 
>Removing the check for production code would restore the run time 
>dispatch speed.

Of course, for purpose 2) you must not remove the check.

>  But perhaps I don't fully understand the implications for the overall 
>dispatch scheme used in objects2 and this trimming may not work there.

Not as it is currently designed, but it could be designed differently
(without class selectors, or maybe with class selectors growing in one
direction and unhashed general selectors growing in the other
direction).

>Regarding sparse dispatch tables, it seems that with the "unhashed 
>general selector" scheme that you present in the paper (which is 
>essentially the scheme used in the dispatch table version of FMS) it can 
>be important to pay attention to the number of different message names 
>used and also the order of class definitions with those names.  To 
>illustrate with an extreme example:  This only applies to a table 
>trimming scheme as I show in Figure 1': above.  If one first defines a 
>class X using 100 message names then a table with 100 cells (100 xts) is 
>needed for X.  If one then defines a class Y that uses only one message 
>name, but it is a different name from any of the 100 in class X, then Y 
>will have 101 dispatch table cells with the first 100 cells empty.  Had 
>class Y been defined first it would have had only 1 cell, and class X 
>defined second would have had 101 cells.  A savings of 101 cells simply 
>by changing the order of class definition.

No, that does not play a role in objects2.  You just specify how many
unhashed selectors you want, and all other selectors are then hashed.
So you might specify 101 unhashed selectors, than you need 202 cells
in your example, or 200, then you need 400 cells.  Or 20, then you
need 40 cells for unhashed selectors, and 256 cells or 512 cells for
hashed selectors (so hashed selectors are a bad idea for that such
not-so-sparsely populated matrices).

>Also, and I believe this is important but often overlooked, message 
>names in OOP are simple generic verbs and can (should be) re-used as 
>often as practicable.  This "best practice" will minimize the number of 
>message names and pay off in fewer names to remember and significantly 
>smaller dispatch table sizes.  I have seen message names used like PUT 
>and PUT$ when PUT would have sufficed for both.

If they do conceptually similar things, and have compatible
interfaces, then yes, they should have the same name.  If not, then
they should have different names.  If you want to save space, use
class selectors, hashed selectors, or, to get the effect you are
thinking of, make one selector an alias of the other one.

>In section 8 of your paper you mention that FMS "seems to be based on a 
>compressed table".  This is true, only for the dispatch table version, 
>and uses a scheme like I mentioned for compressing the 100 empty cells 
>in class Y above.  But the latest FMS dispatch table package in FLAG is 
>a Multiple Inheritance(MI) OOP package.  Because of this, extra 
>information must be carried in the tables.  Any size/speed comparisons 
>to this version should also have MI capability for an apples-to-apples 
>analysis.  The MI capability necessarily leads to somewhat larger tables 
>(hence the use of compression) and somewhat slower late binding speed 
>due to the extra information that must be retrieved.  This size and 
>speed trade-off may or may not be important to the user.

IIRC I looked at the FMS from FLAG, but did not understand it enough
to do any size comparisons, and did not try to do speed comparisons.

- 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 2012: http://www.euroforth.org/ef12/

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

EuroForth 2012 proceedings anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-15 16:40 +0000
  Re: EuroForth 2012 proceedings Mark Wills <forthfreak@gmail.com> - 2012-10-16 01:38 -0700
  Re: EuroForth 2012 proceedings Doug Hoffman <glidedog@gmail.com> - 2012-10-16 07:47 -0400
    Re: EuroForth 2012 proceedings anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-16 16:20 +0000
      Re: EuroForth 2012 proceedings Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-16 20:13 +0200
        Re: EuroForth 2012 proceedings Doug Hoffman <glidedog@gmail.com> - 2012-10-16 17:22 -0400
          Re: EuroForth 2012 proceedings Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-17 01:29 +0200
            Re: EuroForth 2012 proceedings Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-17 01:49 +0200
              Re: EuroForth 2012 proceedings Doug Hoffman <glidedog@gmail.com> - 2012-10-17 06:29 -0400
              Re: EuroForth 2012 proceedings Doug Hoffman <glidedog@gmail.com> - 2012-10-19 10:16 -0400
            Re: EuroForth 2012 proceedings anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-17 14:15 +0000
              Re: EuroForth 2012 proceedings Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-17 17:14 +0200
              Re: EuroForth 2012 proceedings Doug Hoffman <glidedog@gmail.com> - 2012-10-19 09:57 -0400
                Re: EuroForth 2012 proceedings Doug Hoffman <glidedog@gmail.com> - 2012-10-24 08:50 -0400
        Re: EuroForth 2012 proceedings anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-17 13:29 +0000
          Re: EuroForth 2012 proceedings Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-17 17:31 +0200
      Re: EuroForth 2012 proceedings Doug Hoffman <glidedog@gmail.com> - 2012-10-16 17:20 -0400
        Re: EuroForth 2012 proceedings Doug Hoffman <glidedog@gmail.com> - 2012-10-16 17:25 -0400

csiph-web