Re: matching colors (was Stringification, numification, and booleanification of pairs)
HaloO Yuval, you wrote: On Mon, Sep 26, 2005 at 21:02:06 +0200, TSa wrote: demonstrates the lack of transitivity in matching... Sorry, but don't you mean commutativity? Transitivity of relations requires applying it twice to three values and then concluding it applies to the unchecked combination as well: Yes, I tend to confuse these ;-) Don't worry, be happy. I suffer from an impotence versus idempotence confusion. But fortunately both mean 'lack of achievement'. BTW, the context cast prefix operators + ~ ? * ** of Perl6 have that property. In addition they preserve the identity and accessability of their input data. So, beware if you intend to overload them with omnipotence :) -- $TSa.greeting := HaloO; # mind the echo!
Re: matching colors (was Stringification, numification, and booleanification of pairs)
On 9/25/05, Luke Palmer [EMAIL PROTECTED] wrote:
On 9/25/05, Juerd [EMAIL PROTECTED] wrote:
We can do better than equivalence testing for colors. Instead, try to
match. Surely a *smart* match operator really is smart?
$color ~~ '#FF00FF'
==
$color ~~ 'magenta'
==
$color ~~ [ 255, 0, 255 ]
Hmm. That violates my proposal that the right side is the thing that
determines how the left side is matched. So there's something wrong
with one of the two...
If we keep my proposal, then we get:
$color ~~ color('#FF00FF')
$color ~~ color('magenta')
Interesting proposal. Is there any motivation for people not to simply
flip the argument-order to take advantage of the right-wise
determinism? Or is that actually a benefit?
'#F0F' ~~ $color ?? 'yes' !! 'no';
Ashley Winters
Re: matching colors (was Stringification, numification, and booleanification of pairs)
On Sun, Sep 25, 2005 at 23:21:33 -0700, Ashley Winters wrote:
On 9/25/05, Luke Palmer [EMAIL PROTECTED] wrote:
On 9/25/05, Juerd [EMAIL PROTECTED] wrote:
We can do better than equivalence testing for colors. Instead, try to
match. Surely a *smart* match operator really is smart?
$color ~~ '#FF00FF'
==
$color ~~ 'magenta'
==
$color ~~ [ 255, 0, 255 ]
Hmm. That violates my proposal that the right side is the thing that
determines how the left side is matched. So there's something wrong
with one of the two...
If we keep my proposal, then we get:
$color ~~ color('#FF00FF')
$color ~~ color('magenta')
Interesting proposal. Is there any motivation for people not to simply
flip the argument-order to take advantage of the right-wise
determinism? Or is that actually a benefit?
I see a very good reason - the more topicalized and localized an
object the earlier in the sentance it usually goes in any natural
language that I know of.
99% of programmers that know that
if ($number == 123) {
}
is bad because a simple typo makes it into assignment, but
if (123 == $number) {
}
is safe still don't use the safer form, because it just doesn't read
or write as well.
Matching is even more verbose in that sense... If noun defining
concrete object is like shape, pattern, etc makes sense. Other
forms do not:
if greenish describes the color
vs
if the color is greenish
demonstrates the lack of transitivity in matching... Ofcourse, the
sentances say the same thing, but the first one is deceiving,
because you think that 'greenish' is the important thing, when we're
really concerned about the color. It is definately not good for
reading code you didn't write, because it's unclear in subtle ways.
I guess this is just as you guys probably have trouble reading my
subtly pigeon english - it seems normal most of the time, but
occasionally it just doesn't make sense since I'm actually
transliterating hebrew.
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me wields bonsai kittens: neeyah
pgpLdaCjgkCrs.pgp
Description: PGP signature
Re: matching colors (was Stringification, numification, and booleanification of pairs)
HaloO, Yuval Kogman wrote: if greenish describes the color Indeed, it sounds like Yoda Speak: If greenish that color is, modifying it I will. Same in the German version. I don't know of hebrew though. demonstrates the lack of transitivity in matching... Sorry, but don't you mean commutativity? Transitivity of relations requires applying it twice to three values and then concluding it applies to the unchecked combination as well: a ~~ b b ~~ c = a ~~ c -- $TSa.greeting := HaloO; # mind the echo!
Re: matching colors (was Stringification, numification, and booleanification of pairs)
On Mon, Sep 26, 2005 at 21:02:06 +0200, TSa wrote: demonstrates the lack of transitivity in matching... Sorry, but don't you mean commutativity? Transitivity of relations requires applying it twice to three values and then concluding it applies to the unchecked combination as well: Yes, I tend to confuse these ;-) -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me whallops greyface with a fnord: neeyah!!! pgpRqxoEoLhIe.pgp Description: PGP signature
matching colors (was Stringification, numification, and booleanification of pairs)
Yuval Kogman skribis 2005-09-25 21:34 (+0300):
if $color.as(Str) eq '#FF00FF' and $color eq magenta {
$Ashley++;
}
$color.hex_triplet; # no alpha
$color.name; # if we have one... or we can try to make one up (#ff0033 is
bluish red ;-)
We can do better than equivalence testing for colors. Instead, try to
match. Surely a *smart* match operator really is smart?
$color ~~ '#FF00FF'
==
$color ~~ 'magenta'
==
$color ~~ [ 255, 0, 255 ]
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: matching colors (was Stringification, numification, and booleanification of pairs)
On 9/25/05, Juerd [EMAIL PROTECTED] wrote:
We can do better than equivalence testing for colors. Instead, try to
match. Surely a *smart* match operator really is smart?
$color ~~ '#FF00FF'
==
$color ~~ 'magenta'
==
$color ~~ [ 255, 0, 255 ]
Hmm. That violates my proposal that the right side is the thing that
determines how the left side is matched. So there's something wrong
with one of the two...
If we keep my proposal, then we get:
$color ~~ color('#FF00FF')
$color ~~ color('magenta')
etc., for some definition of color(). In fact, that's probably the
right thing to do, is to make color a pattern constructor. Then you
can even put it in signatures:
sub name(color('#FF00FF')) { magenta }
Whatever that buys you
If we ditch my proposal, then we can write it as you did. But I feel
uncomfortable with that (thus the proposal), since you never know how
people may have overloaded ~~ for dwimminess, and when you say:
sub print_colored ($color, $text) {
$color = do given $color {
when 'red' { Color.new('#FF') }
when 'green' { Color.new('#00FF00') }
when Color { $color }
default { fail Unknown color }
}
}
Though in this case it's not much of an issue, unless the red pattern
matches /#../ or something, in which case you are losing
granularity. I guess the reason it makes me uncomfortable is that old
obsession of mine where things that look orthogonal ought to be, like
'red' (a string) and Color (a class).
Then again, would one expect:
$foo ~~ 'bar'
To be equivalent to:
~$foo eq 'bar'
Or not? I mean, that can be the string pattern's job, but then 'red'
and Color aren't really equivalent anymore.
/me punts patterns until he understands more.
Luke
