type-inference-independent comprehensions

[StefanKarpinski]

https://groups.google.com/forum/#!topic/julia-dev/DF8LUiH7FP4

I was looking for an issue for this but realized that it wasn't a GitHub issue yet. Now it is.

[stevengj]

Why is this a breaking change?

[StefanKarpinski]

Because it changes the type of comprehensions, which affects the behavior of programs.

[stevengj]

My impression is that Jeff's algorithm will only produce tighter typing than we have now. Mostly this seems like it will affect performance, but I agree that in principle it could change other behaviors.

I would be suspicious about code whose correctness relies very sensitively on what type Julia infers for a comprehension, though, since Julia's type-inference abilities don't seem to be strictly documented at the moment. And changes in undocumented behaviors are a weaker type of "breaking" change.

[StefanKarpinski]

I suspect this break a fair amount of code, actually. Comprehensions that currently return ByteString will return ASCIIString and the code will break when inserting UTF8Strings.

[StefanKarpinski]

Just one example. There are many others.

[StefanKarpinski]

Of course, maybe it's rarer than I think to insert things into the result of a comprehension.

[IainNZ]

I second @stevengj 's notion that it shouldn't matter - but I'll still be interested to see PackageEval results after its merged :)

[StefanKarpinski]

Well, that would be a lovely surprise. Even though type inference behavior is undocumented, in a sense this is a much worse breaking change than API changes because you can't reasonably deprecate it.

[JeffBezanson]

The good thing about this change is that it is not really possible to
"document" type inference behavior. Our inference necessarily involves
heuristics. Even in an ML-like language, where there is a straightforward
algorithm, what can be inferred is not always totally intuitive.
On Jun 14, 2014 12:04 AM, "Stefan Karpinski" [email protected]
wrote:

Well, that would be a lovely surprise. Even though type inference behavior
is undocumented, in a sense this is a much worse breaking change than API
changes because you can't reasonably deprecate it.

—
Reply to this email directly or view it on GitHub
#7258 (comment).

[StefanKarpinski]

Agreed, getting rid of the dependence on these heuristics is why this is so appealing.

[kmsquire]

I'm also really looking forward to this change.

In the referenced thread, Jeff suggested this might conflict with removing
automatic concatenation of [A,B], which I would REALLY like to see.

Is it possible to have my cake and ear it too here?

[kmsquire]

Is it possible to have my cake and ear it too here?

ear -> 'ere. ;-)

[JeffBezanson]

That has more to do with interpreting a comprehension as a "concatenation"
of a generator, which is separate from this issue.
On Jun 14, 2014 2:15 PM, "Kevin Squire" [email protected] wrote:

Is it possible to have my cake and ear it too here?

ear -> 'ere. ;-)

—
Reply to this email directly or view it on GitHub
#7258 (comment).

[ivarne]

@IainNZ For potentially big breaking changes like this. Would it be possible to run PkgEvaluator on a branch, before we merge it into master?

[StefanKarpinski]

Oh, man, being able to see the impact of a change across packages before merging it would be huge.

[joehuchette]

FWIW Rust has a pretty cool approach to this kind of thing with bors, a bot that automatically takes PRs and tests them before they get merged into master: rust-lang/rust#14906

[StefanKarpinski]

Cool. Maybe we should look into using that. Although @IainNZ's package evaluator is already pretty great.

[IainNZ]

Absolutely @ivarne

[joehuchette]

It's really great, I was thinking more that this kind of thing could be a really slick front-end to PackageEvaluator that automatically spits results out onto Github.

[timholy]

@joehuchette, you know we already do that with Travis for Julia proper? Just open the page of pull requests, and look at the little green checkmarks or red xs.

This is specifically about running the tests in all the packages, too. I couldn't tell if bors does that?

[joehuchette]

I believe Rust uses bors much as julia uses Travis: to run the test suite on PRs to see if anything breaks before merging. A bot in the vein of bors could offer a bit more granularity than Travis does (to the best of my knowledge): instead of running PackageEvaluator with every commit in a branch (and burying the results in a log), run it only when prompted by a collaborator and then dump the results directly to the PR conversation. There certainly is a fair amount of redundancy, though.

[IainNZ]

My first priority for a JuliaBot would actually be In METADATA, automatically apply the same logic PackageEvaluator does to the packages listed in the PR - no human intervention required there.
Something for PRs could be next. Having said that, the nightly runs have caught all the breaks within 24 hours of them occurring (equality, linalg, UTF16/32 strings), so its not clear if its really that high-impact an idea.

[pao]

Having said that, the nightly runs have caught all the breaks within 24 hours of them occurring (equality, linalg, UTF16/32 strings), so its not clear if its really that high-impact an idea.

It might help to get an objective idea of how much pain a breaking change may cause, and when/whether to move forward with it.

[ivarne]

It would make a great difference for Package authors to get notified a week before their package became incompatible with the latest master, rather than within 24 hours after. That will also draw attention to the change and Package authors might have something to add to the discussion.

[StefanKarpinski]

All of these things. It would be a phenomenal way to minimize the pain of language changes.

[tkelman]

Blocked on performance regressions at the moment? Still has a branch that could be rebased (significantly) for testing.

[StefanKarpinski]

Yes, all of the blocking issues/prs are now merged, so we should revisit whether this can be done now.

[JeffBezanson]

I think #15402 is the relevant regression here.

[JeffBezanson]

Current PR: #16622
Blocked by: #16201
which is fixed by: #16692

[StefanKarpinski]

Status update?

[JeffBezanson]

Status is same as last week.