Syntax proposal for making string dicts easier to write

[blerner]

Currently we have two constructors for string dicts:

[string-dict1: "a", 1, "b", 2, "c", 3] # This is the old API
[string-dict2: {"a"; 1}, {"b"; 2}, {"c"; 3}] # This is the new API using tuples

The first one is lousy because of potential arity errors (if you specify an odd number of arguments). The second avoids that problem, but is syntactically heavyweight, and the interleaving of commas and semicolons is (IMHO) confusing.

Proposal: within constructor syntax only (at least for now, because I think it might be ambiguous in other contexts), allow the following:

[string-dict3: "a" => 1, "b" => 2, "c" => 3]

where x => y is simply the tuple {x; y}. The grammar rule would require that if you used this syntax on any of the pairs, you'd need to use it for all of them, so no intermixing of [string-dict-weird: "a" => 1, {"b"; 2}] allowed.

Oddly, to me at least, this sugar seems lighter weight and easier to type, despite objectively being the same exact number of characters...

Thoughts?

[jpolitz]

If there's syntax for this, it could compile to passing two arrays (one for "keys"
and one for "values") to the collection constructor. This would mean more make methods that handle parallel arrays, but would save a lot of allocation of tuples.

[blerner]

True. I was trying to avoid changing the constructors object protocol, though, unless it was unavoidable.

[shriram]

Fully agree that the current tupled syntax feels clunky and the proposal looks a lot better. I like Joe's point. I don't see the need to change anything, though. There'd just be different constructors for "row major" and "column major", right?

[blerner]

Are you suggesting, then, that we have

[string-dict: a, b, c, d]
[newer-string-dict: a => b, c => d]

with two distinct constructor objects? That feels...harder to remember, I guess. And what should the names be for them, since they both construct StringDicts?

(And the same decision obviously needs to happen for MutableStringDict...)

[shriram]

Your first message began by saying "we have two constructors", and your `string-dict` and `newer-string-dict` seem to be the exact same two (except that the second one has been expressed using the newly proposed syntax, which I understand to be local sugar for {…; …}), which means I'm not proposing anything new at all relative to your original message. The proposal relative to Joe's message would indeed be a new "thing", one that took two (raw?) arrays. But since that has fixed arity, it can just be a regular ol' function: e.g., string-dict-from-arrays<T> :: RawArray<String>, RawArray<T> -> StringDict<T>

[blerner]

Oh, that was unintentionally confusing -- we have two such existing ones because we have two string-dictionary libraries: one that existed before tuples, and one that was created afterward...and is not used anywhere yet. They're incompatible with each other.

The problem with your "regular ol' function" is, how can I tell the difference syntactically between [string-dict-from-arrays: a => b, c => d] and [list: a => b, c => d], and generate very different code for them? The constructor-object protocol is, if you write [foo: whatever, you, want], then someone had to define an object named foo that has seven methods on it: make0 through make5, which are fixed-arity functions, and make, which takes a RawArray of however many (i.e., > 5) arguments there were. (Think of it, roughly, as a case-lambda.) The compilation of [foo: whatever, you, want] does not know anything in particular about foo.

[shriram]

The problem with your "regular ol' function" is, how can I tell the difference syntactically between [string-dict-from-arrays: a => b, c => d] and [list: a => b, c => d], and generate very different code for them?

You wouldn't! The second thing you wrote would not produce a string-dict. The proposed function (string-dict-from-arrays) would, as a two-argument function, but it *cannot* be used as a constructor in the [special-constructor-syntax: …] sense. Shriram

[blerner]

You wouldn't! The second thing you wrote would not produce a string-dict.
The proposed function (string-dict-from-arrays) would, as a two-argument
function, but it cannot be used as a constructor in the
[special-constructor-syntax: …] sense.

Now I'm completely confused. Currently the desugaring for [foo: a, b, c]
is foo.make3(a, b, c), and the desugaring for [foo: a, b, c, d, e, f]
is foo.make([raw-array: a, b, c, d, e, f]). I'm proposing that, within
constructors, the syntax a => b is sugar for {a; b}. Therefore, [foo: a => b, c => d] turns into foo.make2({a; b}, {c; d}). This is
compatible with the string-dict2 constructor at the top of this issue.

Joe suggested that "because we would have syntax, we could avoid allocating
all those tuples". Cool.

Could you explain what you're suggesting the desugaring for the following
four things should be?

[new-string-dict: a, b, c, d]
[list: a, b, c, d]

[new-string-dict: a => b, c => d]
[list: a => b, c => d]

If any of those go wrong, what error do they produce, and when (desugaring,
compilation, runtime)? Moreover, while I agree that the first pair of lines
can be compiled differently from the second pair, if you're suggesting that
the last two lines should result in different compiled forms, I'm confused
how we're supposed to achieve that.