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 combi
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:
Ye
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
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
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 smar
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 ~~
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 join
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 cont
* 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
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.
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*, b
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 test
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-speci
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 st
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 dwimmer
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 m
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
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 t
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 l
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?
Strin
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
> drowne
Halo,
someone has switched off my echo ;)
Juerd wrote:
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.
Of course it's parsed, how else should it reach the semantic analyzer?
And I don't consider (arity
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_st
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
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
representati
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:
Un
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 val
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
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
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 value).
>
> Note that S02 does specify that pairs *i
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.
Ju
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 writin
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 C
allows you to overload q{""}, q{0+} and
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 w
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.
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
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
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
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 str
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 kno
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 nu
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 4
42 matches
Mail list logo
