Language design question: value of `block:`

[dbp]

Pyret has good support for mutation, iteration, etc. This requires being able to have multiple expressions/statements per block. This is not allowed by a well-formedness check, so if I write:

fun sum(l :: List<Number>) -> Number:
  var acc = 0
  for each(n from l):
     acc := acc + n
  end
  acc
end

I'll get an error prompting me to wrap the body in block:.

I certainly can, as either:

fun sum(l :: List<Number>) -> Number block:
  var acc = 0
  for each(n from l):
     acc := acc + n
  end
  acc
end

or

fun sum(l :: List<Number>) -> Number:
  var acc = 0
  block:
    for each(n from l):
       acc := acc + n
    end
    acc
  end
end

But, it's a bit clumsy, and in the case I want to do multiple things inside the body of the for each loop, I have to add another block:.

fun sum-odd-indices(l :: List<Number>) -> Number block:
  var acc = 0
  var idx = 0
  for each(n from l) block:
     when num-modulo(idx,2) == 0:
       acc := acc + idx
     end
     idx := idx + 1
  end
  acc
end

Now, the reason why this exists is in order to produce an error when someone accidentally puts multiple expressions inside a block (but, not on the same line, as that triggers a different error). Or, intends the function to return two things, not realizing that this is impossible.

My question is -- is the error (which suggests they add block, which in the functional case is not helpful) actually worth it? vs. them having to discover by testing that the final expression in the function is what is returned.

[shriram]

I feel quite strongly about this. We did this with much thought and on purpose.

Yes, it's annoying to have to write block. But it is also a teachable moment: the good kind of annoyance. And it is the single feature that obviates the need for language levels, in that 50% or more of what I care about from student language levels is covered by this one case, and the rest of it we either get from contexts or get by without.

If you want to argue for lightweight "blocking", we could discuss that. For instance, if there's a block at an outer AST node, it's inherited by inner ones. But I also worry that if we do this, students will just blindly write block at the outset (kinda' like they sometimes mindlessly write var for every binding) and the value will be lost.

The compromise of being able to write block before the : was a useful one: we did not have it originally, and things were indeed worse without that. It avoids the problem of "too mindless" while also avoiding the problem of "too fine-grained" — and in particular, saving several lines on screen. So that has felt like a good compromise.

There may of course be better error message designs.

[dbp]

Maybe this is just my bias in being very familiar with (and liking!) language levels. We've halfway re-implemented them poorly in our autograder -- e.g., we have a pass that, for most assignments, rules out var,:=, and ref.

The clumsiness of the error message for the beginning of the semester (when I had to tell students: don't follow the instructions to add block, only pay attention to the other suggestion, which is less actionable), combined now with the syntactic clumsiness when we do want to use block was what made we wonder whether there might be a better option.

But perhaps without language levels (which I understand the desire to avoid), it's unavoidable.

[jpolitz]

I could see a refinement to the current WF check, which is that if there is a := or a o!{...} in some expression in the block, don't require block:.

Of course, once you lift the mutation out into a function, you need block: again.

My dream would be to statically know if each expression could have effects, and only warn on standalone statements that do not have effects.

[dbp]

I could see a refinement to the current WF check, which is that if there is a := or a o!{...} in some expression in the block, don't require block:.

If you went down that path, it might be nice to lift this slightly, and also say expressions with subexpressions for whom the subexpressions were strictly mutation were also treated as "mutation expressions".

i.e., not only treat a := b, but also when x: a := b end. This would also neatly solve use of for each(), since it is intended to be "effect only". This would mean my examples above would not need block.

While this would allow "bodies with multiple things without having to indicate it explicitly", this is already the case with local definitions (Pyret doesn't have let or local -- which I've actually noticed! I have to say "a function has a single non-definition as its body", which is more complex, though worth it, than in *SL). If there is a clean way of doing it, not forcing people to jump through hoops because they are using := or o!{...} seems nice...

[jpolitz]

i.e., not only treat a := b, but also when x: a := b end. This would also neatly solve use of for each(), since it is intended to be "effect only". This would mean my examples above would not need block.

Yeah, completely agree.

Basically it is “did you signal clearly that you know what a multi-statement body is for”.