On Fri, Jul 08, 2005 at 14:14:27 +0000, Luke Palmer wrote:
> I suppose I was mostly commenting on the junctions part.  I'm
> proposing that All Junctions Are Created Equal.  That is, there is no
> specificity measuring on junctions.  I also didn't really understand
> your right-angle-tree-ratio measure.  Does it have a name, and is
> there a mathematical reason that you chose it?

It's really nothing more then a metaphor.

        method bark ((Dog | Sheep) $inv:) {

        }

        method bark ((Retreiver & Sheppherd) $inv:) {

        }

When I dispatch a 'bark' method on my $uber_dog, I'd like it not to
be a sheep. The way this is weigted is basically '&' is more
particular than '|'.

The tree dimentions thing deals with nested junctions. Basically you
"draw" out the tree on some 2d space, where the root is (0,0), &
combinations are drawn on the Y axis, and | combinations are drawn
on the X axis.

Parent axes are stretched to fit their children's drawings.

Here are two examples:

        ((Dog & Retriever) | (Sheep & Stupid))

                 Dog          Sheep
                  |             |
              +------x------+
                  |             |
          Retriever       Stupid


        ((Dog | Sheep) & (Retriever | Stupid))

                 Dog-----|-----Sheep
                         |
                                 x
                         |
          Retriever--|-----Stupid

By graphically spanning the tree you can see if it tends to be wide
(ORish) or deep (ANDish). The score of the junction is the ratio of
the length on the x axis, over the length on the y axis.

The bigger the combinator is (the | in the first example, the
& in the second one), the bigger the line in the picture will be,
because the boxes under the lines  must fit in the spaces (hence the
right angles bit) between the combinator's line and it's siblings'.
This only showes up clearly in 3 level structures and up:

        ((Dog & (Retriever | Sheppard)) | Sheep

                                     Dog
                                      |
        Sheep------------x------------|
                                      |
                                      |
                       Retriever--|--Sheppard


        ((Dog & (Retriever & Sheppard)) | Sheep

                          Dog
                           |
        Sheep------x-------|
                           |
                          _+_
                   Retriever
                                       |
                                       |
                                       |
                                   Sheppard

(assume for fairness that strings are a block, 1x1, and each line is
1 block thick)..

Of course, you don't need to do that - you just do depth first
traversal, calculate the junction's "dimentions", and push upward.

The eventual junction will either be 'ANDish' or 'ORish', and and
the tendancy of the junctions is their order.

If there are candidates which are too close together for the same
parameter under a single shortname, the user should be warned.

For example, in the stupid sheep/retrieving dog example, you don't
want both definitions, but (Dog & Retriever) is definately more
specific than (Sheep | Dog).

We discussed this a bit on #perl6, and we concluded that my tree
example was stupid. If you have a better explanation, please commit
it to the pugs repo, even if you don't agree with this - just for
the sake of clarity (because I can't explain it any better).

> Anyway, I think that once we start diving inside expressions to
> measure their specificity, we've gotten too complex to be predictable.

I think that may be right, but just for junctions it's very
tempting.

-- 
 ()  Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418  perl hacker &
 /\  kung foo master: /me groks YAML like the grasshopper: neeyah!!!!!!

Attachment: pgpYVPe9ak2Zy.pgp
Description: PGP signature

Reply via email to