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
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'
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?
Mark A. Biggar skribis 2005-09-25 19:42 (-0700):
In a private conversation with Larry this afternoon, he said that by
default $foo and ~$foo and $foo.as(Str) all give the same result
(assuming scalar context, etc.). And that @foo[] and [EMAIL PROTECTED] and
@foo.as(Str) are the same as
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
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
Juerd wrote:
But will they also see foo ~ $bar as something different from
foo$bar?
They ought to, since the two are different in Perl 5.
For example:
my @bar = 'bar';
print [EMAIL PROTECTED];
print foo[ . @bar . ]baz\n;
And what context does foo{ $bar } use?
Stringification,
Damian Conway skribis 2005-09-24 8:31 (+1000):
In my opinion, making the string value in interpolation different from
the value in Str context is madness.
It's dwimmery.
It's dwymmery, or dwdmmery indeed. Not at all what I mean, am likely to
mean, or will ever mean.
Which often looks like
Damian Conway skribis 2005-09-24 8:31 (+1000):
They ought to, since the two are different in Perl 5.
For example:
my @bar = 'bar';
print [EMAIL PROTECTED];
print foo[ . @bar . ]baz\n;
This does not compare stringification to interpolation. It compares
scalarification to
On Sun, Sep 25, 2005 at 12:52:08PM +0200, Juerd wrote:
Hackers on this list, what do you think?
I think separating the two is extremely confusing. I do not see any uses
for it, but maybe I am not thinking hard enough.
--
wolverian
signature.asc
Description: Digital signature
On Sun, Sep 25, 2005 at 12:52:08 +0200, Juerd wrote:
Damian Conway skribis 2005-09-24 8:31 (+1000):
In my opinion, making the string value in interpolation different from
the value in Str context is madness.
It's dwimmery.
It's dwymmery, or dwdmmery indeed. Not at all what I mean, am
On 9/25/05, Yuval Kogman [EMAIL PROTECTED] wrote:
On Sun, Sep 25, 2005 at 12:52:08 +0200, Juerd wrote:
Damian Conway skribis 2005-09-24 8:31 (+1000):
In my opinion, making the string value in interpolation different from
the value in Str context is madness.
It's dwimmery.
It's
On Sun, Sep 25, 2005 at 10:59:38 -0700, Ashley Winters wrote:
The Stringification of a UnixEpochTimestamp should probably be the
same as its Integerization -- 12345678900. However, the Interpolation
of it should be the locale-specific POSIX-style datetime string.
Why? What value does the
On 9/25/05, Yuval Kogman [EMAIL PROTECTED] wrote:
On Sun, Sep 25, 2005 at 10:59:38 -0700, Ashley Winters wrote:
The Stringification of a UnixEpochTimestamp should probably be the
same as its Integerization -- 12345678900. However, the Interpolation
of it should be the locale-specific
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
Ashley Winters skribis 2005-09-25 12:26 (-0700):
It's not a Date, it's a UnixEpochTimestamp.
That is precisely the flaw. Are you honestly likely to have that class?
If you really need an unix epoch timestamp, wouldn't you just use a very
simple integer for that? Because that's what it *is*,
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
* wolverian ([EMAIL PROTECTED]) [050925 11:57]:
On Sun, Sep 25, 2005 at 12:52:08PM +0200, Juerd wrote:
Hackers on this list, what do you think?
I think separating the two is extremely confusing. I do not see any uses
for it, but maybe I am not thinking hard enough.
Of course, having
Mark Overmeer skribis 2005-09-25 17:28 (+0200):
Stringification/Numification should be used to let an object play its
natural role within the program.
Agreed, but...
For instance, some Temperature object producing 273 when compared to
the melting point of water.
That's for numeric context,
In a private conversation with Larry this afternoon, he said that by
default $foo and ~$foo and $foo.as(Str) all give the same result
(assuming scalar context, etc.). And that @foo[] and [EMAIL PROTECTED] and
@foo.as(Str) are the same as join(' ', @foo) where join is effectively:
sub
Juerd wrote:
I think separating stringification and interpolation leads to
unpredictability, and is a very bad thing.
I disagree. I think it's likely that people will think of ~$val and +$val the
same way (i.e. as coerce the value), but that they will think of $val
quite differently (i.e.
Damian Conway skribis 2005-09-22 23:04 (+1000):
I disagree. I think it's likely that people will think of ~$val and +$val
the same way (i.e. as coerce the value), but that they will think of
$val quite differently (i.e. as interpolate a useful string
representation of the entire value).
On Thu, Sep 22, 2005 at 11:59:32AM -0400, Matt Fowles wrote:
Well said! I completely agree that string interpolation should be
handled exactly the same as stringification. I would like C (foo is
$foo of course) eq (foo is ~ $foo ~ of course) at all times.
Yes.
S03 states:
Unary ~ now
HaloO Juerd,
you wrote:
Damian Conway skribis 2005-09-22 23:04 (+1000):
I disagree. I think it's likely that people will think of ~$val and +$val
the same way (i.e. as coerce the value), but that they will think of
$val quite differently (i.e. as interpolate a useful string
representation
TSa skribis 2005-09-23 15:42 (+0200):
1) the circumfix operator has an arity = 1
I think it's parsed, not having specific arity.
We have: foo ~ $bar
I see: a juxtaposition of two operators and an item,
all three separated by whitespace
I can only hope you mean two items
On 2005-09-23 06:08, Juerd [EMAIL PROTECTED] wrote:
In my opinion, making the string value in interpolation different from
the value in Str context is madness.
Hear, hear! I agree 100%. This is another place where we should move the
Rubyometer down rather than up, I think (to_s vs. to_str,
TSa skribis 2005-09-23 19:11 (+0200):
We have: foo ~ $bar
I see: a juxtaposition of two operators and an item,
all three separated by whitespace
I can only hope you mean two items and one operator.
So, at last there is hope somewhere. But I fear I'm hopelessly
drowned in my own
Mark A. Biggar skribis 2005-09-21 17:44 (-0700):
Now for a related question: is it intended that ~$x and +$n be the same
as $x.as(Str) and $x.as(Num)? How locked in stone would this be, I.e.,
~ and + are macros that give the .as() form?
If I read everything correctly, this is the case.
Stuart Cook skribis 2005-09-22 10:39 (+1000):
If there's no (single) obvious interpretation of turn a value into a
number for a particular type, then don't struggle to come up with a
non-obvious one--I say just leave it undefined, or have it fail(), or
whatever.
Leaving it undefined is wrong
Eric wrote:
Since you wouldn't expect an object to stringify or numify...
You wouldn't??! I certainly would.
Object references already stringify/numerify/boolify in Perl 5. Unfortunately,
they do so with problematic default behaviours, which is why Cuse overload
allows you to overload q{},
Ingo Blechschmidt asked:
my $pair = (a = 42);
say ~$pair; # a\t42? a\t42\n? a 42?
Not yet specified but I believe it should be 42 (i.e. stringifies to value).
Note that S02 does specify that pairs *interpolate* to key-tab-val-newline,
so you can still get a\t42\n by writing $pair
Damian Conway skribis 2005-09-22 8:20 (+1000):
Note that S02 does specify that pairs *interpolate* to
key-tab-val-newline, so you can still get a\t42\n by writing $pair
instead.
I think separating stringification and interpolation leads to
unpredictability, and is a very bad thing.
Juerd
--
Yuval~
On 9/22/05, Yuval Kogman [EMAIL PROTECTED] wrote:
On Thu, Sep 22, 2005 at 08:20:42 +1000, Damian Conway wrote:
Ingo Blechschmidt asked:
my $pair = (a = 42);
say ~$pair; # a\t42? a\t42\n? a 42?
Not yet specified but I believe it should be 42 (i.e. stringifies to
Hi,
quick questions:
my $pair = (a = 42);
say ~$pair; # a\t42? a\t42\n? a 42?
say +$pair; # 0 (pairs aren't numbers)?
# 42?
# 0 (a is not a number)?
# 0 (~$pair can't be used as a number)?
say ?$pair; # true (because 42 is
Ingo Blechschmidt skribis 2005-09-21 14:47 (+):
my $pair = (a = 42);
say ~$pair; # a\t42? a\t42\n? a 42?
say +$pair; # 0 (pairs aren't numbers)?
# 42?
# 0 (a is not a number)?
# 0 (~$pair can't be used as a number)?
Hey,
Since you wouldn't expect an object to stringify or numify why expect pairs
to? I'm not sure i see any value in thatm, $pair.perl.say would be the best
way to output one anyway.
my $pair1 = (a = 2);
my $pari2 = (b = 3);
say $pair1 + $par2; # Error: illegal stringification of pair.?
I know
Eric skribis 2005-09-21 16:46 (-0600):
Since you wouldn't expect an object to stringify or numify [...]
Oh? I would in fact expect many objects to stringify or numify to useful
values. Just like I expect an array reference to stringify as if it was
an array, I expect an HTTP header object to
On 22/09/05, Juerd [EMAIL PROTECTED] wrote:
By the way, is it really this simple?
class HTTP::Header is Pair {
foo {
{.key}: {.value ~~ s/\n/\n /g}
}
}
Where foo is whatever is needed to override stringification.
Something along the lines of `method
On 22/09/05, Juerd [EMAIL PROTECTED] wrote:
I don't think +(~$pair) makes any sense, though. It's basically the same
as +(~$pair.key). It's probably wise to avoid that $pair can be confused
for its key or value. A good alternative is hard to find, though. I tend
to prefer 1 at this moment
Eric wrote:
Hey,
Since you wouldn't expect an object to stringify or numify why expect pairs
to? I'm not sure i see any value in thatm, $pair.perl.say would be the best
way to output one anyway.
my $pair1 = (a = 2);
my $pari2 = (b = 3);
say $pair1 + $par2; # Error: illegal stringification of
40 matches
Mail list logo
