Re: conditional wrapper blocks
HaloO,
Yuval Kogman wrote:
Today on #perl6 I complained about the fact that this is always
inelegant:
if ($condition) { pre }
unconditional midsection;
if ($condition) { post }
I'm not sure if you would considered closure traits as equally
inelegant but what are PRE and POST or BEGIN and LEAVE for if
not your case?
So we have:
{
my $condition = ENTER { calculate_condition };
LEAVE { if $condition { cleanup_commit_or_somesuch; }
unconditional midsection;
}
Well and there are more convenient forms mentioned in S04:
{
my $condition will enter { pre }
will leave { post }
will undo { undo pre }
= calculate_condition();
unconditional part;
}
--
$TSa.greeting := HaloO; # mind the echo!
Re: Lazy lists and optimizing for responsiveness
On Tue, Sep 20, 2005 at 14:47:33 -0400, Austin Frank wrote:
Would the named adverbs for gather work in other contexts as well?
Would you suggest this mechanism for specifying the buffering
behavior for IO operations?
See scook's email below... I think that yes. Here is a reference
implementation making heavy use of coros:
sub buffer_lazy ([EMAIL PROTECTED], +$threshold = 100) { # renamed
scook's force_async
my @buffer;
state Sem $collecting;
if ([EMAIL PROTECTED]) { # blocking
push @buffer, shift @lazy;
}
if (@buffer.elems $threshold and
$collecting.lock(:nonblocking)) {
async {
LEAVE { $colecting.release };
while (@buffer.elems $threshold) {
push @buffer , shift @lazy; # or splice
it splice returns a lazy list
}
}
}
yield shift @buffer;
}
my @lazy = buffer_lazy @other_lazy; # using @lazy should be more
responsive
and where gather is
sub gather (body, +$async, +$threshold){
my @result_list = {
temp sub *take ([EMAIL PROTECTED]) {
OUTER::yield(@stuff); # how do we do this?
Maybe $?CALLER_CONTINUATION.yield?
}
body();
};
return $async
?? buffer_lazy @result_list :threshold($threshold)
!! @result_list;
}
Tim Bray recently wrote about wanting a language that would be
smarter about IO buffering by default. Will perl6 be such a
language?
I think it already is about making life easy for the programmer. For
example, the 'will prompt' trait gives autoprompting to a read
handle, by making each read go to another handle, print, flush it
smartly for interactivity, and then actually read the data. This
makes the programmer's life less painful in many ways by
encapsulating a common problem in a standard library definition.
As for Tim's problem, I don't know what exactly Tim means, since I
don't know what he fixed in his program, but I/O primitives are by
default bufferred unless the programmer specifically requested
otherwise sounds a lot like perl 5 and $| ;-)
I think that Perl 6 needs more than this to be smarter about IO
buffering, but I'm not sure I want it to be.
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me beats up some cheese: neeyah!
pgpmpQxyqj48w.pgp
Description: PGP signature
Re: conditional wrapper blocks
On Tue, Sep 20, 2005 at 21:09:09 +0200, Juerd wrote: Mark Reed skribis 2005-09-20 14:31 (-0400): This has so little redundancy that it makes very little sense to want to avoid repeating that very short encode_entities($item-label). The fine line is when the midsection is slightly more than that... If refactoring it into a sub will cause Too much indirection, without reducing complexity (you still have to pass in the parameters), but leaving it as is still duplication. If you minimize the parameters then you get a sub that is very unreusable, since it's specific to this block of code. All you are really doing is making the reader look away from the use by introducing one more symbolic replacement. What I wanted to achieve by the new constructs is two things: * share a lexical scope with the caller to minimize indirection * inline the block to it's caller to add to readability These are two advantages that the construct has over wrapping the code in a new sub. (I'd actually prefer something like: Your example is only WRT data composition... I was actually doing conditional side effects. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: uhm, no, I think I'll sit this one out..: neeyah! pgpSZv7cAtWU4.pgp Description: PGP signature
Re: Symbolic dereferentiation of magical variables
HaloO Larry, you wrote: On Mon, Aug 22, 2005 at 10:51:53PM +0200, Ingo Blechschmidt wrote: : If we go with these changes, this functionality (starting place for a : search) would be available by using : : Foo::Bar$symbol_to_lookup; # right? Presumably, though Foo::Bar differs from OUTER in that, for packages, the only fallback place to look is *. We don't automatically scan Foo after Foo::Bar, for instance. Just for the records: this implies an asymmetry between bareword outwards scans and infixed :: scans. The latter imply a prefixed *:: while the former don't, right? Or do you mean there's a single attempt to get Bar from the innermost Foo and only if *that* fails to fall back to *::Foo::Bar instead of scanning on outwards for candidates for Foo to query for Bar and eventually reaching the root and ultimately fail there. Or not even a single attempt? This would then behave like the UNIX shells I've encountered so far. That is if you have $HOME/bin in your $PATH and two subdirs $HOME/bin/foo and $HOME/bin/bar which are not in $PATH but each contain different version of some prog then neither foo/prog nor bar/prog works. weird Or we interpret 1) Foo::Bar and ::Foo::Bar as the single, innermost, outer access attempt 2) *::Foo::Bar as the lazy outwards scan towards root 3) **::Foo::Bar as eager outwards access that is forced to start from the root of the namespace In case 1) the ::Foo::Bar form is only needed to defer the definedness contraint while compiling or to disambiguate. Well, I guess infix wildcards *::Foo::*::Bar are then even to weird for this weirdness of mine :) /weird Maybe there could be some way for Foo::Bar to delegate to Foo if it likes, though. Sort of an inside-out import. But we've got along fine without that in Perl 5, so I'm not going to mandate it in the base language unless we see some really good uses for it. One that comes to mind is in providing a sandboxed environment without resorting to replicating the Perl6 root namespace environment. When you know that a boxed module needs a Foo with a certain structure you just provide that---easy enough. But if then the code you are wrapping happend to access the Bar from Foo with the oververbose syntax Foo::Bar this lookup suddenly warps out of the sandbox into the actual root environment of the interpreter... In general we should encourage outer classes to share with inner classes via lexical scoping rather than package scoping, I expect. Isn't that mixing access control in an unfortunate way with the namespace manouvering syntax? OTOH, I hear me saying that privacy comes from hiding... -- $TSa.greeting := HaloO; # mind the echo!
Re: ~ and + vs. generic eq
HaloO Yuval, you wrote: On Mon, Aug 29, 2005 at 14:07:51 +0200, TSa wrote: role Object does Compare[Object, =:=] role Numdoes Compare[Num, ==] role Strdoes Compare[Str, eq] What is the implication of from the perspective of the person using Object, Num and Str? Do they have one unified comparator? No, the role installs homogenious targets into the generic binary-MMD comparator which I think is called eqv. If so, this sounds like you are subverting MMD with some odd currying of the 'compare' method (whatever it's name may be) provided by the Compare role, instead of relying on the already existing semantics of MMD dispatch to give you the same name for several, superficially same meanings. The problem with equality checking is that there are several notions of equality :) And if you include them into the set of types used in the dispatch decision you end up with the very unspecific :( ::X, ::Y, Code.does(Compare) -- bool ) type and the difficulty of defining a nice call syntax for it! The driving idea here is that the syntactical choice of the programmer amounts to a type preference of the Comparer subtype. Do you mean on a per class or per comparison basis? That's an interesting question which is related to my retention to metric MMD. We must distinguish homogenous from heterogenous comparisons. My role Compare from above ensures that the comparor can be deduced from the unique (super)type of the two values to be compared. As such the comparator indirectly is class or type specific. The heterogenous cases however have to fallback to real MMD. Now metric MMD could spoils this approach by picking the wrong eqv target even though a proper homogenous target were available! I think that exceptions from the class perspective should not be done by parametrising the quality role, but overriding it, and that from the per comparison perspective we need to say either: coerce_to_other_type($value) generic_equality coerce_to_other_type($other_value) I'm not sure if I get you right, but I think we agree that there should be only one comparer for a certain type/class. Everything else is nonsense. I mean apples should know how to eqv to other apples and oranges with oranges. MMD enters the picture only if you want to compare apples with oranges. By color, by weight, as fruits in general, etc. and being an operator rich language we can specificate the generic comparator to make things a bit more fun like I proposed: $x +eqv $y; $x ~eqv $y; It seems that the Code type is still some kind of second class citizen in Perl6 because you can't nicely apply prefix ops to pending invocations without some help from the meta categories. And I'm unsure if $x (+eqv)() $y works even when prefix:+:(Comparor) exists and returns a numeric Comparor. But named params next to the operator could work $x eqv:num $y and plain eqv could actually mean binary eqv:mmd on the lhs and rhs. Ofcourse, I think that s/eqv/==/;, but everyone hates that. Well, I wonder if ($x eqv $y) is the same as !($x xor $y) and as such we just lack a high precedence correspondence to ^^ :) H, the Mathematician in me sees == ... But wouldn't that mean that ^^ should be != ... -- $TSa.greeting := HaloO; # mind the echo!
Re: conditional wrapper blocks
On 2005-09-21 03:53, Yuval Kogman [EMAIL PROTECTED] wrote: On Tue, Sep 20, 2005 at 21:09:09 +0200, Juerd wrote: Mark Reed skribis 2005-09-20 14:31 (-0400): This has so little redundancy that it makes very little sense to want to avoid repeating that very short encode_entities($item-label). The fine line is when the midsection is slightly more than that... Watch the attributions, please. I didn't write the above text - Juerd did.
Re: Object Model Pictures
On Tue, Sep 20, 2005 at 08:16:23PM -0400, Stevan Little wrote: http://svn.openfoundry.org/pugs/perl5/Perl6-MetaModel2.0/docs/ p6_role_model.jpg I am planning on making Roles self-bootstrapping, so the class(Role) will actually be the first Role in the system. From there, Class will do Role, and Role will do Role. This also means that all the instances of Class will also do Role, which means that classes automatically can also be used as Roles. Thanks for the pictures, Stevan. So every time a class does a new role, a new instance of the class is created as the role. If a class does three roles, there will be three role instances of the class, as well as the class' own instance of itself, and a user instance. When a method is called on the user instance, it asks the class instance if it can do the method, and the class instance looks at the methods in the class, and then at the methods in each role, and dispatches to the appropriate method definition. A role can be done by several classes at once, because a new instance is created for each class, specific to the class. Methods defined in a class are not clobbered by methods defined in a role. Rather, methods in a role are only catalogued by the class instance if it does not already have a method definition for that name. The order that a class does roles is significant, because if two roles define the same method, only the first one is catalogued by the class instance. -kolibrie
Sort of do it once feature request...
Every time I've desired a feature for Perl6 it has turned out that either
it was already planned to be there or I have been given good resons why it
would have been better not be there.
Now in Perl(5) {forum,newsgroup}s you can often see people doing stuff
like
my @files=grep !/^\.{1,2}/, readdir $dir;
Letting aside the fact that in the 99% of times they're plainly
reinventing the wheel of glob() a.k.a. File::Glob, there are indeed
situations in which one may have stuff like
for (@foo) {
next if $_ eq 'boo';
# do something useful here
}
whereas they know in advance that Cif can succeed at most once (e.g. foo
could really be Ckeys %hash).
Or another case is this:
while () {
if (@buffer MAX) {
push @buffer, $_;
next;
}
# ...
shift @buffer;
push @buffer, $_;
}
in which one wouldn't like the Cif condition to be tested any more after
it first evaluated false. Now efficiency is seldom a real issue in all of
these situations, and in the rare cases in which it is one may adopt
alternative strategies, like prefilling @buffer (with apparent referal to
the previous example). In some cases one could need refactoring into subs
to avoid duplication of code, but then the original logic may have been
more clear intuitively to start with...
Whatever, I feel slightly uncomfortable psychologically with the idea of
something that will be tested even when it's not necessary. So now I
wonder if Perl6 is already expected to provide syntactical sugar enough to
do what I want: which something easy enough to type to make a portion of
code (behave like it) silently evaporate(ed) after a condition has been
verified for the first time (or, say, n times). I think this is similar
to the functionality of macros, but as I said, this should be -to be
really useful- only a moderate bunch of keystrokes away from the code that
doesn't employ it...
Michele
--
I just said it was my conjecture. That doesn't mean I think it's right. :-)
- Larry Wall in p6l, Subject: Re: What do use and require evaluate to?
Re: Object Model Pictures
HaloO, Nathan Gray wrote: The order that a class does roles is significant, because if two roles define the same method, only the first one is catalogued by the class instance. Ups, this contradicts the concept of class composition which in the above case should raise an error instead of relying on the order of definition. -- $TSa.greeting := HaloO; # mind the echo!
Re: Sort of do it once feature request...
On 9/21/05, Michele Dondi [EMAIL PROTECTED] wrote:
Letting aside the fact that in the 99% of times they're plainly
reinventing the wheel of glob() a.k.a. File::Glob, there are indeed
situations in which one may have stuff like
for (@foo) {
next if $_ eq 'boo';
# do something useful here
}
I have mocked up an example of how you could do this in p5 with some ugly
looking code:
#!/usr/bin/perl
use strict;
use warnings;
do_something(5);
sub do_something {
my $target = shift;
my $block;
my $block2 = sub {
print No need to check $_ against $target anymore\n;
};
my $block1 = sub {
no warnings;
if ( $_ == $target ) {
print Skipping 5\n;
$block = $block2;
next LOOP;
}
else {
print $_ is not $target\n;
}
};
$block = $block1;
LOOP:
for ( 1 .. 9 ) {
$block-();
}
}
Once the condition has been met, the code dynamically changes to no longer
check for the condition. Keep in mind, you are paying the price of
dereferencing as well as ENTER/LEAVE on subs to get this performance
benefit.
I will be interested to see what the experts say on this. I have often
desired this in long tight running loops and found that the ways to achieve
it (as shown above) are worse then leaving the op in.
Michele
Cheers,
Joshua Gatcomb
a.k.a. Limbic~Region
Stringification, numification, and booleanification of pairs
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 true)? # true (because pairs are always true)? FWIW, I'd opt for ~$pair to be a\t42, +$pair to be +(~$pair) [1], and ?$pair to be always true. --Ingo [1] The numification of match objects used to *not* be the numification of their stringification, causing confusion, see http://tinyurl.com/asocc.
Re: Stringification, numification, and booleanification of pairs
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)? say ?$pair; # true (because 42 is true)? # true (because pairs are always true)? FWIW, I'd opt for ~$pair to be a\t42, +$pair to be +(~$pair) [1], and ?$pair to be always true. Pairs are objects, thus references. I like your suggestions for ~$pair (though any separator except other \s characters would do) and ?$pair. 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 (coincidentally, that's +?$pair). Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Object Model Pictures
Nathan, On Sep 21, 2005, at 9:02 AM, Nathan Gray wrote: On Tue, Sep 20, 2005 at 08:16:23PM -0400, Stevan Little wrote: http://svn.openfoundry.org/pugs/perl5/Perl6-MetaModel2.0/docs/ p6_role_model.jpg I am planning on making Roles self-bootstrapping, so the class(Role) will actually be the first Role in the system. From there, Class will do Role, and Role will do Role. This also means that all the instances of Class will also do Role, which means that classes automatically can also be used as Roles. Thanks for the pictures, Stevan. So every time a class does a new role, a new instance of the class is created as the role. Nope. The Role interface is (for the most part) a subset of the Class interface, well at least the important bits are. So I manually bootstrap the role(Role) into the class(Class), this then means that Class.does(Role). THis means that all instances of Class (all the user defined classes) themselves also do Role. This means that all Classes then become interchangeable with Roles. No new class or role instances need to be created, it is all inherited behavior from the class(Class). If a class does three roles, there will be three role instances of the class, as well as the class' own instance of itself, and a user instance. No, Roles are disposed of once class composition is complete. Part of the class composition process will be to consume any Roles which the class does. THe consumption process takes all the methods and attributes from the Role and actually adds them into the class. After that, the role can essentially be discarded (unless another class uses that same role). When a method is called on the user instance, it asks the class instance if it can do the method, and the class instance looks at the methods in the class, and then at the methods in each role, and dispatches to the appropriate method definition. The dispatch is always in the class since role methods are consumed into the class. A role can be done by several classes at once, because a new instance is created for each class, specific to the class. Methods defined in a class are not clobbered by methods defined in a role. Rather, methods in a role are only catalogued by the class instance if it does not already have a method definition for that name. The order that a class does roles is significant, because if two roles define the same method, only the first one is catalogued by the class instance. Class methods are used first, if the class method is not there, then the Role method is used. If there is a conflict with Role methods, neither Role method is used. By making all conflicts behave this way, we make Role order not-significant. Also If two Role methods conflict, the class consuming the roles must implement that method, otherwise it is a fatal error. Stevan -kolibrie
Re: \(...)?
Hi,
(sorry for the long delay.)
Juerd juerd at convolution.nl writes:
Ingo Blechschmidt skribis 2005-09-19 14:21 (+):
\(1,2,3);# Reference to a list promoted to an array (!)
\(((1,2,3)));# same
Except that it has to be a reference to a reference, because (1,2)
(in scalar context) already evaluates to a reference, because it can't
be a pure array.
See my definition of prefix:\ below. Parentheses used for grouping
do not change the context.
Could you think of a formal specification of \ the way you want it,
that doesn't exist of only examples? What context does it give its
RHS?
multi prefix:\ (Item $item) {...}
multi prefix:\ (@array) {...}
multi prefix:\ (%hash) {...}
# (The necessary magic needed for dealing with the proposed
# [EMAIL PROTECTED], which would be equivalent to map { \$_ } @array,
# is not included here.)
So:
\$obj;# $obj in item context
[EMAIL PROTECTED]; # @array in Array context (so @array doesn't auto-ref
# to a reference to itself, which would cause the problem
# you mentioned (that [EMAIL PROTECTED] would evaluate to a ref
# pointing to a ref))
\%hash; # analogous
What do you want , in that comma to do?
sub infix:, ([EMAIL PROTECTED] is rw) { @things }
# The is rw should refer to the parameters, i.e.
# infix:, returns aliases:
# ($a, $b)[0] = $c;# same as $a = $c
# ($a, $b)[0] =:= $a; # true
So the comma operator supplies list context to its arguments (because
of the slurpy @things) and returns an array. It can't return a list,
because, as you've said, lists aren't real data types.
Because the comma operator supplies list context, (@a, @b) flattens
@a and @b, so it's like @a.concat(@b).
(Of course, there is still the comma operator which separates arguments.
This operator is not the infix:, we talk about, e.g.:
foo(1,2,3); # infix:, *not* called
foo (1,2,3); # same as
foo( (1,2,3) ); # infix:, called
(BTW, is the argument-separator comma operator accessible by a
subroutine, like most other operators are? (I think not.)))
Are parens in any way special when used with \?
No:
\($obj); # same as
\$obj;
\((($obj))); # same as
\$obj;
\($a, $b);# same as
do {
my @temp = ($a, $b);
[EMAIL PROTECTED];
}
\((($a, $b))); # is really
prefix:\$a, $b;# is really
prefix:\( ($a, $b) ); # is really
# (Inner parentheses needed to prevent the comma to be treated
# as the other comma operator which separates arguments.)
prefix:\(infix:,($a, $b)); # same as
do {
my @temp = ($a, $b);
[EMAIL PROTECTED];
}
What is the precedence of \?
The comma operator should bind tighter than \:
\$a, $b# same as
(\$a), $b
BTW, list ::= infix:,:
($a,);# could be considered ugly
list $a; # same effect, but could be considered not ugly
I hope this mail makes sense :)
--Ingo
Re: \(...)?
Ingo~ On 9/21/05, Ingo Blechschmidt [EMAIL PROTECTED] wrote: foo(1,2,3); # infix:, *not* called foo (1,2,3); # same as foo( (1,2,3) ); # infix:, called Do you mean this to read? foo(1,2,3); # infix:, *not* called foo .(1,2,3);# infix:, *not* called foo (1,2,3); # infix:, called foo( (1,2,3) ); # infix:, called Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -Stan Kelly-Bootle, The Devil's DP Dictionary
Re: \(...)?
Hi, Matt Fowles wrote: On 9/21/05, Ingo Blechschmidt [EMAIL PROTECTED] wrote: foo(1,2,3); # infix:, *not* called foo (1,2,3); # same as foo( (1,2,3) ); # infix:, called Do you mean this to read? foo(1,2,3); # infix:, *not* called foo .(1,2,3);# infix:, *not* called foo (1,2,3); # infix:, called foo( (1,2,3) ); # infix:, called Right. Should have added an extra \n. --Ingo
Re: \(...)?
Ingo Blechschmidt skribis 2005-09-21 17:24 (+0200):
multi prefix:\ (Item $item) {...}
multi prefix:\ (@array) {...}
multi prefix:\ (%hash) {...}
I keep forgetting. What's the rule for determining that the (Item $item)
is used, rather than (@array), when one uses \$aref? It'd be bad if
$aref dereferenced first :)
Is Item really a type? Isn't the type actually Scalar? (I thought one
of the reasons to use item context instead of scalar context was
that Scalar and scalar looked too much alike -- having both item
and Item would reintroduce this problem.)
# (The necessary magic needed for dealing with the proposed
# [EMAIL PROTECTED], which would be equivalent to map { \$_ } @array,
# is not included here.)
Also, the magic for handling multiple arguments is missing.
What's the syntax for accepting a variable number of arguments, each of
which can be anything, regardless of context? How do you find out what
you got (array or scalar)?
Does it even make sense to implement \ in Perl? Does it make sense to
try and figure out a Perl signature for it?
Because the comma operator supplies list context, (@a, @b) flattens
@a and @b, so it's like @a.concat(@b).
Ah, comma supplies list context regardless of the context the comma is
in? Is this current, or part of your proposal? I thought comma would
propagate context.
BTW, list ::= infix:,:
This clarifies much. Thanks.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: conditional wrapper blocks
On Wed, Sep 21, 2005 at 09:54:33 -0400, Mark Reed wrote: Watch the attributions, please. I didn't write the above text - Juerd did. Sorry, I must have gotten confused when I was snipping -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me supports the ASCII Ribbon Campaign: neeyah!!! pgpXb84IL4Lg9.pgp Description: PGP signature
Re: Stringification, numification, and booleanification of pairs
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 nothing, but couldn't users create there own pair class that does what they want? Or extend the builting one to override operators they way they want? Just my 2 cents. On 9/21/05, Juerd [EMAIL PROTECTED] wrote: 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)? say ?$pair; # true (because 42 is true)? # true (because pairs are always true)? FWIW, I'd opt for ~$pair to be a\t42, +$pair to be +(~$pair) [1], and ?$pair to be always true. Pairs are objects, thus references. I like your suggestions for ~$pair (though any separator except other \s characters would do) and ?$pair. 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 (coincidentally, that's +?$pair). Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html -- __ Eric Hodges
Re: Stringification, numification, and booleanification of pairs
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 stringify as an actual HTTP
header.
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.
I am assuming that s/// does not mutate, because mutation isn't
something I think a smart *match* operator should do. (To be honest, I
don't think s/// and ~~ should belong together.) How does this actually
work?
Also, it'd be nice to be able to say s/^^/ /g, but have it skip the
first. There's :2nd, but is there also something like :(2...)th?
On 9/21/05, Juerd [EMAIL PROTECTED] wrote:
Please reply properly: below quotation (not above), per subject
(usually: per paragraph), and stripping useless junk like signatures.
--
Speaking of signatures... Instruct your mailer to use sigdashes, that
is: dash, dash, space. Without the space, it's not special, and not
recognised automatically by the many mailers that are capable of
recognising sigdashes.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Stringification, numification, and booleanification of pairs
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 prefix:~`, IIRC.
I am assuming that s/// does not mutate, because mutation isn't
something I think a smart *match* operator should do. (To be honest, I
don't think s/// and ~~ should belong together.) How does this actually
work?
This always bugged me as well. I think it currently still mutates (for
culture-backwards-compatibility reasons), but I do think the match
operator needs to be distinguished from the substitute/translate
operator. We also need to be able to choose between copying and
mutation. In my view, smart-match (~~) should be first and foremost
about returning a meaningful boolifiable value.
(If people want to discuss it further it's probably best to start a new thread.)
Also, it'd be nice to be able to say s/^^/ /g, but have it skip the
first. There's :2nd, but is there also something like :(2...)th?
S05 has:
# Lists and junctions are allowed: :nth(1|2|3|5|8|13|21|34|55|89).
So I assume :nth(2...) would work as expected.
Oh, and remember to start putting your `:g`s at the start of the
substitution/rule :-)
Stuart
Re: Stringification, numification, and booleanification of pairs
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 (coincidentally, that's +?$pair). While having stringification on everything is quite useful (for debugging dumps, if nothing else), I'm wary of giving numification behaviour to objects that simply can't produce a meaningful value. 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. Otherwise, if someone just says to himself I think a pair is a collection of two elements, so it will obviously numify to 2 and then unknowingly gets `1` back, things can get confusing *real* quick. Stuart
Re: Stringification, numification, and booleanification of pairs
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 pair.? I know nothing, but couldn't users create there own pair class that does what they want? Or extend the builting one to override operators they way they want? Actually I do except some object to stringify or numify. For example en object of type date should stringify to something like January 1, 2000 and also to numify to the Julian day number. 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? -- [EMAIL PROTECTED] [EMAIL PROTECTED]
