On Sat, Sep 26, 2020 at 9:35 PM David Mertz <mertz@gnosis.cx> wrote:
On Sat, Sep 26, 2020 at 12:50 AM Stefano Borini <stefano.borini@gmail.com> wrote:
Other use cases are certainly allowed, but to me, something like
a[1, 2, unit="meters"] a[1, 2, unit="meters"] = 3
makes me feel uncomfortable, although I might learn to accept it.
Then why isn't the unit close to 3, as in
a[1,2] = 3 * meters
I think this is a very natural looking use case, and is not as well addressed by putting the multiplier outside the indexing. Imagine you have two arrays that store lengths, but not necessarily in the same units. Whatever the underlying representation, we would be able to ask, e.g.:
a[1, 2, unit="furlongs"] == b[1, 2, unit="furlongs"]
Sure, `a` might store its data as AUs and `b` might store its data as Plank lengths. But the comparison like that would still work. More importantly, a user wouldn't have to KNOW the underlying representation if she knew there was a "unit" term.
I don't find such examples a conclusive argument in favour of this syntax at all. Anything that stored a length and could do conversions in this way would presumably need to be some kind of length object that was able to handle conversions. In that case, the way that equality was calculated should take care of any conversions needed. I can't help feeling that this is a syntax looking for a set of solutions to apply itself to. It will add enormous complexity (together, no doubt, with speed issues and backwards-compatibility issues) to the language, and I'm not sure that I see the gain, yet. I'm obviously missing something.