implement tuple accessors

[andrewchambers]

Currently the only way to access a specific element in a tuple is via match statements or destructuring assignment. Match introduces nesting, and destructuring assignment requires a named variable. In select cases directly accessing tuple values increases code quality.

I can try implement this myself, the feature isn't really urgent so I made this issue so progress can be noted somewhere.

Proposed syntax:

var tup = (1, "b")
std.put("{}\n", tup.0) // prints the 1

where the 0 after the . must be a positive int literal.

[HalosGhost]

I'd like to propose an alternate syntax.

tuplevar.# (given # as a number) will undoubtedly be a new thing to parse. It seems like the standard array access notation thing[index] should be plenty fine. It has the added benefit of being familiar/easy. The draw-back is that it means both tuples and arrays have the same syntax for member access where structs do not (though, I would point out that having dot-notation for tuple access would have the same issue).

An aside (that may be better-suited for a new issue):

I might suggest following a little in Lua's steps and generalizing aggregate member access using [], with aggregate.member being sugar syntax for aggregate["sugar"].

This also has the added benefit of allowing the programmer to determine what member to access at run-time (since index in aggregate[index] is rather normal as a calculated value rather than a compile-time constant).

An issue I can see is that where arrays have homogenous types, so a calculated index into the array is still guaranteed to return the same type, that would not be the case for a calculated index into a tuple or struct. This could be solved with a return type of a union of the types in the tuple/struct, but I'm not sure if that is reasonable/perfect.

[andrewchambers]

runtime lookup is slightly problematic in a statically typed language as you don't know what the type is, and the compiler needs to layout the low level memory details based on that information.

[HalosGhost]

Well, if we go with the thought of returning a union of the types that the index could possibly result in, wouldn't that solve the issue relatively well? Myr, from what I've seen/read already has pretty reasonable support for tagged unions.

[andrewchambers]

That is true, but then it defeats the purpose of using a tuple and not a struct in my opinion. It may be possible to resolve though. Some runtime lookup capabilities might not even be a bad thing in other contexts anyway.

[oridb]

So, let's take a step back. What problem are you trying to solve in your program? Can you show me some code you had to write, and the way you would have preferred to write it?On Dec 31, 2017 22:11, Sam Stuewe <notifications@github.com> wrote:Well, if we go with the thought of returning a union of the types that the index could possibly result in, wouldn't that solve the issue relatively well? Myr, from what I've seen/read already has pretty reasonable support for tagged unions. —You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or mute the thread.

[HalosGhost]

The calculated-indecies comment was not motivated by a wish to use it in a particular situation myself (I'm still working on getting into using Myr generally). Rather, it was a proposal to try and bring some more cohesiveness to Myr.

One of my big objections of many languages today is that they fail to feel cohesive, and member indexing is one of the pieces of a language I usually think is ripe for improvement. I brought up Lua's version because it is one of the few languages which I feel has defined this incredibly well.

If a proposal for the language should only be motivated to more immediately practical, then I can avoid mentioning this kind of thing in the future.

[oridb]

I don't mind it being mentioned, but while the options you mentioned make wonderful sense for dynamic languages, I don't see a clear path for how they'd integrate into Myrddin cohesively, and how I'd use them without a whole lot of pain. That's why I asked for motivating examples, especially ones with code that gets better after this feature would get added.

Specific questions:

• Does this add compiler generated types into the namespace? If yes:

  • What is the naming scheme for them?
  • What happens when they conflict with a user type?
  • What gets returned when there is no matching type?

• Can you set values through this interface?

  • What does that look like?
  • Is this a different API, or the same one?
  • How about iterating members, desirable or not?
  • Are all types iterable? How does this interact with iterable traits?

• What changes would this need to the runtime?

  • Currently, the runtime is about 100 lines of assembly. Depending on the approach taken, I could imagine this adding a lot of code.

And then, the big questions that get opened up:

• How does this change what 'good Myrddin' code looks like?
• Does it involve library changes?
• Does it enable cool things that are extremely difficult today
• What does it cost us in terms of readability/ease of following/additional indirection/...?

Circling back a bit to the comment about niche places: This kind of thing would be great for automatic serialization and deserialization.

But for those niches, the compiler already theoretically generates all the information you'd need. The APIs for using it in libstd are bloody awful, and are due for a rethink, so this might be an interesting motivating example for adding the functionality as a library, and reworking the libstd type walking apis at the same time.

[oridb]

This issue was closed a while ago, thanks to mpu. Forgot to close it on github.