Re: Compile-time checking of assignment to read-only variables (Re:MMD distances)
"Carl Mäsak" wrote: > ] Oh, but it gets even better: it turns out they didn't really have to > ] sneak in through native code anyway, at least as far as the JVM is > ] concerned, since the JVM treats final variables as always writable > to ] the class they're defined in! There's no special case for > ] constructors: they're just always writable. The javac compiler, on > ] the other hand, pretends that they're only assignable once, either > in ] static init code for static finals or once per constructor for > ] instance variables. It 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 when you do, and things go belly up in interesting ways, or worse continue to run but produce mysteriously wrong output, don't go running to blame either the Java spec or the JVM. Their writers made their optimisations, and the proofs of correctness of those optimisations, and proof of correctness of the entire system, based upon the specification of final. You hack it. Your problem. But, if you add *is ro* to the P6 spec and then specify a way for users to ignore or turn it off, and you render it entirely worthless. Indeed it's worse than worthless because it is extra complication for no benefit. If it doesn't allow the compiler writeres to make any extra assumptions, it's just tying up space in symbol tables, consuming cycles in the parser, and most damningly, mindspace in the spec and users. If you add it to the spec. Mean it. If you don't mean it, don't add it. If you mean it, but it doesn't initially get implemented that's fine. Someday it might and someday we might benefit from it. Add it to the spec whilst offering a way to ignore it and you've wasted everyones time. b. --
Re: Compile-time checking of assignment to read-only variables (Re:MMD distances)
"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 but used by other clients which expect the > variable to be read-only. > * You might be writing a one-time hack, which can be done the easy way > by turning off read-only checking. > * You might be writing test code, which is greatly simplified by your > just reaching in an changing the damn thing. > > In short, I have no problem with _turning off_ read-only checking. > That, I think, can be done on a suit-yourself basis. > > I'm arguing for having read-only checking at compile level (which > everyone seemingly agrees on), and spec-requiring of a compiler to > check this (and here opinions divide). > > // Carl And that pretty much sums up about half of the traffic on this list. Speculative considerations of theoretically possible scenarios without any consideration of whether they would ever actually arise. Or be useful if they did. The result is a spec so complex that there is almost no chance of verification against it, even if enough people understand the intersection between all the speculative what-ifs and the few more concrete 'will's and 'must be's, to actually come close to implementing it. Perl made it's name by adopting the useful, pragmatic parts of other languages, and leaving out all the abstract, purely theoretical and only useful to one-legged, six-fingered theologians on wet Wednesdays in October. Sometimes it's a good idea to return to the beginning and ask yourself why do we want this feature in the first place. What does adding the ability to mark variables or parameters RO by the programmer using the language? In Perl 5, people are beginning to jump through hoops in order to achieve encapsulation that cannot be subverted. Giving module/subroutine users the ability to ignore the authors mutability annotations makes them worthless. What does adding the default assumption that subroutine or method parameters are RO buy the language implementor? This provision could be used my the language implementor to achieve some extra level of efficiency by allowing them to hoist RO values into registers; avoid locking of RO values in threaded environments; perform compile-time constant folding and expression substitutions (term-rewriting); and similar. The moment you allow the RO annotations to be overridden at either compile-time or runtime, those optimisations go out the window. In other words, if you allow RO annotations to be overridden, all the benefits that could accrue from having them go out the window, so you might as well simplify everyones life and discard them all together. Now maybe that's the way to go. Historically, the few places where the readonly attribute is applied in Perl 5 it tends to create anomalies and rarely improves performance. But if you are serious about providing the facility, don't go screwing it up for the benefit of the six guys in the world that could count their number on one hand, on one of four days a year when the sun might shine anyway. b. --
Re: Compile-time checking of assignment to read-only variables (Re:MMD distances)
"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 compile-time error. > >> > > > > And do you agree it's reasonable to expect this of every compiler? > > > > // Carl > > > > > I think that is the point of declared types. But, something like > > no strong_type_check :rw > > in scope can turn that off, in case you want to play dirty tricks. What is the point of be able to mark things readonly if the compiler does reject assignment attempts? What is the point of marking things readonly if you can turn it off? --
Re: Multimethod dispatch?
> 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 are thrown into a tuple space, then other (mop) code grabs one or more tuples and dispatches them. Grep like code is used for the grabbing. -- ralph mellor
Re: Multimethod dispatch?
> 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 are thrown into a tuple space, then other (mop) code grabs one or more tuples and dispatches them. Grep like code is used for the grabbing. -- ralph mellor
Re: Conditional Cs?
>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-circuited would one be able to do:
foo==> baz;# do pipe iff foo is true
baz(@args) ==> return; # if LHS true, return it
?
(If you wanted a pipe to NOT short-circuit you would
have to use another pipe operator, say:
foo ==>> baz; # always do pipe
foo ===> baz; # many possible syntaces
The mnemonic would be that the shorter pipe does
short-circuiting. Or use an adverb:
foo ==> :always baz; # always do pipe)
--
ralph
how to code a lazy pipeline?
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
Re: right-to-left pipelines
> 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 issues arise.
First, I don't think it's necessary to allow
a variable (or variables) to be anywhere other
than the front of a chain.
@var = [var|code] >> code >> code;
Second, it would be nice to allow a pipeline
element to pass the LHS, and invoke the RHS,
in one of two ways: iterated or not. If this
were to be done implicitly, perl (and humans)
would have to parse the whole pipeline from
the right to left, defeating the point of a
l2r pipeline syntax in the first place. So,
iteration would need to be invoked explicitly.
Perhaps something like:
@var = for @source >> /foo/ >> sort;
--
ralph
Re: Fw: right-to-left pipelines
> > > '->' 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.
> >
> given $foo -> $_ { ... }
> 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<->> when used with C et al.
So, I guess I'm suggesting a binary C<->> that
really is a left-to-right flow/assignment op
so that:
@data
-> grep { $_ > 0 }
-> sort { $^b <=> $^a }
-> part [/foo/, /bar/]
-> @foo, @bar;
does what you'd expect.
--
ralph
Re: Fw: right-to-left pipelines
> > [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. -- ralph
Re: purge: opposite of grep
> 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...
>
> ( @foo, @bar, @zap) :=
> part { /foo/ => 0, /bar/ => 1, /zap/ => 2 }, @source;
Why not:
part ( @source, /foo/ => @foo, /bar/ => @bar, /zap/ => @zap );
or maybe:
@source -> /foo/ => @foo, /bar/ => @bar, /zap/ => @zap;
To end up with @foo entries being *aliases* of
entries in @source. Btw, could these be valid,
and if so, what might they do:
@source -> $foo, $bar;
@source -> @foo, @bar;
--
ralph
Re: purge: opposite of grep
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 results like this reminds me of:
... -> ...
Can arrays on the rhs of a -> ever mean
something useful?
--
ralph
Anti-globalization (was Re: This week's summary)
> 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. > Larry went on to discuss some rather > splendid extensions of the currying concept: > >use Dog.assuming(tail => "cut short", ears => "cut_long") >my $little_dog = Dog.where_oh_where(); > > Which is rather cute. Indeed. Currying looks like an ideal route to eliminate the need for globals, but it needs to be extended beyond what Larry has so far mentioned to pull that off. -- ralph
Re: Dynamic scoping (take 2)
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 FileUtils.default($src, $dest);
# FileUtils subs now use $src and/or
# $dest if $src and/or $dest args are
# not supplied at run-time:
&foo;
&foo('oldname2','newname2');
}
# FileUtils subs revert to normal
sub foo (;$src, $dest) {
&FileUtils::rename($src, $dest);
}
where FileUtils is a module (ie one can
curry classes OR modules), and where the
use XXX.default has something akin to the
effect of currying FileUtils sub calls
/if the relevant args do not exist/ till
the end of the enclosing lexical scope
for the current execution thread, and
where all of this can be done without a
significant hit to performance, then you
appear to have completely eliminated the
practical need for creating globals and
replaced it with a succinct and intuitive
way to express what's going on (even if
my example above isn't the clearest way
to explain it).
--
ralph
Re: Dynamic scoping (take 2)
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 ;
> my $y is yours ;
> my $z is yours ;
> 1...
> sub_a ;
> 2...
> }
> sub sub_a ( ; $x is yours, $y is yours ) { ...3... } ;
>
> - same as -
> # ( here no special meaning for "is yours" -- just another property )
>
> {
> my $x is yours ;
> my $y is yours ;
> my $z is yours ;
>
> 1...
>
> #alias %MY to topic so that it can be fetched from sub_a by "is given"
> $_ ::= \%MY ;
> sub_a ;
>
> 2...
>
> }
>
> sub sub_a (;$x is yours,
> $y is yours ) is given($CALLER_SYMB)
> {
> #alias variables from $CALLER_SYMB to the local variables if
> #requested
> $SUB_SYMB ::= \%MY ;
> for $SUB_SYMB.keys {
> if $SUB_SYMB{$_}.yours
> and $CALLER_SYMB{$_}.yours
>{
> $SUB_SYMB{$_} ::= $CALLER_SYMB{$_} ;
>}
> } ;
> $CALLER_SYMB = undef ; #but better if this happens at compile time
> # -- probably this have to be forced with
> #BEGIN
> 3...
>
> } ;
>
>
>
>
> arcadi
--
ralph
Re: Dynamic scoping (take 2)
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 callee.
> ...
> But I think it would be wrong for the callee to
> start forcing its namespace into the namespace
> of the caller beyond what we already do with
> named parameter syntax (and $_).
Yes. I was following the same principles.
But I much prefer your route, that is, to use
assuming (a suggested perl lingo replacement
for currying) which so clearly fits the bill.
I love (natural) brevity, so perhaps one could
have .assuming map passed arg values that are
variables (rather than pairs) to a target arg
of same name:
my $tail = "cut_short";
my $ears = "cut_long";
Dog.assuming($tail, $ears);
What's the briefest way to say:
for [Dog, Devil] { use .assuming($tail, $ears) };
Presumably this won't work:
use (Dog&Devil).assuming($tail, $ears);
--
ralph
Re: Dynamic scoping (take 2)
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 old, dangerous and
complex place, but actually it's a new, simple,
friendly, safe yet dynamic principality that
juxtaposes two localities each of which is just
an ordinary lexicality, as a defense against the
evils of globalization.
I'm not sure about the symbolism of all this;
I'll let others hash that out.
> also, another way :
>
> $x is yours
>
> is like saying that all functions that
> will ever call each other ... then I
> will croup them in a group ... may be
> thought of as being in special common
> *enclosing* lexical scope
Perhaps. I find what you've said confusing
so I'm not sure what you mean.
MyYourca already exists for transfer of
variables to called subs via parens; the
scheme I'm talking about just uses the
same MyYourca.
> *share* the same variable.
In the sense that $foo in:
sub baz ($foo) { print $foo };
sub bar { my $foo; baz ($foo); };
is shared (between baz and bar), then yes.
Anything more complicated than that, then,
technically, no.
> {
> my $x is yours = 1;
> a ;
> print $x # print 1 or 5 ?
> }
>
> sub a { $x is yours ; $x = 5 ; }
In my scheme, that would print 1 and some
variable $x that was declared either
package-wise or lexically at the point
where sub a was defined has been changed
to 5.
If sub a were defined this way:
sub a (;$x is yours) { $x = 5 ; }
then it would print 5.
> is "is yours" variable assigned or aliased
> in the callee scope ? probably we should
> have both , and then "is yours" mechanism
> is more general .
Well I was thinking it's always aliased but
can be read-only by attaching C
to a variable declaration (as part of an
explicit my, not in a sig; you can't put
C in a sig -- I can't see an
alias/copy distinction, nor ability to set
ro in a sig, being worth the complexity
they introduce).
> also , anothre question . if "is shared"
> isn't thread safe , is static scoping using
>
> our $x is private ;
>
> thread safe ??
I may have incorrectly used the term "thread
safe". The point is that you can't arrange
for there being a unique $x for multiple
threads of the same code. At least I don't
see how.
--
ralph
Re: Dynamic scoping (take 2)
> 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 dangerous globals is in an important way a mere somewhat surprising side-effect that you don't even need to tell a newbie or even an expert. It just works. I've considered names like "passed", "autoarg", "implied", and so on. But ultimately yours seems to say it all: my $foo is yours; My means my lexical and yours means your lexical where sub calling is the boundary of what's mine and yours. > (secret) symbol-table I would have thought the symbol table handling for implicit (your) args would be the exact same as for regular explicit args passed in parens. > so you propose dynamic (???) sharing. > I propose *static* sharing -- but in > practice they are *the same* -- I'd claim that: 1. Autoargs would work with threads, static sharing won't. 2. By requiring explicit marking of autoargs all along the call chain, one retains a key advantage of explicitly passing args, namely avoidance of accidental action-at-a-distance. Just look at a sub's sig to know what is being shared between it and its callers. 3. Autoargs are significantly less verbose in many scenarios. 4. Autoargs are conceptually simpler than shared variables, for both newbies and experts. But clearly this is subjective. :> -- ralph
Re: Dynamic scoping (take 2)
> 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 way to smoothly extend that for user
defined "pronouns" like $first, $rest and
$last, through to mini-vocabularies like
$source, $target, $user, ...
(Imagine you pull in fop1, fop2, fop3 that
are file ops written by three independent
authors that just agreed to conventions on
naming args. With the mechanism I propose
you can now do something like:
my $source, $target, $user;
...
fop1;
fop2;
fop3;
To get this sort of simplicity, you have
to decouple inter-sub interfaces in a
couple ways, including arg positions and
package names.)
So I'm addressing several idioms that range
from passing one or two pronouns around in
the local vicinity, between a caller and a
called sub, to passing a whole suite of
values (an "environment") to an execution
thread and the far away subs it will contain.
> anyway, my feeling is that once it is
> necessary to pass variable far enough
> it is clearer to do it with globals --
> which are restricted to be seen only
> in the restricted set of lexical scopes.
That's name restriction, not the container.
This doesn't help when dealing with threads.
Basically, global /containers/ is the root
of all evil, not so much global names.
> package ... ;
> sub a { our $x is shared ; ... } ;
> sub b { our $x is shared ; ... } ;
This isn't thread-safe.
There are other significant issues too, but
I'll move on.
> [accidentally aliasing vars to the same global]
> I dont know how to stop this source of errors.
Having lots of little local namespaces that
get chained across long distances does away
with this problem.
--
ralph
Re: Dynamic scoping (take 2)
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
# unless it is passed
# to a sub explicitly.
my $foo;# same for $foo
my $baz is yours; # $baz will automatically
$baz = 10; # be passed to /directly/
# called subs that "ask"
# explicitly for $baz.
&waldo($foo);
}
sub waldo ($b ; $baz is yours)
{ print $baz; &emer; }
sub emer (;$baz is yours(no))
{ print $baz; &qux; }
sub qux { ... }
Running this prints '1010'. Here's why:
A property exists that can mark any lexical
as "yours". When a variable is marked yours
it is automatically passed to any directly
called sub (not nested subs) that mentions
it appropriately.
The "automatic" $_ (available without
declaring with a 'my') is marked "yours"
by default.
All other (ie declared) lexicals are, by
default, not yours, hence guaranteed to be
private lexicals unless explicitly passed
to a sub. This is safer than the current
perl 6 design in which use of $CALLER::,
and even builtins and subs that merely
use the topic, might accidentally clobber
one of my lexicals at any time.
Once execution reaches the body of waldo,
there is a new lexical called $baz that is
bound to the lexical with the same name in
the body of the caller.
The C in waldo's sig has two
effects:
1. It requires that any /caller/ has a
variable of the same name marked as
yours or must pass a variable/value
using the named arg syntax for that
arg name;
2. It propogates the marking of $baz as
a yours marked variable for any sub
called from this, the body of waldo.
Once execution reaches the body of emer,
there is a new lexical called $baz that is
bound to the lexical from waldo which is in
turn bound to the lexical within qux.
The '(no)' at the end of the C
means that $baz is private to emer -- it
will not be passed to called subs by the
yours mechanism.
In summary, you mark variables that are
to be automatically passed from sub to
sub with 'is yours' where appropriate.
--
ralph
Re: Dynamic scoping (take 2)
> [temp] > [implicit args] Here's a snippet of conversation on a haskell list about implementation of implicit args : http://tinyurl.com/2ym1 -- ralph
Dynamic scoping (take 2)
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 allowed? 2. C is a conditional C; it only restores a variable's value if, on exit from the enclosing block, the block is somehow considered to have "failed". It can be applied to a global or lexical. The above two features are basically sugar for what would otherwise be achieved with paired FIRST/LAST/UNDO blocks. Both must be applied to an existing variable. Next, I want to do a better job of stating a problem I wonder about: Consider "environmental" values such as "screen sizes, graphics contexts, file handles, environment variables, and foreign interface environment handles." [1] Consider a sub One that is going to call a 10 deep stack of subs such that sub Ten needs to access one of these environmental values. How do you pass the data? A. Globals. Bad. Disastrous in threads. B. Passed as args to all intervening subs. Verbose. Sometimes incredibly verbose. C. Aggregate info into objects. But then you still have to do either 1 or 2 above with the object references. And it's a shame to be forced to the object paradigm unnecessarily. D. Use $CALLERS::. Relatively succinct, but definitely error-prone and ugly. Given what I understand of Perl 6 syntax, Parrot, and Perl philosophy, I suspect P6 should, and could fairly easily, provide a good solution to the problem outlined above. Does anyone agree the problem I've outlined is inadequately addressed by $CALLERS::? In previous emails I've suggested: 1. The notion of something like attaching a C property on variables, and picking appropriate defaults for its args (not/ro/rw), to allow the writer of a sub to easily strictly limit what a called sub can access. 2. The notion of args that are explicitly defined in a sub's sig but implicitly passed. This kills most of the verbosity of B above, while, in combination with the previous point, being otherwise just as safe as passing args explicitly all the way down the call stack. [1] http://tinyurl.com/2yhl -- ralph
Re: Unifying invocant and topic naming syntax
> > 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 inner dynamic scope at run-time.
>
> By default that would only apply to $_, but the mechanism should be
> generalisable to any name.
Yes. Regardless of the exact syntax, the idea
is presumably that the default way in which a
called sub can see/modify its caller's lexical
space is that it can see $_, can't see other
existing lexicals, and can add new lexicals.
Or something like that.
--
ralph
Re: Unifying invocant and topic naming syntax
> [perhaps]
> : bare blocks (even those passed as args) just
> : pick up from the surrounding lexical context.
This is definitely a significant simplification.
Is it a problem?
> Yes, that's the problem. A bare block would
> have to notice at run time that it was called
> with unexpected arguments and unbind its
> binding to the outer $_.
That would be ughly, but I don't understand why
you say it must necessarily be so.
> : What does this mean:
> :
> : $_ = 1; mumble -> { $_ = 2 }; print;
> :
> : perhaps the '->' could imply that $_ /is/
> : going to be private to the block somehow?
>
> As it stands now, explicitly telling it there
> are no arguments would have exactly the opposite
> effect, and bind $_ to the outer $_.
Oh.
I had the vague notion that (inline) bare blocks
don't do anything 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 would be
that a blank arg list after a '->' would mean the
topic remains private (and is set to undef).
Perhaps having bare blocks work the same simple
way whether or not they appear as an arg, and
have -> behave the same simple way whether or
not it is used with, say, a for, or as a sub
def, introduces problems or lost opportunities
elsewhere that nix the whole idea. But wait...
> I think C has to be able to wrap its own
> idea of $_ around the block at compile time somehow.
Perhaps.
But presumably you agree that it would be
nice if the calling syntax naturally made
it clear how $_ was being bound.
And documenting this by the '->' distinction
described above (ie -> means private $_ set
by mumble, no -> means $_ is just the outer
lexical) would look natural as well being
logical and strikingly simple.
> Perhaps we need to distinguish the type of
> a "thunk" from a "sub" in the signature of
> C.
This would not be necessary with the scenario
I describe above.
--
ralph
Re: Unifying invocant and topic naming syntax
> $_ = 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 (without some
as yet undefined language support).
What does this mean:
$_ = 1; mumble -> { $_ = 2 }; print;
perhaps the '->' could imply that $_ /is/
going to be private to the block somehow?
Could mumble somehow be a continuation that
alternated between generating values to be
plugged in to the block and executing it?
> sub mumble (&block) {
> block()
> }
>
> Oddly, if we make the first argument the
> topic by default, the second block actually
> gets &block as its topic. That's...strange.
This would go away with the above scenario.
--
ralph
Re: Unifying invocant and topic naming syntax
> # 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.
>
> So how does Exporter declare its import() function?
Keeping things simple, something like:
method import [*] { ... }
is required if one is to use $CALLERS::
in the body.
Skip the rest unless you enjoy flights
of pure fancy.
=
Being really radical, perhaps [*] means
that all the lexicals in the caller are
mapped to an identical set of lexicals
in the called. Dangerous stuff, huh?
Entering the realms of the truly insane,
one could have something like:
method import (@symbols)
[ { @symbols } ]
{ ... }
to indicate run time eval of the locals
list, but the above ignores all sorts
of practical problems and is plainly
huge overkill for the situation.
(All of this would of course still be
subject to the Yours property that by
default restricts localization to the
topic, and to non-existent lexicals,
ones the called sub intends to /add/
to the caller's lexical context.)
--
ralph
Re: Unifying invocant and topic naming syntax
> # 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
caller's lexical context, but where one gets
to declare that that is going to happen.
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.
--
ralph
Re: Unifying invocant and topic naming syntax
> > 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 caller's lexical context from any place in a callee's body. It exacerbates the (mostly over-stated, imo) action-at-a-distance concerns about this. I know you can do what you wrote anyway with the $CALLER::foo syntax, but I don't like that either. Allison et al have already intimated that they too find a generic 'yours' (or $CALLER::foo) capability that can be fired off anywhere in a sub's body to be dangerously obscure, to say the least. So while they expect to provide the raw $CALLER::foo capability, they have suggested some sugar that's a lot prettier AND a lot less dangerous for common cases (probably just for dealing with $_, though I am currently thinking it could work rather nicely to have it work for any lexical). Hence my focus on putting any callee side 'yours' sugar in the sub preamble. > However, I also like the idea of having to > mark shareable lexicals explicitly in the > caller, and the "your" keyword doesn't work > as well from the caller's point of view: > > your $_; > somesub(); # this sub can see $_ > > It almost calls for "our"; too bad that's > taken. I was thinking of yours as in "yours too", and as in a property: my $foo is yours; $_ would be yours(rw) by default, all other lexicals are not yours by default. The ability to have yours(ro) and yours(rw) is part of why I was thinking in terms of a property rather than a, er, whatever C is. -- ralph
Re: Unifying invocant and topic naming syntax
> 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 of cheese just prior to suggesting that. Damian has estimated that 5% of perl 6 code will do so. I've heard he can wolf a lot of pizza. -- ralph
Re: Unifying invocant and topic naming syntax
> 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 being ppp: c) introducing 'locals' or 'yours' Where this terminology and perspective comes from: My view is that c) is about sharing vocabulary between a caller and a callee to retain much of the referential simplicity and brevity of globals (and hence I think it's a pretty large issue), and c) is also about the fact that this can be done while omitting /all/ the dangers of globals (short of dangers that also apply to ordinary lexicals). Elements of this shared vocabulary might be called 'locals' or 'yours'. -- ralph
Re: Unifying invocant and topic naming syntax
> >> $_ # 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 thus:
sub bar ($a, $b)
[$_, $foo]
{ ... }
In the above, implicit args go inside the
square brackets and the topic and $foo of
the sub being def'd are the same as (aliased
to) the topic and $foo of the calling sub.
As I said before, if you call a sub you
really ought to know that sub's signature,
and the above would make it clear that $_
and $foo are shared between caller and callee.
Of course, you might then come back and
change your calling code, accidentally
clobbering a shared lexical. So, back at
the caller end of things, I suggest the
following (simplified from an earlier post):
o There's a property that controls whether
called subs can share a given lexical of
a callee. I'll call this property Yours.
o By default, topics are set to Yours(rw);
other lexicals are set to not Yours.
--
ralph
Re: Unifying invocant and topic naming syntax
> > 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 them I have no way of > preserving my chosen interface. Or > porting that code cleanly. Well, it would mean the interface gets the additional facet that the caller can /optionally/ explicitly pass $_. I'd call that a benefit, not a problem. What's the issue with porting cleanly? > Besides all that, ($_ = $_) where $_ > means something different from $_ > is Just Plain Wrong. ;-) Well, I don't see it in quite that strong a tone. One could argue that the context of the rhs of assignments in the arg list is /naturally/ the caller's. But I agree it might cause a good ppl to double-take, because of the way it looks. More importantly, it doesn't seem LOUD enough for what it's doing. Unless it doesn't need to be loud because one sorts out the issue of protecting against potential problems by requiring some explicit marking at the caller's end, as I suggested in my recent "Access to caller's topic" post. -- ralph
Re: Unifying invocant and topic naming syntax
> > 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 understand when one could do the 'is given($_)' and not do the ($_ = $_). > > Possibly we have something more evil than > > that, such as the notion that $? is a double > > sigil that pulls a name out of the dynamic > > context's lexical scope. > > 1. Do we really want to allow every lexical to >be accessible anywhere in its dynamic scope? It is intriguing. One only needs to know the def of a sub one is calling. One does not have to worry about subs that get called by the sub one is calling. Imo one should know the def of a sub one calls. In this case one needs to know the pertinent arg /names/, not just their position, but that is already somewhat the case for optional args. When writing in the, er, medium (as against small or large), one could develop a variable name vocabulary, rather as one does with globals, but without its dangers: A (horrible, but hopefully illustrative) example: my $filename = 'foobar'; my $buf; open; read; write; delete; I'm imagining a potential sweetspot between globals and lexicals. An extension of the power of "it", which is just a way to talk more succinctly when you can get away with assumptions about nearby nouns. No? > 2. If we *do* want to provide that mechanism, >do we really want to make it that easy/subtle If the sweetspot I theorize above exists, then I think my answer is 'yes' to easy. But, no matter what, NO to subtle. It would be important that people know that any given arg is, er, given, or one just ends up with something that is halfway to the usual global problem. I'm thinking the syntax should be, in order of priority, LOUD, short, pleasing. I'm also thinking it would be nice to be able to say that the called sub's lexical shares its name as well as value (copy or bound) with the calling sub's lexical, without having to say the name twice. Further, that this would be a good pick as the norm, with the syntax optimized for that, so that it may be more cumbersome when you want the formal and actual arg names to be different. Perhaps we need some Unicode? ;> -- ralph
Re: Unifying invocant and topic naming syntax
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 is MY.topic) is given($whatever) {...}
Isn't this confusing dynamic and lexical scopes?
Perhaps:
sub bar (;$foo = YOUR.topic) { ... }
sub bar (;$foo = CALLERS.topic) { ... }
> > sub bar(*@args = $) {...} # default to [$_]
> >
> > What might be is an interesting, er, topic.
>
Damian:
> I would argue it ought to be just $_
You seem to be saying one could write:
sub bar (;$foo = $_) { ... }
Btw, can one write any/all of these and
have DWIMery:
sub bar (;$_) { ... }
bar ( _ => 1 );
sub bar (;$_ = $_) { ... }
As other's have suggested, a mumble of
$CALLERS::_ makes sense:
sub bar (;$foo = $CALLERS::_) { ... }
but I can see the point of a different
syntax dedicated to just the upscope topic
to avoid encouraging wider use of $CALLERS.
Hmmm.
--
ralph
Re: Control Structures I: given
> 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 6's analog to "superpositions" is currently called "junctions". > Since I don't understand what ~~ does, Polymorphic equals. Smart match. The old =~ operator was a specific variant of this general idea. More generally, based on an a table of what to do for the various LHS/RHS combinations, a value is picked from the LHS and compared with a value picked from the RHS. The overall hope is it just DWIMs. -- ralph
Access to caller's topic (was Re: Unifying invocant and topic naming syntax)
> "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 set to not Yours. o A mechanism exists for a sub to bypass this access control for use with library routines. -- ralph
Re: Unifying invocant and topic naming syntax
> > 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 methods.
Oh.
Are placeholders only usable with anonymous
subs, or named subs too?
Switching briefly to currying, can one curry
a method?
--
ralph
Re: Unifying invocant and topic naming syntax
> 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 help too.
Sometimes verbosity doesn't matter, but
I don't see how it can ever help. I'd buy
"clarity".
More to the point, the declaration syntax
will not help with avoiding accidents at
the time of call. So what is driving you
guys to deliberately avoid a brief def
syntax?
> > $foo = sub { print $^_ }; # shorthand for
> > $foo = sub { print $_ } is given($_);
> If you're proposing that there be some special
> exemption for $^_ so that it (a) doesn't
> placehold a parameter and (b) aliases the
> caller's topic instead
Well it clearly does placehold something.
In
method f ($self : $a) { ... }
sub f ($a) is given ($line) { ... }
what do you call $self and $line? I am
talking about being able to placehold
these things, whatever you choose to call
them.
> > Why bother with currying?
>
> You mean placeholders.
I meant currying. (I was listing mechanisms
that I believed existed to enable coding
brevity.)
--
ralph
Re: Unifying invocant and topic naming syntax
Damian:
> ["it" will be passed to about 5% of subs,
> regardless of whether the context is your
> 10 line scripts or my large modules]
If the syntax for passing "it" to a sub
remains as verbose as it currently is,
you are probably right that "it" won't
be used to achieve brevity! I think it's
a pity given that the core point of "it"
is to achieve brevity.
Why do you think your estimate of Perl 6
usage of "it" is so much lower than is
true for the standard Perl 5 functions?
Btw, can I just confirm that one can't do:
sub f ($a = ) { ... }
or
sub f (;$_ = ) { ... }
where is the upscope it and $_
is the sub's topic.
> > Can currying include the given topic?
>
> Maybe.
Naturally, I see this as another symptom
of the way upscope "it" is being treated
as a second class citizen, and that this
is leading things in the wrong direction.
> > And what about a topic placeholder:
> >
> > $foo = { print $^_ };
> >
> > such that $^_ is effectively converted
> > to an 'is given($^_)'.
>
> No, that doesn't work. The placeholder
> $^_ is entirely unrelated to $_.
Well, it is at the moment, but there is
clearly mnemonic value between $^_ and $_.
> Besides, what's wrong with:
>
> $foo = sub { print $_ } is given($_);
Compared with
$foo = sub { print $^_ };
The answer is brevity, or lack thereof.
Why bother with currying? Why bother with
the "it" concept? None of these are necessary.
They simplify code generation, but their more
general feature is enabling brevity.
--
ralph
Re: on Topic
In the hope this saves Allison time, and/or
clarifies things for me, I'll attempt some
answers.
> In your article at perl.com you describes
> various ways and situations when perl
> creates a topic and this is described as
> perl making the following binding on my behalf:
>
> $_ := $some_var ; *1*
Well, $_ might not be bound to a named variable
but instead be just set to a value, or it might
be bound to an array cell or some other unnamed
container.
> is *1* _all_ that topic is about ?
Sorta. To quote an excellent summary:
"Topic is $_".
> my $x,$z;
> given $x->$y {
> $_ := $z ;
> when 2 { ... } #checks against $z ???
> }
Yes.
> methods topicalize their invocant. Is $self
> aliased to $_ inside the method in this ex. ?
>
> method sub_ether ($self: $message) {
> .transmit( .encode($message) );
> }
Yes.
> will it be an error to write
> method sub_ether ($self: $message, $x is topic) {...}
No.
> what happens if I write
> method sub_ether ($self: $message) {
> $_ := $message ;
> }
> or
>
> method sub_ether ($self: $message) {
> $_ = $message ;
> }
Both Ok. $_ is "it" and has the value $message;
in the former case $_ and $message are bound.
> is $_ always lexical variable.
Yes.
> Or I can have $MyPackage::_ ?
You can copy or alias any value.
> * can I alias $something to $_ ?
> $something := $_
Sure. Because...
> (it seems that I can , because $_ is just
> another variable )
> $b := $a ;
> $c := $b ;
>
> ( now changing value of one variable will
> change other two ??? )
Yes.
> or e.g.
>
> $a = 1 ;
> $Z = 10 ;
>
> $b := $a ;
> $c := $b ;
>
> print $c # prints 1
> $a := $Z ;
> print $c # prints 10
> $a = 5;
> print $Z # prints 5
Yes.
> also
>
> @a := ( $a, $b)
Er, I don't think (it makes sense that) you
can bind to a literal.
> $b := $c
> @a[1] = 10 ;
> print $c # prints 10
Lost you there, even ignoring the literal issue.
--
ralph
Re: list comprehensions
> Will there be some shorter-hand way to say these? > [list comprehensions] (bb clarified that this is about hash slicing.) >From A2: RFC 201: Hash Slicing ...Concise list comprehensions will require some other syntax within the subscript... And There are many ways we could reintroduce a slicing syntax ... but we'll defer the decision on that till Apocalypse 9 -- ralph
Re: Unifying invocant and topic naming syntax
> Can currying include the given topic? Can
> I do something like:
>
> $foo = &bar.assuming( _ => 0)
>
> or whatever the latest syntax is?
Oops. More clearly:
sub bar is given($foo) {
...
}
$foo = &bar.assuming( foo => 0 )
--
ralph
Re: Unifying invocant and topic naming syntax
> > My imagination suggests to me that in a
> > typical short perl 6 script
>
> That's some imagination you've got there! ;-)
:>
> My estimate (based on the -- not inconsiderable --
> code base of my own modules) is closer to 5%.
Your estimate of what others will do when
knocking out 10 line scripts in a hurry,
or what's in your current p5 modules?
> But that's beside the point. The two factors
> that nix this idea IMHO are that:
>
> * Putting a non-parameter in the parameter list
>is Just Plain Wrong
Right. I've always thought that too.
> * Using a single character to denote the use of
>an upscope topic is insufficiently
>obvious (regardless of which character
>is used for the purpose)
Right again. And again, I've always thought
that too.
As I said in my original email on this topic:
Afaik, the syntax for invocant naming is:
method f ($self : $a, $b) { ... }
But whatever it is, I think one can build
on it for topic transfer / naming too in a
wide range of contexts.
I didn't like the invocant syntax but didn't
want to tackle the problems with it that you
so rightly list above. My point was always
just that what's good for one very common
implicit arg (invocant) seems to me likely
to be good for what could so easily become
the other-not-quite-so-but-still-somewhat
common implicit arg (it).
But I'll assume the horse is dead, and move
on to the horses sibling, which hopefully
might live on:
Can currying include the given topic? Can
I do something like:
$foo = &bar.assuming( _ => 0)
or whatever the latest syntax is?
And what about a topic placeholder:
{ print $^_ }
such that $^_ is effectively converted to
an 'is given($^_)'.
?
--
ralph
Re: Unifying invocant and topic naming syntax
> relatively few subroutines need access
> to the upscope topic.
Well, this is a central issue. What are
the real percentages going to be here?
Just how often will one type the likes
of
-> is given($foo is topic) { ... }
rather than
-> $foo: { ... }
?
My imagination suggests to me that in a
typical short perl 6 script, between 20%
and 50% of all sub defs would use the
upscope topic... ;>
Seriously, the functions chapter of Camel
III contains 202 functions; 36 of these
use the upscope topic.
So that gives an idea of what to expect --
although there is likely to be /more/ use
of tricks like this that support brevity
when advanced coders specifically wish to
write brief scripts.
Unless of course the very syntax that
creates /call/ brevity is itself so
verbose that it neutralizes some of its
utility in such cases, something that
would be rather ironic, don't you think?
> Moreover, because ['is given'] compromises
> the lexical scoping of the upscope topic,
> it ought to be marked very clearly
Yes.
> [keywords are clearer than punctuation for
> marking something]
I think that's overly general.
In something that is as likely to be naturally
keyword dense as a sub or method definition, I
imagined the situation would be near reverse,
i.e. well chosen punctuation would often be a
better pick than YAK for marking something.
(Maybe colon isn't it, but I didn't pick that.)
Of course, in code written to be brief, sub
defs would tend to be less keyword, but then
again, in code written to be brief, brevity
would again suggest punctuation.
So perhaps punctuation wins in both cases;
in large projects sub defs will be keyword
dense and punctuation would better highlight
"it" and in small scripts, punctuation in
sub defs would be desirable for brevity.
--
ralph
Re: Unifying invocant and topic naming syntax
> > (naming) the invocant of a method involves
> > something very like (naming) the topic
>
> Generally, there's no conceptual link...
other than
> The similarity is that both are implicit
> parameters
which was my point.
Almost the entirety of what I see as relevant
in the context of deciding syntax for naming
the invocant is that it's an especially
important implicit argument to methods that
may also be the topic.
Almost the exact same thing is true of the
"topic", with the exception being that it
applies to subs as well as methods.
It's clear you could have come up with
something like one of these:
method f ($a, $b) is invoked_by($self)
method f ($a, $b) is invoked_by($self is topic)
method f ($a, $b) is invoked_by($_)
but you didn't. Any idea why not?
> There are times when it's useful to access
> the caller's topic without setting the current
> topic and times when it's useful to just set
> the current topic.
> ...
> When you have a system with two independent
> but interacting features, it's far more
> efficient to define two independent flags
> than to define 4 flags
Of course. The general scheme I suggested
doesn't impinge on this one way or the other.
But the specifics I suggested made a different
choice for the default situation.
As you said of the current scheme:
The following example will either print
nothing, or else print a stray $_ that is
in lexical scope wherever the sub is defined.
sub eddy ($space, $time) {
print;
}
In the scheme I suggest the first arg is the
topic by default (just as is the case for the
other topicalizers such as pointy sub, for,
etc in the current scheme). I think this
choice makes sense, but then, as I implied,
maybe I'm missing something.
> > method f ($self : $c : $a*, $b) { ... }
(where * is short for 'is topic'.)
> Is this really common enough to merit a single
> punctuation character?
If I didn't think so I wouldn't have suggested
the shortcut. ;>
> > Anyhow, a further plausible tweak that builds
> > on the above colon stuff is that one could
> > plausibly do:
>
> So, in this system, the colon is used for both
> explicit parameters and implicit parameters.
> ...
> I'd prefer more consistency.
If by "system" you mean the scheme I suggested
prior to this "plausible tweak", then no. The
colon would only be used in this way if one
introduced the tweak. Rejecting this tweak has
no impact on the value of the general scheme
I suggested.
The colon in my scheme (not the tweak) can
optionally be used to be explicit in sub
*defs* about otherwise implict args. The
tweak I am suggesting is that one could,
optionally, use the exact same syntax to
be explicit in sub *calls* about otherwise
implicit args. I think this has a clean
consistency.
> > given $c : $foo {
> > # $c = outer $_
> > }
>
> It would be much more transparent to simply
> name the outer topic.
How is this so different to
method f ($c : $foo) {
# $c = invocant
}
?
>
> Allison
--
ralph
Re: UTF-8 and Unicode FAQ, demos
> people on the list who can't be bothered to read > the documentation for their own keyboard IO system. Most of this discussion seems to focus on keyboarding. But that's of little consequence. This will always be spotted before it does much harm and will affect just one person and their software at a time. Errors in encoding during transmission is a whole lot more problematic. This will almost always be spotted after the fact, and may affect many people at a time and require fixes to multiple systems not controlled by the sender or receiver. -- ralph
Re: UTF-8 and Unicode FAQ, demos
> After all, there's gotta be some advantage to > being the Fearless Leader... > > Larry Thousands will cry for the blood of the Perl 6 design team. As Leader, you can draw their ire. Because you are Fearless, you won't mind... -- ralph
Unifying invocant and topic naming syntax
I read Allison's topicalization piece:
http://www.perl.com/pub/a/2002/10/30/topic.html
I started with a simple thought:
is given($foo)
seems to jar with
given $foo { ... }
One pulls in the topic from outside and
calls it $foo, the other does the reverse --
it pulls in $foo from the outside and makes
it the topic.
On its own this was no big deal, but it got
me thinking.
The key thing I realized was that (naming)
the invocant of a method involves something
very like (naming) the topic of a method,
and ultimately a sub and other constructs.
Thus it seems that whatever syntax you pick
for the former is likely to work well for
the latter.
Afaik, the syntax for invocant naming is:
method f ($self : $a, $b) { ... }
But whatever it is, I think one can build
on it for topic transfer / naming too in a
wide range of contexts.
With apologies for talking about Larry's
colon, something that really does sound
like it is taboo for good reason, I'll
assume the above invocant naming syntax
for the rest of this email.
So, perhaps:
sub f ($a, $b) is given($c) { ... }
sub f ($a, $b) is given($c is topic) { ... }
sub f ($a, $b) is given($_) { ... }
could be something like:
sub f ($c : $a is topic, $b) { ... }
sub f ($c : $a, $b) { ... }
sub f ($_ : $a, $b) { ... }
where the first arg to be mentioned is the
topic unless otherwise specified.
(The first line of the alternates is not
semantically the same as the line it is a
suggested replacement for, in that the
current scheme would not set the topic --
its value would be the value of $_ in
the lexical block surrounding the sub
definition. It's not obvious to me why
the current scheme has it that way and
what would best be done about it in the
new scheme I suggest, so I'll just move on.)
Anyhow, the above is my suggestion for an
alternate to 'is given' in a sub definition.
The obvious (to me) thing to do for methods
is to have /two/ colon separated prefixes of
the arg list. So one ends up with either one,
two, or three sections of the arg list:
# $_ is invocant:
method f ($a, $b) { ... }
# $_ and $self are both invocant:
method f ($self : $a, $b) { ... }
# $_/$self are invocant, $c caller's topic
method f ($self : $c : $a, $b) { ... }
One could have incantations such as:
method f ($self : $c : $a is topic, $b) { ... }
method f ($self : $c is topic : $a, $b) { ... }
method f ($self : $_ : $a, $b) { ... }
which all clobber the invocant being 'it',
but if that's what a method author wants,
then so be it.
One question is what happens if one writes:
method f (: $c : $a, $b) { ... }
Is the invocant the topic, or $c, ie what
does a missing invocant field signify?
Jumping to a different topic for one moment,
I think it would be nice to provide some
punctuation instead of (or as an alternate
to) a property for setting 'is topic'. Maybe:
method f ($self : $c : $a*, $b) { ... }
or maybe something like:
method f ($self : $c : $aT, $b) { ... }
(Unicode TM for Topic Marker? Apologies if I
screwed up and the TM character comes through
as something else.)
Anyhow, a further plausible tweak that builds
on the above colon stuff is that one could
plausibly do:
sub f ($bar : $a, $b) {
...
}
and then call f() like so:
f (20 : 30, 40)
as a shortcut for setting $_ before calling f(),
ie to set $_ in the body of f to 20, $a to 30.
Unfortunately that conflicts with use of colon
as an operator adverb. Conclusion: if y'all
end up using a different syntax for specifying
the variable name of the invocant for a method,
and go with the extension I suggested earlier
for replacing 'is given', then maybe the above
can still work, and maybe it would be a good
idea to allow it.
And if you do, I can see a further trick being:
given $foo {
# $_ = $foo here, hiding outer topic
}
given $c : $foo {
# $_ = $foo here, hiding outer topic
# $c = outer $_
}
And likewise for other topicalizers.
--
ralph
Re: Perl6 Operator (REMAINING ISSUES)
> > A ^ prefix visually interferes a lot more > > I know it clutters up things a bit, that's my very argument; that > ^[ ] clutters up things even *more*. especially, with use of arrays: > > @array[1,2,3] ^[+=] @array[4,5,6]; > > bleah. > > @array[1,2,3] ^+= @array[4,5,6]; > > Not much of a improvement, but its palpable. Maybe. I slightly prefer the first line right now. But it's close, and I think I've gotten too used to both notations to know what I'd think if I saw one or other for the first time, and I don't know what I'd think after a month of use of one or other. As I said, it's close. This will defintely be my last email on the topic... There's a couple other reasons to go for ^[op]. One is that [] is more obviously indicative to a newbie that there is some array aspect to how the op applies than ^ (or backtick) would be. Another is that bracketing works better to indicate the difference between the two ...= variants that might be useful: @a ^[+=] @b @a ^[+]= @b # vectorize the +, not the = @a ^+= @b @a ^+^= @b # vectorize the +, not the = ?!? > '^' is being used as a sigil for an operator, and that all > you need is one keystroke in order to use it. On my keyboard it's two (shift and the 6 key). > Oh by the way. IMO 'vector' operators should be the > proper term. Oops. Yes. -- ralph
Re: Perl6 Operator (REMAINING ISSUES)
> > 1) Need a definite syntax for hypers > > ^[op] and <> > > have been most seriously proposed -- something that keeps a > > bracketed syntax, but solves ambiguity issues. > > hm. What was wrong with just '^' again? Right. I didn't have a problem with ^ in the first place. But... A ^ prefix visually interferes a lot more with the op being hypered. I didn't understand that until I first saw use of square brackets (interestingly, use of angle brackets didn't grab my attention, though that may have been due to other factors). Personally, I liked the use of single backtick someone suggested. I suspect that this is because it seemed to be just as good as square brackets at getting out of the way visually (vastly better than ^); was enough to catch my attention to suggest something special was going on; was just one, unshifted, character (or two, if used for a `op`= variant); and seemed to be the least disruptive (it left ^ for other duties and just meant one needed to eliminate `` for a syscall; hmm, maybe that's not acceptable...) -- ralph
Re: Vectorizing operators for Hashes
> temp sub infix:^[] is force_hash_to_intersect ; Right. A property used as you suggest is effectively an adverb applied at op definition rather than use. > maybe somebody will wont ( 1,2 ) ^[op] ( 1, 2, 3 ) to return array of > length 3 ; Right. It's quite plausible that one would want to be able to control this at op use, rather than definition. -- ralph
Re: Vectorizing operators for Hashes
> On Thu, 31 Oct 2002, Me wrote:
> : That's one reason why I suggested control of this sort
> : of thing should be a property of the operation, not of
> : the operands.
>
> I think that by and large, the operator knows whether it wants to
> do union or intersection. When you're doing +, it's obviously
> union that you want, with undef defaulting to 0. And // would
> want intersection.
Ok. So I accidentally got something right! ;> ("control of this sort of
thing should be a property of the operation, not of the operands.")
There are clearly some operations where adverbs make sense.
Presumably one of the classes of op for which adverbs might
make sense is hyperop.
Assuming so, did my suggestion of ^adverb make sense to you
as a way to distinguish op and hyperop adverbs?
--
ralph
Re: Vectorizing operators for Hashes
> > union: > > intersection : > > How would this work for hashes with differing properties? > > %a ^is strict_keys; > %b ^is no_strict_keys; > > What would happen? That's one reason why I suggested control of this sort of thing should be a property of the operation, not of the operands. -- ralph
Re: Vectorizing operators for Hashes
> > %a ^:union[op] %b > > > > %a :foo[op]:bar %b > > I think that any operators over 10 characters should > be banished, and replaced with functions. I'd agree with that. In fact probably anything over 4, and even 4 is seriously pushing it. I'll clarify that I am talking here about using adverbs. >From A3 (about the colon): Hence, this operator modifies a preceding operator adverbially. ... It can be used to supply a ``step'' to a range operator, for instance. I would expect the length of these adverbs to fall in a range somewhat the same as properties. So a word like 'union' is reasonable, and even 'intersection' too. Ignoring hyperoperators, one might use an adverb thus: $a / $b : dbz_Inf to have a divide by zero be treated as Infinity. I can see scope for a bunch of adverbs that control how a particular hyperoperation works. Thus, perhaps: @a ^[/] @b : short to stop iteration when the shortest of two arrays is used up. But this assumes that the adverb applies to the ^[] hyperop, not the / op. Perhaps this is resolved thus: @a ^[/ : dbz_Inf] @b : short But I also suspect it would be good to be able to associate distinct adverbs with the lhs and rhs of a binary operation. So I thought perhaps one could go down the path of @a ^ :step(2) [/ : dbz_Inf] :step(3) @b : short Hmm. Perhaps hyperop adverbs are preceded with a ^ and one gets instead: @a ^[/] @b : dbz_Inf, ^short, ^step(2,3) -- ralph
Re: Vectorizing operators for Hashes
> hash ^[op] hash > ... > array ^[op] scalar ie, generally: term ^[op] term > what to do if @a, @b in @a ^[op] @b have different length > what to do if %a, %b in %a ^[op] %b have not the same set of keys > what to do in %a ^[op] @a > > [what to do] resolved by hash property : I'd expect adverbs rather than adjectives for these sorts of issues, ie ':' modifiers of vectorization rather than use of variable/value properties. > @a ???[op] @b = [ array of @a[x] op @a[y] for all pairs x,y ] > > this path have no end, but where to stop ?? b4p6>J! ;> (http://jsoftware.com/) Seriously, I also think it's worth seeing where this goes. As noted above, I'd expect use of adverbs to allow modification of hyperactivity: %a ^[op] %b : union Of course, this suffers the obtw problem. An alternative might be: %a ^:union[op] %b I can definitely see scope for wanting separate adverbs to influence how vectorization works on the lhs and rhs. Perhaps %a :foo[op]:bar %b where I'm assuming :[op] instead of ^[op] as the base syntax for vectorization. -- ralph
Re: [RFC] Perl6 HyperOperator List
> So despite the beauty of > > @a [+] @b > > I think it cannot survive in its current form. It overloads square > brackets too heavily. What about using colon thus: @a [:+] @b or other character after the opening bracket, so long as that character is not valid as the initial character of a prefix op or term. There's also: @a []+ @b -- ralph
Re: [RFC] Perl6 Operator List, Take 5
> : > I wonder if we can possibly get the Rubyesque leaving out of
> : > endpoints by saying something like 1..!10.
> :
> : Similarly: 1 >..< 10 == 2..9
> There's also an issue of what (1..10) - 1 would or should
> mean, if anything. Does it mean (1..9)? Does 1 + (1..10)
> mean (2..10)?
>
> And what would ('a' .. 'z') - 1 mean?
1..10-1 # 1..9
1+1..--10# 2..9
'a'..'z'-- # a - y
?
--
ralph
PS. [op] is such a sweet improvement. the [op=] vs [op]=
trick that then became possible, the move of ^ back to its
previous meaning, is nice icing.
Re: labeled if blocks
> And that's also why we need a different way of returning from the
> innermost block (or any labelled block). "last" almost works, except
> it's specific to loops, at least in Perl 5 semantics. I keep thinking
> of "ret" as a little "return", but that's mostly a placeholder in
> my mind. I've got a lot of those...
A unary <-, as in
if $foo -> {
<- $bar
}
?
--
ralph
Re: perl6 operator precedence table
> Somebody fairly recently recommended some decent fixed-width typefaces. > I think it may have been MJD, but I can't find the reference right now > (could be at work). Michael Schwern recently suggested "Monaco, Neep or, if you can find them, Mishawaka or ProFont". I investigated and found this link to be useful: http://www.tobias-jung.de/seekingprofont/ -- ralph
Re: Draft Proposal: Declaring Classwide Attributes
> Nothing the matter with "our" for class attributes since they're
> already stored in the package if we follow Perl 5's lead. But using
> "my" for instance attributes is problematic if we allow a class to
> be reopened:
>
> class Blurfl {
> my $.foo;
> }
> ...
> class Blurfl is continued {
> print $.foo;
> }
>
> This violates the Perl 6 rule that "my" is always limited to a block.
> That's why we came up with "attr", which has since mutated to "has".
[snip]
> It's my gut feeling that class variables are already pretty close to
> "our" variables, so we only need a new word for instance variables,
> which have a very different scope from any variables in Perl 5.
Ok.
We also need a signifier for class methods (assuming
a distinction is made).
Perhaps one could use an initial cap to indicate a class
attribute/method:
class foo {
my $bar;# my is not used for attributes
our $baz;# neither is our
has qux; # instance attribute
has Waldo; # class attribute
method qwe; # instance method
method Rty; # class method
}
or similar.
--
ralph
Re: Draft Proposal: Declaring Classwide Attributes
I've looked before for discussion of the rationale behind
introducing attr/has and failed to find it. I noticed you
mention Zurich, so perhaps this decision followed from
discussion in living color (as against b+w).
Anyhow, what was deemed wrong with using my/our?
And...
> class Zap {
> my %.zap_cache; # a private classwide attribute
> our $.zap_count = 0; # a public classwide attribute
>
> has $.foo;
> has $.bar;
> }
>
> It may be that $.zap_count is public not so much because of the class
definition
> where it would default to private, but because $.zap_count's real
global name is
> $Zap::.zap_count. To get a public accessor method you might still
need to declare
> it public. And you could get a public accessor method to the "my"
variable as well
> the same way.
So:
class Zap {
my %zap_cache; # var, lexical
my %.zap_cache;# class attr, lexical
my %.zap_cache is public; # class attr, lexical/public
our $zap_count = 0;# var, lexical/global
our $.zap_count = 0; # class attr, lexical/global
our $.zap_count = 0 is public; # class attr, lexical/public/global
has $.foo; # instance attr, lexical
has $.bar is public; # instance attr, lexical/public
}
Yes?
What about something like:
my $.foo; # private instance attr
our $.foo; # public instance attr
my $foo;# as p5
our $foo;# as p5
MY $.foo; # private class attr
OUR $.foo; # public class attr
MY $foo;# invalid?
OUR $foo;# invalid?
method bar; # public instance method
my method bar; # private instance method
our method bar; # public instance method
MY method bar; # private classmethod
OUR method bar; # public classmethod
--
ralph
Delegation syntax
Problem:
You want to use delegation (rather than inheritance)
to add some capabilities of one class or object to
another class or object.
Solution:
Use a PROXY block:
class MyClass {
PROXY {
attr $left_front_wheel is Wheel;
attr $right_front_wheel is Wheel;
when 'steer' { $left_front_wheel, $right_front_wheel }
}
...
}
Discussion:
The PROXY block behaves as if the following were
true. The block has a topic. The topic is an object
that represents a method call. This object stringifies
to the name of the method called. The block is called
each time a method call is invoked on the enclosing
class, or an instance of the class. The whens' blocks
are a list of things that are proxies for (ie delegatees
of) the matched call.
Roughly speaking, my idea is to do Damian's Delegation
class dressed using new clothes that look like ones from
the Apos that have come out since he wrote the module
at http://tinyurl.com/1qsk. A longer example follows.
class MyClass {
PROXY {
attr $left_front_wheel is Wheel;
attr $right_front_wheel is Wheel;
attr $left_rear_wheel is Wheel;
attr $right_rear_wheel is Wheel;
attr FlyWheel $flywheel .= new;
attr MP3::Player $mp3 .= new;
when 'steer'{ $left_front_wheel, $right_front_wheel }
when 'drive'{ 'rotate_clockwise' => $left_rear_wheel,
'rotate_anticlockwise' => $right_rear_wheel }
when 'power'{ 'brake' => $flywheel }
when 'brake'{ / .*_wheel / }
when 'halt' { 'brake' => SELF }
when /^MP_(.+)/ { sub { $1 } => $mp3 }
when 'debug'{ 'dump' => ATTRS }
}
...
}
or something like this.
--
ralph
Re: <( .... )> vs <{ .... }>
> If you can't distinguish braces and parentheses (or quotes and
> backquotes in some other fonts), you are in deep trouble in many
> languages including perl5 BTW.
I've seldom found myself mistaking a brace for a paren
or a quote for a backquote when using Perl 5. So maybe
you are right.
But maybe not. Given that I have another definite concern,
mentioned below, I'll spray just a little bit more before I
pedal off.
I suspect the reason I didn't fall foul of '` and ({ ambiguity
in Perl 5 might be due to other cues being present.
If it looks like:
$stdout = '/bin/foo -abc def';
then those quotes are probably backquotes.
If I see
sub foo (
...
)
then I know those parens are probably braces.
But I'm not sure the cues will be so clear for the
pattern embedded code interpolation and assertion
cases.
And here's where I add my other small niggle: it's not
clear to me /mnemonically/ which is which. Even if
you can tell which is a brace and which a paren, you
are still left wondering what each does when you're
learning this new stuff. I mean, which one of these is
executing some code to return a boolean assertion,
and which one a string value to be interpolated?
$rx1 = rx / foo <( bar )> qux /;
$rx2 = rx / foo <{ baz }> qux /;
But then again, the above is obviously contrived.
I've got my clips on; I'm outta here.
--
ralph
Re: Backtracking syntax
> [EMAIL PROTECTED] (Me) writes: > > 1. It's nice how the ':', '::', and ':::' progression indicates > > progressively wider scope. But I would be surprised if > > newbies don't say to themselves, "now just how wide a > > scope am I backtracking when there's three colons?". > > Why would newbies be writing three-colon regexes? By "newbie" I meant it in a relative sense, ie. someone who is learning those particular features. The newbie could be an expert in Prolog and Perl 5. And I'm more concerned about when they are reading some existing patterns than when they are writing one. -- ralph
Backtracking syntax
Backtracking syntax includes:
:, ::, :::, ,
I like the way the ':' looks in patterns. But I noticed I have
several niggles about a number of other aspects of the
above syntax. All the niggles are minor, individually, but
they added up to enough that I thought I'd see what the
bikeshed might look like in another color.
First, the niggles:
1. It's nice how the ':', '::', and ':::' progression indicates
progressively wider scope. But I would be surprised if
newbies don't say to themselves, "now just how wide a
scope am I backtracking when there's three colons?".
2. Typo-trap: I can imagine it being fairly easy for some
people to miss, during debugging, both the visual and
behavioral distinction between '::' and ':::'.
3. It seemed odd how the and assertions
switch to the general <...> syntax. I felt like it would be better
if they avoided the general syntax, and preferably had some
family resemblance with the first three backtracking controls.
So, how about something like:
: # lock in current atom, ie as now
:] # lock in surrounding group, currently ::
:> # lock in surrounding rule, currently :::
:/ # lock in top level rule, currently
:// # cut
Thus, redoing a couple examples from synopsis 5:
m:w/ [ if :]
| for :]
| loop :] ?
]
rule subname {
([|_] \w*) :/ { fail if %reserved{$1} }
}
m:w/ sub ? /
--
ralph
<( .... )> vs <{ .... }>
In several forms of courier, and some other text fonts
I view code in, I find it hard to visually distinguish the
pattern element:
<( ... )>
from:
<{ ... }>
What about replacing the former syntax with:
?
--
ralph
Re: Throwing lexicals
> I'm talking about just in the same namespace, how > do we keep rules from messing with file-scoped > (or any-scoped, for that matter) lexicals or globals. > How do we get rule- or closure-scoped lexicals > that are put into $0? How about something like the following rework of the capture/hypotheticals thing: You're allowed to declare variables beginning with a 0 inside rules, eg $0foo or @0bar. Rules by default capture to $0rulename. Variables that begin with a digit are rule variables, all rule variables are always hypothetical, no other variables are hypothetical. Drop the 'let' keyword. -- ralph
Re: Throwing lexicals
I may be missing your point, but based on my somewhat
fuzzy understanding:
> Oh. Duh. Why don't we have such a mechanism for matches?
>
> m/ my $date := /
>
> is ambiguous to the eyes. But I think it's necessary to have a
lexical
> scoping mechanism for matches
The above would at least have to be:
m/ { my $date := } /
(otherwise the 'my ' and ':=' would be matched literally.)
And you can of course do that.
But you won't be able to access $date outside the closure.
Hence the introduction of let:
m/ { let $date := } /
which makes (a symbol table like entry for) $date available
somewhere via the match object.
And has the additional effect that $date (I think the whole
variable/entry, but at the very least its value) disappears
if the match backtracks over the closure.
Right?
--
ralph
Re: @array = %hash
> [run time control of assignment behavior when array contains pairs]
How much have I misunderstood things from a mechanisms
available point of view (as against a practical / nice way to
do things) when I suggest something along the lines of:
my sub op:= (*@list : %adverbs) {
...
if %adverbs{keyed} = PAIR {
...
}
}
# create 2 element hash:
%hash = : { keyed=>PAIR } (1, 2, 3=>4, 5=6);
--
ralph
Re: Argument aliasing for subs
> Damian Conway wrote: > >>And is the is/but distinction still around? > > > >Oh, yes. > > Could someone please reference where this decision was > made. I do not find any information describing the distinction. The following May 2001 post was related. Poke around the thread it was in, especially posts by Larry or Damian: http:[EMAIL PROTECTED]/msg07604.html Btw, I've created a tiny url for using google groups to search for posts by Larry or Damian in perl 6 lists since early May 2002 (google doesn't have archives prior to then :<). http://tinyurl.com/1ce0 (Some posts similar to those shown will have been filtered out; you can fix that by going to the last page and clicking the 'repeat the search with the omitted results included' link). -- ralph
Re: atomicness and \n
> > $roundor7 = rx /<+[17]>/ > > That is: the union of the two character classes. > > Thank you; that wasn't in A5, E5 or S5. Will there be <-> as > well? >From A5: The outer <...> also naturally serves as a container for any extra syntax we decide to come up with for character set manipulation: <[_]++-> -- ralph
Some regex syntax foibles
Current p6 rx syntax aiui regarding embedded code:
/
#1 do (may include an explicit fail):
{ code }
#2 do with implicit 'or fail'
<( code )>
#3 interp lit:
$( { code } )
#4 interp as rx:
<{ code }>
/
This feels cryptic. Do we need abbreviated syntax for
all these cases? If we do, is there a better syntax for
this stuff?
--
ralph
Re: Using closures for regex control
> : 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) = / pat2 / } pat3 /
work?
> I don't think the return of the closure will be interpreted as
> [a string to be matched or a boolean success indicator or
> indeed anything, at least not something that the regex
> pays attention to]. Closures will be used for side effects,
> and I'd hate to see a lot of closures ending in a cryptic C<0;>.
Right.
Here's a thought, no need to respond just yet:
Perhaps the regex could look to see if the return
value has one of a set of properties. If it does not,
the regex ignores the return value. Otherwise it
uses the value in accord with the property:
# match pat1 _ 'foo bar':
/ pat1 { 'foo bar' is pat } /
Not exactly a compelling example, but the point is
this might be an appropriate way for closure return
values to participate in regex matching operation.
Aiui, one has regular perl code (not regex) read
access to what is *matched by* a parens, but not
write access to the *matching of* a parens.
So, one can do:
/ pat1 ( pat2 ) { $foo = $-1 } /
to read the value, but not
# made up, no thought applied, syntax
# match pat1 _ pat2 _ pat2
/ pat1 { .match 2 } ( pat2 ) /
where .match is followed by an expression that
applies some control to the next parens. I'm out
of my depth here, but can you see what I'm trying
to get to? To see how far one can have closures,
and hence regular perl syntax, take on regex
control duties.
--
ralph
Re: Loop controls
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
Using closures for regex control
[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 pat1 behind
/ { .lookbehind /pat1/ } pat2 } /
--
ralph
Re: Regex and Matched Delimiters
> 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.*?)$$/ >/(foo.*)$/s # matches all three lines /(foo.*)$/ -- ralph
Re: Regex and Matched Delimiters
> > : 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 stuff. But I can't get my head around parse trees and grammars, so I'll continue to fiddle around spraying a bit of grafitti here and there on the bikeshed. -- ralph
Re: Regex and Matched Delimiters
> : 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 when perl is handling a multi-line string, it is handling a case grep never encounters. Second, I think the perl 5 default is the wrong one from the point of view of a typical newbie's guess. Third, I was thinking that having perl 6 regexen have /s on by default would be easy for perl 5 coders to understand; not too hard to get used to; and have no negative effects for existing coders beyond getting used to the change. -- ralph
Using closures for regex control
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, we automatically continue where we left
> off, and require explicit =~ to start an unrelated match.
So, this might DWIM:
# match pat1 _ pat2 _ pat3 and capture pat2 match:
/ pat1
{ ($foo) = / pat2 / }
pat3 /
What is the meaning of a string returned by some code
inside a regex? Would this DWIM:
# match pat1 _ 'foo bar' _ pat2:
/ pat1 # white space is ignored
{ return 'foo bar' } # conserve whitespace
pat2 /
What if there were methods on the match state to
achieve regex extensions:
s/ { .<; /c/ } ei / ie /; # wierd look behind?
and so on:
/ pat1 { .>; /pat2/ } pat3 /
/ { .! and .<; /pat1/ } pat2 } /
--
ralph
Re: Regex and Matched Delimiters
> /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 ^ or $ should match
at newlines, double ^ or $ should only match
at start/end string.
Ah. The newline matches between the ^^ or $$.
That works.
Then there's the PID issue. Hmm. How to save $$
(it is nice for one liners)?
Sorry if this is a dumb suggestion, but could you have
just one assertion, say ^$, that alternates matching
just before and just after a newline?
> /./s // or /<.>/ ???
I'd expect . to match newlines by default. For a . that
didn't match newlines, I'd expect to need to use [^\n].
> space (or \h for "horizontal"?)
Can one quote a substring of a regex? In a later part you
say that \Q...\E is going away, so it seems not. It would be
nice to say something like:
/foo bar baz 'qux waldo' emerson/
and have the space between qux and waldo be literal.
Similar arguments apply more broadly so that one
could escape the usual meaning of metacharacters etc.
> \Lstring\E \L
> \Ustring\E \U
Maybe, if I wasn't too far off with the quote mark
suggestion above, then \L'string' would be more
natural.
> (?#...) {"..."} :-)
Will plain # comments work in p6 regexen?
> (?:...) <:...>
> (?=...)
> (?!...)
> (?<=...)
> (?
> (?>...)
Hmm. So <> are clustering just like ().
One difference is that () always capture whereas <>
only do so sometimes. Oh, and {} can too.
() are no longer used for clever stuff, <> are instead.
And {}.
Hmm. Time for bed.
--
ralph
Re: Regex and Matched Delimiters
> 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)( data)
(?opsdata)(ops data)
({}) {}
--
ralph
Re: Regex and Matched Delimiters
> [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 default, ie as
per perl5.
--
ralph
Re: Please rename 'but' to 'has'.
I agree 'but' seems a tad odd, and I like the elegance of your suggestion at first sight. However... > First, but is just strange. I have a thing and I want to tell you it is > red, so I say 'but'. Huh? banana but red; "foo" but false; According 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 usage to contradict a built-in or compile time property is not the most common form of usage, it is still arguably the case that if one keyword is to cover both cases (contradict or not), then having the keyword "warn" that contradiction may have occured is better than having the keyword indicate to a newbie that there is nothing to worry about, as would be the case with 'has'. Further, even if the "warn" notion is deemed unimportant, 'has' is still far from an ideal fit in many cases: banana has red; "foo" has false; Yet another issue is use of 'is' in a conditional: if ($foo is red) ... This would be nice, and would work nicely if one uses a different keyword for runtime properties, but works best if that other word is more consistent with the notion of 'is' than 'has' is. One plausible middle ground word off the top of my head that is odd in its own special way would be 'now': banana now red; "foo" now false; banana now foo; banana now tainted; I read 'now' as somewhat suggestive of changing something. -- ralph
Re: Regex and Matched Delimiters
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 simple.
New extension syntax:
1. Syntax is (ops data).
2. There are a bunch of built-in ops, but user can define new ones.
[2c. What about ( data) or (ops data) normally means non-capturing,
($2 data) captures into $2, ($foo data) captures into $foo?]
Rationalized ops syntax:
Ops string consists of arbitrarily ordered individual op characters.
(eg '<' signifies a look behind, '!<' signifies fail if look behind
match.)
Embedded code:
Code is inserted using {} with something other than digits in them.
(Other stuff, such as sexegers, ignored.)
--
ralph
Re: Unary dot
> 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, what about: $.foo -- ralph
Re: Unary dot
> 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 'i' instead of 'self'?
And "use me;" instead of "use invocant;"?
--
me
PS. Please don't flame me, my assistant wrote this.
"Non-yet-thrown exceptions must be a useful concept."
"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
Re: Apocalypse 4 : The Strange Case of the STRANGE CASE
I would not be appalled if Perl 6 were to assume use
of caps for catcher block labels, but I would still like to
see Larry et al reconsider this design choice.
One suggestion is use of label syntax for catcher
blocks (suggests "come-from"). If catch and CATCH
were defined as synonyms, then one could type:
LAST: {
or
last: {
--me
Re: Some Apocalypse 4 exception handling questions.
> [final, private] I detest what these modifiers have done to me in the past. They seem very unperlish to me.
Re: Some Apocalypse 4 exception handling questions.
> I think our terminology is getting sloppy here. Ok, I (think I) understand. It's simple: If you declare a derived method, then preconditions and postconditions may or may not be inherited, and independently, the code may or may not be inherited. By default, the conditions are inherited 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
Re: Some Apocalypse 4 exception handling questions.
> The problem I see with inheriting subblocks such as > FIRST/LAST/etc, is that they are tied in with the logic > ... of their enclosing block... Surely this is an argument *for* it being pretty odd *not* to inherit them. Let's say you add a LAST block to a method. In the LAST block 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
Apo4 misc (given nothing, ->, break, c::, keep/undo, hierarchy)
> "given nothing...":
>
> given () { ... }
do { ... }
seems simpler.
> Suppose you want to preserve $_ and alias
>
>given $value -> $g {
'->' seems more visually noisy than it need be in this case.
Perhaps:
given $value as $g { ... }
for @foo as $f { ... }
But, I can see how
> for 0 .. Inf; "a" .. "z" x 1000 -> $i; $a {
for 0 .. Inf; "a" .. "z" x 1000 as $i; $a {
would be seen as a counterexample by some.
> Similarly, if we make a word to mean to explicitly 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 is too long a name to
> prefix most common exceptions...
>c::NEXT
Based purely on visual impact, c:: seems best.
Perhaps 'when', or CATCH, could cause the parser to automatically
try an Error:: (or Exit:: or whatever) class prefix when it encounters a
classname.
> KEEP blocks would only be executed if the block succeeded.
> UNDO blocks would only be executed if the block failed.
What defines success? I sometimes raise exceptions to signal
that I'm done, with success, and it's time to wrap up and go back
to some calling code several levels up the stack. But I guess this
is an unusual case so not being able to use KEEP and UNDO
as intended is OK.
Or maybe each block has a Success class exception object
associated with it unless a different exception is raised, and
KEEP is called if the exception isa(Success). Then I can raise
a subclass of Success.
> However, X::Control exceptions (such as X::NEXT) are a
> subset of Exceptions
..
..
> Where exactly control exceptions fit in the class hierarchy is
> still open to debate
What about a change of perspective and terminology:
Exit (or Flow)
NEXT
Exception
ie exeptions are a subset of the ways to exit a block.
--me
Re: [A-Z]+\s*\{
> On Saturday 19 January 2002 22:05, Brent Dax wrote: > > Is this list of special blocks complete and correct? > > > > BEGIN Executes at the beginning of compilation > > CHECK Executes at the end of compilation > > INIT Executes at the beginning of run > > END Executes at the end of run > > PRE Executes at beginning of block entry > > POST Executes at end of block entry > > NEXT Executes on call to next() within current block > > CATCH Executes on exception within current block > > KEEP Executes on normal exit of the current block > > UNDO Executes on "un-normal" exit of the current block - LAST (Per Damian's last (LAST/POST) post.) - FIRST? (Symmetry.) - ALWAYS? (Another plausible addition. Rounds out PRE and POST with invariant assertions that get checked twice, once at the time PRE does, 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
Re: Apo4: PRE, POST
> [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
Re: NaN semantics
A quarter-baked idea: How about punting by using nan (all lowercase) as a boolean logic not-a-number, leaving NaN for someone to (later) create an IEEE style tristate not-a-number. Later: $foo == NaN; # NaN literal is not same as nan literal use NaN; NaN(expr);
Re: What's up with %MY?
>> What about if the symbol doesn't exist in the caller's scope
>> and the caller is not in the process of being compiled? Can
>> the new symbol be ignored since there obviously isn't any
>> code in the caller's scope referring to a lexical with that
>> name?
>
> No. Because some other subroutine called from the caller's scope might
> also access caller().{MY}. In fact, you just invented a new pattern,
in
> which a set of subroutines called within a scope can communicate
invisibly
> but safely through that scope's lexical symbol table.
Foxy variables. Nice.
Re: Multiple-dispatch on functions
Dan, I don't immediately see how per object/class dispatch control helps to make multimethods pluggable. Perhaps a multimethod (a set of methods) is a class/object? Is there a general mop for dispatch? More generally: > Yes. Ordinary subroutine overloading (like that offered by C++) > certainly does fall out as a happy side-effect of multiple dispatch > in dynamic languages. > > For example, see: > > http://dev.perl.org/rfc/256.html#Handling_built_in_types How would you handle making (multimethod) dispatch pluggable when built in types are involved?
Re: CLOS multiple dispatch
> If the dispatcher is drop-in replacable, what does its > interface look like? I'm thinking this is either deep in mop territory, or a probably quite straightforward set of decisions about dispatch tables, depending on how you look at things. I found just one relevant occurence of 'mop' in perl6-all archives: http://www.mail-archive.com/perl6-all@perl.org/msg10432.html And not a single reply... I'd really like to see what Dan / lisp folks have to say about mops and perl6...
Re: CLOS multiple dispatch
> What is the need for CLOS? Are we trying to build a kitchen > sink here? To echo Michael, CLOS != multiple dispatch. > http://dev.perl.org/rfc/256.html "The usefulness of multiple dispatch depends on how intelligently the dispatcher decides which variant of a multimethod is "nearest" to a given set of arguments. That decision process is called I, and it is proposed that it be done (or I to be done, modulo optimization) like this:" I can imagine plausibly useful dispatch rulesets that do not involve comparing sums of inheritance distances. (Though this *is* all imagining as I haven't used multimethods/clos in about 10 years.) I would also imagine that others see that summing inheritance distances may not be the only intelligent way to pick among candidates when a perfect fit is not available. (By the way, the term variant is widely used to mean something utterly different in other common languages. And I never did find 'multimethods' appealing either.) Even if the dispatcher is the heart of multimethods, perhaps it would be nice if it were convenient to replace the dispatcher in whole or part. Kinda reminds me of the story of the old mop.
Re: Lexicals within statement conditionals
In a nutshell, you are viewing: foo if bar; as two statements rather than one, right? Personally, I think it's more natural to view the above as one statement, so any my anywhere in one element of it does not apply to other elements of it.
