Open sbc100 opened 6 days ago
If I'm understanding correctly, the spec today currently doesn't choose an official name like "index" for the parameter to table.get
, but I think "index" is clearly implied - the execution instructions use i
for the parameter name, and the structure section uses "index" to refer to one of the parameters of table.copy
.
Anyway, unless there's something I'm missing, I think "index type" is a perfectly good term that I'd vote to keep.
I'm basically neutral on this. I've gotten used to calling it index type, so there is some inertia there I suppose.
@bvisnuss, i
is universally used for integers.
I'd prefer avoiding overloading terminology in potentially confusing ways. We already use the term "index" for all the index spaces, and in particular, "memory index" and "table index" already have a different meaning. Moreover, while "index" is natural for tables, it is less so for memories. Hence I suggested "offset" as a more neutral and unclobbered name, but perhaps there are better suggestions.
I agree that "index" is the most natural term in isolation, but I do agree that avoiding overloading it is a good idea. I would prefer "address" over "offset," even for tables, and it would be an even less overloaded term. It would be weird to explain the offsets in memargs as being "offsets from an address/index that has an offset type."
Address type (addrtype) sounds good to me.
What's wrong with "index type"? I haven't been following #50 very closely, but I struggle to think of a better term generally. If it were only memories, you could call it an "address type", but since tables are in the mix I think "index" is the better general term.