RE: Static streamability, regarding bug 29984

> -----Original Message-----
> From: C. M. Sperberg-McQueen [mailto:cmsmcq@blackmesatech.com]
> Sent: Thursday, December 08, 2016 5:12 PM
> To: Abel Braaksma
> Cc: C. M. Sperberg-McQueen; Public XSLWG
> Subject: Re: Static streamability, regarding bug 29984
> 
> 
> > On Dec 8, 2016, at 8:42 AM, Abel Braaksma <abel.braaksma@xs4all.nl>
> wrote:
> > ...
> > Furthermore, I like the idea that the specification would be written in such
> a way that it does NOT limit performance improvements, and I believe
> expression rewriting is a performance improvement that we should not
> discourage.
> 
> I think that you are once again conflating the concepts of guaranteed
> streamability and streamability in fact.
> 
> Given that the concepts are distinct, as they are in our spec (though not, it
> seems, in every WG member’s mind) how does the phenomenon you
> describe work?  How does our definition of guaranteed streamability serve
> to encourage or discourage performance improvements in processors?
> 
> Perhaps you are interpreting the proposition “Construct C is not guaranteed
> streamable” as meaning “Construct C should not be streamed” — but that’s
> not what it means.
> 
> Or perhaps you are interpreting the proposition “The failure of construct C to
> be guaranteed streamable must be detected by a processor”
> 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 — it
> has been clear since 2007 at the latest that the definition of guaranteed
> streamability given in the spec will not necessarily be isomorphic to an
> implementation’s internal analysis of streamability (i.e. its analysis of
> streamability in fact), nor to part of it.  It seems to me a fairly obvious
> consequence that the analysis of guaranteed streamability may then need to
> be carried out independently of a processor’s analysis of streamability in fact,
> at least in part.  All of your arguments seem to rest on the premise that there
> should be no difference between guaranteed streamability and streamability
> in fact — that is, it seems to me that you are conflating the two concepts.
> Please stop doing so; it is becoming harder and harder for me to believe that
> you are doing so in good faith.
> 

I'm sorry, but I think I don't understand. For sure it wasn't intentional.

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.

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).

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. 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, 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.

(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)


Cheers,
Abel

Received on Thursday, 8 December 2016 16:52:57 UTC