2 ms·
How would you feel about: y[end(1)] y[len - 1] Either one then constructs a "reverse index" value, and the actual index is determined by the slicing o
by ben509 6y ago
How would you feel about:
y[end(1)]
y[len - 1]
Either one then constructs a "reverse index" value, and the actual index is determined by the slicing operation.
- throwaway_pdp09 6y agoBoth of these are idiomatic because they're not built by composition. y[end(1)] is non-composed because AFAICS end(1) is meaningless by itself. Ditto the second although y[len(y) - 1] would be closer to the mark. If you're willing to accept a naive implementation that can be optimised, something like reverse(y)[1] is compositional though inefficient as-is. You could though recognise this overall and optimise it to not reverse the lot before picking out a single item.
- ben509 6y agoAllow me to justify why end(1) and len are meaningful: Suppose indexing (and you can extend this to slicing if these are possible components of a Range type) is polymorphic. list[Index] means to find an element at Index, starting at the beginning list[ReverseIndex] means to find an element at ReverseIndex, starting from the end Int is naturally a subtype of Index. end(Int) would be a constructor for some concrete subtype of ReverseIndex that is distinct from Int. Or len would simply be shorthand for ReverseIndex(0). And ReverseIndex is also defined for the usual int arithmetic, except that it returns new values of ReverseIndex.
- throwaway_pdp09 6y agoInteresting idea. I can see that end(1) would work though it's bringing in a lot of machinery just for a little thing (though if we looked harder that might generalise to other situations enough to make it viable). Alternatively you could do the same with a method I think, something like y.end[1] although y.fromEnd[...] might be more mnemonic. I don't see that y[len - 1] could work in this scheme, but whatever. I like yer thinking!