Re: Common Serialization Interface
Larry Wall wrote:
On Mon, Sep 25, 2006 at 09:02:56PM -0500, Mark Stosberg wrote:
:
: eval($yaml, :lang);
:
: Still, these options may not substitute for the kind of role-based
: solution you have mind.
I'm not sure it's wise to overload eval this way. Seems like a
great way to defeat MMD. Plus I really want a file interface so I
don't have to slurp a 37M string, which in turn requires a 400M stack
allocation currently. Seems to want even more heap after that, and
then it really starts thrashing...
Not everything has to be done via MMD, of course, and more to the point,
many things can play nice with MMD.
multi sub eval(Str $data, Str :$lang) {
given $lang ->{
when 'perl' { perl_eval($data) }
when 'yaml' { yaml_eval($data) }
when 'perl5' { perl5_eval($data) }
when 'pir' { pir_eval($data) }
when 'pbc' { pbc_eval($data) }
when defined { call } # Back to MMD!
default { perl_eval($data) }
}
}
BTW: for the above, it would be nice to be able to say:
when m:i/^perl$/ {...}
without all the "noise". That is, it would be nice to have something like:
when 'perl':i {...}
Dunno if that makes any sense or not.
Re: Common Serialization Interface
On 9/27/06, Aaron Sherman <[EMAIL PROTECTED]> wrote:
BTW: for the above, it would be nice to be able to say:
when m:i/^perl$/ {...}
without all the "noise". That is, it would be nice to have something like:
when 'perl':i {...}
Well, there are a few ways to do that:
given lc $lang {...}
when { lc eq 'perl' } {...}
when insensitive('perl') {...}
Where the last one is a user-defined function which can be written:
sub insensitive($str) { /:i ^ $str $/ }
Such "pattern functions" can be useful in a variety of contexts. That
is, write functions which are designed explicitly to be used in the
conditions of when statements.
Luke
[svn:perl6-synopsis] r12466 - doc/trunk/design/syn
Author: larry
Date: Wed Sep 27 10:27:18 2006
New Revision: 12466
Modified:
doc/trunk/design/syn/S05.pod
Log:
Made directly called tokens and rules auto-anchor for readability.
Modified: doc/trunk/design/syn/S05.pod
==
--- doc/trunk/design/syn/S05.pod(original)
+++ doc/trunk/design/syn/S05.podWed Sep 27 10:27:18 2006
@@ -14,9 +14,9 @@
Maintainer: Patrick Michaud <[EMAIL PROTECTED]> and
Larry Wall <[EMAIL PROTECTED]>
Date: 24 Jun 2002
- Last Modified: 21 Aug 2006
+ Last Modified: 27 Sept 2006
Number: 5
- Version: 33
+ Version: 34
This document summarizes Apocalypse 5, which is about the new regex
syntax. We now try to call them I rather than "regular
@@ -332,6 +332,23 @@
to imply a C<:> after every construct that could backtrack, including
bare C<*>, C<+>, and C quantifiers, as well as alternations.
+The C<:ratchet> modifier also implies that the anchoring on either
+end is controlled by context. When a ratcheted regex is called as
+a subrule, the front is anchored to the current position (as with
+C<:p>), while the end is not anchored, since the calling context
+will likely wish to continue parsing. However, when a ratcheted
+regex is called directly, it is automatically anchored on both ends.
+(You may override this with an explicit C<:p> or C<:c>.) Thus,
+you can do direct pattern matching using a token or rule:
+
+$string ~~ token { \d+ }
+$string ~~ rule { \d+ }
+
+and these are equivalent to
+
+$string ~~ m/^ \d+: $/;
+$string ~~ m/^ \d+: $/;
+
=item *
The new C<:panic> modifier causes this regex and all invoked subrules
Re: Common Serialization Interface
On Wed, Sep 27, 2006 at 10:43:00AM -0600, Luke Palmer wrote:
: Well, there are a few ways to do that:
:
:given lc $lang {...}
:
:when { lc eq 'perl' } {...}
:
:when insensitive('perl') {...}
With the latest change to S05 that auto-anchors direct token calls,
you can now alo write:
when token { :i perl } {...}
By the way, your 0-ary "lc" needs to be written ".lc" these days.
In Chicago we outlawed most of the 0-or-1-ary functions since we now
have a 1-character means of specifying $_ as invocant.
: Where the last one is a user-defined function which can be written:
:
:sub insensitive($str) { /:i ^ $str $/ }
:
: Such "pattern functions" can be useful in a variety of contexts. That
: is, write functions which are designed explicitly to be used in the
: conditions of when statements.
I guess that can also now be written:
my &insensitive ::= token ($str) :i { $str };
or maybe even
my &insensitive ::= token :i { $^str };
Larry
RFC: multi assertions/prototypes: a step toward programming by contract
Executive summary:
I suggest a signature prototype that all multis defined in or exported
to the current namespace must match (they match if the proto would allow
the same argument list as the multi, though the multi may be more
specific). Prototypes are exportable. Documentation tie-ins are also
suggested, ultimately allowing for documentation-only interface modules
which collect and re-export the interfaces of implementation modules
while providing high-level documentation and constraints.
Details:
Larry has said that programming by contract is one of the many paradigms
that he'd like Perl 6 to handle. To that end, I'd like to suggest a way
to assert that "there will be multi subs defined that match the
following signature criteria" in order to better manage and document the
assumptions of the language now that methods can export themselves as
multi wrappers. Let me explain why.
In the continuing evolution of the API documents and S29, we are moving
away from documentation like:
our Scalar multi max(Array @list) {...}
our Scalar multi method Array::max(Array @array:) {...}
toward exported methods:
our Scalar multi method Array::max(Array @array:)
is export {...}
"is export" forces this to be exported as a function that operates on
its invocant, wrapping the method call. OK, that's fine, but Array isn't
the only place that will happen, and the various exported max functions
should probably have some unifying interface declared. I'm thinking of
something like:
our proto max(@array, *%adverbs) {...}
This suggests that any "max" subroutine defined as multi in--or exported
to--this scope that does not conform to this prototype is invalid. Perl
will throw an error at compile-time if it sees this subsequently:
our Any multi method Array::max(Array @array: $x)
is export {...}
However, this would be fine:
our Any multi method Array::max(Array @array: :$x)
is export {...}
because the prototype allows for any number of named parameters.
The default behavior would be to assume a prototype of:
our proto max([EMAIL PROTECTED], *%namedargs) {...}
Which allows for any signature.
Any types used will constrain multis to explicitly matching those types
or compatible types, so:
our Int proto max(Seq @seq, *%adverbs) {...}
Would not allow for a max multi that returned a string (probably not a
good idea).
The goal, here, is to allow us to centrally assert that "Perl provides
this subroutine" without defining its types or behavior just yet.
Documentation/code could be written for the prototype:
=item max
=inline our proto max(@array, *%adverbs) is export {...}
C takes an input sequence or array (C<@array>) and
returns the maximum value from the sequence.
Specific implementations of max may be defined which
allow comparators or other adverbs (C<%adverbs>) to
be defined.
=cut
I've invented the "=inline" POD keyword here as an arm-wave to
programming by contract (both Perl and POD read its argument). If it's
not liked, the proto could be duplicated both inside and outside of the
documentation as we do now. Kwid, when it comes to pass, could provide
similar mechanisms. Given this, an entire "interface-only" module could
exist as POD/Kwid-only, which isn't a bad thing given that pre-processed
bytecode will be what most people are loading anyway, and thus not
parsing the POD every time as in Perl 5.
There's also another interesting thing that we might or might not decide
to tack onto protos, which is that the "is export" tag on one could
cause the exporter mechanism to automatically export any "is export"
tagged subroutines from the current namespace that match this prototype,
even if they came from a different namespace. Essentially defining one
proto allows you to re-export any multis that you imported by that name.
This seems to me to be a better mechanism than a simple :REEXPORT tag or
the like on the "use", as it more explicitly targets the interfaces that
your module defines its own prototype for.
This produces a generic set of documentation for a module that might
only act as a re-exporter for other modules. e.g. the above might appear
in a module called CORE which is "use"d by the runtime automatically,
and uses various other modules like Math::Basic and List without any
explicit export tags, thus providing the minimal interfaces that Perl
promises. S29 could eventually be adapted as the documentation for the
prototypes in that module without having to actually document the
individual APIs of the rest of the Perl runtime.
In Perl 6, therefore, "perldoc perlfunc" would become "perldoc CORE" or
whatever we call that module.
This is only a first step to programming by contract, which has many
more elements than simply blending signatures into docume
special named assertions
>From an IRC conversation earlier today: A quick scan of S05 reveals definitions for these seven special named assertions: <'...'> Twenty-four more are listed in docs/Perl6/Overview/Rule.pod (some of which are used in S05, but I don't think there are definitions). <"..."> # not sure if this counts Additionally, in t/regex/from_perl6_rules/stdrules.t there is one I didn't notice elsewhere, but appears to be implemented in Pugs: As far as I can tell, this yields a total of 31 or 32 special named assertions. I'm sure if I have missed any obvious ones, someone will speak up. Some have passing tests, some have failing tests, and some have no tests. Does it make sense to have a single place in S05 where all the builtin special named assertions are defined? It would make it easier to link the tests, and to tell the difference between examples like and builtins like . Last, but not least, should any of these be crossed off the list? Best, David.
Re: Motivation for /+/ set Array not Match?
Audrey (>): Indeed... Though what I'm wondering is, is there a hidden implementation cost or design cost of making /+/ always behave such that $.from returns something, compared to the current treatment with the workaround you suggested? Has this been settled or addressed off-list? Because from my perspective as one who has never used P6 rules for anything in particular, but who in the future most likely will, the proposed semantics seems a lot saner and more useful. It'd be sad to let pass this opportunity to fix (what from my perspective appears to be) a shortcoming of the rule semantics. Kindly, -- masak
Re: RFC: multi assertions/prototypes: a step toward programming by contract
In a message dated Wed, 27 Sep 2006, Aaron Sherman writes: Any thoughts? I'm still thinking about the practical implications of this... but what immediately occurs to me: The point of multiple, as opposed to single, dispatch (well, one of the points, and the only point that matters when we're talking about multis of a single invocant) is that arguments are not bound to a single type. So at first gloss, having a single prototype in the core for all same-named multis as in your proposal seems to defeat that use, because it does constrain arguments to a single type. I would hate for Perl 6 to start using C or C in the sort of ways that many languages abuse "Object" to get around the restrictions of their type systems. I think that, as a rule, any prototype encompassing all variants of a multi should not only specify types big enough to include all possible arguments, but also specify types small enough to exclude impossible arguments. In other words, to use your proposal, "our proto moose (Moose $x:)" should assert not just that all calls to the multi moose will have an invocant that does Moose, but also that all objects of type Moose will work with a call to the multi moose. That may have been implicit in your proposal, but I wanted to make it explicit. In practice, the ability to use junctive types, subsets, and roles like any other type makes the concept of "single type" a much less restrictive one in Perl 6 than in most languages. For example, if you wanted C to work on both arrays and hashes, you could have our proto max (Array|Hash $container) Or you could define an C role that both Array and Hash do and have: our proto max (Indexed $container) So maybe this is a reasonable constraint. But it seems odd to me that Perl might then not allow me to write a C that takes, say, Bags or Herds or whatever. And as I said before, I think a prototype of our proto max (Whatever $container) is incorrect too. What I really want is for max to be callable on anything that can do max, and not on anything that can't. Following that observation to its logical conclusion, at some point we get to the core containing prototypes like: our proto max(Maxable $container) our proto sort(Sortable $container) our proto keys(Keyable $container) which (I think) results in no better support for contracts, but merely requires gratuitious typing (in both senses of the word): where before we could just write our routine "multi max...", now we need to write both "multi max..." and remember to add "does Maxable" so Perl will let us compile it. My apologies if I'm attacking a strawman here; perhaps there's a saner way to allow the flexibility for users to define novel implementations of global multis while still having the prototypes well-typed. All that said, the globalness of multis does concern me because of the possibility of name collision, especially in big systems involving multis from many sources. Your proposal would at least make an attempt to define a multi not type-conformant with a core prototype throw a compile-time error, rather than mysterious behavior at runtime when an unexpected multi gets dispatched. Trey
Re: special named assertions
On Wed, Sep 27, 2006 at 11:59:32AM -0700, David Brunton wrote: > A quick scan of S05 reveals definitions for these seven special named > assertions: > [...] I don't think that <'...'> or <"..."> are really "named assertions". I think that (as well as <+xyz> and <-xyz>) are simply special forms of the named assertion . I should probably compare your list to what PGE has implemented and see if there are any differences -- will do that later tonight. Pm
Re: special named assertions
The documentation should distinguish between those that are just pre-defined characters classes (E.G., and ) and those that are special builtins (E.G., and . The former are things that you should be freely allowed to redefine in a derived grammar, while the other second type may want to be treated as reserved, or at least mention that redefining them may break things in surprising ways. -- Mark Biggar [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- Original message -- From: "Patrick R. Michaud" <[EMAIL PROTECTED]> > On Wed, Sep 27, 2006 at 11:59:32AM -0700, David Brunton wrote: > > A quick scan of S05 reveals definitions for these seven special named > assertions: > > [...] > > I don't think that <'...'> or <"..."> are really "named assertions". > > I think that (as well as <+xyz> and <-xyz>) are simply special forms > of the named assertion . > > I should probably compare your list to what PGE has implemented and see if > there are any differences -- will do that later tonight. > > Pm >
Re: special named assertions
On Wed, Sep 27, 2006 at 09:12:02PM +, [EMAIL PROTECTED] wrote: > The documentation should distinguish between those that are just > pre-defined characters classes (E.G., and ) and > those that are special builtins (E.G., and . > The former are things that you should be freely allowed to redefine > in a derived grammar, while the other second type may want to be > treated as reserved, or at least mention that redefining them may > break things in surprising ways. FWIW, thus far in development PGE doesn't treat and as "special built-ins" -- they're subrules, same as and , that can indeed be redefined by derived grammars. And I think that one could argue that redefining or could equally break things in surprising ways. I'm not arguing against the idea of special builtins or saying it's a bad idea -- designating some named assertions as "special/non-derivable" could enable some really nice optimizations and implementation shortcuts that until now I've avoided. I'm just indicating that I haven't come across anything yet in the regex implementation that absolutely requires that certain named assertions receive special treatment in the engine. Thanks, Pm > -- Original message -- > From: "Patrick R. Michaud" <[EMAIL PROTECTED]> > > On Wed, Sep 27, 2006 at 11:59:32AM -0700, David Brunton wrote: > > > A quick scan of S05 reveals definitions for these seven special named > > assertions: > > > [...] > > > > I don't think that <'...'> or <"..."> are really "named assertions". > > > > I think that (as well as <+xyz> and <-xyz>) are simply special forms > > of the named assertion . > > > > I should probably compare your list to what PGE has implemented and see if > > there are any differences -- will do that later tonight. > > > > Pm > > > > >
Re: RFC: multi assertions/prototypes: a step toward programming by contract
Minor nitpick:
Any types used will constrain multis to explicitly matching those types
or compatible types, so:
our Int proto max(Seq @seq, *%adverbs) {...}
Would not allow for a max multi that returned a string (probably not a
good idea).
IIRC, perl 6 doesn't pay attention to the leading Int here except when
dealing with the actual code block attached to this - that is, "Int"
isn't part of the signature. If you want Int to be part of the
signature, say:
our proto max(Seq @seq, *%adverbs -> Int) {...}
More to the point, I _could_ see the use of type parameters here
(apologies in advance if I get the syntax wrong; I'm going by memory):
our proto max(Seq of ::T [EMAIL PROTECTED], *%adverbs -> ::T) {...}
This would restrict you to methods where the return type matches the
list item type.
--
Jonathan "Dataweaver" Lang
Re: RFC: multi assertions/prototypes: a step toward programming by contract
Trey Harris wrote: In a message dated Wed, 27 Sep 2006, Aaron Sherman writes: Any thoughts? I'm still thinking about the practical implications of this... but what immediately occurs to me: The point of multiple, as opposed to single, dispatch (well, one of the points, and the only point that matters when we're talking about multis of a single invocant) is that arguments are not bound to a single type. So at first gloss, having a single prototype in the core for all same-named multis as in your proposal seems to defeat that use, because it does constrain arguments to a single type. I certainly hope not, as I agree with you! That's not the goal at all, and in fact if that were a side effect, I would not want this to be implemented. The idea of having types AT ALL for protos was something that I threw in because it seemed to make sense at the end. The really interesting thing is to match signature shapes, not types. That is, max doesn't take two positional arguments, and a max that does is probably doing something that users of max will be shocked by. To this end, a programmer of a library *can* issue an assertion: all implementations of max will take one (no type specified) positional parameter and any number of adverbial named parameters (again, no type specified). Notice that I keep saying "no type specified", when in reality, us Perl 6 programmers know that parameters default to type Any (it is Any now, right?) I don't see value in protos taking this into account. If there is value, then I'll bow to superior Perl 6 mojo on the part of whoever can point it out. Remember that this is NOT part of the MMD system. Once a multi is declared, and passes any existing protos, the proto no longer has any relevance, and is never consulted for any MMD dispatch. It is forgotten (unless a new multi is defined later). Does that help to remove any concerns? Adding in types is fine, and I have no problem with it, but adding in types should probably not be something done in core modules without heavy thought. In other words, to use your proposal, "our proto moose (Moose $x:)" should assert not just that all calls to the multi moose will have an invocant that does Moose, but also that all objects of type Moose will work with a call to the multi moose. That may have been implicit in your proposal, but I wanted to make it explicit. If you specify such types, OK, that seems fair. Side point: "the multi moose" is a pretty darned funny turn of phrase ;) All that said, the globalness of multis does concern me because of the possibility of name collision, especially in big systems involving multis from many sources. Your proposal would at least make an attempt to define a multi not type-conformant with a core prototype throw a compile-time error, rather than mysterious behavior at runtime when an unexpected multi gets dispatched. Say "signature-conformant" there, and I'm in full agreement.
