Re: Static streamability, regarding bug 29984

> On Dec 8, 2016, at 9:51 AM, Abel Braaksma <abel.braaksma@xs4all.nl> wrote:
> 
> ...
> 
> My understanding of what the specification says is that a processor *must* be able to raise error XTSE3430 when a certain construct is not guaranteed streamable. It *must*, next to that, also give the user option to stream it anyway, if it is able to do so.
> 
> Now that that I see this section 19.10 again, we also seem to say that "if a processor is not able to do so (process using streaming) it must raise XTSE3430". While not part of this original bug report, but there are constructs that can be processed using streaming that cannot be statically assessed as streamable (optimistic streaming: just try, and fail dynamically if you can't).
> 
> This latter option is not something we presently seem to allow.

That seems to me to be covered by giving the user an option to stream anyway,
if the processor is able to do so.  Processor says “This isn’t GS, and I don’t know 
whether I can stream it or not, shall I try?”  User says yes or no.

> Besides that, from the above I'm in particular lost about this statement, which indeed may mean that I have misunderstood the specification:
> 
>> to mean “The processor’s streamability analysis must detect the failure of a
>> construct to be guaranteed streamable.”  But that’s not what it means
> 
> I need some help here. I think this is exactly what is expected: if a construct is not considered GS by the specification, we must raise an error (or offer one of the other options at *user option*, but being able to raise an error is not optional). And the inverse, if a construct is GS per our rules in the spec, a processor that claims conformance *must* process it using streaming (whereas what exactly "streaming"  means is not specified).

I’m distinguishing two things here:

  1 a processor’s “streamability” analysis, which has the ordinary language 
meaning of “analysis of whether the thing being analysed is streamable or 
not”.

  2 a processor’s “guaranteed streamability” analysis, which means its
analysis of whether the thing being analysed is guaranteed streamable
or not.

I do not assume the two are the same.

> 
> Then there was this: 
> 
>> How does our definition of guaranteed streamability serve
>> to encourage or discourage performance improvements in processors?
> 
> Say you have the expression " foo + foo", which is not GS. An optimizing processor may rewrite that very early on to "2 * foo". And then it is streamable. However, it isn't streamable.

Contradiction, here due solely to your conflation of the concepts GS and SIF
(guaranteed streamable and streamable in fact).  The expression is not GS.
It is SIF.

> So either the streamability analysis must come *before* optimization, or it should be allowed. But, unfortunately, we have some rules in the streamability section that encourage processors to optimize away certain constructs (for instance, we say if something is statically known to return the empty sequence, it is streamable, but we don't say what constructs these are, we leave that to the optimizing processor).

So the WG has built up the rules for GS in a way that makes calculation of 
GS separate from a calculation of SIF more expensive and complicated. 
That’s a shame, and makes me wish Dimitre had had more success persuading
the WG in 2012, or whenever that discussion took place.

> 
> So, some parts of expression rewriting must happen prior to streamability analysis, some parts afterwards. I would like to find a way that rewriting is not relevant for the streamability analysis (or more generally, optimizations). It is possible that I am vague about this, I just don't have the right expressive power to make my point understood, it seems.

I am not thinking of anything clever.  I am thinking of simple brute force:  Perform
the GS analysis.  Now compile the stylesheet.  Not elegant, but doable.

> 
> (conversely, I think our current rules are very good and I would dislike it very much if others would feel like we're throwing them out of the window, rendering them useless, that's certainly not my intent, if anything, it was my intent to make them *more* useful, to a wider audience, not a smaller one)

I think that ship has sailed.  The average power user of XSLT has essentially 
zero chance of reading and useing these rules if they take more than two pages
or so to print out.

********************************************
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
cmsmcq@blackmesatech.com
http://www.blackmesatech.com
********************************************

Received on Thursday, 8 December 2016 17:03:57 UTC