Re: Common Serialization Interface
Brad Bowman wrote: Both Data::Dumper and Storable provide hooks to customize serialization ($Data::Dumper::Freezer|Toaster, STORABLE_freeze|_thaw). Other modules like YAML and Clone could also possibly reuse a common state marshalling interface. Is there some common element to this process which can be gathered into a Serialize role with a default implementation? There is already .yaml to serialize to yaml and .perl to serialize to Perl (I'm not sure what the limits are round-tripping Perl this way). They can be returned to Perl in a consistent way, too: eval($yaml, :langyaml); Still, these options may not substitute for the kind of role-based solution you have mind. Mark
Re: Good list-flattening question.
Mark J. Reed wrote: Ok, I dkimmed through the synopses again and didn't see this offhand. If I have two arrays @a and @b and I wish to create a two-element list out of them - a la Perl5 ([EMAIL PROTECTED], [EMAIL PROTECTED]) - what's the correct way to do that in Perl6? If it's still ([EMAIL PROTECTED], [EMAIL PROTECTED]), then what do we call what the \ is doing there, now that references are supposed to be a behind-the-scenes automagical thing? I think it's a good question, considering this is worked for me in Perl 6: my @c = ([EMAIL PROTECTED], [EMAIL PROTECTED]); I'm not sure how to reconcile that with the spec I found for \: The unary backslash operator captures its arguments, and returns an object representing those arguments. Mark
Re: renaming grep to where
Darren Duncan wrote:
Putting aside legacy issues for the moment,
I suggest that it might be appropriate to rename the .grep list operator
to .where, so we can say, for example:
@filtered = @originals.where:{ .foo eq $bar };
We already have a where keyword in the language, which is used for
very similar things, and I think it would be reasonable that users would
see it used in other situations and think they can use it for filtering
a list too.
I agree with this proposal, although I don't full understand the
implications of using where in this context when it already appears
elsewhere in the language.
Mark
request for addition to administative field to Synopsis
Hello, As I've worked on smart linking, I've found some gaps in the spec, often of the variety of obvious parts that should largely work the same as Perl 5. For example, say was formally spec'ed until recently, or print for that matter. I have a suggestion which I believe make the docs more useful to users as well as the spec maintainers, in addition to helping the smart linking work flow. I would like a new heading at the bottom of each synposis that would be there to be a target for smart links, which clearly should be associated with this particular synopsis, but are lacking a specific target, because the spec is incomplete or missing. This is different than unspecced features, it more about features like print, that are so obvious they have been left out until now. To users, it would be convey that there is already functionality they can review related to the synopsis, that might be fully spec'ed yet. To spec maintainers, it provides a kind of TODO list of things that need to be clarified. To smart linkers, it makes better use of our time than making no link, or linking to something suboptimal, with no visible result that we found something that needed attention. A name for this section might be To Be Clarified The boilerplate text might be: The following tests relate to this synopsis, but need further spec clarifications so that a specific smart link can be created. As an example, today's discovery was that the auto-increment and decrement operators aren't spec'ed, beyond mentioning them in a precedence table. This specific example also illustrates why just pointing to how Perl 5 works isn't a good idea. The first sentence of the Perl 5 docs work are: '++ and -- work as in C ...' While I realize creating a self-contained Perl 6 spec is leaves significantly more work, It has the important benefit of clarifying exactly how large of a task it is to create something which is official in the sense that it complies with such a large volume of documentation, which will finally be available all in one place. Mark
sub ($self: $foo ) (was: Re: single named param)
Larry Wall wrote: I'm trying to decide if sub ($self: $just_a_named_param) can meaningfully put anything into $self. It seems doubtful, and it should probably be submethod ($self: $just_a_named_param) I agree. If sub ($self: $foo) works than it reduces privacy, since someone could call a sub like externally, when it wasn't intended. Mark
Re: not and true appear unspec'ed, too
Mark Stosberg wrote: The formal definition of Inf appears to be missing from the spec documents. Since I'm not exactly sure how Perl 6 treats Inf, I'll leave submitting this patch to someone else. Once the spec is added, a smart link to it should be added from: t/builtins/math/infinity.t Along the same lines, I couldn't find a spec for either not or true, which both have passing tests for pugs in t/builtins/bool/ Mark
Re: Inf appears to be unspec'ed
Mark Stosberg wrote: The formal definition of Inf appears to be missing from the spec documents. Since I'm not exactly sure how Perl 6 treats Inf, I'll leave submitting this patch to someone else. Once the spec is added, a smart link to it should be added from: t/builtins/math/infinity.t TimToady caught me on IRC and pointed out where Inf, not and true are mentioned in the spec, if only briefly. Smart links have been added for them now. Mark
Inf appears to be unspec'ed
The formal definition of Inf appears to be missing from the spec documents. Since I'm not exactly sure how Perl 6 treats Inf, I'll leave submitting this patch to someone else. Once the spec is added, a smart link to it should be added from: t/builtins/math/infinity.t Mark
Re: Cwhen outside of Cgiven
Trey Harris wrote:
markstos++ pointed out the following behavior:
use v6-alpha;
{
when 1 ~~ 0 {
say Surprise!
}
}
This code prints Surprise!, because $_ is undef, which is false, just
like 1 ~~ 0 is.
I'd like to make the following suggestions for Synopsis clarification:
1. It will be a very common pitfall, I think, to write Cwhen as a
synonym for Cif. For an extra layer of safety for such a novitiate
mistake, a boolean used as an argument to when should emit a warning
unless suppressed with an explicit C?().
when 1 ~~ 0 # warning
when ?(1 ~~ 0) # no warning
2. I think Cwhen should either be disallowed outside of Cgiven, or
it should be made to do something useful.
To refine this point a bit, the spec is clear that 'when' is useful not
just with 'given' but with any block that sets $_.
I agree that it should be an error outside of any block that sets $_,
and I ask that that any block that sets $_ be further defined. for
statements and method bodies are mentioned explicitly, but it would be
nice to have something approach a complete list.
Mark
CATCH: changing the topic and preserving the call stack
I'll hold up some error handling in CGI::Application as use case some
for some CATCH spec refinements. The Perl 5 code is below for reference.
First, we handle the exception conditionally based /not/ on the
exception itself, but whether we have an exception handle installed
to deal with it. Is it valid to not use a when/default chain in CATCH
or to change topic, using: $_ = $my_new_topic. ?
An example of that would be helpful.
My second point involves re-throwing errors with useful stack traces.
Here's an example similar to what we do in CGI::App:
try { boom(); }
if ($!) {
die died trying: $!
}
I haven't seen the nice stack traces that pugs generate on death
mentioned in the spec. I think it's OK that this isn't mandatory for
Perl 6 implementations, but for those that do offer it, I suggest it
be spec'ed how to access the stack trace that is generated.
The above example would currently give a trace from where the re-throw
happened, but I really just want to enhance the message that was
originally generated. I want something like:
die died trying: ~$!.stack_trace;
Without this, I'm currently worse off trying to handle and re-throw
errors, because the pugs CATCH implementation isn't complete, and using
the above recipe, all the errors are traced to the same unhelpful
location.
Mark
##
if ($@) {
my $error = $@;
$self-call_hook('error', $error);
if (my $em = $self-error_mode) {
$body = $self-$em( $error );
} else {
croak Error executing run mode '$rm': $error ;
}
}
gather/take definition missing
I found 6 references to gather in Perl6/Spec/*, but none of them were a formal definition. It would great if an official entry for gather/take could be added. Mark
Re: clarify: how WALK arguments can be combined
Brad Bowman wrote:
Mark Stosberg wrote:
In the Objects chapter, a WALK pseudo-class is spec'ed for using
when calling sets of methods:
http://feather.perl6.nl/syn/S12.html#Calling_sets_of_methods
These are the arguments listed that can be used with WALK:
:canonical # canonical dispatch order
:ascendant # most-derived first, like destruction order
:descendant # least-derived first, like construction order
:preorder # like Perl 5 dispatch
:breadth# like multi dispatch
First, it would be nice if the comments like Perl 5 and like multi
dispatch could be expanded, if only to provide references to their
complete specs. Also, if canonical means something besides I don't
care, it would be nice to have a reference for that, too.
I think Class::C3 on CPAN describes and implements the Perl 6 dispatch
algorithm in Perl 5. I don't know if it's in the Synopses, etc.
So that would the preorder or the canonical case. In either case,
since multi methods don't (normally) exist in Perl 5, it's still not
clear what order multi methods will be resolved in.
My concern for the moment is clarification how these options can be
combined. Clearly, combining :ascendant and :descendant doesn't make
sense.
But, I assume a self.*meth call can work along both the inheritance
axis and the multi method access.
Therefore, it seems fair to combine one option that affects each axis.
Wouldn't :breadth just be the breadth first order of the same set
of methods? Mentioning multi dispatch kind of confusing...
So I think the permitted combinations are:
One sorting adverb (defaulting to :canonical):
:canonical, :ascendant, :descendant, :preorder, :breadth
Some number of filtering adverbs:
:super # only immediate parent classes
:methodname # only classes containing method declaration
:omit(Selector) # only classes that don't match selector
:include(Selector) # only classes that match selector
I agree in general, but still wonder about how the details sorting
adverbs apply to multi methods AND inherited methods.
I'd like to be able to access the list of methods returned by
the WALK traversal. Perhaps it is:
@methods = $object.*WALK::can('meth');
That looks potentially useful. The use case might be checking to see
which which methods /might/ be called and then perhaps changing or
avoiding the method set call based on the result.
Mark
Re: when calling sets of methods, what happens to the return values?
Mark Stosberg wrote: S12 describes a feature to call sets of methods at the same time: http://feather.perl6.nl/syn/S12.html#Calling_sets_of_methods I would like the spec to clarify what happens to the return values of all these methods. I'm fine with a simple answer, such as that they are not available, or only the first or last set of return values is returned. As a use case, we may use of basically this feature in CGI::Application in Perl5, as part the plugin system. Each plugin location is like a method name, and as we get to each point in the code, we look up through the inheritance tree, executing methods at each location. So, Audrey implemented the beginning of this functionality: $obj.*$meth, for single inheritance. As part that she implemented return values. Her design was to compose the final return value as an unconcatenated list of each method's return value. Example: If C.foo returns (1,2,3) and D.foo returns(4,5,6) you get $obj.*$meth.[0][0] == 1 $obj.*$meth.[1][0] == 4 That works OK for me. If there's a downside, if there is a downside, it's that it could be hard to track down where a mysterious return value came from, since the return value object doesn't tell you exactly which methods were called, and in which order. Mark
clarify: how WALK arguments can be combined
In the Objects chapter, a WALK pseudo-class is spec'ed for using when calling sets of methods: http://feather.perl6.nl/syn/S12.html#Calling_sets_of_methods These are the arguments listed that can be used with WALK: :canonical # canonical dispatch order :ascendant # most-derived first, like destruction order :descendant # least-derived first, like construction order :preorder # like Perl 5 dispatch :breadth# like multi dispatch First, it would be nice if the comments like Perl 5 and like multi dispatch could be expanded, if only to provide references to their complete specs. Also, if canonical means something besides I don't care, it would be nice to have a reference for that, too. My concern for the moment is clarification how these options can be combined. Clearly, combining :ascendant and :descendant doesn't make sense. But, I assume a self.*meth call can work along both the inheritance axis and the multi method access. Therefore, it seems fair to combine one option that affects each axis. As a use case, in CGI::Application we traverse classes :ascendant but then execute what would be multi methods in the order they are defined, which sounds like perhaps :preorder to me. Mark
Re: multi method dispatching of optional arguments (further refined)
Luke Palmer wrote: I don't follow your examples. What is the logic behind them? On 9/3/06, Mark Stosberg [EMAIL PROTECTED] wrote: Examples: Arguments (1 2) to signatures 1. (@a?) and 2. (@a) calls 2 For example, I would expect this one to be ambiguous, because the 1. (@a?) sub introduces two different signatures, 1. () and 1. (@a). When given 1 2, 1. (@a) matches as well as 2. (@a), so it is ambiguous. Oops. Yes, I would call that a tie, too. Arguments (@a) to signatures 1. (@a?) and 2. (@a) IS TIE The only difference I can see between this and the one above is @a vs. 1 2, which ought to behave the same way, right? Yes. Note that the variant /with/ the parameter can be considered an exact match, but but the variant /without/ it cannot be considered an exact match. And I expect that if either or both matches the method is considered to be a match. Right? Let's look again at the last example: Arguments () to signatures 1. (@a?) and 2. () calls 2 (@a?) really means () OR (@a). The () implicit in (@a?) is a match, but not an exact match, so the () declared by itself wins, because it /is/ an exact match. Mark
Re: request: clarify how symbolic references with OO
Mark Stosberg wrote: ::($meth)(self:); Well, audreyt just made this work (r12960), which I what I what I thought should work in the first place: self.$meth(). So I'm happy. (But my curiosity about the spec for symbolic refs and OO still stands. ) Mark
multi method dispatching of optional arguments
Hello, I think it would helpful if the spec addressed who wins in MMD when optional arguments are present. I just submitted these failing tests for pugs which illustrate the issue. not ok 11 - Arguments (a = 'b') to signatures 1. () and 2. (*%h) calls 2 not ok 14 - Arguments () to signatures 1. (@a?) and 2. () calls 2 not ok 15 - Arguments (1 2 3) to signatures 1. () and 2. (@a?) calls 2 In summary, matches that should otherwise happen are failing because the optionalness. Mark Reference: http://feather.perl6.nl/syn/S12.html#Multisubs_and_Multimethods
Re: multi method dispatching of optional arguments
Mark Stosberg wrote: Hello, I think it would helpful if the spec addressed who wins in MMD when optional arguments are present. I just submitted these failing tests for pugs which illustrate the issue. not ok 11 - Arguments (a = 'b') to signatures 1. () and 2. (*%h) calls 2 not ok 14 - Arguments () to signatures 1. (@a?) and 2. () calls 2 not ok 15 - Arguments (1 2 3) to signatures 1. () and 2. (@a?) calls 2 In summary, matches that should otherwise happen are failing because the optionalness. Reference: http://feather.perl6.nl/syn/S12.html#Multisubs_and_Multimethods I just patched mmd-draft.txt in the pugs tree to try address optionals. Here's what I came up with: == Handling Optional and Slurpy Parameters Optional parameters need special consideration, because they represent two options themselves: one with with the argument and one without. Slurpy parameters have the same concern, as they can take zero or more arguments themselves. For each optional parameter, a case with and without the optional parameter is considered. Examples: Arguments (a = 'b') to signatures 1. () and 2. (*%h) calls 2 Arguments () to signatures 1. (@a?) and 2. () calls 2 Arguments (1 2 3) to signatures 1. () and 2. (@a?) calls 2 Mark
Re: multi method dispatching of optional arguments (further refined)
Mark Stosberg wrote: Hello, I think it would helpful if the spec addressed who wins in MMD when optional arguments are present. I just submitted these failing tests for pugs which illustrate the issue. not ok 11 - Arguments (a = 'b') to signatures 1. () and 2. (*%h) calls 2 not ok 14 - Arguments () to signatures 1. (@a?) and 2. () calls 2 not ok 15 - Arguments (1 2 3) to signatures 1. () and 2. (@a?) calls 2 In summary, matches that should otherwise happen are failing because the optionalness. Reference: http://feather.perl6.nl/syn/S12.html#Multisubs_and_Multimethods I took a break and thought of an important further clarification for this. The updated text is below: == Handling Optional and Slurpy Parameters Optional parameters need special consideration, because they represent two options themselves: one with with the argument and one without. Slurpy parameters have the same concern, as they can take zero or more arguments themselves. For each optional parameter, a case with and without the optional parameter is considered. Examples: Arguments (a = 'b') to signatures 1. () and 2. (*%h) calls 2 Arguments (1 2) to signatures 1. (@a?) and 2. (@a) calls 2 Arguments (1 2 3) to signatures 1. () and 2. (@a?) calls 2 Arguments (@a) to signatures 1. (@a?) and 2. (@a) IS TIE Note that the variant /with/ the parameter can be considered an exact match, but but the variant /without/ it cannot be considered an exact match. That rule makes the following example work: Arguments () to signatures 1. (@a?) and 2. () calls 2
when calling sets of methods, what happens to the return values?
S12 describes a feature to call sets of methods at the same time: http://feather.perl6.nl/syn/S12.html#Calling_sets_of_methods I would like the spec to clarify what happens to the return values of all these methods. I'm fine with a simple answer, such as that they are not available, or only the first or last set of return values is returned. As a use case, we may use of basically this feature in CGI::Application in Perl5, as part the plugin system. Each plugin location is like a method name, and as we get to each point in the code, we look up through the inheritance tree, executing methods at each location. In this case, I think we ignore the return values. Mark
request: clarify how symbolic references with OO
In reading about symbolic references, I didn't find any specific
language that mentioned using them in conjunction with methods or OO. I
would like to see specific language and examples added to the spec to
clarify this.
Here's a specific example which currently doesn't work in pugs.
It's attempting to use a symbolic reference to call a method in a parent
class, and fails to find it.
With an equivalent syntax in Perl 5, this works.
{
my $test = ' ::($meth)(self:) should find method in parent class';
class Foo {
method foo () { found }
}
class Child is Foo {
method b () {
my $meth = 'foo';
::($meth)(self:);
}
}
my $obj = Child.new;
eval_is( $obj.b, 'found', $test);
}
Perhaps there some other recommended I've missed for this ?
Re: could 'given' blocks have a return value?
Agent Zhang wrote:
According to S04, given {} is at statement level, so you can't use it
directly as an expression. But Perl 6 always allow you to say
my $foo = do given {...}
As well as
my $foo = do if foo {...} else {...}
I confirmed this both work now with pugs!
I think the 'do given' case is useful enough to document
more officially along with 'given'.
If you are thinking about the if/else case, ?? ... !! would be a
simpler way to write it.
Mark
return Types: what are the enforcement details?
I'm interested in helping to write some tests for return types, but
I'd like some clarifications about them first. Are they just
declarations that help Perl optimize stuff, or they actually contracts?
As this little script shows, both inner and of are valid syntax now
with pugs, but neither is considered an error to throw an error when the
different type is actually returned.
I'd like see it documented in exactly what cases errors should be thrown
here.
For reference, return are described here:
http://feather.perl6.nl/syn/S06.html#Return_types
demo:
sub foo of Array {
my %h = ( a = 1 );
return %h;
}
sub zoo returns Array {
my %h = ( a = 1 );
return %h;
}
# Hashes are happily returned, despite the Array return types.
my %b = foo(); say %b.perl;
my %c = foo(); say %c.perl;
named arguments: What's the signature?
Regarding The S06 description of named arguments:
http://feather.perl6.nl/syn/S06.html#Named_arguments
What I find missing here is documentation of the signature to use
if you want to declare I accept an arbitrary number of named
arguments. (Like the param() methods common in Perl5 do).
Maybe it's the slurpy hash?
sub foo (*%h) {...} ?
The spec could use some clarification on this point.
Mark
Re: named arguments: What's the signature?
Trey Harris wrote:
Slurpy parameters follow any required or optional parameters. They are
marked by a C* before the parameter:
sub duplicate($n, *%flag, [EMAIL PROTECTED]) {...}
Named arguments are bound to the slurpy hash (C*%flag
in the above example). Such arguments are evaluated in scalar context.
Any remaining variadic arguments at the end of the argument list
are bound to the slurpy array (C[EMAIL PROTECTED] above) and are evaluated
in list context.
So would this mean zero or more pairs of named arguments, or one or more:
sub foo (*%h)
I expected this:
sub foo (*%h) # one more pairs
sub foo (*%h?) # zero or more pairs
The answer with pugs now is different:
sub foo (*%h) # zero or more pairs
sub foo (%h, *%h), # one or more pairs
If pugs behavior is intended, I think it should be documented in the
spec, as I found unintuitive.
Mark
could 'given' blocks have a return value?
Sometimes I use 'given' blocks to set a value. To save repeating myself
on the right hand side of the given block, I found I kept want to do this:
my $foo = given { }
...and have whatever value that was returned from when {} or default {}
populate $foo.
It turns out pugs already allow this, through the trick of wrapping the
given block in an anonymoose sub...which is then immediately executed:
my $rm = sub { given $rm_param {
when Code { $rm_param(self) }
when Hash { %rm_paramrun_mode }
default{ self.query.param($rm_param) }
}}();
Not only do you get implicit matching on the left side, you get implicit
return values on the right!
I'd just like to be able to clean that up a little to:
my $rm = given $rm_param {
when Code { $rm_param(self) }
when Hash { %rm_paramrun_mode }
default{ self.query.param($rm_param) }
};
Mark
feedback on the draft documentation spec
Perl6::Spec::Documentation is a draft spec for documentation formats for use with Perl6. My own reading of it is that POD still exists and is supported, while a new wiki-like format kwid is added, and a framework for various dialects is supported. POD was successful for its simplicity. It was easy to learn, and since it was simple and a subset of just about everything, it was easy to translate into many formats. Kwid is an upgrade to POD that recognizes the success of wiki-like formats, which are themselves relatively simple, and are pleasantly easy to read without a kwid2SomethingElse translator. Considering just about everything but the semicolon seems to be changing from Perl5 to Perl6, I have no problem replacing POD with Kwid. POD was easy to learn, and Kwid looks easier. I'm not sold on the on the generic documentation-framework-with-dialects though. The spec opens with this: Perldoc is a documentation format specification that is completely orthogonal to the Perl 6 specification. If that's the case, what the Perl6 spec says about documentation doesn't need to stop the broader Perldoc framework project from existing or being used. I advocate what the Perl6 spec does say is that Kwid is the official documentation format of Perl6. Let simplicity succeed again. Mark Reference: http://svn.openfoundry.org/pugs/docs/Perl6/Spec/Documentation.pod
clarifying the spec for 'ref'
I noticed in pugs, 'ref' does not return 'HASH' and 'ARRAY' as Perl5
does, but returns values including 'Hash', 'Array' and 'Array::Const'.
I don't find meaningful mentions of 'HASH' and 'ARRAY' by grep'ing
docs/Perl6 (or even ref!), so I wanted to check in here about the
meaningfulness of this change.
Personally, I dislike the change from HASH to 'Hash' because it seems to
be change without a significant benefit. It's annoyingly different.
The ARRAY case is worse, because it seems I now need to write this:
if ref $a eq any('Array','Array::Const') {
If you are interested, here's code which illustrates cases when
'Array' is returned, versus 'Array::Const'
my $a = [a];
my $b = \@('b');
say ref $a;
say ref $b;
I'd like for 'HASH' and 'ARRAY' to keep working, or for the Perl6 docs
to justify the change.
Mark
clarify: does Dog is Mammal load Mammal for you?
In S12, we see a number examples of: class Dog is Mammal http://dev.perl.org/perl6/doc/design/syn/S12.html However, it's not clear if it is necessary to preload Mammal for Dog to function properly here, or what that syntax would be. Testing with current version of pugs, this doesn't happen. Adding use Mammal before this syntax seems to fix it, but doesn't seem like it should be necessary, especially since use Mammal has traditionally implied as has-a relationship. Mark
typo fix: trinary - ternary
In Perl6/Spec/Operator.pod Trinary should be Ternary. Mark
