Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

if the implicit "else" of p:if is redefined, p:otherwise should have the same semantics #785

Open
pmasereeuw opened this Issue Mar 10, 2019 · 10 comments

Comments

Projects
None yet
5 participants
@pmasereeuw
Copy link

pmasereeuw commented Mar 10, 2019

No description provided.

@pmasereeuw

This comment has been minimized.

Copy link
Author

pmasereeuw commented Mar 10, 2019

If the semantics of the implicit "else" part of p:if will be "p:identity", it would be strange if, inside p:choose, the effect of a left out p:otherwise would be p:sink. But I am not sure if redefining that would be in conflict with xproc 1.0 semantics (I never left out p:otherwise, I must confess).

See #751

@eriksiegel

This comment has been minimized.

Copy link
Contributor

eriksiegel commented Mar 10, 2019

it would be strange if, inside p:choose, the effect of a left out p:otherwise would be p:sink

Why strange?

And yes, redefining that would be in conflict with the 1.0 semantics.

@pmasereeuw

This comment has been minimized.

Copy link
Author

pmasereeuw commented Mar 10, 2019

Compared to other programming languages, it seems to me that otherwise in a case statement is very much the same as an else in an if-statement. So it might come as a surprise when in xproc, the definition of both clauses would have different semantics.

In other languages, if an else or an otherwise is missing, that would usually mean "nothing happens". And my feeling is that the xproc equivalent of "nothing happens" is p:identity rather than p:sink.

How bad is it to break with 1.0 behaviour? It will certainly be something to be aware of when porting existing pipelines, and that makes it bad. So maybe my original proposal about p:if/else was not so good an idea after all. Or am I too sensitive about orthogonality between else and otherwise?

@eriksiegel

This comment has been minimized.

Copy link
Contributor

eriksiegel commented Mar 11, 2019

How bad is it to break with 1.0 behaviour?
@gimsieke SInce you're one of the biggest 1.0 users, any comments?

@gimsieke

This comment has been minimized.

Copy link
Contributor

gimsieke commented Mar 11, 2019

I analyzed a typical transpect project, including many of the libraries and project-specific code, all written by a variety of authors (approx. 10–12) with no specific p:choose coding guidelines in place.


Number of p:choose: 125

Explicit p:otherwise identity (anonymous) with a single p:when (can be converted to p:if): 47
This is a strong case for p:if with identity by default.

Explicit p:otherwise identity (anonymous) with multiple p:when: 4

Explicit p:otherwise identity (named) with a single p:when (can be converted to p:if): 5

Explicit p:otherwise identity (named) with multiple p:when: 0

Interesting stuff in p:when and p:otherwise branches: 36

Explicit p:otherwise identity with non-DRP input: 10

Explicit p:otherwise identity with cx:message side effect and a single anonymous primary output: 5

Explicit p:otherwise with multiple ports, primary does identity, others do sink/empty/identity: 5

Main action happens in p:otherwise, p:when does anonymous identity: 4
Can be manually converted to p:if when negating the @test expression.

Explicit p:otherwise identity with p:empty input, maybe additional outputs: 2

Explicit p:otherwise with p:sink only: 7

No p:otherwise: 0


So of all p:chooses that may not automatically be converted to p:if or that must keep their p:otherwise because it is too complex, we have 7 times p:sink in p:otherwise and 4 times multiple p:whens with an identity in p:otherwise.

This means there is no clear contender for a preferred default behavior (sink or identity) for p:otherwise.

Migration is no concern, these cases can be identified and converted automatically to either variant.

So we are still left with making the call: Consistency with p:if or with XProc 1.0.

Applying the principle of least surprise/magic can give arguments for both variants.

Stuff for the next conference call, I guess.

@eriksiegel

This comment has been minimized.

Copy link
Contributor

eriksiegel commented Mar 11, 2019

Wow Gerrit, That's an impressive analysis. Thanks.

I lean towards default p:identity behavior. I think we have a reason for a next call.

@ndw

This comment has been minimized.

Copy link
Contributor

ndw commented Mar 12, 2019

I don't disagree, but as a point of clarification, a missing p:otherwise today is not p:sink, it's a dynamic error.

@xml-project

This comment has been minimized.

Copy link
Contributor

xml-project commented Mar 13, 2019

@ndw Sure that it's a dynamic error? Can't find this in the specs. The syntax box leaves p:otherwise explicitly optional. What did I miss?

@ndw

This comment has been minimized.

Copy link
Contributor

ndw commented Mar 13, 2019

My bad. We changed that rule in #648 and I'd just forgotten.

Yes, I agree, the behavior of p:if and p:choose without a p:otherwise should be consistent.

@ndw

This comment has been minimized.

Copy link
Contributor

ndw commented Mar 20, 2019

Per the 20 March editorial meeting; if the p:when steps define a primary output port, then an absent p:otherwise acts like p:identity. If there is no primary output port, then nothing is produced.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.