Re: underscores in the core lib
On 8/10/06, Larry Wall [EMAIL PROTECTED] wrote: Yes, it's a design smell. The point of core is to huffman code common things, so something in core with _ should normally either be shorter or out of the core. I don't think I agree. I've been programming in Ruby, and I appreciate all the nice convenient methods it gives me. I fear that if underscores are not allowed in the core, then we will have to omit methods like Ruby's 'protected_methods' or 'instance_eval' in favor of some more superfluous syntax. I think that standard functions ought not to have underscores *most of the time*, because their presence indicates something that could be better named or is miscategorized. However, for methods, especially advanced or introspective methods, I think longer names that describe the action are better than short ones that only describe the action if you understand the pun. Huffman coding does not imply that *everything* is short. Luke
Re: Module/Class Authoritys
On Thu, Aug 10, 2006 at 10:25:24PM -0700, Darren Duncan wrote:
At 12:35 AM -0400 8/11/06, Stevan Little wrote:
Quick question for the group.
Can there be more than one authority?
module Foo-0.0.1-cpan:JRANDOM-http://www.foo.org-mailto:[EMAIL PROTECTED]
S11 would seem to indicate no (it states that names are made up of 3
parts), but I guess I am wondering if one of those parts can have
multiple sub-parts in it?
Thanks,
- Stevan
Perhaps something like what is done with versions; eg:
Foo-0.0.1-(cpan:JRANDOM|http://www.foo.org|mailto:[EMAIL PROTECTED])
What does it *mean*? In a module declaration it seems out of place. And
this is something that can be solved culturally (the CPAN could provide
a name that aliases multiple authorities, for instance), so you really
only need one authority in a declaration.
In a use, it would seem that you're saying use any one of these,
they are equivalent for my purposes when you say
use Foo-0.0.1-(X|Y);
Though could you imagine tracking down the bug when they *aren't*
equivalent? Seems like a bad idea.
I can see some use for this though:
use Foo-0.0.1-{X,Y};
if it means try Foo-0.0.1-X and then, if that fails, try Foo-0.0.1-Y
But that's just moving some information from the normally invisible
@INC into the module name.
And what do we do with the combinatorial explosion of this?
use Foo-(1.2 .. 3.3)-(X|Y|Z);
Suddenly it seems like a really good idea to only have one authority.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Fwd: [svn:perl6-synopsis] r10804 - doc/trunk/design/syn
On 8/11/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Some object types can behave as value types. Every object can produce a safe key identifier (CSKID for short) that uniquely identifies the -object for hashing and other value-base comparisons. Normal objects +object for hashing and other value-bases comparisons. Normal objects I'm glad you fixed this typo. +no explicit call to CMAIN was performed by the time the mainline code +finishes. I don't see a purpose for this. Isn't it better to have a simple, predictable call at the end of the program regardless? If a module wants to call MAIN differently, it can use .wrap. +If CMAIN is declared as a method, the name of the invoked +program is passed as the invocant. What a hack. Please don't do that. Luke
Re: [svn:perl6-synopsis] r10804 - doc/trunk/design/syn
On 8/11/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
+To return from other types of code structures, the Cleave function
+is used. The first argument, if supplied, specifies a CSelector
+for the control structure to leave. The CSelector and will be
+smart-matched against the dynamic scope objects from inner to outer.
+The first that matches is the scope that is left.
s/and //
+As with module and class declarations, a sub or method declaration
+ending in semicolon is allowed at the outermost file scope if it is the
+first such declaration, in which case the rest of the file is the body:
+
+sub MAIN ($directory, :$verbose, *%other, [EMAIL PROTECTED]);
+for @filenames { ... }
+
+Proto or multi definitions may not be written in semicolon form,
+nor may CMAIN subs within a module or class. (A CMAIN routine
+is allowed in a module or class, but is not usually invoked unless
+the file is run directly (see a above). This corresponds to the
+unless caller idiom of Perl 5.) In general, you may have only one
+semicolon-style declaration that controls the whole file.
Should the following text now be removed from S06:
--- S06.pod.orig2006-08-11 11:50:46.0 +0300
+++ S06.pod 2006-08-11 11:51:08.0 +0300
@@ -159,14 +159,6 @@
sub foo {...} # Yes, those three dots are part of the actual syntax
-The old Perl 5 form:
-
-sub foo;
-
-is a compile-time error in Perl 6 (because it would imply that the body of the
-subroutine extends from that statement to the end of the file, as Cclass and
-Cmodule declarations do).
-
Redefining a stub subroutine does not produce an error, but redefining
an already-defined subroutine does. If you wish to redefine a defined sub,
you must explicitly use the Cis instead trait.
--
Markus Laire
Re: underscores in the core lib
在 2006/8/11 下午 2:35 時，Luke Palmer 寫到： I think that standard functions ought not to have underscores *most of the time*, because their presence indicates something that could be better named or is miscategorized. However, for methods, especially advanced or introspective methods, I think longer names that describe the action are better than short ones that only describe the action if you understand the pun. Huffman coding does not imply that *everything* is short. .SKID and the like are methods of Object, and as such should be considered part of the standard functions, as they are available to all terms. Methods for the other implicit-coerced-to types (Bit/Int/Num/Str/ List) share this concern; because all terms may be coerced implicitly into them, their methods also have unbounded visibility. For other built-in types, I think underscore names are just fine. For example, metaclass methods such as Class.has_method should indeed remain as such. :) Thanks, Audrey PGP.sig Description: This is a digitally signed message part
[svn:perl6-synopsis] r10828 - doc/trunk/design/syn
Author: larry
Date: Fri Aug 11 08:41:18 2006
New Revision: 10828
Modified:
doc/trunk/design/syn/S06.pod
Log:
2nd whack, with help from gaal++, luqui++, audreyt++, malaire++, and others++.
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod(original)
+++ doc/trunk/design/syn/S06.podFri Aug 11 08:41:18 2006
@@ -13,9 +13,9 @@
Maintainer: Larry Wall [EMAIL PROTECTED]
Date: 21 Mar 2003
- Last Modified: 10 Aug 2006
+ Last Modified: 11 Aug 2006
Number: 6
- Version: 46
+ Version: 47
This document summarizes Apocalypse 6, which covers subroutines and the
@@ -165,7 +165,8 @@
is a compile-time error in Perl 6 (because it would imply that the body of the
subroutine extends from that statement to the end of the file, as Cclass and
-Cmodule declarations do).
+Cmodule declarations do). The only allowed use of the semicolon form is to
+declare a CMAIN sub--see L/Declaring a MAIN subroutine below.
Redefining a stub subroutine does not produce an error, but redefining
an already-defined subroutine does. If you wish to redefine a defined sub,
@@ -1922,7 +1923,7 @@
To return from other types of code structures, the Cleave function
is used. The first argument, if supplied, specifies a CSelector
-for the control structure to leave. The CSelector and will be
+for the control structure to leave. The CSelector will be
smart-matched against the dynamic scope objects from inner to outer.
The first that matches is the scope that is left.
@@ -2414,8 +2415,8 @@
=item c)
-no explicit call to CMAIN was performed by the time the mainline code
-finishes.
+the mainline code is not terminated prematurely, such as with an explicit call
+to Cexit, or an uncaught exception.
=back
@@ -2429,17 +2430,17 @@
for @filenames { ... }
}
-If CMAIN is declared as a method, the name of the invoked
-program is passed as the invocant. If CMAIN is declared as a
-set of multi subs, MMD dispatch is performed.
+If CMAIN is declared as a set of multi subs, MMD dispatch is performed.
-As with module and class declarations, a sub or method declaration
+As with module and class declarations, a sub declaration
ending in semicolon is allowed at the outermost file scope if it is the
first such declaration, in which case the rest of the file is the body:
sub MAIN ($directory, :$verbose, *%other, [EMAIL PROTECTED]);
for @filenames { ... }
+This form is allowed only for simple subs named CMAIN that are intended
+to be run from the command line.
Proto or multi definitions may not be written in semicolon form,
nor may CMAIN subs within a module or class. (A CMAIN routine
is allowed in a module or class, but is not usually invoked unless
@@ -2465,11 +2466,16 @@
-name='spacy value':name«'spacy value'»
-name=val1,'val 2', etc:name«val1 'val 2' etc»
---name :name
---name=value :namevalue
+--name :name # only if declared Bool
+--name=value :namevalue# don't care
+--name value :namevalue# only if not declared Bool
+
--name=spacy value :name«'spacy value'»
+--name spacy value :name«'spacy value'»
--name='spacy value' :name«'spacy value'»
+--name 'spacy value' :name«'spacy value'»
--name=val1,'val 2', etc :name«val1 'val 2' etc»
+--name val1 'val 2' etc:name«val1 'val 2' etc» # only if declared @
-- # end named argument processing
+name :!name
@@ -2486,6 +2492,42 @@
:name='spacy value':name«'spacy value'»
:name=val1,'val 2', etc:name«val1 'val 2' etc»
-As usual, switches are assumed to be first, and any switches after C--
-are treated as positionals or slurpy. Other policies may be introduced
-by calling CMAIN explicitly.
+Exact Perl 6 forms are okay if quoted from shell processing:
+
+':namevalue' :namevalue
+':name(42)':name(42)
+
+For security reasons, only constants are allowed as arguments, however.
+
+The default CCapture mapper pays attention to declaration of
+CMAIN's parameters to resolve certain ambiguities. A C--foo switch
+needs to know whether to treat the next word from the command line as
+an argument. (Allowing the spacey POSIX form gives the shell room to
+do various things to the argument.) The non-POSIX C-foo form never
+assumes a separate argument, and you must use C=. For the C--foo
+form, if there is a named parameter corresponding to the switch name,
+and it is of type CBool, then no argument is expected. Otherwise an
+argument is expected. If the parameter is of a non-slurpy array type,
+all subsequent words up to the next command-line switch (or the end
+of the list) are bound to that parameter.
+
+As usual, switches are
Re: underscores in the core lib
On Fri, Aug 11, 2006 at 11:28:08PM +0800, Audrey Tang wrote: : For other built-in types, I think underscore names are just fine. For example, : metaclass methods such as Class.has_method should indeed remain as such. :) That's fine--I don't think of anything behind the META curtain as core, at least not in the sense that I was meaning it earlier. Larry
designing a test suite for multiple implementations
recently, perl 6 development has taken the form of a multi-method dispatch. that is, multiple implementations are under active development. this includes pugs (in haskell,) v6 (in perl5,) v6-Compiler (in perl6,) and perl6 (on parrot.) hopefully, each of these returns the same result, a working[1] perl6 implementation. it makes sense for these implementations to share perl6 tests written from the perl6 specification. it is also important for this to happen, as it will help solidify the specification, allow implementations to check results against each other, share new and corrected tests easily, and be the canonical reference for answering questions about the spec. it is also important that only perl6 specification tests be shared; implementation-specific tests belong solely with the implementation.. few have ever created a test suite of this magnitude before--i certainly haven't, and don't expect anyone will do it alone. the overarching question i have is: how is an test suite targeted for multiple implementations designed, developed, managed, and controlled? i believe we can quickly address the developed question with the word organically. tests will be added, changed, or removed as needed. organization of tests in the suite will change over time as refactoring of any large body of tests or code is inevitable. this is the simple, practical solution we usually expect when working with perl. as for controlled, i expect restricted access to the test repository, as a protected body of tests is important to more people as soon as multiple implemenations are using it. providing a method of submitting and applying patches will allow anyone the ability to propose a new test for inclusion. for managed, i have a few ideas. currently, the suite lives in the pugs repo. this is a fine first approximation, but i believe it will soon be time to move this suite[3]. the question is, should it be moved into their own repository, or into the repo of the official perl6 implementation (if such a beast will indeed exist,) or should it live in some other place i haven't thought of yet? the options here are limited, and i believe straightforward. it should be easy to come to an agreement and take action. i've left the designed question for last, because i think it's the most difficult. perl6 test suite has already taken steps towards targeting multiple implementations. the suite has been designed with a set of sanity tests, which are required to pass successfully in order to run the perl6 Test module, which is written in perl6. this allows the remainder of the suite's test files to be written in perl6, making their representation independent of implementation. all the perl6 implementations i've mentioned above use this test suite, and pass some subset of the tests. this is a big win, and has allowed newer implementations to grow quickly as the course has already been laid. but unsolved problems remain. perl has a long history of testing. there are widely held beliefs on how to design and develop test suites. simple rules, like keeping like tests together, using good test descriptions, testing components in isolation, performing integrated tests, and marking tests as todo() or skip() when not working as expected. this last testing rule i mentioned becomes somewhat problematic when designing a test suite for use by multiple perl6 implementations. it is obvious that some implementations of perl6 will not pass all tests, and will need to mark certain tests as todo() and skip() in order to run the suite successfully. this is further complicated by the fact that perl6 is designed to be executed in multiple platforms. therefore, a test may succeed for a particular subset of implementations on a particular subset of platforms per implementation, but fail elsewhere. so, what should todo() information would look like, and where it should go? it's a tough problem, because there's a lot of pain, and it has to be shared somehow. if it's decided we are testing the specification, we should design implementation-independent tests. from this, it follows that implementation details (like todo()) should not exist in the test. instead, todo() info would be contained in a config file, or in a test harness, or by some other implementation-specific method. this is not ideal, since changes to the shared test suite may invalidate the todo() information in a particular implementation as test numbers or descriptions change. keeping todo info directly with the test means a particular implementation has this information with the test (as is currently best practice,) but it has it's downsides as well. test files become crowded with todo() statements and conditional logic for implementation- and platform-dependent todo()s. each time a new implementation is updated, the shared test suite will be modified, requiring (imo) unnecessary test suite changes. i should point out that implementation-specific tests must exist, but they must not be in a
Re: designing a test suite for multiple implementations
Note: This reply is being sent to all 4 mailing lists that the original was, though I am only subscribed to the first 2 myself, for the benefit of completeness to the readers of the original. -- As my initial reply, I'll bring up 2 recent discussions or Pugs changes that affect this, so please keep them in mind when continuing this thread. 1. First, I started a making v6 test suite its own distro thread on just perl6-compiler which overlapped a lot with the intent of your email, though went into some other details, and there were 4 replies: * http://www.nntp.perl.org/group/perl.perl6.compiler/1434 - me * http://www.nntp.perl.org/group/perl.perl6.compiler/1435 - Gaal * http://www.nntp.perl.org/group/perl.perl6.compiler/1442 - me * http://www.nntp.perl.org/group/perl.perl6.compiler/1448 - Gaal * http://www.nntp.perl.org/group/perl.perl6.compiler/1449 - Jerry Aside from proposing v6::tests as a separate distro that implementation distros have as an external dependency, ... In summary, I had proposed that unilateral SKIPs/TODOs etc would be eliminated, and that a language-level feature, eg, a global %FEATURES could be queryable at run time by programs, including the test suite, to see if the current implementation claims to correctly implement some features they want to use or test. A test suite would query this for a feature, and output a SKIP if it returns false, and tests the feature if it returns true, with PASS or FAIL. At the very least, some language tests would have to be unconditional, such as the ability to reference a predefined hash, use basic conditionals, and strings, but once those are passing, it is possible to use %FEATURES to conditionalize everything else. We realized that, while this should work well long-term, and should certainly work well for a framework written in a language that has interchangeable backends and common tests for all, like DBI (or my Rosetta), this may be too difficult to implement short-term for Perl 6 itself. 2. And so, within the last week, some commits to Pugs added the ability for a SKIP/TODO to hardcode in the tests that it is just for a particular version or version range of a particular implementation, so it would either skip or not skip based on the declared version of the interpreter, which would increment at release time. That is, unconditional TODOs are conditional TODOs. It seems that this is the current plan to do what you suggest in the short term. The short term would have the tests referencing specific implementation versions, and the long term would have the tests completely agnostic to what implementations or versions they run under. -- Darren Duncan
Re: designing a test suite for multiple implementations
Just to avoid repeating some of the discussion, here's a link to #perl6: http://colabti.de/irclogger/irclogger_log/perl6?date=2006-08-07,Monsel=110#l193 The discussion goes on and off for most of the rest of the page, so you probably want to search for and highlight todo if you're using firefox. Anyway, we thrashed the internal/external question pretty hard, and the rough consensus was to leave todos with the tests for now, but move to a todo() function that is easy to isolate, visually if nothing else. My own take on it is that we can just define the official tests to be the parts outside of todo() calls for now. But Jerry raises a lot of good questions that need to be answered over the long haul. Certainly by the time we have a real 6.0 we'll need to have worked out the policy and polity issues. For now, my gut feeling is that we'll need at least four times as many tests as we have so far, and rapid test development is best served by exercising the least amount of control. Trying to lock it down too early will simply stall the process for most of the million monkeys who are currently writing tests. Version control is our best friend here, at least for now. Trouble tickets are probably premature unless they're *very* lightweight. Well, that's my 2¢ or so. Larry
Re: designing a test suite for multiple implementations
On 8/11/06, Larry Wall [EMAIL PROTECTED] wrote: Just to avoid repeating some of the discussion, here's a link to #perl6: http://colabti.de/irclogger/irclogger_log/perl6?date=2006-08-07,Monsel=110#l193 The discussion goes on and off for most of the rest of the page, so you probably want to search for and highlight todo if you're using firefox. thanks for the link, i didn't know #perl6 was logged. for those of you who may not know, on that channel i'm known as [particle]. Anyway, we thrashed the internal/external question pretty hard, and the rough consensus was to leave todos with the tests for now, but move to a todo() function that is easy to isolate, visually if nothing else. My own take on it is that we can just define the official tests to be the parts outside of todo() calls for now. that take seems to me like a particularly interesting form of blindness. however, it is a blindness that we (perl6 language implementors) would all share. using this definition, it seems we the blind should all be able to eventually describe this official elephant. But Jerry raises a lot of good questions that need to be answered over the long haul. Certainly by the time we have a real 6.0 we'll need to have worked out the policy and polity issues. For now, my gut feeling is that we'll need at least four times as many tests as we have so far, and rapid test development is best served by exercising the least amount of control. Trying to lock it down too early will simply stall the process for most of the million monkeys who are currently writing tests. Version control is our best friend here, at least for now. Trouble tickets are probably premature unless they're *very* lightweight. true, my questions are mainly long haul. i agree that control to the test repo should not *yet* be limited, so we can maintain our (seemingly quickening) pace of perl6 development. i don't intend to fix what isn't broken. the timely questions are those related to design, and implementation thereof. it is here where i hope suggestions like darren's (thanks!) and those from others with test design experience can lend a hand. ~jerry
[svn:perl6-synopsis] r10855 - doc/trunk/design/syn
Author: audreyt
Date: Fri Aug 11 20:28:03 2006
New Revision: 10855
Modified:
doc/trunk/design/syn/S06.pod
Log:
* S06: dconway++ suggested that we still provide convenience methods
on Signature level, to reduce line noise in common want operations.
* Also remove a stray paragraph miscommitted with the previous commit.
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod(original)
+++ doc/trunk/design/syn/S06.podFri Aug 11 20:28:03 2006
@@ -13,9 +13,9 @@
Maintainer: Larry Wall [EMAIL PROTECTED]
Date: 21 Mar 2003
- Last Modified: 11 Aug 2006
+ Last Modified: 12 Aug 2006
Number: 6
- Version: 47
+ Version: 48
This document summarizes Apocalypse 6, which covers subroutines and the
@@ -1766,10 +1766,6 @@
Specifies that the parameter cannot be modified (e.g. assigned to,
incremented). It is the default for parameters.
-$x = 5;
-
-sub f ($x) {}
-
=item Cis rw
Specifies that the parameter can be modified (assigned to, incremented,
@@ -1902,16 +1898,24 @@
...
}
-You can also use the postfix signature syntax to test for compatibility:
+Or use its shorthand methods to reduce line noise:
+
+ifwant.item {...} # called in non-lvalue scalar context
+elsif want.list {...} # called in list context
+elsif want.void {...} # called in void context
+elsif want.rw{...} # expected to return an lvalue
+
+The C.arity and C.count methods also work here:
-ifwant:($) {...} # called in scalar context
-elsif want:(*@) {...} # called in list context
-elsif want:($ is rw) {...} # expected to return an lvalue
-elsif want:($,$) {...} # expected to return two values
+if want.arity 2{...} # must return more than two values
+if want.count 2{...} # can return more than two values
-The C.arity method also works here:
+Their difference is that C.arity considers only mandatory parts,
+while C.count considers also optional ones, including C*$:
-if want.arity 2{...} # expected to return more than two values
+($x, $y) = f(); # Within f, want === :(*$?, *$?, *@)
+#want.arity === 0
+#want.count === 2
=head2 The Cleave function
