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
Previous text:
2002-11-11 19:55: Subject: Re: More about ADTs
Somewhat verbose, but I think that's ok for destructive operations that are expected to be used an order of magnitude more seldom than for instance plain indexing (->).
They might be sufficient untils someone finds out operators for these operations.
Are shift operators used for these datatypes?
set<<elem; set>>elem;
A little C++-ish though, and lacks a syntax for key:value tupels...
Maybe set<<[elem] set>>[elem] map<<[key;elem] map>>[key]
...is that possible to parse?
/ Brevbäraren