Re: Hyper-slices?
David Christensen wrote: I definitely like the hyper stuff how it is; maybe the answer is to just define an infix:[[]] operator which returns the crosswise slice of a nested list of lists. In any case it could be shunted aside to some package and certainly does not need to be in core. Didn't S09 take care of that w/ the [ ; ; ] syntax? -- Rod Adams
Re: Hyper operator corner case?
Roger Hale wrote: One set of cases that doesn't seem to have come up in discussion: (1, 3, 2) - (83, 84, 81, 80, 85) Should this give (-82, -81, -79, -80, -85) From an arithmetic point of view it should be exactly that. The implementation might need to morph the code though, see below. as by hallucinating $neutral - $x == $x? This latter $neutral in fact doesn't exist among ordinary numbers, and I would call it algebraically unnatural: for all (other) $n, $n - ($a + $b) == ($n - $a) - $b or, as you increase $a by $b, $n - $a decreases by $b (a sort of contravariance), but $neutral - ($a + $b) == $a + $b == ($neutral - $a) + $b ! This violates algebraic relations I would prefer to rely on, both in my own reasoning and that of the compiler and other program-handling programs. Me too! The thing is that the field of the real numbers is build on the operators + and * which are associative and commutative. The neutral elements are 0 and 1 respectively. The non-associative operators - and / are defined in terms of the inverse elements. Thus $a - $b == $a + (-$b) and $a / $b == $a * (1/$b) if $b != 0. We could also bring in $b**-1 as another way to find the multiplicative inverse. But that just pulls in yet another operator and the question which axioms apply to it and how it is hyperated. For user-defined numerical types---that is ones that provide +, *, -, /, **, etc---I would hope that these axioms hold. Actually I hope that there is a set of roles that define the standard numerics and enforce sanity as far as that is possible via the class composition mechanics. So coming back to your example, operator - would call - on the RHS and call + with the result. But I've no idea to which extent operator is a special runtime operator versus a term re-writing at compile time. -- TSa (Thomas Sandla)
rx/abc$/
On Sat, Apr 16, 2005 at 12:10:48PM -0700, Larry Wall wrote: I think I have to clarify what I mean by that last phrase. Trailing delimiters are hidden inside any token that has already been started, but not at the start of a token (where token is taken to be fairly restrictive). Therefore these are errors: qq. $foo.bar() . qq: @foo::bar[] : However qq/ foobar( $a / $b ) / is just fine, since (...) is looking for its own termination. Consider this: rx/abc$/ qq/abc$/ After roie's refactoring, both now breaks, whilst in Perl 5, only the latter break -- qr/abc$/ is just fine. Is it something we need to special-case for rx? Thanks, /Autrijus/ pgpSvwQMyMWSN.pgp Description: PGP signature
Re: rx/abc$/
On Tue, Apr 19, 2005 at 01:31:12AM +0800, Autrijus Tang wrote:
: On Sat, Apr 16, 2005 at 12:10:48PM -0700, Larry Wall wrote:
: I think I have to clarify what I mean by that last phrase. Trailing
: delimiters are hidden inside any token that has already been started,
: but not at the start of a token (where token is taken to be fairly
: restrictive). Therefore these are errors:
:
: qq. $foo.bar() .
: qq: @foo::bar[] :
:
: However
:
: qq/ foobar( $a / $b ) /
:
: is just fine, since (...) is looking for its own termination.
:
: Consider this:
:
: rx/abc$/
: qq/abc$/
:
: After roie's refactoring, both now breaks, whilst in Perl 5, only
: the latter break -- qr/abc$/ is just fine. Is it something we need
: to special-case for rx?
Certainly. rx// does not do any kind of interpolation any more. It is
a language of its own, and $ is just a token in that language. On the
other hand, like Perl 5, that language does have variables in addition
to $, so we still have to distinguish whether the character after the $
indicates a variable. Perl 5's rule was that $ meant end-of-whatever
if it was followed by ), | or the end of the interpolated string.
(Or by # or whitespace in /x mode.) Otherwise it's a variable.
Since we're parsing left-to-right, we can't do exactly the same, but
I suspect we can check after the $ for ), ], |, #, whitespace, or the
terminator, which rules out direct use of $/ inside /.../. That's not
a great hardship, since we have the $1 and $foo shortcuts for
backrefs, and anything fancier probably wants to be in {...} anyway.
As for qq/abc$/, I think it's okay for that to notice that you're trying
to interpolate a variable that has the same name as the delimiter, and
blow up immediately. While we could let people interpolate such
variables by default, it's probably better to stop and make people
clarify what the mean in that case. There aren't that many puncuational
variables any more. Certainly we don't have $' and $ anymore, which
would be the usual ambiguous cases for normal quotes.
And yes, this is pretty much the opposite of what I said about
@foo.bar.baz[]
But in either case we're just trying to figure out what the user expects.
Or doesn't expect, in the case of qq/abc$/.
Larry
alarm() and later()
Two things popped up while implementing a demo version of alarm() today. 1. In perl5 and in most underlying libraries, alarm() has 1 second granularity (and a possible 1 second error on top of that). Can we have the alarm builtin not assume the worst, and take a Num instead of an Int, so that on some systems at least we get higher resolution sleeps? 2. Since signals are so global and sometimes we want something else, how about a variation on the traditional u?alarm theme, in which you can pass an optional closure to alarm() that will get called back instead of having a SIGALRM raised? multi sub alarm(: Num ?$timeout = $CALLER::_, Num ?$interval, Code ?$callback) returns Int This should be reentrant and allow multiple uses. The Int return is an id on the future event so you can cancel it. (Which needs speccing. Possibly this could return a reference to some object instead of an id?) If the alarm builtin is getting too overloaded, I propose the closure version be named later. -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Re: Context of hash slices; quotation adverbs
: But when you start interpolating, you get into a big mess:
: h\qq[$interpolated] = want(); # ???
: h$foo = want(); # ???
I think that, as with functions called in unknown context, we should
just force the RHS here to list context, and rely on the RHS to add
extra context as necessary if they really mean scalar. If something
really is always producing a scalar value, it doesn't matter if it's
called in list context.
That makes sense, but that would make
%num_of_linesfile = @file
not DWIM... of course that would translate into
%num_of_linesfile = scalar @file
so maybe that's OK.
Any bit of expression by default evaluates at ordinary run time, but can
be forced to evaluate earlier by surrounding context.
What you're saying is that
BEGIN { $c=1 }
$c=0;
q:c($c)/.../
interpolates, because the $c in line three is evaluated after the $c in line
one but before the $c in line two, right? If you don't obfuscate on purpose
(like I did), that makes sense.
--
-Roie
v2sw6+7CPhw5ln5pr4/6$ck2ma8+9u7/8LSw2l6Fi2e2+8t4TNDSb8/4Aen4+7g5Za22p7/8
[ http://www.hackerkey.com ]
Re: Context of hash slices; quotation adverbs
On Mon, Apr 18, 2005 at 11:23:34PM +0300, Roie Marianer wrote:
: : But when you start interpolating, you get into a big mess:
: : h\qq[$interpolated] = want(); # ???
: : h$foo = want(); # ???
:
: I think that, as with functions called in unknown context, we should
: just force the RHS here to list context, and rely on the RHS to add
: extra context as necessary if they really mean scalar. If something
: really is always producing a scalar value, it doesn't matter if it's
: called in list context.
:
: That makes sense, but that would make
: %num_of_linesfile = @file
: not DWIM... of course that would translate into
: %num_of_linesfile = scalar @file
: so maybe that's OK.
Eh, no, I wouldn't call that one unknown context. I'd call it scalar.
: Any bit of expression by default evaluates at ordinary run time, but can
: be forced to evaluate earlier by surrounding context.
: What you're saying is that
: BEGIN { $c=1 }
: $c=0;
: q:c($c)/.../
: interpolates, because the $c in line three is evaluated after the $c in line
: one but before the $c in line two, right? If you don't obfuscate on purpose
: (like I did), that makes sense.
Yes. The main problem is that you have to make sure the my $c isn't
hidden in an inner block. This wouldn't work:
BEGIN { my $c=1 }
$c=0;
q:c($c)/.../
Note that
my $c = BEGIN { 1 };
doesn't quite work either. However, we'll probably end up
my $c will begin { $_ = 1 };
or some such. Compile-time binding
my $c ::= 1;
probably also works, or maybe you have to write:
my $c ::= \1;
Larry
Re: rx/abc$/
LW = Larry Wall AT = Autrijus Tang LW I think I have to clarify what I mean by that last phrase. Trailing LW delimiters are hidden inside any token that has already been started, LW but not at the start of a token (where token is taken to be fairly LW restrictive). AT Consider this: AT AT rx/abc$/ AT qq/abc$/ AT After roie's refactoring, both now breaks, whilst in Perl 5, only Actually, it wasn't due to my refactoring. It was because I tried to implement the rule above, which meant getting rid of the special case (which was present in qqInterpolatorVar) of a variable whose name _ended_ with the delimiter. AT the latter break -- qr/abc$/ is just fine. Is it something we need AT to special-case for rx? LW Certainly. rx// does not do any kind of interpolation any more. It is LW a language of its own, and $ is just a token in that language. But rx:P5// should act like qr//, shouldn't it? LW I suspect we can check after the $ for ), ], |, #, whitespace, or the LW terminator, which rules out direct use of $/ inside /.../. I'll add a flag for that in rx:P5. In any case, I suspect that the code to parse rx which is not :P5 will be completely different from what we have now (rx:P5 is basically a not-so-glorified qq:b(0)) LW As for qq/abc$/, I think it's okay for that to notice that you're trying LW to interpolate a variable that has the same name as the delimiter, and LW blow up immediately. Makes sense, but what exactly do you mean by blow up? -- -Roie v2sw6+7CPhw5ln5pr4/6$ck2ma8+9u7/8LSw2l6Fi2e2+8t4TNDSb8/4Aen4+7g5Za22p7/8 [ http://www.hackerkey.com ]
Re: Context of hash slices; quotation adverbs
On Mon, Apr 18, 2005 at 11:23:34PM +0300, Roie Marianer wrote: That makes sense, but that would make %num_of_linesfile = @file not DWIM... of course that would translate into %num_of_linesfile = scalar @file so maybe that's OK. In order to promote proper syntactical thinking, note that this is now spelled: %num_of_linesfile = @file.elems; because the Perl 5 way would put a reference to @file in the hash. Scalar context always makes references now, from what I understand.
junctions as indicies
I'm looking in S09, and reading about junctions. It seems to me that
if we have a junction $j which we use to index into an array or a hash,
it should DWIM and return a junction of the corresponding values.
@ar=[1..10];
%hash=(a=1,b=4,c=7);
$j=1|2|3;
$k=a|c;
$u = @ar[$j]; # 2|3|4
$v = %hash{$k}; # 1|7
Does this make sense to others?
David
Re: junctions as indicies
David Christensen writes:
I'm looking in S09, and reading about junctions. It seems to me that
if we have a junction $j which we use to index into an array or a hash,
it should DWIM and return a junction of the corresponding values.
@ar=[1..10];
%hash=(a=1,b=4,c=7);
$j=1|2|3;
$k=a|c;
$u = @ar[$j]; # 2|3|4
$v = %hash{$k}; # 1|7
Does this make sense to others?
Well, if we replaced @ar[$j] with, say, @ar.get($j), what you're
proposing happens automatically. So I think that it's the right thing
to do.
Luke
Re: Context of hash slices; quotation adverbs
On Mon, Apr 18, 2005 at 06:44:55PM -0400, Kurt Hutchinson wrote: : On Mon, Apr 18, 2005 at 11:23:34PM +0300, Roie Marianer wrote: : That makes sense, but that would make : %num_of_linesfile = @file : not DWIM... of course that would translate into : %num_of_linesfile = scalar @file : so maybe that's OK. : : In order to promote proper syntactical thinking, note that this is now : spelled: : : %num_of_linesfile = @file.elems; Or more succinctly: %num_of_linesfile = [EMAIL PROTECTED]; : because the Perl 5 way would put a reference to @file in the hash. : Scalar context always makes references now, from what I understand. Interestingly, a stored reference would track the current number of lines rather than taking a snapshot. But you should definitely think of it as storing a reference rather than the number of lines, because the ref will certainly behave differently in string context. Larry
junction adverb: :except
Hypothetical here: If we want to calculate a set of values for a junction which map nicely to a range with a few outliers, would it be possibly to have a qualifier :except which allows us to make exceptions to our given range? I.e., (Ignore for the moment the inefficiency of the choice of this particular algorithm.) my $year = 1900; # or whatever my $leap_year = $year % 400 == any(0..400 :by(4) :except(100,200,300)); Here except would be a modifier on the range being generated for any(). I could also see except being used to strip choices from junctions: my $j = 1|2|3|4; my $k=$j :except(2); # 1|3|4 Let me know if I'm totally abusing junctions here... David
Re: junction adverb: :except
David Christensen writes: Hypothetical here: If we want to calculate a set of values for a junction which map nicely to a range with a few outliers, would it be possibly to have a qualifier :except which allows us to make exceptions to our given range? I.e., (Ignore for the moment the inefficiency of the choice of this particular algorithm.) my $year = 1900; # or whatever my $leap_year = $year % 400 == any(0..400 :by(4) :except(100,200,300)); Here except would be a modifier on the range being generated for any(). I could also see except being used to strip choices from junctions: my $j = 1|2|3|4; my $k=$j :except(2); # 1|3|4 Let me know if I'm totally abusing junctions here... No, you're abusing adverbs. You can't give an adverb to a variable (because adverbs don't modify actually nouns :-). I don't know if we've destroyed Damian's comparator semantic, but if not, then you can just do: my $k = ($j != 2); But if that no longer happens, it's best a method on the junction. Except every time we add a method to junction, we destroy the ability to automatically thread that method over the junction. I've proposed several solutions to this over the years (applying to autodelegating iterators as well). I still think it's something that that needs to be solved. Luke
Re: rx/abc$/
On Tue, Apr 19, 2005 at 12:02:45AM +0300, Roie Marianer wrote: : But rx:P5// should act like qr//, shouldn't it? Yes. : LW I suspect we can check after the $ for ), ], |, #, whitespace, or the : LW terminator, which rules out direct use of $/ inside /.../. : I'll add a flag for that in rx:P5. In any case, I suspect that the code to : parse rx which is not :P5 will be completely different from what we have now : (rx:P5 is basically a not-so-glorified qq:b(0)) More or less. For a number of the backslashes it doesn't matter whether they get interpolated in the first pass or the second, though you need to be really careful with things that regexen treat differently, and especially you mustn't lose track of your backwhacked backwhacks. It gets pretty messy, which is one of the reasons Perl 6 does it differently. : LW As for qq/abc$/, I think it's okay for that to notice that you're trying : LW to interpolate a variable that has the same name as the delimiter, and : LW blow up immediately. : Makes sense, but what exactly do you mean by blow up? I suppose that depends on whether you're programming a cruise missile or not. For most purposes, an appropriate parse failure message would suffice. Larry
statement modifiers for setting variables
The following is legal perl: print $a $b $c if ($a,$b,$c)=(1,2,3); This prints 1 2 3, but the definitions obviously aren't scoped to the modified statement. And a Cmy in the modifier is a bit too late. Any reason to [not] add a Cwhere statement modifier which restricts the scope of the declarations? Sure its redundant, but so are all statement modifiers. Sometimes its good to factor things out and express them later, rather than earlier. It lets us focus on the important things first: print $a $b $c where ($a,$b,$c)=(1,2,3); (in this case, we could use printf to to the factoring, but that's not a general solution).
Re: junctions as indicies
--- David Christensen [EMAIL PROTECTED] wrote:
I'm looking in S09, and reading about junctions. It seems to me
that if we have a junction $j which we use to index into an array
or a hash, it should DWIM and return a junction of the corresponding
values.
@ar=[1..10];
%hash=(a=1,b=4,c=7);
$j=1|2|3;
$k=a|c;
$u = @ar[$j]; # 2|3|4
$v = %hash{$k}; # 1|7
Does this make sense to others?
David
Maybe, but I don't like returning junctures in those cases unless you
*explicitly* ask for it. I'd rather the default be the arbitrary lists
returned, or whatever fits the context. How about
@ar=[a..z];
%hash=(a=1,b=4,c=7);
$j=1|2|3;
$k=a|c;
@u = @ar[$j];# (b..d)
%u = @ar[$j].kv; # (1='b',2='c',3='d')
$u = @ar[$j];# \(b..d)
$ju = juncture @ar[$j]; # 'b'|'c'|'d'
@v = %hash{$k}; # (1,7)
%v = %hash{$k}.kv; # (a=1,c=7)
$v = %hash{$k}; # \(1,7)
$jv = juncture %hash{$k}; # 1|7
Am I way off base here?
__
Do you Yahoo!?
Plan great trips with Yahoo! Travel: Now over 17,000 guides!
http://travel.yahoo.com/p-travelguide
Re: junctions as indicies
Paul Hodges writes: Maybe, but I don't like returning junctures in those cases unless you *explicitly* ask for it. I'd rather the default be the arbitrary lists returned, or whatever fits the context. How about @ar=[a..z]; %hash=(a=1,b=4,c=7); $j=1|2|3; @j = (1,2,3); $k=a|c; @k = a c; @u = @ar[$j];# (b..d) @u = @[EMAIL PROTECTED]; etc. Perl can indeed slice using ordinary lists. Another problem with using junctions for this is that they're unordered, and you're expecting ordered results back. Luke
Re: junctions as indicies
Paul Hodges wrote:
--- David Christensen [EMAIL PROTECTED] wrote:
I'm looking in S09, and reading about junctions. It seems to me
that if we have a junction $j which we use to index into an array
or a hash, it should DWIM and return a junction of the corresponding
values.
@ar=[1..10];
%hash=(a=1,b=4,c=7);
$j=1|2|3;
$k=a|c;
$u = @ar[$j]; # 2|3|4
$v = %hash{$k}; # 1|7
Does this make sense to others?
David
Maybe, but I don't like returning junctures in those cases unless you
*explicitly* ask for it. I'd rather the default be the arbitrary lists
returned, or whatever fits the context. How about
@ar=[a..z];
%hash=(a=1,b=4,c=7);
$j=1|2|3;
$k=a|c;
@u = @ar[$j];# (b..d)
%u = @ar[$j].kv; # (1='b',2='c',3='d')
$u = @ar[$j];# \(b..d)
$ju = juncture @ar[$j]; # 'b'|'c'|'d'
@v = %hash{$k}; # (1,7)
%v = %hash{$k}.kv; # (a=1,c=7)
$v = %hash{$k}; # \(1,7)
$jv = juncture %hash{$k}; # 1|7
Am I way off base here?
What would you propose
@v[all(any(4,5),one(1,2,3),none(7,8,9))]
return?
-- Rod Adams
