Introduce non-anonymous tables and reactors

[blerner]

Shriram:

We routinely see the pattern

t = table …

r = reactor …

in Pyret. Indeed, it's almost impossible to not write that: it's very rare to write a truly first-class table or reactor, especially early on.

I must admit that to me, these also look rather ugly, due to Pyret's indentation scheme (sorry BenL, but my Lisper eyes can never get used to Pyret indentation).

And yet we don't write

f = lam …

all the time. We think there's value to having named, first-order(-presenting) versions of what are actually anonymous, first-class values. In fact, at least some of our curricula go from fun to lam in its generality, but I don't know of almost any situation where we would truly use the anonymous, first-class-ness of especially reactors, but even — because of their syntactic unwieldiness (size, indentation, etc.) even tables. In practice they're likely to almost always be named. Yet we've stuck students with the equivalent of only lam.

Why can't we just name tables and reactors at the time of creation? There is not an obvious analog to fun/lam (which anyway are not a "logical" pair, they're just historical precedent), and I'm not sure we want more new keywords floating about anyway. But what if you could write either

table <rows>: …

or

table named <var> has <rows>: …

Likewise

reactor: …

or

reactor named <var>: …

One could then even imagine allowing

lam named <var>(…):…

[MIT Scheme actually had this construct. It's really useful when you want to define a lambda in the usual places you want a lambda, but suddenly realize you want it to be recursive. You don't have to refactor the code; you just name it and refer to that name recursively. It's not common but it's pretty handy when you want it. Yes, it's slightly ironic.]

One could imagine a consistent thing after the name (is is taken, but hypothetically, you always follow the name with the same keyword, like is), but I'm not sure that always parses well (the way from in for doesn't always). Or just let each construct choose its own meaningful following keyword, or none at all — as above.

[blerner]

Ben:
Viscerally, I’m not a fan — one of the few things I actively detest in Racket is the (let loop …) syntax, which is pretty darned similar to the MIT Scheme named-lambdas you mention: the first 10+ times I saw that syntax I thought “let and loop are both keywords”, and didn’t understand the syntax or semantics for quite a while. I’ll try to set that aside, but I really don’t like it and that is coloring my opinions below.

• I’m not a fan of having more kinds of binding sites in our language, especially because they’re non-orthogonal. Could you write t = table named not-t: ... end? Would that bind two names, one, or complain about well-formedness? (None of those answers are objectively or uniquely “right”…)
• I think the table named ... syntax is especially pernicious, because I would expect (and I’d wager teachers and or students might expect) that name position to be whatever the title of the table is, in the source from which it came. table named Potholes across the county: ... end or maybe if we’re lucky table named "Potholes across the county": ... end, and those won’t be grammatically valid or linguistically sensible identifiers.
• I don’t know how many BS:DS lessons turn on having a single table, vs multiple tables, but aren’t they frequently t = the-initial-table ...... ans = some table processing expression involving t? So it seems to me like the motivation is less urgent here.
• For reactors, I’m slightly more favorable, because it is rarer that we have multiple student-written reactors in a single program. I have two qualms here, though: (1) it’s virtually certain that students will get snarled up as to where to put the name: reactor named name: init: 0, on-tick: whatever ... end vs reactor: named: name, init: 0, on-tick: whatever ... end (there’s only one colon of difference there, but a potentially huge semantic one) (2) rather than make reactors named, if we want to optimize for the simple case why don’t we bring back and design a big-bang: ... end syntax that creates an anonymous reactor and interacts with it immediately?

I’m not objecting to this as a “this is the syntactic hill I shall die upon” level of fervor, but I don’t think I’m convinced the existing syntaxes lend themselves to this naming very cleanly, and am not sure if it’ll buy us more than it confuses. (I’m gonna guess that Emmanuel’s reaction will be something along the lines of “I’ve already worked through this in my lessons, and teaching more syntax takes away more time and cognitive budget from other things, so I don’t know if I’d actually use it in workshops.”)

[blerner]

Kuang-Chen:

I find it difficult to imagine a bug that is "attributable to the absence of such a feature" and does not involve misusing table expressions as name-binding.

Could you show me some patterns that you are looking for?

[blerner]

Shriram:

I expect it to show up in naming issues, if anywhere, e.g., in unbound identifiers.

I think this is more a "source of frustration" than "cause of bugs" issue, anyway. There's a tradition (originating from Dan Friedman) to teach Scheme syntax as

(define f (lambda (x) …))

from the very beginning, because Dan felt it was "important for students to see that that's what was really going on". (I virtually never saw a student "see" anything, they just made many more mistakes, and missed out on the pattern-matching connection between definition and use, which is why I got Matthias to stop using Dan's style.)

[blerner]

Joe:

I would love to hear some anecdotes about students who were confused
about this in lab/office hours, etc.

It's worth pointing out that one reason for fun <name> is that
functions are so often recursive it's not quite so simple to say
<name> = lambda. So it's usefully pulling more weight.

This doesn't feel urgent to me, even if it's the right thing to do.

---

Note that I think we can make a syntactic proposal that's simpler than
anything so far. Since tables and reactors both require a colon before
the rest of the declaration, we could write these like this, which I
would vastly prefer to adding new keywords. Cue an argument about
colons being attached to identifiers vs. keywords that would need to
be resolved and is better for a separate thread, but worth being aware
of.

table <name>: <row-name>, ...
  ...
end

reactor <name>:
  ...
end

[blerner]

Shriram:

Oooh! I like that! That's a nice analog to fun <name> too.

[blerner]

Joe's suggestion crystalizes for me why I don't like this proposal. I think his suggested syntax is the best we can do without breaking all BS:* programs, and it's worrying me:

• It breaks our desired min-edit-distance-2 rule, that different syntactic forms ought to be at least two tokens distinct. So

table: t, x, y, vx
  row: ...
  row: ...
end

is an expression, but

table t: t, x, y, vx
  row: ...
  row: ...
end

is a binding statement. That's subtle and hard to read. This will likely be very hard to engineer good error messages for, as well

• I don't think I like how this interacts with well-formedness:

fun foo():
  table: t, x, y, v
    row: ...
  end
  42
end

is a well-formedness error (two expressions without a block: keyword), but

fun foo():
  table t: t, x, y, vx
    row: ...
  end
  42
end

is just fine. And then at the top level (i.e. not in a function body), both forms are fine, and one of them is pointless (but would always render the table in the REPL area).

• There are already so many names at the outset of a table literal -- all those columns! So I really don't like this table t: t, x, y, vx ... end, even if that's a very common Physics table to have: the two t names have exceedingly different semantics, separated by a flimsy colon. One defines an identifier, and either the other should shadow or there should be a lot more identifiers defined here!

I've focused so far on tables, but I'm concerned for reactors as well. The first two points carry over unchanged. The last one is analogous, but I think we'll have a bigger issue with the name of the reactor vs the initial world value:

reactor r:
  init: r0
  ...
end

(Both r and r0 are lousy names here; my point is that one is a binding-site and one is a use-site, and they're disturbingly adjacent to each other.)

I think Shriram's claimed analogy that tables, reactors and functions are all three renditions of the same concept is a bridge too far. Tables are discrete and finite; reactors are temporal, and functions are neither of those things -- at least, as they're manipulated programmatically. Yes, I understand the concept you're trying to convey, but I don't think that shoehorning it into this position in the syntax is a good way to convey it...