> I like more "shared" instead of "yours"
But that's because that's the way you are
thinking about the problem/solution.
I'm just talking about a very local trick
of having autoargs instead of explicitly
passing args in parens. The fact that this
ends up creating an elegant alternative to
dangero
Warning: I just watched The Wizard Of Oz
for the first time tonight.
> $x is yours
>
> tells that $x is aliased to variable in
> some "secret scope symbol table" that
>( the table ) is shared between caller
> and callee
The "secret" place is MyYourca, a Subterranean
island. People think it's an
Thanks for the clear answers.
Larry:
> I think that currying should be extended to
> handle any caller-instituted defaulting.
Argh. So obvious! (So of course I missed it.)
> Basically, the parameter list of the subroutine
> is already providing a limited namespace to be
> shared by caller and c
Larry's earlier response means this 'yours'
idea is history, but for closure, yes, this
seems to be headed in the right direction,
at least in theory. It may have even been
practical to implement it thru the standard
property mechanism.
> so these two are equivalent ???
>
> {
> my $x is yours ;
>
I'm sorry, but I gotta get back on the
no-global grail trail for at least one
more post.
> The granularity [of currying] can be
> controlled on a sub-by-sub or on a
> class-by-class basis.
If one could do something like this:
{
my $src = 'oldname1';
my $dest = 'newname1';
use FileUt
> Dynamic scoping (take 2)
> ... a system of implicit argument passing ...
> Larry pointed out [an error about threads]
The system of implicit argument passing was
intended to eliminate the need to use globals.
I was wrong about threads but that doesn't
change my view that globals are mostly evil
Michael said:
> I worry that C sounds too much like
> something class-related
'Classify' also seems wrong if some items are
thrown away. I like 'part':
(@foo,@bar) := part { ... } @source;
Headed off in another direction, having a sub
distribute its resul
> push (/foo/ && @foo ||
> /bar/ && @bar ||
> /zap/ && @zap), $_ for @source;
Presumably, to avoid run time errors, that
would need to be something like:
push (/foo/ && @foo ||
/bar/ && @bar ||
/zap/ && @zap ||
@void), $_ for @source;
> But perhaps...
>
>
> > [regarding -> as a left-to-right pipe-like operator]
>
> '->' isn't (in my mind) "a left-to-right
> flow/assignment operator." It's a unary
> operator, synonymous with "sub" without
> parens required around the argument list.
You seem to be forgetting:
given $foo -> $_
and cousins.
--
r
-> $_ { ... }
> given $foo sub { ... }
>
> Are all equivalent (if sub topicalizes its
> first parameter).
Oh. Now I understand C<->> rather differently!
The left-to-right flow/assignment viewpoint
had worked for me as an (incorrect) way to
interpret C<->>
> suggest using >> instead of -> for now,
> as a placeholder.
I like it as the real thing too. It stands
out better in a line, among other advantages.
>@source >> @out;# 'map' or 'assignment'-like
>@source >> grep { /foo/ } >> @out; # object-method-like
Yes, several
How would one most nicely code what I'll call
a lazy pipeline, such that the first result
from the final element of the pipeline can
appear as soon as the first result has been
processed from the intervening elements?
--
ralph
>given baz(@args) { return $_ when defined }
>given baz(@args) { return $_ when $_ > 0 }
Sweet.
Shouldn't the latter example be:
given baz(@args) { return $_ if $_ > 0 }
In general, if a C condition clause contains
a C<$_>, chances are good that it's a mistake, right?
If a pipe short
> A better fitting solution wouldn't focus on classic
> MMD, but simply "Dispatch", where type- and value-based
> dispatching are two of many kinds of dispatching supported.
I've always liked the sound of Linda's tuple spaces
and view that as a nice generalized dispatch approach.
Procedure calls
> A better fitting solution wouldn't focus on classic
> MMD, but simply "Dispatch", where type- and value-based
> dispatching are two of many kinds of dispatching supported.
I've always liked the sound of Linda's tuple spaces
and view that as a nice generalized dispatch approach.
Procedure calls
> [concerns over conflation of post-processing and post-assertions]
Having read A4 thoroughly, twice, this was my only real concern
(which contrasted with an overall sense of "wow, this is so cool").
--me
once at the time POST does.
Personally I'd leave this out until it became clear, well
past p6.0, whether it was really worth it, but it seems
worth mentioning.).
--me
icitly break
> out of a topicalizer, it should not be last. I'd suggest break!
> So it looks to me like we need a break.
I'm glad Larry didn't suggest 'done', because I really enjoyed Apo4.
I'll suggest it instead.
> I also happen to think that Exception i
lock you write clean up code that frees some
resources. If you inherit from that method, and do not
inherit the LAST block, then you've got a leak. This is
obviously a mild example.
--me
ited and the code
is not. One can optionally not inherit the conditions
(at least preconditions, from another post I just read).
And one can optionally inherit the code (by calling it).
Right?
Btw, are you going to have an equivalent of super?
--me
> [final, private]
I detest what these modifiers have done to me
in the past. They seem very unperlish to me.
, then one could type:
LAST: {
or
last: {
--me
"Non-yet-thrown exceptions must be a useful concept."
This is a bullet point from a list in Apo4 introducing
coverage of exception handling. Was Larry talking
about an exception object that hasn't yet been thrown?
Did he refer to this issue again anywhere else in the Apo?
--me
> But suppose you want all .foo to refer to self and not
> to the current topic.
What about
given (self) { }
Also, what about
use invocant;
resulting in all method bodies in scope getting an implied
surrounding given (self) { }.
And what about 'me' or
> The following syntaxes have been seen:
>
> foo()
> .foo()
> ..foo() ## rejected because ".." is different binary op
> class.foo()
> FooClass.foo()
> ::foo()
> Package::foo()
> $foo()
> $_.foo()
With a nod to Piers, and with apologes if this is silly in
the context of Perl 6 syntax, wh
Let me see if I understand the final version of your (Mike's)
suggestions
and where it appears to be headed:
Backwards compatibility:
perl5 extended syntax still works in perl6 if one happens to use it.
Forward conversion:
Automatic conversion of relevant perl5 regex syntax to perl6 is s
g to Larry, run time properties will most often be used
to contradict a built-in or compile time property. If he is right
about the dominant case being a contradiction, 'but' works
better for me than anything else I can think of, including 'now'
(explained below).
-
Even if
> [2c. What about ( data) or (ops data) normally means non-capturing,
> ($2 data) captures into $2, ($foo data) captures into $foo?]
which is cool where being explicit simplifies things, but
ain't where implicit is simpler. So, maybe add an op ('$'?)
or switch that makes parens capturing by d
> Very nice (but, I assume you meant {$foo data})!
I didn't mean that (even if I should have).
Aiui, Mike's final suggestion was that parens end up
doing all the (ops data) tricks, and braces are used
purely to do code insertions. (I really liked that idea.)
So:
Perl 5Perl6
(data)
> /pat/i m:i/pat/ or // or even m ???
Why lose the modifier-following-final-delimiter
syntax? Is this to avoid a parsing issue, or
because it's linguistically odd to have a modifier
at the end?
> /^pat$/m /^^pat$$/
What's the mnemonic here? It feels the wrong
way round -- like a single
Larry said:
> I haven't decided yet whether matches embedded in
> [a regex embedded] closure should automatically pick
> up where the outer match is, or whether there should
> be some explicit match op to mean that, much like \G
> only better. I'm thinking when the current topic is a
> match state
> : I'd expect . to match newlines by default. For a . that
> : didn't match newlines, I'd expect to need to use [^\n].
>
> But . has never matched newlines by default, not even in grep.
Perhaps. But:
First, I would have thought you *can't* make . match newlines
in grep, period. If so, then whe
> > : I'd expect . to match newlines by default.
I forgot, fourth, this simplifies the rule for . -- it
would become period matches any char, period.
Fifth, it makes the writing of "match anything but
newline" into an explicit [^\n], which I consider a
good thing.
Of course, all this is minor s
> when matching against something like "foo\nwiffle\nbarfoo\n"
>/(foo.*)$/ # matches the last line
/(foo[^\n]*)$/ # assuming perl 6 meaning of $, end of string
>/(foo.*)$/m # matches the first line
/(foo[^\n]*)$$/ # assuming perl 6 meaning of $$, end of line
or
/(foo.*?
[modified repost due to warnock's dilemma]
Would something like these DWIM?
# match pat1 _ pat2 and capture pat2 match:
/ pat1 { ($foo) = / pat2 / } /
# match pat1 _ 'foo bar':
/ pat1 { 'foo bar' } /
# match pat2 if not pat1
/ { ! /pat1/ } pat2 } /
# match pat2 if
I'm basically sold on Damian's conclusions. On the other
hand the 'otherwise' clause still feels to me like a CAPITALS
block.
So, as a tweak, I suggest:
while condition() {
...
}
NONE {
...
}
--
ralph
> : Would something like these DWIM?
> :
> : # match pat1 _ pat2 and capture pat2 match:
> : / pat1 { ($foo) = / pat2 / } /
>
> Yes
So a match in a closure starts where the outer match
was. Simple enough.
Will:
# match pat1 _ pat2 _ pat3 and capture pat2 match:
/ pat1 { ($foo)
"John M. Dlugosz" wrote:
> Carl Mäsak cmasak-at-gmail.com |Perl 6| wrote:
> > Pm (>):
> >
> > > In Rakudo's case, we just haven't implemented read-only traits
> > > on variables yet.
> >>
> >
> > Goodie. I guessed as much.
> >
> >
> >> But yes, I expect that it will be caught as
> > > a
"Carl Mäsak" wrote:
> > What is the point of marking things readonly if you can turn it off?
>
> There are many possible reasons, I think.
>
> * The code that declares the variable readonly might not be available
> to you (compiled to bytecode, fetched by RCP etc),
> * or it might be available b
t also will optimize access to finals, despite
> ] the fact that it's actually unsafe to do so.
I'm pleased to note that you made my point for me.
Sure, you can sneak in under the covers of the JVM and compromise the
immutability of its final data. But you do have to sneak in. And wh
101 - 140 of 140 matches
Mail list logo
