> And maybe: > > A bitwise operator is just a logic operator scoped to a set of > bits. > > That's why I can't accept a characterization of > > +& +| +X - bitwise operations on int > +&= +|= +X= > > ~& ~| ~X - bitwise operations on str > ~&= ~|= ~X= > > ?& ?| ?X - bitwise operations on booleans > ?&= ?|= ?X= > > as UME (Unnecessary Multiplication of Entities). The things you > see there aren't entities--rather, they're decomposable to entities > that are reused from elsewhere. The *only* new thing is the > grammar rule that says you can modify a logic operator with a > context operator. I would submit that > > some_big_long_term ~| some_other_big_long_term > > is much clearer than > > ~some_big_long_term .| ~some_other_big_long_term > > because you have the same problem as when you move the parenthese > out front of the function--the context is further away. Plus we > still have to reason out what the polymorphic operator is going to > do. >
Could we please, please, please have bitwise operators be out of the core. We expect that they are not going to be used by the average user, so it looks fair to apply the ultimate negative huffman enconding: they need to be specially required. A simple "use bitwise" would be ok. That would provide a proper manpage to explain the meta-operators thing, and would shorten the main list, which is something that we desperatelly need. On other order of things: if it is about providing context to an operation, wouldn't an adverb be more natural? So it would be something like this: $c = $a | $b; # superposition $c = $a | $b : int; # integer bitwise $c = $a | $b : str; # char bitwise $c = $a | $b : bool; # bool bitwise This can be expanded to other context-requiring cases: $c = $a / $b; # float division $c = $a / $b : int; # integer division Admitedly, it's more verbose. But again this is Huffman encoding at use. Or, speaking aloud, we could move the adverb just along the operator, tying them together visually: $c = $a |:int $b; $c = $a &:str $b; But honestly, that looks weird. -angel
