This is the mail archive of the kawa@sources.redhat.com mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Suggestions for handling XML from Kawa?


On 7 Aug 2001, Per Bothner wrote:

> Jocelyn Paine <popx@pop3.ifs.org.uk> writes:
> 
> > To take my last message (about TreeList) further, has anyone any
> > suggestions on the best way of processing parsed XML from Kawa?
> 
> I like the idea of using pattern matching combined with
> "xml type expressions".  XQuery has a type algebra that is rather
> expressive.  You can combine this with run-time type tests.and
> "FLWR"-expressions to do some quite fancy stuff.  Even nicer
> would be ML-style patterns where you can make variable bindings to
> *parts* of a value.  A hypothetical Scheme syntax might be:
> 
> (match EXPR
>   ((x :: (element-type 'a)) => (something1 x))
>   ((element-type 'b (y :: (element-type 'c))) => (something2 y))
>   (else => (something3)))
> 
> This would evaluate EXPR and first see if it is <a>...</a>.
> If so, the variable x is bound to the element, and someting1 is called.
> Otherwise, we see is teh value of EXPR matches <a><c>...</c?</b>.
> If so, y is bound to the <c>...</c>, and something2 is called.
> Otherwise, something3 is called.
> 
> I suggest reading about XQueryand related issues at
> http://www.w3c.org/XML/Query.  There are some interesting ideas there.
>
> 	--Per Bothner
>
That would all be very nice. But why stop at matching XML? It would
be wonderful to have this for manipulating arbitrary Kawa (and
Java) data structures. One (of several?) problems would be that
to maintain data abstraction, one would want the patterns to refer
to public access selectors/methods rather than going down to the
underlying fields:

  (match EXPR
    ((x :: (complex? (get-real -> R get-imag -> I)) 
      => (something1 R I))
    ((x :: (free-vector? (v :: (get-origin -> O get-end -> E))) 
      => (something2 O E))
    (else => (something3)))

If EXPR satisfied the predicate complex?, then this would call the
functions get-real and get-imag to extract its components, avoiding
exposure of how a complex is actually represented.

Jocelyn Paine


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]