Re: Command-line args (weekly contribution to P6)
Hi David, thanks for your contribution. I'll review it thoroughly in the next few days. Am 24.05.2010 21:14, schrieb David Green: Also the line that sets the "but False" variations is commented out for now, because "but" isn't working. That's a reason why the challenge included only the simple cases in the first case :-) The tests might need fixing too, since I'm not sure whether eqv (as used by is_deeply) would cover that, or whether it would take a separate test in bool context. probably the latter. Instead of a %boolean-names hash, I used an array to hold those parameter names, as well as @arrays to hold the array-parameters. Or it would be pretty easy to change to a hash that maps the parameter names onto their types, or something like that. After playing with the first submission, the hash of types is what I found most useful. See http://github.com/moritz/process-cmd-args/blob/master/process-cmd-args.p6#L256 for some code that actually generates it by introspecting the signature of sub MAIN. I also added a %shorts param that maps short arg-names onto their full names. The spec doesn't elaborate on how the short args are specified in the signature of MAIN. I see two possible approaches (that don't contradict): 1) one renames them in the signature, so it would like sub MAIN(:name(:$n)) then $n has two names, 'name' and 'n', and we could consider all one-letter parameter names as short names 2) Iterate over all named parameters and build unambiguous prefixes. If any of them is just one letter short, we consider it a short name. Anz opinions from p6l about it? I have a few questions about the spec that are worth clarifying on p6l, but despite some slow going, I'm pleased to find that some aspects of P6 have already settled nicely in my brain. Great to hear that. Is there anything (except better error reporting) that Rakudo could do to further ease the learning? We're always looking for feedback from new hackers. Cheers, Moritz
Re: Command-line args (weekly contribution to P6)
On Wed, May 26, 2010 at 00:53, Moritz Lenz wrote: > The spec doesn't elaborate on how the short args are specified in the > signature of MAIN. I see two possible approaches (that don't contradict): > > 1) one renames them in the signature, so it would like > > sub MAIN(:name(:$n)) > > then $n has two names, 'name' and 'n', and we could consider all one-letter > parameter names as short names > this is what was intended in the spec. if you can update it to stamp out the ambiguity, that would be most welcome. > 2) Iterate over all named parameters and build unambiguous prefixes. If any > of them is just one letter short, we consider it a short name. > > > Anz opinions from p6l about it? > this method has too much magic. ~jerry
Re: Command-line args (weekly contribution to P6)
On Wed, May 26, 2010 at 07:22:36AM -0700, jerry gay wrote: : On Wed, May 26, 2010 at 00:53, Moritz Lenz wrote: : > The spec doesn't elaborate on how the short args are specified in the : > signature of MAIN. I see two possible approaches (that don't contradict): : > : > 1) one renames them in the signature, so it would like : > : > sub MAIN(:name(:$n)) : > : > then $n has two names, 'name' and 'n', and we could consider all one-letter : > parameter names as short names : > : this is what was intended in the spec. if you can update it to stamp : out the ambiguity, that would be most welcome. Yes, that was the intent. : > 2) Iterate over all named parameters and build unambiguous prefixes. If any : > of them is just one letter short, we consider it a short name. : > : > : > Anz opinions from p6l about it? : > : this method has too much magic. And also too little magic, insofar as it won't guess which options deserve precedence over another due to frequency of use. Also, it's a bit antisocial to get people used to using certain short switches and then cancel them out when they get ambiguous. If you're going to have a mechanism for forcing short ones, then we already have #1 above, and the intermediate names are not terribly useful, because people will tend to prefer the extremes most of the time. And if you want a particular program to behave the other way, you can pull in all the switches with *%args and then do your own key matching with the <*name> forms, assuming it's implemented, and plays nice in alternations, LTMishly speaking. Larry
r30811 -[S05] attempt to clarify :nth and :x
Author: lwall
Date: 2010-05-26 18:55:57 +0200 (Wed, 26 May 2010)
New Revision: 30811
Modified:
docs/Perl6/Spec/S05-regex.pod
Log:
[S05] attempt to clarify :nth and :x
Modified: docs/Perl6/Spec/S05-regex.pod
===
--- docs/Perl6/Spec/S05-regex.pod 2010-05-26 15:50:56 UTC (rev 30810)
+++ docs/Perl6/Spec/S05-regex.pod 2010-05-26 16:55:57 UTC (rev 30811)
@@ -16,8 +16,8 @@
Created: 24 Jun 2002
-Last Modified: 17 May 2010
-Version: 121
+Last Modified: 26 May 2010
+Version: 122
This document summarizes Apocalypse 5, which is about the new regex
syntax. We now try to call them I rather than "regular
@@ -461,12 +461,21 @@
m/(\d+)/ && m:c/(\d+)/ && s:c/(\d+)/@data[$0]/;
-Lists and junctions are allowed: C<:nth(1|2|3|5|8|13|21|34|55|89)>.
+The argument to C<:nth> is allowed to be a list of integers, but such a list
+should be monotically increasing. (Values which are less than or equal to the
previous
+value will be ignored.) So:
-So are closures: C<:nth({.is_fibonacci})>
+:nth(2,4,6...*)# return only even matches
+:nth(1,1,*+*...*) # match only at 1,2,3,5,8,13...
+
+This option is no longer required to support smartmatching. You can grep a
list
+of integers if you really need that capability:
+
+:nth(grep *.oracle, 1..*)
+
If both C<:nth> and C<:x> are present, the matching routine looks for
submatches
-that are compatiable with C<:nth>. If the number of matches is compatible with
+that match with C<:nth>. If the number of post-nth matches is compatible with
the constraint in C<:x>, the whole match succeeds with the highest possible
number of submatches. The combination of C<:nth> and C<:x> typically only
makes sense if C<:nth> is not a single scalar.
r30812 -[S03] explain how not-raising works on != and ne
Author: lwall
Date: 2010-05-26 19:21:03 +0200 (Wed, 26 May 2010)
New Revision: 30812
Modified:
docs/Perl6/Spec/S03-operators.pod
Log:
[S03] explain how not-raising works on != and ne
Modified: docs/Perl6/Spec/S03-operators.pod
===
--- docs/Perl6/Spec/S03-operators.pod 2010-05-26 16:55:57 UTC (rev 30811)
+++ docs/Perl6/Spec/S03-operators.pod 2010-05-26 17:21:03 UTC (rev 30812)
@@ -15,8 +15,8 @@
Created: 8 Mar 2004
-Last Modified: 21 May 2010
-Version: 205
+Last Modified: 26 May 2010
+Version: 206
=head1 Overview
@@ -3118,22 +3118,29 @@
successful thread may terminate the other threads abruptly. In general
you probably want to avoid code with side effects in junctions.
-Use of negative operators with syntactically recognizable junctions may
-produce a warning on code that works differently in English than in Perl.
-Instead of writing
+Use of negative operators with junctions is potentially problematic if
+auththreaded naively. However, by defining C and C in terms
+of the negation metaoperator, we automatically get the "not raising"
+that is expected by an English speaker. That is
if $a != 1 | 2 | 3 {...}
-you need to write
+really means
-if not $a == 1 | 2 | 3 {...}
+if $a ![==] 1 | 2 | 3 {...}
-However, this is only a syntactic warning, and
+which the metaoperator rewrites to a higher-order function resembling
+something like:
-if $a != $b {...}
+negate((* == *), $a, (1|2|3));
-will not complain if $b happens to contain a junction at runtime.
+which ends up being equivalent to:
+if not $a == 1 | 2 | 3 {...}
+
+which is the semantics an English speaker expects. However, it may well
+be better style to write the latter form yourself.
+
Junctive methods on arrays, lists, and sets work just like the
corresponding list operators. However, junctive methods on a hash
make a junction of only the hash's keys. Use the listop form (or an
r30813 -[S03] typo
Author: moritz Date: 2010-05-26 19:57:01 +0200 (Wed, 26 May 2010) New Revision: 30813 Modified: docs/Perl6/Spec/S03-operators.pod Log: [S03] typo Modified: docs/Perl6/Spec/S03-operators.pod === --- docs/Perl6/Spec/S03-operators.pod 2010-05-26 17:21:03 UTC (rev 30812) +++ docs/Perl6/Spec/S03-operators.pod 2010-05-26 17:57:01 UTC (rev 30813) @@ -3119,7 +3119,7 @@ you probably want to avoid code with side effects in junctions. Use of negative operators with junctions is potentially problematic if -auththreaded naively. However, by defining C and C in terms +autothreaded naively. However, by defining C and C in terms of the negation metaoperator, we automatically get the "not raising" that is expected by an English speaker. That is
r30821 -[spec] Add Real.Int, Real.Rat, Real.Num, and Real.Complex to the spec.
Author: colomon Date: 2010-05-26 21:29:50 +0200 (Wed, 26 May 2010) New Revision: 30821 Modified: docs/Perl6/Spec/S32-setting-library/Numeric.pod Log: [spec] Add Real.Int, Real.Rat, Real.Num, and Real.Complex to the spec. Modified: docs/Perl6/Spec/S32-setting-library/Numeric.pod === --- docs/Perl6/Spec/S32-setting-library/Numeric.pod 2010-05-26 19:20:46 UTC (rev 30820) +++ docs/Perl6/Spec/S32-setting-library/Numeric.pod 2010-05-26 19:29:50 UTC (rev 30821) @@ -19,8 +19,8 @@ Created: 19 Mar 2009 extracted from S29-functions.pod -Last Modified: 14 May 2010 -Version: 7 +Last Modified: 26 May 2010 +Version: 8 The document is a draft. @@ -174,6 +174,30 @@ =over +=item Int + + our Int multi method Int () + +Converts this C to an C as if C had been called. + +=item Rat + + our Rat multi method Rat ( Real $epsilon = 1.0e-6 ) + +Converts this C to a C with an accuracy of C<$epsilon>. + +=item Num + + our Num multi method Num () + +Converts this C to a C as accurately as is possible for a C. + +=item Complex + + our Complex multi method Complex () + +Returns a C whose real part is this C and whose imaginary part is 0. + =item floor our Int multi method floor ( Real $x: ) is export
eqv and comparing buts
On 2010-05-26, at 1:53 am, Moritz Lenz wrote: >> The tests might need fixing too, since I'm not sure whether eqv (as used by >> is_deeply) would cover that, or whether it would take a separate test in >> bool context. > > probably the latter. I guess it would have to -- that is, "but" creates an ad-hoc new class, so even if you take two identical objects and "but" them the same way, there's probably no good way that eqv can tell they are the same. At best, it could know that one or both of its operands had been "tampered with", and report false. (If you wanted to manipulate two or more objects the same way, then you'd have to make a new class with the appropriate overloaded methods and then eqv could compare my NumButFalse $n1 to my NumButFalse $n2.) In order to compare two objects that were created and modified on the fly, you could see what roles/methods they actually have, and compare the values in whatever way is suitable. I guess you could see whether an object has extra roles with something like: all($x.roles) === all ($x.WHAT.roles) Still, it's important to be able to tell whether two things can be expected to work the same way, so perhaps there can be an adverb for eqv that says to pay attention to ad-hoc changes (or vice versa). Since 'but' is special syntax, maybe there's even a way to compare snapshots of all the types that were 'but'ed in to the base type, but I don't know how feasible that is. -David
Re: eqv and comparing buts
On Wed, May 26, 2010 at 11:09:49PM -0600, David Green wrote: : On 2010-05-26, at 1:53 am, Moritz Lenz wrote: : >> The tests might need fixing too, since I'm not sure whether eqv (as used by is_deeply) would cover that, or whether it would take a separate test in bool context. : > : > probably the latter. : : I guess it would have to -- that is, "but" creates an ad-hoc new class, : so even if you take two identical objects and "but" them the same way, : there's probably no good way that eqv can tell they are the same. : At best, it could know that one or both of its operands had been : "tampered with", and report false. : : (If you wanted to manipulate two or more objects the same way, then : you'd have to make a new class with the appropriate overloaded methods : and then eqv could compare my NumButFalse $n1 to my NumButFalse $n2.) : : In order to compare two objects that were created and modified on : the fly, you could see what roles/methods they actually have, and : compare the values in whatever way is suitable. I guess you could : see whether an object has extra roles with something like: : : all($x.roles) === all ($x.WHAT.roles) : : Still, it's important to be able to tell whether two things can be : expected to work the same way, so perhaps there can be an adverb for : eqv that says to pay attention to ad-hoc changes (or vice versa). : Since 'but' is special syntax, maybe there's even a way to compare : snapshots of all the types that were 'but'ed in to the base type, : but I don't know how feasible that is. Or going the other direction, perhaps we're missing a primitive that can produce a data structure with the type information stripped, and then eqv might be able to determine structural equivalence between two canonicalized values. Larry
