> You're confusing brevity of declaration
> with brevity of use.
One needs sufficient brevity of both call
and declaration syntax if the mechanism's
brevity is to be of use in short scripts.
> Making (limited) circumvention of [$_'s
> lexicality] depend on a verbose and
> explicit syntax will he
> > method f ($self : $a) { ... }
> > sub f ($a) is given ($line) { ... }
> >
> > what do you call $self
>
> The "invocant".
>
> > and $line?
>
> A lexical variable that happens to be
> bound to the caller's topic.
The "invokit" perhaps?
> placeholders create subroutines, not method
> "access caller's topic" is an unrestricted
> licence to commit action at a distance.
Right.
Perhaps:
o There's a property that controls what subs
can do with a lexical variable. I'll call
it Yours.
o By default, in the main package, topics are
set to Yours(rw); other lexicals are s
> My complete knowledge comes from
> archive.develooper.com/perl6-language...
> (search for "superpositions").
I find google (rather than develooper's
archive/search) the best tool for most
searching of p6lang. Unfortunately even
google only goes back so far, and doesn't
search punctuation.
Perl
Larry:
> > sub bar(; $foo = ) {...}
Damian:
> topic [would be] C.
I assumed implied an 'is given'.
I don't see why it couldn't.
Damian:
> Hm. Given that the topic is in some sense
> a property of the lexical scope of the subroutine
> body, this might be a possibility:
>
> sub bar($foo i
> > my sub foo ($_ = $_)
> >
> > to just propagate the outer $_ inward.
>
> That only works when $_ can somehow be
> shoe-horned into the parameter list.
> Whereas:
>
>my sub foo is given($_)
>
> works for *any* parameter list.
Other than the placeholder situation, I
don't understa
> > don't understand when one could do the
> > 'is given($_)' and not do the ($_ = $_).
>
> Any time that the caller's topic isn't
> supposed to be explicitly passed as an
> argument, but is still used within the
> subroutine.
>
> [example]
>
> And, yes, I could make it an optional
> argument, but
> >> $_ # current topic
> >> $__ # outer topic
> >> $___ # outer outer topic
>
> [not sufficiently visibly distinct]
> [too much anyway]
Agreed.
Returning to the topic of binding/copying
from a caller to a callee, what about using
square brackets to mark implicit args
> c) the ability to break lexical scope
Well, I could argue that c) already exists
in the form of passing parameters in parens.
Of course, that doesn't feel like "breaking"
anything.
So instead I'll argue that the word "break"
is perhaps prejudicially perjorative.
I'd say, to steer away from be
> inheriting a caller's topic isn't going to be
> that common a thing that it needs such a short
> name, is it?
15% of the perl 5 builtins do so.
I have suggested that, in some extreme
scenarios such as short scripts, perhaps
as many as 50% of subs might do so. But
then again I probably ate a lot
> > Elements of this shared vocabulary might be
> > called 'locals' or 'yours'.
>
> I like the 'yours' idea from the point of
> view of the callee:
>
> my $inherited = your $_;
I like that syntax, but I'm uncomfortable
with an underlying principle, which is that
one can reach in to the ca
> # I'm uncomfortable [that]
> # one can reach in to the caller's lexical
> # context from any place in a callee's body.
>
> We need that capability if we're going to
> have lexically-scoped exports:
I think I was a bit careless in how I worded
that.
My problem is not that one reaches in to the
c
> # I am thinking one should have to predeclare
> # in a sub's preamble that such a trick will
> # be going on.
> #
> # Thus something like:
> #
> # sub foo [&bar] { ... }
> #
> # is (part of what is) required to be allowed
> # to create a bar sub in the context of the
> # caller of foo.
>
>
> $_ = 1; mumble { $_ = 2 }; print;
>
> will print 1 or 2?
Least surprise, visually, is obviously 2.
This would be true if bare blocks (even
those passed as args) just pick up from
the surrounding lexical context. And if
that were true, mumble presumably could
not do anything about this (wit
special beyond establishing
a nested lexical scope:
$_ = 1; { $_ = 2 }; print; # 2
whereas '->' means the topic gets set and is
private to the block (ignoring aliasing effects):
$_ = 1; for @foo -> $_ { $_ = 2 }; print; # 1
It seems to me that a logical conclusion wou
> > Are you suggesting this?
> >
> > if($error) {
> > use visible '&croak';
> > require Carp;
> > import Carp: 'croak';
> > croak($error);
> > }
>
> No - that would be pointless as well as error-prone.
>
> My idea of "visible" is that it would make a lexically scoped thing
> accessible to an inn
First, I'd like to confirm I've understood
C and C right:
1. C dynamically scopes changes to a
variable's value to the enclosing block.
It does not dynamically scope the name.
The variable can obviously be a global.
It can also make sense if it is lexical.
Is the latter currently al
> [temp]
> [implicit args]
Here's a snippet of conversation on a
haskell list about implementation of
implicit args : http://tinyurl.com/2ym1
--
ralph
In summary, I am proposing that one marks
variables that are to be automatically
passed from sub to sub with 'is yours'
where appropriate.
An example of what I'm suggesting follows.
Code with brief comments first then explanation.
{
my $_; # $_ can't be touched
> you propose a mechanism of passing [vars]
> between desired subroutins by default
> through all the dynamical chain of sub
> calls "connecting them.
There's more, or rather, less to it than that.
The same mechanism also includes a clean way
to pass "it", something that needs to be done.
And a
> 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
"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 - 138 of 138 matches
Mail list logo
