IE-0011: New data structures by curiousdannii · Pull Request #11 · ganelson/inform-evolution (original) (raw)

I hope it's not unwelcome for me to chime in over a year later…?

I just wanted to comment on the chosen syntax for each of the proposed types. (Though I've ignored promises and mostly ignored closures on the basis of them being both more advanced and more experimental.)

Any

If I'm not mistaken, the word "any" already has a meaning of sorts to Inform, so I think it might be bad to use it as the name of a kind. Maybe this is actually unambiguous with the other meaning though.

As to what the other meaning is:

To something or other: if any man (called the slouch) is on the couch: say "Look at that lazy [slouch]!";

I think that makes it basically one of the "noise words" alongside things like "a", "an", "some", etc. As far as I can tell it's only allowed in conditions though, not in assertions.

The only other possibility I can think of for a name though is "any value".

I'm also not happy with that "value as an any" syntax, but I don't have a better suggestion.

For these two:

To say kind/type of (A - any): To decide if kind/type of (A - any) is (name of kind of value K):

I would say articles should be allowed here - "the" before "kind/type" (though maybe that already works since it's at the beginning of the phrase?) and "a/an/--" before the name of the kind.

Similarly, in these ones:

To decide what K result is (A - any) as a/an (name of kind of value K): To decide what K is (A - any) as a/an (name of kind of value K) or (backup - K):

Is there some reason for the article to be required instead of optional?

It might be worth supporting some as an alternate to a/an in all these cases, too.

Couples

I don't actually have a comment on couples, but seeing the => syntax for accessing the values made me think it would be nice to have that work on lists too.

Maps

Is the new syntax actually necessary? As with lists, can't you already say "let M be a map of K to V"?

The clone syntax is probably useful for lists as well.

For checking keys, I think allowing "contains" as an alternative to "has" would be helpful for programmers coming from other languages, where that function is commonly called "contains".

I think it would be nicer if get were an optional keyword when looking up keys. Does that cause ambiguity problems or was it just not thought of?

The || option for the backup feels too programmer-ish for Inform. If it is included I think I'd prefer a single pipe instead of a double pipe (and if it works for maps it should probably also work for all the other backup cases).

It's slightly incongruous that getting and setting keys has a shorthand syntax (map => key [= value | or value]) but deleting and checking them does not. For checking, maybe something like "if map => key exists", and for deleting, maybe something like "map => key = none" or "del/delete map => key"?

Closures

I don't have much to say about these, but the term "closure" strikes me as a little strange here. Based on the example in the documentation, they seem more like what I'd call a "coroutine". What I'd call a "closure" does have some similar semantics, admittedly, in that it captures local variables from a stack somewhere, but from the way I understand things, it would usually be local variables from a function that has already terminated.

I was going to add an example in Inform-like pseudo-code, but I'm not even sure how to express what I'm trying to say in an Inform-like way. However, it's basically what you'd get from the (x, y) => expression syntax in JavaScript or the lamda x, y: expression syntax in Python when the expression references variables local to the current function.

Maybe that turns out to just be a special case of what you've implemented here as closures – I'm not sure. Since I'm not even sure how I'd express it in an Inform-like way, I can't even tell if your closures offer a way to express it.

Optionals

I second not being a fan of the "K option" syntax. I'm not sure if I can think of any good alternatives, but here are a few random ideas I thought of.

I also really dislike the is some syntax. I think at least is something should be permitted, maybe also forms like is filled; and for the inverse, maybe is nothing, is empty, is blank, etc.

Also, though it works a bit against the list of forms I mentioned above, I notice that there's perhaps a missed opportunity here in that these phrases could instead be defined as adjectives. And maybe even writable adjectives, something like the below pseudo-code, though kind variables don't actually work in adjectives as far as I'm aware (and I don't know if rather than is even supported for adjectives defined in I6).

Definition: a value of kind K option is empty rather than full if I6 routine "OPTION_TY_Empty" makes it so (it does not contain a value).

Which has the neat feature that you can now write now my-optional is empty… although it does leave open the question of what happens if you write now my-optional is not empty. (I think filling in the default value of that kind would be fine.)

If this was already considered and rejected, perhaps on the basis of "what does now my-optional is full mean, then that's fine (I wouldn't say I'm especially attached to the idea in any case); but in case it was not considered at all, I thought it would be worth mentioning.

That said, defining them as read-only adjectives still remains an option even if one cares about the ambiguity of "what does now my-optional is full mean".

Results

Some of the comments about optionals also apply here – they're literally the same as an optional except that the "none" state is replaced with an error message that can be arbitrary text. Especially relevant is the comment about defining adjectives rather than phrases for the basic states of the type.

I don't see why a/an can't be optional when casting to a result. Also I think it should be allowed before error when creating a failed result, and before the name of the kind as well (maybe that one already works).