About implicit do or do* expressions

[kasperpeulen]

I was also posting this in the do proposal:
tc39/proposal-do-expressions#9

To me, it sounds most logical that if any of the if, switch, for, while, try keywords are used in an expression context, then it will be an implicit do expression construction:

So the following

const num  = if (cond) {
  100; 
} else {
  10;
};

would be equivalent to:

const num  = do {
  if (cond) {
    100; 
  } else {
    10;
  }
}

Similarly, the following

const iterable = for (let user of users) {
  if (user.name.startsWith('A'))
    yield user;
}

would be equivalent to

const iterable = do* {
  for (let user of users) {
    if (user.name.startsWith('A'))
      yield user;
  }
};

[leonardfactory]

To me this looks very promising. Even thinking about JSX.

To better understand the first example, I see you use if (cond) { 10; }, without yielding. Is this intentional? Maybe something like:

const result = if (cond) {
  yield 100;
}
else {
  yield 10;
}

Sounds better?

Digging deeper, the yield solves some odd behaviours shown in CoffeeScript about nested list comprehensions. Wondering if CS history (considering differences) would help in understanding this proposal eventual downsides/upsides.

[sebmarkbage]

If you put any of these in an outer generator function things start getting subtle.

function* generator() {
  if (users[0].name.startsWith('A'))
    yield user;
  }
  const iterable = for (let user of users) {
    if (user.name.startsWith('A'))
      yield user;
  }
  const result = if (cond) {
    yield 100;
  } else {
    yield 10;
  }
  yield 123;
}

That's something that the extra * { } helps avoid since there is another boundary to indicate that something special is going on and where the yield will end up.

[babakness]

This would be awesome.

im not sure, but is what you trying to propose is a substitute for Arrow Function?

const num
= params => params.cond1
         && params.cond2
          ? 100
          : 10

generators dont mix, but direct yield* of map, filter or reduce would probably be sufficient

const firstLetterIsA = _ => _.name.startsWith( 'A' )

function* iterable()
  { yield* users.filter( firstLetterIsA ) }

[babakness]

I don't think so...

const num = params => params.cond1
         && params.cond2
          ? 100
          : 10

console.log(num) // [Function]
console.log(num()) // 100 or 10
const num2 = if (params.cond1 && params.cond2) {
  100
} else {
  10
}

console.log(num2) // 100 or 10 

A programming example that really exemplifies the utility of this is Ruby. In fact one reason arrow function offer so much utility is that single line arrow function have the implicit return. It leads to better readability. Consider this

const hasNoRemainder = n => d => !n ? n : n % d === 0
const fizzBuzz = fizzNum => buzzNum => num => {
  const numHasNoRemainder = hasNoRemainder( num )
  return if ( numHasNoRemainder( fizzNum * buzzNum ) ) { 'fizzBuzz' }
    else if ( numHasNoRemainder( fizzNum ) ) { 'fizz' }
    else if ( numHasNoRemainder( buzzNum ) ) { 'buzz' }
    else { num }
}

There is a single return statement. Rather than this example, where each condition has an return statement.

const hasNoRemainder = n => d => n % d === 0
const fizzBuzz = fizzNum => buzzNum => num => {
  const numHasNoRemainder = hasNoRemainder( num )
  if ( numHasNoRemainder( fizzNum * buzzNum ) ) { return 'fizzBuzz' }
    else if ( numHasNoRemainder( fizzNum ) ) { return  'fizz' }
    else if ( numHasNoRemainder( buzzNum ) ) { return 'buzz' }
    else { return num }
}

The first example conveys the idea in a much clearer way, the function returns the value resolved from the condition check; this versus each condition check returns some value (or maybe not, resulting in bugs, etc.)

here come the imperative vs functional again..

/rel https://github.com/tc39/proposal-pattern-matching

[tasogare3710]

I think that better to put an asterisk like if*, switch*, for*, while*.

const num  = if* (cond) {
  100; 
} else {
  10;
};

const iterable = for* (let user of users) {
  if (user.name.startsWith('A'))
    yield user;
}

but, I feel that extra "let" and "yield" appear compared to the comprehensions.

[for(n of "1234567890") if(n != "0" && n != "1") for(op of "+-/*") eval(`${n} ${op} ${n}`)]

[for(let n of "1234567890") if (n != "0" && n != "1") for(let op of "+-/*") yield eval(`${n} ${op} ${n}`)]

can let and yield be omitted?

[kasperpeulen]

I think that better to put an asterisk like if*, switch*, for*, while*.

That makes very much sense to me if the * indicates an implicit do* expression. And without, is an implicit do expression.

That would also solve the problem that @sebmarkbage describes above.

So then we would write this:

const iterable = for* (let user of users) {
  if (user.name.startsWith('A'))
    yield user;
}

Writing without a star (justfor) would then raise an error, as yield is not defined in that context.

You could then also generate an iterable like this:

const numbers  = if* (cond) {
  yield* [100,200];
} else {
  yield* [10,20];
};

The usecase is probably very little for the last example, but it would make this all very consistent and predictable.

[tasogare3710]

@kasperpeulen

That makes very much sense to me if the * indicates an implicit do* expression.

Yes. I believe that it is implicit do expression, but may be confusing indeed.
Also, there may be problems that I overlook.

[babakness]

Please don't add * to each if* etc.. that is, in my opinion, clunky and ugly.

Since inception JavaScript if returns void. So if it started to return the last evaluated value, no old code will break, since that code is just ignoring that value.

Anyway, it isn't too hard to just build one's own ifElse. For example, here is one that behaves similarly to Ramda's ifElse

