undefined | Better HN

0 pointsben5096y ago0 comments

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.

0 comments

3 comments · 1 top-level

throwaway_pdp096y ago· 2 in thread

Both 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.

ben509OP6y ago

Allow 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_pdp096y ago

Interesting 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!

j / k navigate · click thread line to collapse