`then` has funny status

[shriram]

Is then a keyword or not?

It doesn't show up in the docs (all I see is the .and-then method of Option).

Curiously, I'm still allowed to define a function called then, only not a field of an object:

fun then(): 3
where:
  then() is 3
end

o = {then: 1}

The function definition is fine, but the object produces a syntax error (even with the function erased), but

o = {thn: 1}

check:
  o.then raises ""
  o.thn is 1
end

passes (i.e., then can legally be used as a field name access without producing a syntax error).

[blerner]

then is not a keyword, but then: is a color-keyword. So {then : 5} would be a valid object, but {then: 5} is a parse error. In general, we have several colon-keywords, and not all of them have non-colon counterparts.

[sorawee]

To avoid confusion, I think then should be a keyword (and reserved). More generally, if <x>: is a keyword, <x> should as well.

[sorawee]

See also #744.

[blerner]

We've taken pains to avoid doing that precise thing. The idea was to steal as few words from the language as possible. (table, block, examples, doc, otherwise, source, where, with, row, and probably a few more that I'm missing)

[shriram]

But in this extremely natural scenario, where I built a top-level function and then wanted to group it and a few other functions inside an object, I get really odd behavior. I'd rather have been told "you can't write then at all" than to have to go and change all my code (CPO doesn't have any rename facility that would make that easier).

[blerner]

"In this extremely natural scenario"...that only you have encountered, once, in several years of programming in Pyret :) We've now seen a couple of examples (once each) of colon-keywords being surprising. #744 suggests that we make all colon-keywords be non-colon keywords too (as @sorawee said above), and we had initially intended to not do that, to avoid stealing too many good words from the available pool of names. I don't think it makes sense to be piecemeal about this: either we stick to the "only minimal keywords" viewpoint, or we break back-compat and reserve all the un-colon'ed keywords as well. My hunch is that there aren't many programs that we would break because of such a change, but I don't have any way to quantify that.

So: do we want to break back-compat?

[jpolitz]

We could do @schanzer 's WeScheme trick and run the alternate parser (with reserved words) for a few months in the background and log any cases where a program would fail when it didn't before – infrastructure for that would be cool in general. I'm not going to go do that tomorrow, but it would be a great project for future back-compat issues!

[shriram]

That sounds like a neat idea!