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)
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: 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: 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 Creturns?
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 Cwhen 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: 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 Cfor 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: 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 Cclassify 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)
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 (DogDevil).assuming($tail, $ears);
--
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)
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)
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)
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 Cyours(ro)
to a variable declaration (as part of an
explicit my, not in a sig; you can't put
Cis yours(ro) 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
Dynamic scoping (take 2)
First, I'd like to confirm I've understood Ctemp and Clet right: 1. Ctemp 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. Clet is a conditional Ctemp; 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 Cpassed 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: 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
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 Cis yours 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 Cis yours
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: 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 Cmumble 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
Cmumble.
This would not be necessary with the scenario
I describe above.
--
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
$_ = 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
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
$_ # 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
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
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
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 Cmy is. -- 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
# 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
Larry:
sub bar(; $foo = topicmumble) {...}
Damian:
topic [would be] Cundef.
I assumed topicmumble 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 = $mumble) {...} # default to [$_]
What mumble 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: 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: 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
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
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: 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: 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 = mumble) { ... }
or
sub f (;$_ = mumble) { ... }
where mumble 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: 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: 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
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: 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
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: 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
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: [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: 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 ?? b4p6J! ; (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 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
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
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
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
( .... ) 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
Backtracking syntax
Backtracking syntax includes:
:, ::, :::, commit, cut
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 commit and cut 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 commit
:// # cut
Thus, redoing a couple examples from synopsis 5:
m:w/ [ if :] expr block
| for :] list block
| loop :] loop_controls? block
]
rule subname {
([alpha|_] \w*) :/ { fail if %reserved{$1} }
}
m:w/ sub subname? block /
--
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
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 := 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 := 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 := 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 /roundascii+[17]/ That is: the union of the two character classes. Thank you; that wasn't in A5, E5 or S5. Will there be foo-bar 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: [_]+alpha+digit-Swedish -- 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 C0;.
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
Re: Regex and Matched Delimiters
/pat/i m:i/pat/ or /?i:pat/ or even m?i:pat ???
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 /any/ 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 sp (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 \Lstring
\Ustring\E \Ustring
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?
(?:...) :...
(?=...) before: ...
(?!...) !before: ...
(?=...) after: ...
(?!...) !after: ...
(?...) grab: ...
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
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
: 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
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
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
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
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: 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
[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: 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.
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
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.
[final, private] I detest what these modifiers have done to me in the past. They seem very unperlish to 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: 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: 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: 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
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 Idispatch resolution, and it is proposed that it be done (or Iappear 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.
pragma adverbs/attributes
use strict 'recursive'; If this is not yet done and is deemed a good idea, I'd add that it seems to me to be equally applicable to perl 5. Further, considering the more general [pragma] 'recursive'; I can imagine pragma adverbs / attributes. I searched p5p and p6all for things like pragma attributes (and recursive pragma) and didn't find anything relevant. It would seem natural (if not already going to be valid in p6) to allow something like: use foo :bar :quux; which clearly echoes: use foo qw( :bar :quux ); Perhaps pragma attributes could be used to make some common cases and highly visible uses of qw() rather prettier. Perhaps not. Regardless of the latter point, I could imagine: :recursive :excl :incl etc. I could further imagine a metapragma that makes these attributes available and used: use pragma 'adverbs'; Or maybe this functionality is added to: use attributes; I have no idea if any of this stuff would need to be in the perl compiler core. I can see a generic recursive pragma attribute being problematic if used anywhere but the file fed to perl, because then it becomes rather difficult to tell which pragma are in effect when looking at some source. (Otoh, for plain use strict, this seems pretty irrelevant.)
Re: aliasing - was:[nice2haveit]
Sounds like what we really want is a form of for which can iterate
over a list of hashes or arrays:
for my @a ( @foo, @bar ) { ...
for my %h ( %foo, %bar ) { ...
Yes.
Isn't the underlying issue in the above how perl6 handles manipulation
and aliasing of multi-dimensional arrays into derived sub-structures?
In other words, isn't there a more general problem of how to provide
MD access and what to do with the currently one dimensional operations
like:
for (@foo) {
when @foo is multi-dimensional?
Jeremy Howard wrote RFCs that I think relate to this and pointed
me to J (APL cleaned up) as a powerful source of related ideas.
I think the specific issue above relates to a combination of
merge/unmerge and other proposed features.
Re: Generalizing value property setting to become postits
What I was suggesting was to consider broadening what the $foo : bar style postfix sub syntax allows/assists bar to do, so that bars can be used to set properties OR do other stuff. What's the practical utility of this? 1. Simplification for perl 6 implementation. I would expect it to be easier, when implementing the case of a user-defined property setting sub, to implement this as a straight reuse of existing perl functionality, namely use of plain old subs and $_ aliasing, than to invent some alternate mechanism purely because it is deemed evil to even have the option of changing the bar'd value. 2. Simplification for explanation. A value property setting sub is just a sub that happens to set a value property. Oh, and by the way, the most convenient and expressive notation for calling value property setting subs is the one we taught you for applying a sub to a value, namely one gets to: return $foo : bar; from @foo := bar;# already gonna have to be learnt for perl 6 3. Availability of another, brief, convenient and expressive way of calling subs with one argument on the left: OUTPUT : open foo; OUTPUT : print bar; OUTPUT : close; I realize that a more general mechanism for postfix (or more accurately, infix) subs is hoped for, and, depending on how that looks, it might well make the above example pointless. Or, the more general mechanism for postfix/infix might subsume the above, so that property setting is just a way to use a sub with one of its args on its left, and that is just one of various postfix/infix options available. Once one takes that step, : can become a generalized apply to value(s) character, and the next natural step is: @foo := bar;# iterate over @foo, applying bar to values. Actually, Larry has already indicated in an earlier message to the list that ':' will work a lot like that! Yes, that was part of my reason for posting this. I thought it was interesting how the syntax fell in to place nicely for what Larry had already said he wanted, if ':' property setters are allowed to generalize to being subs (or blocks or -- I have more ideas on this, but they can wait or die with this thread) that can see and change the values from their left hand side. A key point here is that value properties apply to values, not variables, and element-wise operations also apply to values, not variables. Given that they share this applicability aspect, and (coincidentally?) shared ':' in proposed syntaces to date, I thought there might be value in looking at just how they might fit together.
Re: Generalizing value property setting to become postits
Me: [$foo is bar] can change the value of $foo. Damian: Yes. For example: my $foo is persistent; Could you explain this further please? Me: $foo : bar baz is roughly equivalent to baz(bar($foo)) Damian: Err. No. That would be: bar(1); baz(1); or possibly: $_=\$foo; bar(1); baz(1); . . There will, I hope, be a mechanism for pre- and postfixing subroutines, but not properties I think. I'm certainly not suggesting that : be _THE_ way to enable postfixing of subs. (I would assume you need a character pair to surround multiple args in the general case anyway, quite apart from the fact that : doesn't immediately strike me as a natural looking character for this sort of purpose.) But the $foo : bar syntax IS (at the very least rather close to) _A_ postfix sub syntax, whether or not this is currently viewed as a desirable way to look at it. Damian: You lost me here. Your ideas for properties are different from mine I didn't mean to suggest any changes whatsoever regarding properties. To the extent I understand them, I like them just the way you have proposed. (Indeed, I thoroughly applaud your influence on Perl 6. Personally I am rooting for one of my favortite bits from clos, multimethods, which was covered by one of your RFCs, but has not yet been raised on the list, though object inheritance is all about method dispatch as well, so that has made interesting reading.) What I was suggesting was to consider broadening what the $foo : bar style postfix sub syntax allows/assists bar to do, so that bars can be used to set properties OR do other stuff. If constraints of what bars can do are deemed appropriate to ensure adequate performance for the property setting case, which is after all, in the first place, the motivation for the syntax, and in the second, the foreseeable primary use, well, so be it. Otherwise, I see a possibly interesting twist in which bar can do things beyond property setting, in particular, change $foo's value. Once one takes that step, : can become a generalized apply to value(s) character, and the next natural step is: @foo := bar;# iterate over @foo, applying bar to values. One character, one concept (apply to value(s)), used for two purposes that I think might not ever get in the way of each other. (Though I'm not sure about that -- that's what this thread was intended to help determine.) Finally, and really a distinct point, I would like to see a distinct term for value properties that doesn't use the word properties. I liked the metaphor of post-it notes, and, if bars were to end up being allowed to be an idiosyncratic but handy form of postfix sub, then postit or similar would, imo, be a natural name for value properties. Indeed, I think this may be true even if bars remain constrained to setting postits, er, properties.
Generalizing value properties to become postits
Simplifying somewhat (ok, a heck of a lot), an rvalued:
$foo is bar
or
$foo : bar
is syntactic sugar for:
bar($foo)
with some extra magic for handling a properties hash
associated with $foo's value, in particular resetting the
hash when $foo's value changes.
Right?
Basically, perl will (do the equivalent of) define a sub bar
if it doesn't exist, then call bar, and bar can attach some
data to the value in $foo, or update some data attached
to the value in $foo, and will always return $foo.
Right?
If I got the above badly wrong, the rest of this post
probably won't make sense.
I also presume it would make sense to alias $_ to $foo
in (the method associated with) bar. (Is that intended?)
-
One could generalize so that bar can do as above, but
doesn't _have_ to do as above, ie it doesn't have to
attach data to $foo's value or update that data; it can
return a value other than $foo; and it can change the
value of $foo. Basically, an rvalued:
$foo : bar
becomes a syntactically and cognitively cheap way, and
a cognitively very different way, of calling bar on $foo, a
cheapness and difference that amplifies if one applies
several of these:
$foo : bar baz qux
instead of
qux(baz(bar($foo)))
I realize this isn't particularly appealing, but bare with me
a little longer.
So, in:
$foo : bar
bar in this context is not a property, but instead a more
general post or similar (alluding to the notion that it is
a bit like a postfix sub as well as (possibly) having the
sticky note aspect.)
So, to recap:
$foo : bar;
means bar is posted to $foo. $foo's value may change
or stay the same. The return value may be $foo's, either
before or after posting, or some other value. $foo's value
may now have an attached bar postit.
Presumably bar can be a block, method, or expression:
$foo : { code };
$foo : method;
More interestingly:
@foo : bar;
posts bar (expression, sub, block) to each element of
@foo. An alternate to 'for (@foo) bar' for single dim
arrays, and a syntactically cheap way to iterate over
entire multi-dim arrays (I'm assuming here that 'for'
won't, by default at least, iterate over all dimensions.)
@foo : bar;
@foo := bar;
@foo = @foo : bar;
are possibly just alternate ways of saying the same thing.
$foo := bar;
$foo = $foo : bar;
are also probably alternate ways of saying the same
thing, but are not necessarily the same as:
$foo : bar;
as the latter could return a value other than $foo.
Re: ~ for concat / negation (Re: The Perl 6 Emulator)
For what it's worth, I like it. So do I, actually... it's sort of growing on me. Me too. (I think it (~ for concat, ^ for negation) is just fine.) The clash with =~ is disappointing though. Now if Larry had the cahones to change the =~ operator... (I find the notion of a short infix word, like 'in', somewhat appealing. But I understand how easy it is to see this as more radical than is really called for.)
Re: Multi-dimensional arrays and relational db data
OK. My last addition to this painful thread. Your position depends on having a syntax so simple that it is somehow worth implementing as a native capability instead of the tied modules others have pointed out. No it does not. I am not suggesting that a rdb modelling tied version of MD arrays would be in core. Of course it would not. I am suggesting that a rdb modelling tied version of MD arrays might be nice. And that for it to be its nicest: A) the general mechanisms that these tied arrays would need to work adequately will need to be in place in core; and B) the syntax and behaviors chosen for the core MD array features shouldn't jar with what makes sense for the db modelling tied version of MD arrays. I'll wrap with a final thought. I think there's scope for a simple generalized relational model (Nd arrays, joins between arrays, and Nd discontiguous slice subsets across joined arrays) to be a powerful yet simple general purpose algebra for creating normalized tabular datastructures. This has nothing to do with dbs, even less to do with SQL, and everything to do with general purpose programming expressiveness. OK. No more from me on this topic, at least not in the perl world.
Re: Multi-dimensional arrays and relational db data
the end user is going to be able to redefine the syntax anyway, Yes. But if the syntax for arrays and db data are to be simultaneously the same and as ideal as possible, then either the core array syntax needs to be relatively ideal for relational db data, or one needs to redefine the array syntax to match a created db syntax and thus have a version of perl that doesn't use the standard array syntax. While the latter is pretty cool, it's a whole lot less cool than the former (assuming that multi-dimensional arrays and relational db data are as close cousins as I think they may be).
Re: Multi-dimensional arrays and relational db data
If array syntax really is a good analogy to database access (it's not) Agreed. So long as you are talking about Perl 5's arrays. I disagree, if you are talking about 2 dimensional structures. If you don't think a two dimensional structure is a good basic fit with a lot of database access, what do you suggest IS a good fit? array (or hash, you don't seem to care) Records have named fields so one dimension is like a hash. Get started now - Perl 5's.. ...arrays are one dimensional. tie and overload support should be more than sufficient. Aiui, overload won't get me past the one-dimensionality of Perl 5's arrays. Without a native 2d syntax, the win from tying isn't significant. On the other hand, if Perl's array syntax isn't a good fit for database access (bingo) then you propose we change our array syntax to be a better fit. I don't think it's reasonable to say I propose you change something that hasn't yet been defined. Rather, it is precisely because you haven't yet defined the MD array syntax that I thought it worth at least considering how it parallels db data BEFORE you define it.
Re: Multi-dimensional arrays and relational db data
Sam, I don't think we're on the same wavelength. So a direct response seems pointless. Larry himself said: while allowing multidimensional arrays to distinguish between [this and that] in a manner more conducive to database programming Ok, I did s/numerical/database/, but what's a programming domain between friends?
Re: Multi-dimensional arrays and relational db data
modeling of the whole database Doesn't seem like it's hard to do. With MD arrays, you are all but there anyway: Table: A 2d array. Whatever is introduced to more directly support handling MD arrays could very plausibly help in more directly supporting handling of single table data. This includes basic syntax, and standardized MD array sorting, filtering, and aggregating functions (which will all but inevitably emerge once standard direct support for MD arrays is in place). Virtual dataset from one table: A 2d 'slice' or rectangle. Both slices must support, er, discontiguousness. 'Horizontal' slice picks certain fields from the set available. I would expect it to be a small (or zero) hop, from whatever MD array syntax Perl 6 ends up with, to having a slice serve as a field selector. 'Vertical' slice picks certain records based on column data. This will be a bigger hop, involving some array filtering function, but it again seems inevitable that Perl 6's MD arrays will have this sort of filtering function/feature available. So, again, possibly zero extra work required. Dataset from multiple 'joined' tables (A pair of joined tables can be visualized as two spreadsheet like grids that intersect at right angles with the intersection point being the joined column. The vertical slice picks out rows where the joined column values from the two tables are the same.) Whatever is used to support vertical slicing based on col data should be extensible to do joining too. With the above, you have all the direct support I need to do all the non-transactional database crunching I have done with perl for the last several years. ALL of it. I'm pretty sure I'd be able to do grand sweeping db operations in one liners! DejaVuDidn't we have this discussion about six months ago???/ I searched the perl6-all archives for any discussion of this sort of stuff when I first started to think about it. I used the string SQL. I read all the posts (about 50-100 iirc). None went down this path.
Re: Multi-dimensional arrays and relational db data
[joining 2d arrays] I can't envisage this... Perhaps you could reveal an example. Well, for a trivial example, here's two 2d arrays: foo, bar, baz, qux, quux, waldo and rab, foo, baz, xuuq, qux, zug Joining the first col of array 1 with the second col of array 2 would pick both rows from both arrays. Seems simple to me. Perhaps you meant the concrete method and/or syntax to achieve the join, or to reference the two arrays, or to reference the result table. But thinking of concrete details like that is way premature. For one thing, if Simon and Sam are anyone to go by, this thread has zero chance of getting over the basic this is worth considering consensus hurdle, so concrete details are pointless. Particularly I can't envisage it for multicolumn Joining the first and last cols of array 1 with the second and last cols of array 2 would pick the first row from both arrays. Again, this seems simple to me. If you were considering my intersecting grids example, you need to view the multiple columns from each table as one column. outer joins. Let's just consider a left outer join. That just means picking all rows from the first table referenced in what syntax is used (the left table) and either matching rows from the right table, or pretending there is a matching blank row from the right table. So, an outer left join between array 1 and 2 above, joined on the last col of array 1 and the last col of array 2 would pick both rows of array 1, and the first row of array 2, to go with the first row of array 1, and an unitialized row from array 2 to go with the second row of array 1. It's cumbersome describing this in english, but I would expect it to be really brain dead simple intuitive as a computer syntax and semantics.
Multi-dimensional arrays and relational db data
(The intent is that) Perl 6 will be a better general purpose programming language for building application specific sub-languages. I'm interested in how far Perl 6 could go in providing support for a high-level expressive syntax sub-language for dealing with relational data. To the extent the general mechanisms will be in place in the core, there is no need to discuss it at this juncture; but then again, it's worth discussing to ensure that A) the general mechanisms will indeed be in place, and B) any syntaces chosen for core features won't jar with what makes sense for the relational data sub-language (at least not accidentally). For this post (and hopefully thread), I'm interested in focusing on the fact that a multi-dimensional array syntax, whatever it might end up being, is clearly going to be a direct analog of tables; that a multi-dimensional slice syntax could be seen as half way to virtual datasets drawn from multiple tables (eg a SQL select); that a discontiguous slice syntax gets the analogy even closer; that a missing piece, akin to SQL joins, could be darn useful outside of the usual database domain; that the issue that arrays have numeric indices means I'm really talking about multi-dimensional hashes, but then I don't see as sharp a divide between arrays and hashes as others may do, so I would expect whatever syntax is chosen for arrays is also usable for hashes; and finally that some of the issues that arise in considering multiple dimensional arrays are the same as those that arise in dealing with database data, for example sorting on multiple columns. I'm not going to post anything more concrete for this initial post. I thought others might want to pitch in first. If no one bites, I'll try to do a follow up in a few days with some more specific notes (unless someone bites so hard it's clear that I should just shut up).
