Larry Wall wrote:
On Sat, Oct 07, 2006 at 07:49:48PM -0700, Jonathan Lang wrote:
: Another possibility: make it work. Add a "delayed" parameter trait
: that causes evaluation of that trait to be postponed until the first
: time that the parameter actually gets used in the routine. If it
: never
Before Christmas, as promised!
I have a 95% complete Perl 5 implementation of a parser for this, but it is
too large to fit in the margin. I may release the beta of that next week, once
I'm home from my travels.
Damian
-cut--cut--cut--cut--cut-
=for c
On Sat, Oct 07, 2006 at 07:49:48PM -0700, Jonathan Lang wrote:
: Another possibility: make it work. Add a "delayed" parameter trait
: that causes evaluation of that trait to be postponed until the first
: time that the parameter actually gets used in the routine. If it
: never gets used, then it
Jonathan Lang wrote:
Another possibility: make it work. Add a "delayed" parameter trait...
...although "lazy" might be a better name for it. :)
--
Jonathan "Dataweaver" Lang
Larry Wall wrote:
As a unary lazy prefix, you could even just say
s[pattern] doit();
Of course, then people will wonder why
.subst(/pattern/, doit())
doesn't work.
Another possibility: make it work. Add a "delayed" parameter trait
that causes evaluation of that trait to be postpone
Larry Wall wrote:
Jonathan Lang wrote:
: Translating this to perl 6, I'm hoping that perl6 is smart enough to let me
: say:
:
:s(pattern) { doit() }
Well, the () are illegal without intervening whitespace because that
makes s() a function call, but we'll leave that alone.
Thank you; I noti
On Sat, Oct 07, 2006 at 03:07:49PM -0700, Jonathan Lang wrote:
: S5 says:
: >There is no /e evaluation modifier on substitutions; instead use:
: >
: > s/pattern/{ doit() }/
: >
: >Instead of /ee say:
: >
: > s/pattern/{ eval doit() }/
:
: In my perl5 code, I would occasionally take advanta
Jonathan Lang skribis 2006-10-07 15:07 (-0700):
> Translating this to perl 6, I'm hoping that perl6 is smart enough to let me
> say:
>s(pattern) { doit() }
> Instead of
>s(pattern) { { doit() } }
I would personally hope that Perl isn't that clever, but treats all
bracketing delimiters the
Larry Wall wrote:
On Sat, Oct 07, 2006 at 03:28:04PM -0700, Jonathan Lang wrote:
: It's been indicated that several regex modifiers that are found in
: Perl5 are gone. That's all well and good, unless you're using the
: Perl5 modifier to port code to perl6. What happens if you're trying
: to po
On Sat, Oct 07, 2006 at 03:28:04PM -0700, Jonathan Lang wrote:
: It's been indicated that several regex modifiers that are found in
: Perl5 are gone. That's all well and good, unless you're using the
: Perl5 modifier to port code to perl6. What happens if you're trying
: to port in a regex that m
It's been indicated that several regex modifiers that are found in
Perl5 are gone. That's all well and good, unless you're using the
Perl5 modifier to port code to perl6. What happens if you're trying
to port in a regex that made use of one of the now-obsolete modifiers?
Bear in mind that there
S5 says:
There is no /e evaluation modifier on substitutions; instead use:
s/pattern/{ doit() }/
Instead of /ee say:
s/pattern/{ eval doit() }/
In my perl5 code, I would occasionally take advantage of the "pairs of
brackets" quoting mechanism to do something along the lines of:
Trey Harris writes:
> In a message dated Wed, 4 Oct 2006, chromatic writes:
>
> > The assumption I remember from the design meetings was always "No
> > library designer has the knowledge or the right to tell me how fast
> > or strict my program has to run." Whatever B&D you do in the
> > privacy
TSa wrote:
Dispatch depends on a partial ordering of roles.
Could someone please give me an example to illustrate what is meant by
"partial ordering" here?
--
Jonathan "Dataweaver" Lang
On 10/6/06, TSa <[EMAIL PROTECTED]> wrote:
HaloO,
Stevan Little wrote:
> On 10/2/06, Jonathan Lang <[EMAIL PROTECTED]> wrote:
>> This notion of exclusionary roles is an interesting one, though. I'd
>> like to hear about what kinds of situations would find this notion
>> useful; but for the mome
On 10/6/06, TSa <[EMAIL PROTECTED]> wrote:
HaloO,
Stevan Little wrote:
> As for how the example in the OP might work, I would suspect that
> "super" would not be what we are looking for here, but instead a
> variant of "next METHOD".
I'm not familiar with the next METHOD syntax. How does one ge
16 matches
Mail list logo
