Suggestion: if-comprehensions

[Ichoran]

@jackcviers

Are we planning on issuing the transformation for any type that contains a getOrElse method? Does the type also need flatMap, and map as well?

I’m ok with targeting getOrElse for syntactic sugar as long as it would apply to more than just (pun intended) Option.

You would need getOrElse to support if p then a else b, and you would need orElse to support if p then a else if q then b else c.

[Ichoran]

@jxtps

Thoughts on if(a <- aOpt && !b <- bOpt)?

We should probably either not allow it

I would disallow it. You would write that logic as if (a <- aOpt && b.isEmpty).

[Jasper-M]

@Ichoran

No, because if you have a sum type you don’t know which branch to match on. Also, you have to finish your typing pass first so you even know what the branches are.

You could if you have to specify the pattern like in @LPTK’s language:

@LPTK

if aOpt is Some(a) and bOpt is Some(b) and a.foo() == b.bar() then 
   // Use a & b...
else ...

Then you are also no longer limited to data structures that are isomorphic to Option.

[morgen-peschke]

@Jasper-M

You could if you have to specify the pattern like in @LPTK’s language:

Wouldn’t that be closer to flow typing that it would something like a for-comprehension?

[hypatian]

I think the magical behavior of conditions in ifs sounds atrociously difficult to understand.

About the only thing I can imagine making sense here would be to add a for comprehension piece for “else”, although I think even then the specific semantics would need some working out:

for a <- aOpt; b <- bOpt; if c yield foo(a, b) else d

For Option this would be more or less the same as:

(for a <- aOpt; b <- bOpt; if c yield foo(a, b)) orElse d

For Seq it would be more or less the same as:

(for a <- aSeq; b <- bSeq; if c yield foo(a, b)) ++ d

Or in either case it could be something like:

{
   val tmp = (for a <- aThing; b <- bThing; c yield foo(a, b))
   if ! tmp.isEmpty then tmp else d
}

(Although that one feels somehow unsatisfying to me, despite the problem that the plus in Option is orElse and the plus in Seq is ++. ++ on Option forces it to become an Iterable instead of remaining an Option.)

[morgen-peschke]

@hypatian

For Seq it would be more or less the same as:

(for a <- aSeq; b <- bSeq; if c yield foo(a, b)) ++ d

I don’t think this works for Seq, as it unconditionally appends d

[hypatian]

Ahh. Good point. I was fixating on the “plus” part and not the “only when zero” part. Whoops. And “else” definitely implies that it only happens if the prior result was zero.

Seq doesn’t really have an operation like that. “orElse” on Seq is the orElse of PartialFunction, and not at all like orElse on Option. So if x.isEmpty then d else x is about the best you can do without adding something new.

Which is perhaps another illustration of how this isn’t really a very universal concept, and perhaps when it’s wanted it ought to be done in a way specific to the type involved.

[Ichoran]

@hypatian

I think the magical behavior of conditions in ifs sounds atrociously difficult to understand.

I kinda agree, but to be fair, I find for difficult to understand too

I basically never use for any longer. Too much sugar in my diet is bad.

[charpov]

@Ichoran

I basically never use for any longer.

Same here. I found for-yield mystifying when I started with Scala. Then, once I understood what it does I loved it for a while (especially on futures). Now, I tend to write map/flatMap/filter explicitly.

[jackcviers]

Agreed. That still gives us signatures in Option, Try, and Either in the standard library and would allow users to create interfaces that get desugared as well. Required methods are getOrElse and orElse.

[Jasper-M]

@morgen-peschke

Wouldn’t that be closer to flow typing that it would something like a for-comprehension?

Not any closer to flow typing than regular match expressions.
IMHO for-comprehensions are not the right feature to base this on either way.

[tarsa]

another language that do flow analysis is java with JEP 394: Pattern Matching for instanceof (looks like nobody mentioned it in this thread yet)

jep snippet:

Rather than using a coarse approximation for the scope of pattern variables, pattern variables instead use the concept of flow scoping . A pattern variable is only in scope where the compiler can deduce that the pattern has definitely matched and the variable will have been assigned a value. This analysis is flow sensitive and works in a similar way to existing flow analyses such as definite assignment.

terminology is rather unfamiliar to me, so i won’t comment on it, but my point is that java is yet another language that already does some analysis of type or value refinements. since java is mainstream, it made flow analysis mainstream too already, so maybe it’s not that scary. note that java doesn’t do flow-typing as described in wikipedia, because it needs additional identifier that receives refinement. on the other hand that makes it more similar to the proposal in this thread.