I think this may be in response to an earlier message of yours looking for a replacement for "superposition." But I recall getting a Dilbert calendar for Xmas some years back with a cover featuring the PHB saying "I'm not indecisive - I'm flexible!"
Thus, flexops. And flexpressions (flexprs, for short). With operator:flexible|, operator:flexible&, and operator:flexible^. And $result = flexible ($a & $b & $c) ^ ($d | $e | $f); instead of $result = bitwise ($a & $b & $c) ^ ($d | $e | $f); (Of course, flexprs are the default, so you won't need to specify that. See below.) --- Larry Wall <[EMAIL PROTECTED]> wrote: > On Tue, 29 Oct 2002, Austin Hastings wrote: > : --- Piers Cawley <[EMAIL PROTECTED]> wrote: > : > >> > : > >> one(any($a, $b, $c), all($d, $e, $f)) > : > >> > : > >> Is a good deal more intention revealing than the superficially > : > >> appealing than > : > >> > : > >> ($a & $b & $c) ^ ( $d | $e | $f ) > > First I would like to point out that the & and | are backwards there > from the original. & means all(), and | means any(). Which implies, since no one else has pointed this out, that <function-style> is not as clear as <operator-style>. (FYI: The little <>'s around -style descriptors is shorthand for some sort of Saturday afternoon "Kung Fu Theatre" combat pose. As in, "Your <stork> is no match for my <drunken guppy>. My sister will be avenged!") > > : Would it be practical/meaningful to say > : > : $result = bitwise ($a & $b & $c) ^ ($d | $e | $f); > : $result = superpose ($a & $b & $c) ^ ($d | $e | $f); > : > : And allow a use operation to select defaulting behavior? (With an > : appropriate warning if the code used one of these operators without > : specifying the use directive, even though <crab-style> is the > default?) > > All other things being equal, I think people will find modal > operators > more confusing than if we just make separate operators. To quote Rene Descartes, "I think not! (poof!)" >From what everyone has chipped in thus far, the discussion is between the "conservatives" who feel that since everyone knows 'C', we should keep the 'C' operator semantics when possible, and the "avant garde" who feel that "bitops are dead, long live flexops!" Frankly, I have a hard time imagining a perl program where bitops are generally useful. (In functions, yes. But will they permeate the code?)On the other hand, flexops may well be. So I propose that we give the "nervous" types a way to clearly specify both, and provide a default (<new-style>). There's no going back, of course. But the ability to give warnings on unspecific ops and the ability to override the default should satisfy the conservatives long enough to get them addicted to qrack.. > That being said, I'm still wondering whether we can finesse it. > Damian's > default any() semantics in numeric context select a random element. > If > we made that not the default, we could have an alternate default > semantics > in numeric (or, at least, integer) context. So suppose we introduce > for > the "pick one" semantics an explicit verb named, oddly enough, > pick(). > > my int $foo = pick( 1 | 2 | 4 ); # $foo gets (1,2,4)[rand 3] > my int $bar = 1 | 2 | 4; # $bar gets 7 It seems to me that flexible results are more like NaN than anything else. Once they go into an expression, they corrupt the expression. my $var = 1 | 3; print $var * 2 - 1; Should print something like: ANY-SCALAR(1|5) Or perhaps it should give a warning: "Doubleplusungood: Eigenbunny at line 3. Scalar expected." > People can be scared if they like, but I am also of the opinion that > superpositions are more "basic" than bitops, at least in a sense. > My reasoning for that is that they don't commit to an interpretation > prematurely. A 1 | 2 | 4 means "a 1, a 2, or a 4", nothing more. > You can make other things out of a superposition depending on the > context. Damian already made them mean two different things in > numeric > vs string context. Can I say bitwise $str ^~^= 16:20 x ...; # Each chr in $str xor= shift; to change case? Or is one ^ enough? (Admittedly an ASCII hack, but ..) > So I wonder about whether, in > > $result = superpose ($a & $b & $c) ^ ($d | $e | $f); > > the "superpose" is really a no-op. I don't think so. Or at least, if it is, I'm not sure how to deal with it. Because I fear trying to mix "eval" and whatever parser magic is implied below. And if you don't do that, then there's property-creation going on which will upscrew the optimizer, I think. (See next para below.) > If you go on to say > > my int $foo = pick( $result ); # random element filling > "contract" > my int $bar = $result; # bitwise > > then the superposition would collapses as specified. What do you do for actions at a distance. That is, you say my int $foo = (3 | 4); here, and return $foo, and store it away in a hash, and some time later, possibly in a different module written months earlier, take that value OUT of that hash (or, worse, read it back in from a serialized representation). Did you carry the flexibility with you throughout? If so, what's the impact on performance going to be when you can't decide if a value is 7 or 3|4 (note: I'm deliberately NOT using 1|2|4. Look at some of the flags in /usr/include/sys/*.) > There is one little difficulty with this approach, though. It would > have to retroactively change the meaning of non-powers-of-two. That > is, > if you say > > $mask = 7; > $somebits = 1 | 2; > my int $foo = $somebits & $mask; > > then at the point of wave-function collapse, the 7 from $mask has to > be re-interpreted as a 1|2|4. Maybe that's okay, and maybe it isn't. > From a transactional view of QM, it's probably fine, since that view > allows for sending information back through time to entangled > partners. > It's also fine from a tagmemics point of view, I think, since context > can change the meaning of both nouns and verbs. Yes, but if I say $netmask = 256:255.255.255.0; $ip_range = any(256:10.10.10.1 .. 256:10.10.10.200); print $netmask & $value; What will you print? Having any() (aka operator:flexible|) "taint" the expression probably won't dwim. I don't want $netmask to be converted into a flexpression -- it's bits! I want 200 different alternates, all alike. =Austin __________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
