> Well clearly "on" is the opposite of "no". Yes?
maybe, as in:
my cat maybe Dog;
for some form of relaxed typing constraint.
> So bool would perhaps be a synthetic property that has opposite
polarity
> from bit? I can see that, sort of. It's something like electrons
being
> negative, thank you Mr. Franklin.
s/bit/yes/
yes?
And, despite perl5's use of no as the opposite
of use, and given that there may be no use in
> If you're trying to confuse me, I can assure you it's unnecessary.
;-)
Hey, I try.
--me
(Under cover Ruby/Python agent and
promotor of RFCs 380 thru 1,000,000)
My apologies if the following has already been suggested.
I know Larry said the colon was his, but presumably he's
not talking about the double colon, as currently used as a
package name separator, right?
What if:
use Foo::Bar qw/ qux waldo /;
can be written:
use Foo::Bar :: qux waldo
Larry:
> Currently, @ and [] are a promise that you don't intend to use string
> indexing on this variable. The optimizer can make good use of this
> information. For non-tied arrays of compact intrinsic types, this
> is going to be a major performance win in Perl 6.
Assuming that optimization
Larry:
> : > Currently, @ and [] are a promise that you don't intend to use
string
> : > indexing on this variable. The optimizer can make good use of
this
> : > information. For non-tied arrays of compact intrinsic types, this
> : > is going to be a major performance win in Perl 6.
Clearly the
> : Assuming that optimization opportunities remained intact,
>
> They won't, but go on.
Because the syntax won't provide the compiler enough info?
> : do you think conflating @ and % would be a perl6 design win?
>
> Nope, I still think most ordinary people want different
> operators for stri
> an ordered hash is common
Arrays too.
> not wise ... to alter features just for beginners.
Agreed.
> (PS 11 people isn't a statistic, its a night at the pub)
Your round...
The extra complexity of a separate hash syntax might
be justified for other reasons, but not the ones
> Hm, OK. What does this access and using what method ?
>
> $foo = '1.2';
> @bar[$foo];
This is an argument against conflating @ and %.
It has nothing to do with using [] instead of {}.
(I accept that the @/% issue is problematic. Otoh,
I don't yet see @/% conflation as being obviously
a b
e with that.
My vote is now against conflating [] and {}.
---
Please bear with me just a (hoefully little) longer.
Ok, why not deprecate %foo and always use @
instead and have [] and {} represent two indexing
name spaces?
In perl 6 experiments, and perl 7, you'll have % to
play with.
Graham Barr said:
> I am not interested in continuing this in private.
As you wish.
> If you don't want your comments public then be quite.
I thought it was best for the list if we had some private
exchanges first to reduce noise. I'll try to remember
that you don't like that approach.
> surv
> As someone else pointed out (I forget who). But beginners are not
> always the best people to ask. Beginner don't stay beginners for
> long I think the quote was.
And as I said before, I agree.
I picked the beginners list as much because it was
active as anything else. They are *somebody* afte
> (i.e. ordered or "associative").
A (probably futile, but one has to try) plea for
people to use "numbered" rather than "ordered".
@foo = ['England', 'France', 'Germany'];# unordered
%foo = {First => Fred', Last => 'Bloggs']; # ordered
(I'd also suggest "named" instead of the scie
Larry,
No need to respond to individual points, because you
are so clearly wrong. ;> But I would appreciate an
overall response of something like either "this ain't
happening, so give up" or "it remains a possibility,
but I'm not yet remotely convinced". Thanks for your
continued forbearance.
>
I will read replies, and respond to off list emails,
but I will refrain from posting to the list on this topic
for at least one week.
If you have nothing new to add, then please don't post.
Suggestion: pseudohash.
%foo{Fred} = 'Bloggs';
$bar = %bar[1];# $bar is 'Bloggs'
Suggest
Just a thought. No need for replies.
Suggestion: rename local your.
my is mine, nothing to do with anyone else's code.
our is ours, used in my code and declared in a package
known to my code.
your is yours, the value used in code I call. Oh, and
it's also ours.
trict mode that warns if a
method name matches a built in property name?
--
Q1 followed from me thinking about my/our concepts
as they might apply to properties. The more I thought
about it, the more I gravitated toward the proposed
system (lowercase for builtins, Mixedcase for use
Afaict, even with use strict at its most strict, perl 6
can't (in practice) complain, at compile time, if
$foo.Foun
refers to an undeclared Foun.
Right?
Should there be a strict mode that warns if a
method name matches a built in property name?
>> Consider the code:
>>
>> my $foo = 1 is Found;
>> &bar($foo);
>>
>> sub bar { my $baz = shift; if ($baz.Found) { ...} }
>>
>> Does the value of $baz have the Found property?
>
> Yes.
>
>> If so, does the compiler know that?
>
> No. Because i
pretty much exactly what I was thinking.
One of several benefits would be to help deal with the
introduction of new properties in later Perl versions.
When an older class was used with the newer Perl,
conflicting names would immediately break or warn,
which it seems to me would be a Good Thing.
> On Tue, Jun 05, 2001 at 04:38:24PM -0500, Me wrote:
> > Question 1:
> >
> > Afaict, even with use strict at its most strict, perl 6
> > can't (in practice) complain, at compile time, if
> >
> > $foo.Foun
> >
> > refers to
> > Afaict, even with use strict at its most strict, perl 6
> > can't (in practice) complain, at compile time, if
> >
> > $foo.Foun
> >
> > refers to an undeclared Foun.
>
> it is already detectable. from perldoc perlref:
Perhaps for perl 5, but, aiui, Damian confirmed
that my thi
t, where I had my doubts about stricture being
an on topic perl6-language issue, I have none
about static analysis support from the compiler.
So, no more on that here from me...
> Larry's MMV on that ;-)
Man I really need to get up to speed with these
acronyms. I know YMMV, is MMV a distant
cousin perhaps?
> I have done a quick scan of the archives for a
> discussion on this topic and didn't see it; if I
> just missed it, I'd appreciate it if someone
> could send me a link to the thread or
> applicable RFC[s].
I suspect you didn't use the all search, right?
Just
> [strict typing]
>
> Not a negative, but realize that many people find it
> of less value than the annoyances it brings with it
> (myself included)
Michael, I don't know which is more impressive; the
fact that use of a strictly typed language implies that
a copy of you would land on the poor un
cond 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
ot 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
> 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 s
(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 gen
oins 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.
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
> 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 tabl
> > 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
All, of course, imho:
> Were something dreadful to happen to Larry and his estate chose to
> change the licensing terms of the current *implementation*
Well they can only do that to a copy of their own, not
existing copies. While the law isn't clear on a lot of
nuances related to more complex o
ies 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 (allu
> 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. T
> > 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 expec
asing 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 th
> 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 p
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.
> 2. Format (quick to read, quick to write docs that link together;
> 2 paragraph intro that becomes a daily tip)
Are thinking of making a wiki a key part of the overall picture?
> I haven't finished this idea yet but, I was talking with Andy Wardley
> and this may be the idea. Except it will be the Template Toolkit
> interfacing with wiki which means we can build filters that translate
> POD. Of course, if the wiki internal format isn't some type of
> DocBook, it's not
ean 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.
> 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 perl
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
>> 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 so
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
> > $roundor7 = rx /<+[17]>/
> > That is: the union of the two character classes.
>
> Thank you; that wasn't in A5, E5 or S5. Will there be <-> as
> well?
>From A5:
The outer <...> also naturally serves as a container
for any extra syntax we decide to come up with for
charac
> 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, especial
> [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) {
...
I may be missing your point, but based on my somewhat
fuzzy understanding:
> Oh. Duh. Why don't we have such a mechanism for matches?
>
> m/ my $date := /
>
> is ambiguous to the eyes. But I think it's necessary to have a
lexical
> scoping mechanism for matches
The above would at least hav
> 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/hypoth
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 includes:
:, ::, :::, ,
I like the way the ':' looks in patterns. But I noticed I have
several niggles about a number of other aspects of the
above syntax. All the niggles are minor, individually, but
they added up to enough that I thought I'd see what the
bikeshed might
> [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
> > sco
27;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 t
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;
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 %.za
> 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
> 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
> 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 g
> : > 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)?
>
> A
> 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
> 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 exp
> > %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
> > union:
> > intersection :
>
> How would this work for hashes with differing properties?
>
> %a ^is strict_keys;
> %b ^is no_strict_keys;
>
> What would happen?
That's one reason why I suggested control of this sort
of thing should be a property of the operation, not of
the operands.
--
ra
> 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.
> temp sub infix:^[] is force_hash_to_intersect ;
Right. A property used as you suggest is effectively
an adverb applied at op definition rather than use.
> maybe somebody will wont ( 1,2 ) ^[op] ( 1, 2, 3 ) to return array of
> length 3 ;
Right. It's quite plausible that one would want to be
> > 1) Need a definite syntax for hypers
> > ^[op] and <>
> > have been most seriously proposed -- something that keeps a
> > bracketed syntax, but solves ambiguity issues.
>
> hm. What was wrong with just '^' again?
Right. I didn't have a problem with ^ in the first place.
But...
A ^ prefix
> > A ^ prefix visually interferes a lot more
>
> I know it clutters up things a bit, that's my very argument; that
> ^[ ] clutters up things even *more*. especially, with use of arrays:
>
> @array[1,2,3] ^[+=] @array[4,5,6];
>
> bleah.
>
> @array[1,2,3] ^+= @array[4,5,6];
>
> Not much of a i
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 wha
> 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
> 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
> > (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 dec
> relatively few subroutines need access
> to the upscope topic.
Well, this is a central issue. What are
the real percentages going to be here?
Just how often will one type the likes
of
-> is given($foo is topic) { ... }
rather than
-> $foo: { ... }
?
My imagination su
> > My imagination suggests to me that in a
> > typical short perl 6 script
>
> That's some imagination you've got there! ;-)
:>
> My estimate (based on the -- not inconsiderable --
> code base of my own modules) is closer to 5%.
Your estimate of what oth
> Can currying include the given topic? Can
> I do something like:
>
> $foo = &bar.assuming( _ => 0)
>
> or whatever the latest syntax is?
Oops. More clearly:
sub bar is given($foo) {
...
}
$foo = &bar.assuming( foo => 0 )
--
ralph
> 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 re
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:
>
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
> You're confusing brevity of declaration
> with brevity of use.
One needs sufficient brevity of both call
and declaration syntax if the mechanism's
brevity is to be of use in short scripts.
> Making (limited) circumvention of [$_'s
> lexicality] depend on a verbose and
> explicit syntax will he
> > method f ($self : $a) { ... }
> > sub f ($a) is given ($line) { ... }
> >
> > what do you call $self
>
> The "invocant".
>
> > and $line?
>
> A lexical variable that happens to be
> bound to the caller's topic.
The "invokit" perhaps?
> placeholders create subroutines, not method
> "access caller's topic" is an unrestricted
> licence to commit action at a distance.
Right.
Perhaps:
o There's a property that controls what subs
can do with a lexical variable. I'll call
it Yours.
o By default, in the main package, topics are
set to Yours(rw); other lexicals are s
> My complete knowledge comes from
> archive.develooper.com/perl6-language...
> (search for "superpositions").
I find google (rather than develooper's
archive/search) the best tool for most
searching of p6lang. Unfortunately even
google only goes back so far, and doesn't
search punctuation.
Perl
Larry:
> > sub bar(; $foo = ) {...}
Damian:
> topic [would be] C.
I assumed implied an 'is given'.
I don't see why it couldn't.
Damian:
> Hm. Given that the topic is in some sense
> a property of the lexical scope of the subroutine
> body, this might be a possibility:
>
> sub bar($foo i
> > my sub foo ($_ = $_)
> >
> > to just propagate the outer $_ inward.
>
> That only works when $_ can somehow be
> shoe-horned into the parameter list.
> Whereas:
>
>my sub foo is given($_)
>
> works for *any* parameter list.
Other than the placeholder situation, I
don't understa
> > don't understand when one could do the
> > 'is given($_)' and not do the ($_ = $_).
>
> Any time that the caller's topic isn't
> supposed to be explicitly passed as an
> argument, but is still used within the
> subroutine.
>
> [example]
>
> And, yes, I could make it an optional
> argument, but
> >> $_ # current topic
> >> $__ # outer topic
> >> $___ # outer outer topic
>
> [not sufficiently visibly distinct]
> [too much anyway]
Agreed.
Returning to the topic of binding/copying
from a caller to a callee, what about using
square brackets to mark implicit args
> c) the ability to break lexical scope
Well, I could argue that c) already exists
in the form of passing parameters in parens.
Of course, that doesn't feel like "breaking"
anything.
So instead I'll argue that the word "break"
is perhaps prejudicially perjorative.
I'd say, to steer away from be
> inheriting a caller's topic isn't going to be
> that common a thing that it needs such a short
> name, is it?
15% of the perl 5 builtins do so.
I have suggested that, in some extreme
scenarios such as short scripts, perhaps
as many as 50% of subs might do so. But
then again I probably ate a lot
> > Elements of this shared vocabulary might be
> > called 'locals' or 'yours'.
>
> I like the 'yours' idea from the point of
> view of the callee:
>
> my $inherited = your $_;
I like that syntax, but I'm uncomfortable
with an underlying principle, which is that
one can reach in to the ca
> # I'm uncomfortable [that]
> # one can reach in to the caller's lexical
> # context from any place in a callee's body.
>
> We need that capability if we're going to
> have lexically-scoped exports:
I think I was a bit careless in how I worded
that.
My problem is not that one reaches in to the
c
> # I am thinking one should have to predeclare
> # in a sub's preamble that such a trick will
> # be going on.
> #
> # Thus something like:
> #
> # sub foo [&bar] { ... }
> #
> # is (part of what is) required to be allowed
> # to create a bar sub in the context of the
> # caller of foo.
>
>
> $_ = 1; mumble { $_ = 2 }; print;
>
> will print 1 or 2?
Least surprise, visually, is obviously 2.
This would be true if bare blocks (even
those passed as args) just pick up from
the surrounding lexical context. And if
that were true, mumble presumably could
not do anything about this (wit
special beyond establishing
a nested lexical scope:
$_ = 1; { $_ = 2 }; print; # 2
whereas '->' means the topic gets set and is
private to the block (ignoring aliasing effects):
$_ = 1; for @foo -> $_ { $_ = 2 }; print; # 1
It seems to me that a logical conclusion wou
> > Are you suggesting this?
> >
> > if($error) {
> > use visible '&croak';
> > require Carp;
> > import Carp: 'croak';
> > croak($error);
> > }
>
> No - that would be pointless as well as error-prone.
>
> My idea of "visible" is that it would make a lexically scoped thing
> accessible to an inn
First, I'd like to confirm I've understood
C and C right:
1. C dynamically scopes changes to a
variable's value to the enclosing block.
It does not dynamically scope the name.
The variable can obviously be a global.
It can also make sense if it is lexical.
Is the latter currently al
> [temp]
> [implicit args]
Here's a snippet of conversation on a
haskell list about implementation of
implicit args : http://tinyurl.com/2ym1
--
ralph
In summary, I am proposing that one marks
variables that are to be automatically
passed from sub to sub with 'is yours'
where appropriate.
An example of what I'm suggesting follows.
Code with brief comments first then explanation.
{
my $_; # $_ can't be touched
> you propose a mechanism of passing [vars]
> between desired subroutins by default
> through all the dynamical chain of sub
> calls "connecting them.
There's more, or rather, less to it than that.
The same mechanism also includes a clean way
to pass "it", something that needs to be done.
And a
1 - 100 of 140 matches
Mail list logo