const ifElse = testCondition => trueCondition => falseCondition => input => (
   testCondition(input) ? trueCondition(input) : falseCondition(input)
)

example:

const halveOnlyEvenValues = ifElse
   ( num => num % 2 === 0 ) // test condition
     ( num => num / 2 ) // true condition
     ( num => num )  // false condition

const val1 = halveOnlyEvenValues(10) // 5
const val2 = halveOnlyEvenValues(11) // 11

To emulate the if / else discussed here, one could do

const noInputIfElse = testCondition => trueCondition => falseCondition => 
  ifElse(testCondition)(trueCondition)(falseCondition)()

For example this

const num1 = 5
const val3 = if(num1 % 2 === 0) {
  num1 / 2
} else {
  num1
}

is essentially just

const num2 = 5
const val4 = noInputIfElse( _ => num2 % 5 === 0 )( _ => num2 / 2 )( _ => num2)

Which, upon looking over, probably isn't as nice as the way Ramda does it. Also, it isn't hard to build a variadic version of our ifElse.

// first, some standard helper functions
const always = a => b => a
const head = arr => arr[ 0 ]
const tail = arr => arr.slice( 1 )
const pipe = ( ...funcs ) => input => tail( funcs ).reduce( (a,b) => b(a), head( funcs )( input ) )
const compose = ( ...funcs ) => pipe( ...funcs.slice().reverse() )
const chunk = n => arr => !arr.length 
  ? [] 
  : [ arr.slice( 0, n ) ].concat( chunk( n )( arr.slice(n) ) )

// group list items into pairs
const pairListItems = chunk(2)

// multiIfElse 
const multiIfElse = ( ...conditions ) => defaultCondition => compose(
  ...pairListItems( conditions )
      .map( pairs => ifElse( pairs[ 0 ] )( pairs[ 1 ] ) )
)( defaultCondition )

Side note, this mulitIfElse can also serve as the basis to create a pretty neat switch.

Now the fizz-buzz example is just

const hasNoRemainder = n => d => !n ? n : n % d === 0
const fizzBuzz = fizzNum => buzzNum => num => 
  multiIfElse(
    numHasNoRemainder => numHasNoRemainder( fizzNum * buzzNum ),
      always('fizzBuzz'),
    numHasNoRemainder => numHasNoRemainder( fizzNum ),
      always('fizz'),
    numHasNoRemainder => numHasNoRemainder( buzzNum ),
      always('buzz'),
)( always(num) )(hasNoRemainder( num ))

or perhaps

const hasNoRemainder = n => d => !n ? n : n % d === 0
const numHasNoRemainder = num => hasNoRemainder( num )
const fizzBuzz2 = fizzNum => buzzNum => num => multiIfElse(
     always( numHasNoRemainder( fizzNum * buzzNum ) ),  always('fizzBuzz'),
     always( numHasNoRemainder( fizzNum ) ),  always('fizz'),
     always( numHasNoRemainder( buzzNum ) ),  always('buzz'),
)( always(num) )()

Anyway this

const hasNoRemainder = n => d => !n ? n : n % d === 0
const numHasNoRemainder = hasNoRemainder( num )
const fizzBuzz2 = fizzNum => buzzNum => num => 
  multiIfElse(
     always( hasNoRemainder( num )( fizzNum * buzzNum ) ),  always('fizzBuzz'),
     always( hasNoRemainder( num )( fizzNum ) ),  always('fizz'),
     always( hasNoRemainder( num )( buzzNum ) ),  always('buzz'),
)( always(num) )()

Would be awesome. It just feels like what JavaScript should do...

I just don't see the advantage to adding an unnecessary asterisks

const hasNoRemainder = n => d => n % d === 0
const fizzBuzz = fizzNum => buzzNum => num => {
  const numHasNoRemainder = hasNoRemainder( num )
  return if* ( numHasNoRemainder( fizzNum * buzzNum ) ) { 'fizzBuzz' }
    else if* ( numHasNoRemainder( fizzNum ) ) { 'fizz' }
    else if* ( numHasNoRemainder( buzzNum ) ) { 'buzz' }
    else { num }
}

Seriously why do this? (yuck!) What an eye sore! From the return function it is pretty clear what is going on. I'm not a huge fan of the generator syntax in Javascript. I pretty much avoid them. But at least there the function behaves quite differently. Here the if just implicitly returns. Why add line noise?

[babakness]

No asterisks! :-)

[ljharb]

@babakness you might be wrong about “no old code breaking”:

if (true) { [1,2] }
[1] // is this an array with `1`, or the index 1 on the array literal, `2`?

[tasogare3710]

@babakness I think that noise is generated due to too many functions names and function applications.
If do not need reusability, arrow function feels noisy.

Btw, may not need to put an asterisk in else if.

/*
 * code not to reuse
 */

function* fizzBuzz(max) {
    for (let i = 1; i < max; i++) {
        if ( (i % 3 == 0) && (i % 5 == 0) ) {
            yield 'FizzBuzz'
        } else if (i % 3 == 0) {
            yield 'Fizz'
        } else if (i % 5 == 0) {
            yield 'Buzz'
        } else {
            yield i
        }
    }
}

console.log(...fizzBuzz(1000))

console.log(...(for* (let i = 1; i < 1000; i++) {
    if* ( (i % 3 == 0) && (i % 5 == 0) ) {
        yield 'FizzBuzz'
    } else if (i % 3 == 0) {
        yield 'Fizz'
    } else if (i % 5 == 0) {
        yield 'Buzz'
    } else {
        yield i
    }
}))

[babakness]

@ljharb Hey Jordan, this must be a warning from a linter, in Node I get

> if (true) { [1,2] }
[ 1, 2 ]