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" notifications@github.com
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" notifications@github.com 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).