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

Groups > comp.lang.postscript > #3163

Re: Experiments with multimethods

Show all headers | View raw

[luser droog <luser.droog@gmail.com>, 2017-08-05 17:29]
> On Wednesday, August 2, 2017 at 1:37:47 AM UTC-5, luser droog wrote:
> 
> > And I was complaining about implementing the typed argument syntax
> > with executable/literal names but methodcompile shows how to scan
> > through and match a sequence of two things, even though you're doing
> > a 'forall' which only gives you one thing at a time.
> > 
> > So, that shouldn't be so hard after this example.
> >   
> <snip> 
> > Before I had the above realization, I sketched out a "structure" which
> > I think accomodates extensible multi-dispatch and local named args.
> > 
> > Just a sketch. The types from top-of-stack down are arranged in a tree
> > of dictionaries. Descending the tree, matching types against the stack,
> > as soon as we hit an executable array, then that's the procedure body
> > and we execute it.
> >   
> 
> > That's what I'm thinking...  
> 
> Here's a partly-working version of this idea. It works with one function
> signature, and only with real types returned by 'type'. The /isa function
> understands /anytype and /numbertype (which may be all we need here) but
> it's not currently used. 
[...]

I went that way before, but I now don't think it's a good idea. In the
multimethod library a couple messages upthread, if you write, for
instance,

  /add [/stringtype /stringtype] {
      2 copy length exch length add string
      dup 4 -1 roll 1 index copy length 4 -1 roll putinterval
  } defmethod

  /mul [/stringtype /stringtype] {
      exch ( x ) add exch add
  } defmethod

  /mul [/stringtype /integertype] {
      () exch { 1 index add } repeat
      exch pop
  } defmethod

GS>(John) (Mary) mul =
John x Mary
GS>(xx) 5 mul =
xxxxxxxxxx

the METHODS global ends up with

  <<
    /add <<
      /ORIGINAL add
      /ARITY 2
      /DISPATCH <<
        /stringtype <<
          /stringtype { 2 copy length exch length add string
                        dup 4 -1 roll 1 index copy length 4 -1 roll
                        putinterval }
          >>
        >>
      >>
    /mul <<
      /ORIGINAL mul
      /ARITY 2
      /DISPATCH <<
        /stringtype <<
          /stringtype { exch ( x ) add exch add }
          /integertype { () exch {1 index add} repeat
                         exch pop }
        >>
      >>
    >>
  >>

(Only difference with yours is that this one goes left-to-right.)

The problem is that this works well with disjoint types, but bad with
inheritance. If you have "/fn [/anytype] {...} defmethod" and
"/fn [/integertype] {...} defmethod", "1 fn" won't necessarily call
the second method.

There is also the problem when the wrong path is selected. For
instance, with "/fn [/anytype /arraytype] {...}" and
"/fn [/integertype /integertype] {...}", "2 [1 2] fn" should call the
first method, but, having matched the first parameter, the dispatcher
is now committed to the wrong path and ends up signaling type error.

I think the way to go is to match sequentially full parameter lists,
which are ordered from more specific to least specific. (I think
that's how CLOS (the inspiration of this multimethod thing) does it.)

-- 

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

Thread

Experiments with multimethods Carlos <carlos@cvkm.cz> - 2017-07-28 02:58 +0200
  Re: Experiments with multimethods luser droog <luser.droog@gmail.com> - 2017-07-29 09:12 -0700
    Re: Experiments with multimethods luser droog <luser.droog@gmail.com> - 2017-08-01 22:33 -0700
      Re: Experiments with multimethods luser droog <luser.droog@gmail.com> - 2017-08-01 23:37 -0700
        Re: Experiments with multimethods luser droog <luser.droog@gmail.com> - 2017-08-05 17:29 -0700
          Re: Experiments with multimethods Carlos <carlos@cvkm.cz> - 2017-08-06 14:45 +0200
            Re: Experiments with multimethods luser droog <luser.droog@gmail.com> - 2017-08-22 09:25 -0700

csiph-web