possibly.js

const [not, definitively] = [Symbol(), Symbol()]

export default const possibly = possibility => premise => alternatively =>
    [premise, ...possibility, definitively].reduce((premise, postulate) => 
        premise === not
      ?
        alternatively
      :
        postulate === definitively
      ? 
        premise
      :
        postulate in premise
      ?
        premise[postulate]
      :
        not
    )

I think it's a little hard to distinguish the predicate expression from the result.

Maybe some nesting to distinguish question/answer ?

I do this fwiw:

question 
  ? answer
: question
  ? answer 
  : otherwise

To sort of mimick:

if question:
  answer
else if question:
  answer
else:
  otherwise

Usage

var pathToDesiredPoint = possibly(['path', 'to', 'desired', 'point'])

pathToDesiredPoint({
  path: {
    to: {
      desired: {
        point: 'foo'
      }
    }
  }
})(
  false
)

// ☝️ 'foo'

pathToDesiredPoint({
  path: {
    WTF: {
      shit: 'lol'
    }
  }
})(
  false
)

// ☝️ false

@JAForbes this form of indentation is notionally intuitive, but I find doesn't work in practice – if all operands are simple references it's not so bad but in practice I find the combination of (indentation + ternary operator + ternary operand expression with own punctuation) on the same line is a false compromise which diminishes the individual legibility of all elements.

The idea with operators having their own lines is that it's very quick to parse the overall structure of the ternary expression at a glance, and then be able to digest the contents of the constituent expressions without the leading noise of the operators.

In this case we have a formalisation of the switch(a){【case a: b break】* default d pattern, where only the last operand of the ternary can be another ternary. By glancing at a sequence of

  a
?
  b
:
  c
?
  d
:
  e

…we see a linear sequence of ? : ? : and can immediately determine that pattern. Then we can parse the alternating lines with different indent as a sequence of postulate left (postulate left (postulate left (right))).

This is IMO a win of least signal/noise in pattern recognition that also allows the internal concerns of each operand expression to have its own sub-pattern indentation concerns without having to take account of the surrounding context:

  !postulate
?
    further === condition
  ?
    [anything, could, happen] 
  :
    on.itsOwn(terms)
:
  ({
    multiline,
    construct,
  })

It also has the advantage of accommodating the other logical operators (&&, ||) without having to consider conflicting whitespace patterns, because the rule of

  operand
#
  operand

…is agnostic as to the significance of operand expressions within wider structure.

Sorry I completely missed your actual function's functionality! 😆 It's cool. Ramda has a function like this called pathOr.

I don't agree that legibility is affected, but I also see value in what you're doing. I think the fact that in my code bases operator first applies to everything, from dot access, ternaries, addition/concatenation, logical and/or, bit shifting whatever... there's not really as much fighting on on the ternary operand expression. But I think if I wasn't so strict here, it'd seem noisier.

I am probably struggling to read your ternaries just because my mental algorithm for reading ternaries requires matching a certain pattern and I'd just need to internalize your pattern and then it'd seem just as good. But I'm generally pretty white space dense so I'm wary, but yeah it looks neat!

It's the Material Design Lite of code styles