Re: pattern matching on fields of the argument

Daniel Bonniot <[email protected]> writes:
> foo(Apply a) = if (a.e1 is Lambda && a.e1.id.equals("foo") && a.e2 == null)
> It's still a one liner (introducing 'is' for 'instanceof'),

Aha!  Now I see where you're going.  Yes, this will work quite well.
The 'is' operator is the key to making everything work smoothly and
concisely.

Three other (independent) suggestions:

  - It would be nice if 'is' were a non-alphanumeric token in order to
    eliminate the extra whitespace.  Perhaps

             a.e1~Lambda

    Although '~' is already in use as the bitwise complement (which in
    my opinion isn't useful enough to warrant a symbol all to itself).
    Other possibilities would be '@' or ':' (although the latter
    introduces ambiguity inside a ..?..:.. expression).

  - It would also be cool if there were a very short form of
    'if (x != null && x.equals(y))' to complement 'is' (which is
    the same expression with 'instanceof' instead of equals.

             a.e1===y

  - Finally -- and I hesitate to suggest this because I'm not sure
    it's a good idea -- you could combine these operations into a
    generalized pattern-match operation

         a.e1~~Lambda(e1===x,e2~Integer)

    The entity on the right hand side of the ~~ is a new grammatical
    production:

        expr    ::= ...
                    <expr> ~~ <pattern>

        pattern ::= <constructor-name> ( <pattern> )
                    <pattern> , <pattern>
                    <field-name> ~ <pattern>
                    <field-name> ~~ <pattern>
                    <field-name> == <pattern>
                    <field-name> === <pattern>
                    <class-name>

    The '==', '~', and '~~' operators could be combined into a single
    operator ('~'), although this requires a context-sensitive parser,
    which I think is somewhat ugly.  Note that the comma operator is a
    generalized conjunction (the RHS must match both patterns) so you
    can do things like

        a.e1~~Interface1,Interface2

    Conveniently this can share syntax with the conjunction of two
    field-pattern-matches.  Most of the advantage here comes from
    being able to put conjunctions inside projections; ie to say

       a.e1~~Foo(a==1,b==1)

    instead of
    
       a.e1.a==1 && a.e1.b==1

    The other major benefit is "short-circuit null checking" -- if you
    mention a.e1.a in a pattern, the compiler implicitly generates
    code to check if a.e1==null.

    I don't believe that it makes sense to have patterns be
    first-class.  It's also pretty easy to wrap an anonymous
    lambda-abstraction around them.

    This is a pretty ambitious goal; obviously I'm working on the
    simpler approach first, but I think something similar to this is
    worth discussing.

Thanks for the pointers; I'm going to get started with the simple case
(just implementing patterns-as-boolean-expressions and 'is').

> Does that help you get started?

You bet; thanks a lot!  I did most of gcj's Win32 target, and that
experience taught me to always ask for pointers before diving into the
internals of another compiler... ;)

> testsuite/compiler/methods/deepDispatch.testsuite

You bet.

> If you wish, we can set up a virtual meeting, to avoid one-day lags
> in communication :-)

That sounds like a good idea -- let me get acquainted with the code
first though.

  - a



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com