On the same line, one could perhaps also dream up an operator to replace the use of zero_type(foo[bar]), which I've always considered a bit ugly since the single operation "index exists" is broken up in "lookup index" and "check for magic value".
I'd like that too; perhaps foo![bar], if we'd settle for foo+[bar]=baz and foo-[bar]?
/ Johan Sundström (ärkehertig av Lysators rootgrupp)
Previous text:
2002-11-12 02:50: Subject: Re: More about ADTs
The problem with the last case is that [...] can be both a prefix and a postfix operator. E.g. in this case:
x << [y] - z
it can either be a type cast:
x << ([y] -z)
(the minus is unary) or your new operator:
(x << [y]) - z
But I think that's solvable just by applying operator precedence. Since postfix operators in general have higher precedence than prefix operators, it would reasonably be disambiguated to the second case. (This is not a "real" case of precedence, though; in reality it's a shift/reduce conflict.)
I'm thinking along the lines of building on the [] and []= operators, since these operations to a large extent is an index operation. I thought it'd be better to use + and - since those are used elsewhere for adding and removing elements, while the shift operators would have to be stretched a bit to include that. Your placement of the operator before the open bracket is the only place that both makes some sense and (probably) is parseable. Thus:
Insert: foo+[bar] = gnu (lfun: `+[]=) Delete: foo-[bar] (lfun: `-[])
On the same line, one could perhaps also dream up an operator to replace the use of zero_type(foo[bar]), which I've always considered a bit ugly since the single operation "index exists" is broken up in "lookup index" and "check for magic value".
/ Martin Stjernholm, Roxen IS