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. P
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
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
=
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:
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 a
>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).
<"...">
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
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'
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 form
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 t
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 r
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 le
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 t
13 matches
Mail list logo
