Hi Jens, To answer your opening question, this email exchange has brought us to the root of the issue, which I personally find very useful, because I like to understand what is happening to me when something is happening to me. After all, this was not really about the XRPC extension not being parsable. Rather, the small diff needed to introduce the proposed syntax does not suit your *coding* easthetics, apparently because you object to the use of REJECT in a scanner. Or something along those lines. I infer this from your qualification of my code as "lowering the quality of the Pathfinder parser". I can only assure you that "messing up the Pathfinder parser" was not my intent while writing that code. Given that the Pathfinder parser (and beyond) is mostly your brainchild, I can understand that you want to retain control over where it is heading. So if you block this proposal for reasons of taste, I will have to listen to you, even if I disagree or simply do not understand what the fuss is about (I myself care more if a language syntax is handy for a human user, rather than for a parser, which is operated by a machine without feelings). So, on to an alternative syntax. I will restrict myself to the alternatives that you find acceptable for some reason. For me the XQueryD syntax is not a holy thing, as it does not really have any installed base. It is not part of Galax, just was part of some prototype that never made it into a stable version. But I do like the 'xquery' variant better than the curly braces, plus we have indeed the argument that this is the same as something that was proposed before (even if that something has become irrelevant). So, thanks in advance for making that change.. Peter

van: Jens Teubner datum: 2006/10/25 Wed PM 06:38:03 CEST aan: p.a.boncz@chello.nl cc: Ying Zhang , P.Boncz@cwi.nl onderwerp: Re: Re: XRPC syntax

On Wed, Oct 25, 2006 at 06:00:39PM +0200, p.a.boncz@chello.nl wrote:

...

Hi Jens,

Well, you had me reading the flex manual there, after which I must still conclude that our modification is parsable.

What I meant from the start is that one can match the operator keywords after which a "(" can legally occur (eq, etc) with preference over QName_LParam. See the below diff.

There are also ways of doing that without REJECT, if your religion does not permit its use. e.g.: ("eq"|("eq"/{_}"(")) { gotoState (DEFAULT); yield (eq); }

The MIL parser is a mess; but gladly its internals should play no role in this discussion.

Hi Peter,

I cannot see where this shall head. Why would we, under all circumstances, try to mess up Pathfinder's parser? As far as I can see, *all* the proposals made by other people do use some syntax that aids parsing. The XQuery syntax itself built its way for good reason, and both approaches we had are very much in the flavor of XQuery. I cannot see why we would want to give that up.

I *strongly* vote for using either of the following two options:

-- execute at { Expr } { FunctionCall }

-- execute at Expr xquery FunctionCall

Both, in my opinion, are clean and in line with the remaining language. From a parser point of view, we could leave out the *second* pair of curly braces, but that would only make things inconsistent.

Also, I cannot understand why you insist on introducing your very own syntax for XRPC. There have been other proposals. In the spirit of interoperability, experimentation, comparison, etc. I think the adaption of existing syntax is a good idea. It would help increasing our system's acceptance and visibility, I argue.

(I brought the MIL parser into the discussion, because I thought that would put you off any attempts to lower the quality of Pathfinder's parser.)

Jens

-- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263

Linus Torvalds is a lot like Bill Gates. Both are about the same height. -- USA Today