It has been mentioned in Apocalypse 6 that there may not be a difference
between a method and a multimethod that has one invocant. If this does
indeed turn out to be the case, I'd like to see the method syntax being
expanded to act as an alternative to the multi syntax:
method- In the method
My apologies for the break in the chain of responses; I lost your reply
before I could reply to it, and had to retrieve it from the list archives.
Luke Palmer wrote:
Well, multi is no longer a declarator in its own right, but rather a
modifier. Synopsis Exegesis 6 show this.
I don't know
Luke Palmer wrote:
Jonathan Lang writes:
Luke Palmer wrote:
Well, multi is no longer a declarator in its own right, but rather
a modifier. Synopsis Exegesis 6 show this.
I don't know about Exegesis 6,
Then you should probably read it. It is the most recent of the
documents
Larry Wall wrote:
So far we've only allowed is parsed on the macro itself, not on
individual arguments. Still, that's an interesting idea.
Forgive me if this has already been addressed, but this could have some
useful applications:
So far, everything I've read about macro parsing concentrates
I'm invoking the principle that the only stupid question is the one not
asked:
Larry Wall wrote:
if indeed properties can be unified with roles (and roles with
classes).
Based on the source material pointed to as your inspiration for roles, I'm
a little confused as to how roles and classes
Paul Hodges wrote:
Jonathan Lang [EMAIL PROTECTED] wrote:
Incidently, I think I've caught on to _one_ of the concepts in the
upcoming object-orientation proposal: linguistically, there's a triad
of basic verbs - namely be, do, and have. If I'm following
things properly, one could think
Larry Wall wrote:
I think the class is still the final arbiter of what its objects
are--there is no other entity that holds all the reins. If a class
chooses to include a role, and that role violates the normal rules of
roles, the class is still responsible for that (or else you need some
Larry Wall wrote:
Jonathan Lang wrote:
: Let's see if I've got this straight:
:
: role methods supercede inherited methods;
But can defer via SUPER::
: class methods supercede role methods;
But can defer via ROLE:: or some such.
Check, and check. Of course, SUPER:: works well
Larry Wall wrote:
Jonathan Lang wrote:
: Larry Wall wrote:
: Jonathan Lang wrote:
Also, there will be access to the list of call candidates for SUPER::
(and presumably ROLE::) such that the class's method can get explicit
control of which super/role method or methods get called. So we can
Larry Wall wrote:
Maybe there's an intermediate syntactic form like:
$x but subclass MyClass does FooBar[bar] { }
IMHO, Cbut should be defined as generating a singleton class that
derives from the variable's class and composes a specified role - but not
neccessarily a Ipre-existing role.
Larry Wall wrote:
Jonathan Lang wrote:
: Arguably, the role's might be required to declare their methods
: multi if they want to participate in this, but that's one of those
: things that feel like they ought to be declared by the user rather
: than the definer. On the other hand, maybe
Larry Wall wrote:
Jonathan Lang wrote:
: It also occurs to me that traits can be thought of
: as adjectives (thus the is trait vs. is a class distinction) -
: another way to attach an adjective to a noun in English is to prepend
: it to the noun:
:
: my Dog $Spot is red;
: my black
Larry Wall wrote:
Jonathan Lang wrote:
: In a similar vein, what about making a disjunction of classes in an
: Cis or Cisa clause synonymous with a sequence of appropriate
: clauses? Ditto with traits and Cis, roles and Cdoes, attributes
: and Chas, etc.; thus:
:
: class DangerousPet
I've just been rereading the recent discussions, and I noticed something
that I missed the first time:
Larry Wall wrote:
Traits are not definitional but rather operationally defined in the
worst way. That's why traits are renegade roles. They don't play by
the rules.
In other words, a
David Storrs wrote:
On Sat, Dec 13, 2003 at 11:12:31AM -0800, Larry Wall wrote:
On Sat, Dec 13, 2003 at 04:57:17AM -0700, Luke Palmer wrote:
: For one, one role's methods don't silently override another's.
: Instead, you get, er, role conflict and you have to disambiguate
: yourself.
Joe Gottman wrote:
How about something like
class Trog
does Dog {bark=dogBark} does Tree {bark=treeBark}
{...}
Then we could have code like
my Trog $foo = Trog.new();
my Dog $spot := $foo;
my Tree $willow := $foo;
$spot.bark(); #
Luke Palmer wrote:
Renaming methods defeats the purpose of roles. Roles are like
interfaces inside-out. They guarantee a set of methods -- an interface
-- except they provide the implementation to (in terms of other,
required methods). Renaming the method destroys the interface
Joe Gottman wrote:
Luke Palmer wrote:
Your renaming can be done easily enough, and more clearly (IMO) with:
class Trog
does Dog does Tree {
method bark() { ... } # Explicitly remove the provided method
method dogBark() { .Dog::bark() }
method treeBark() {
Austin Hastings wrote:
There's two ways to look at that. One way is to say: I'm going to
define an interface as being this OTHER thing minus a method. That
seems like a positive construction, and supporting it might be
desirable.
The other way is to say: Nobody knows what methods call
Austin Hastings wrote:
Jonathan Lang wrote:
Austin Hastings wrote:
There's two ways to look at that. One way is to say: I'm going to
define an interface as being this OTHER thing minus a method. That
seems like a positive construction, and supporting it might be
desirable
Piers Cawley wrote:
Why does it have to be a String, though? What prevents it from
working with anything that can stringify, besides the overly
restrictive signature? What if you could say (the Perl 6 equivalent
of):
sub print_it ( does Stringify $thingie )
{
Austin Hastings wrote:
Jonathan Lang wrote:
Maybe as an alternative to
role Stringify {must stringify();}
sub print_it (Stringify $thingie) {print $thingie.stringify();}
you might be able to say
sub print_it ($thingie must stringify()) {
print $thingie.stringify
Austin Hastings wrote:
Jonathan Lang wrote:
Austin Hastings wrote:
This kind of granularity does kind of imply a JavaScript-like
ability to compose objects, too, no? (If you can compose
requirements atomically, why not compose capabilities, too?)
my $photon does Particle does
Larry Wall wrote:
Note that if we do take this approach, we'll have to require the space
after = in
@list = «a b c d e»;
Perl 6 has already set the precedent of the presence or absence of
whitespace being syntactically important (as opposed to Python, where the
amount and type of
Joe Gottman wrote:
About a month ago, a thread here suggested that we change the meaning
of the comma operator. Currently, in scalar context the expression
foo(), bar()
means evaluate foo(), discard the result, then return the value of
bar().
It was suggested that this be changed to
Austin Hastings wrote:
Larry Wall wrote:
On the other hand, it's possible that we should extend the visual
metaphor of »« and apply it asymmetrically when one of the arguments
is expected to be scalar. That would mean that your last three lines
would be written:
(1,2,3) »+«
Dave Whipp wrote:
But, presumably, you could write a macro that has a whitespace-eater
encoded
somehow. That is,
macro leach() { chomp_trailing_whitespace; return » }
macro reach () { chomp_leading_whitespace; return « }
then the macro magic would expand leach eq reach as »eq« (which,
Joseph Ryan wrote:
Of course, roles are another great way to prevent confusion with
multiple inheritance. A good question would be whether something
like forget is useful in addition, or whether everyone should
just use roles. :)
For the record, roles are not a form of multiple inheritence.
Austin Hastings wrote:
Jonathan Lang wrote:
The danger isn't really in the ability to suppress a method from a
given role or parent; the danger comes from the ability to suppress a
method from _every_ role or parent. A safe alternative to this would
be to define a class method which
Luke Palmer wrote:
Scott Walters writes:
Would it be possible to subclass things on the fly, returning a
specialized object representing the argument that knew how to
vectorize when asked to add? Aren't add, subtract, multiply, and so
on, implemented as class methods in Perl 6, much
Austin Hastings wrote:
Jonathan Lang wrote:
Actually, no; roles don't _need_ suppress or rename options to
disambiguate a conflict: the priority chain of class methods, then
role methods, then inherited methods provides all the tools that are
_required_ to remove ambiguities: you merely
Joseph Ryan wrote:
Well, what if the two classes you want to inherit from weren't
designed with roles in mind? For instance, there might be two
CPAN modules that each have a dozen methods that you want to
inherit, but they each have 1 that overlap whose conflict you
want to easily resolve.
Larry Wall wrote:
What I'm currently thinking about is a does predicate that tells you
if an object/class does a particular role completely. If you pull
part of a role into a class, it returns false, because it doesn't do
the complete role. However, if you use like instead, it returns a
Jonathan Lang wrote:
Luke Palmer wrote:
I've been thinking about this problem which comes up in my code a lot:
@sorted = sort { $^a.foo('bar').compute = $^b.foo('bar').compute}
@unsorted;
Often the expressions on each side are even longer than that. But one
Luke Palmer wrote:
Jonathan Lang writes:
How about including something similar to ==, but which binds the
elements of the list to the various positional parameters? For
instance:
@sorted = sort {infix:= args map {$_.foo('bar').compute},
$^a, $^b } @unsorted
role A {has Cat $.x;}
role B {has Dog $.x;}
class Foo {does Cat; does Dog;}
my Foo $bar;
$bar.x; # Is this a Cat or a Dog?
=
Jonathan Dataweaver Lang
__
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25¢
How would I call attributes? Specifically, what if I'm calling a list
attribute from a scalar object?
my Dog $spot;
my Dog @pack;
$spot-@.legs; # INCORRECT (I hope)
[EMAIL PROTECTED]; # INCORRECT?
@spot.legs;# What if you also have @spot declared?
=
Jonathan Dataweaver
Austin Hastings wrote:
Jonathan Lang wrote:
role A {has Cat $.x;}
role B {has Dog $.x;}
class Foo {does Cat; does Dog;}
my Foo $bar;
$bar.x; # Is this a Cat or a Dog?
A12
If, however, two roles try to introduce a method of the same name (for
some definition of name
Can role definitions be nested? That is:
role A {
role subRole1 {...};
role subRole2 {...};
...
};
As I see it, this ought to be equivelent to
role A::subRole1 {...};
role A::subRole2 {...};
role A {
does A::subRole1; does A::subRole2;
...
};
The advantage
How would I declare a subtype of a class which messes with the dispatching
mechanism to exclude certain methods and/or roles from it?
=
Jonathan Dataweaver Lang
__
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for
Larry Wall wrote:
On Fri, Apr 23, 2004 at 02:37:58PM -0700, Jonathan Lang wrote:
: Note that the problem extends past accessors: a role's methods can
: access its attributes directly. So:
:
: role A {has Cat $.x; method m1 {return $.x;};}
: role B {has Dog $.x; method m2 {return $.x
One of the beauties of the original Traits paper was that its roles had
ways of specifying assertions of what criteria must be met by whatever
classes they were to be composed into. Meanwhile, it's been mentioned
that roles and classes in P6 might look declarative in nature, but they
are in fact
Larry Wall wrote:
Jonathan Lang wrote:
: How would I declare a subtype of a class which messes with the
: dispatching mechanism to exclude certain methods and/or roles from
: it?
Er, uh...tell you what. Why don't you provide some sample code to
go with your question, and we'll just
Dov Wasserman wrote:
It's a valid question in general, but since you're designing this
functionality from the ground up (and not retro-fitting it in to
existing code), wouldn't the better approach be to create a non-GUI
HList class, and a GUI subclass that adds the indicator methods? Or
Scott Bronson wrote:
On Wed, 2004-06-30 at 18:41, Luke Palmer wrote:
Larry didn't go for it. Note, we already have an operator that puts
its left side in void context and evaluates it before its right one:
we call it C;.
But C; requires a surrounding do block, as you noted. I'm
Juerd wrote:
Scott Bronson skribis 2004-07-01 14:11 (-0700):
Juerd wrote:
pray_to $_ ., then sacrifice $virgin for @evil_gods;
I meant it without then, but apparently forgot to remove it.
pray to $_ ., sacrifice $virgin for @evil_gods;
Strictly from a grammatical perspective,
Larry Wall wrote:
Arrays with explicit ranges don't use the minus notation to count from
the end. We probably need to come up with some other notation for the
beginning and end indexes. But it'd be nice if that were a little
shorter than:
@ints.shape[0].beg
@ints.shape[0].end
Larry Wall wrote:
On Fri, Sep 03, 2004 at 06:31:49PM -0700, Jonathan Lang wrote:
: I wonder if this notion of contextualizing a method's signature could
: be generalized... I could see a case for treating most methods as if
: the expressions in each parameter were being evaluated within
Larry Wall wrote:
David Green wrote:
: I actually found things I liked in pretty much all the suggested
: alternatives, but none of them reached out and grabbed me by the
: throat the way nth did. It just seems more Perlish.
Yow. Presumably nth without an argument would mean the last.
David Green wrote:
Anyway, if we can have last, we should also have first (just for
people who don't mind all the extra typing).
No problem here, especially if C0th and Clast are synonyms - that is,
make ..., -4th, -3rd, -2nd, -1st, 0th, 1st, 2nd, 3rd, 4th, ... be the
underlying mechanism, and
David Green wrote:
It is kind of comfortable. Which is why I think I'd like to keep the
redundant nth (if we have first and last), aka 'th (where nth($i)
and $i'th are just pre- and postfixed versions of each other).
Especially important since there's a potential ambiguity problem between
David Green wrote:
Jonathan Lang wrote:
If C@foo[last+1]=$bar is equivalent to Cpush @foo, $bar, what
happens if you say C@foo[last+2]=$bar? While I like the notion that
subtracting from first or adding to last takes you beyond the bounds
of the list, you generally can't go more than
John Williams wrote:
Jonathan Lang wrote:
The only place where it makes
sense to wrap is when you define 0th as the final element, making it
logical that 0th+1 == 1st and 1st-1 == 0th.
I don't think 0th is a good name for the final element. I've never seen
it used for that. I've only
Smylers wrote:
(But personally I'm quite happy with zero-based arrays, so as long as
-1 continues to work for those I'm not too bothered what happens with
other cases.)
This is an interesting point: can the perl optimizer be made to treat
0-based contiguous lists in the same way that perl 5
Juerd wrote:
John Williams wrote:
4 :th
$foo :th
No. Adverbs modify verbs (operators or functions), not terms like 4 or
$foo.
Then perhaps a method? Number::th?
4.th
$foo.th
Again, with a bit of magic where the dot is optional when the object in
question is an
Juerd wrote:
Michael Homer skribis 2004-09-08 15:54 (+1200):
I think (correct me) what he's getting at here is a sparse array 1=a,
3=b, 4=c where 2nd is 'b' (the second item) but 1st+1 is undefined
(there is no index 2). I don't know how well that scheme works from a
comprehension
Larry Wall wrote:
David Green wrote:
: And if you restrict your hash to numeric keys, Perl could notice and
: optimise it into an array. (Or integer keys, or positive integers, or
: a consecutive range of positive ints)
What exactly do you mean by could notice? The point about the
How would I do the following in Perl 6?
if a given condition is true for every element in a list, do something.
or
if a given condition is true for any element in a list, do something.
=
Jonathan Dataweaver Lang
__
Do you Yahoo!?
Rod Adams wrote:
Now that I've gotten some feedback from my original message (on list and
off), and have had some time to think about it some more, I've come to
some conclusions:
Junctions are Sets. (if not, they would make more sense if they
were.)
As pointed out elsewhere, Junctions
Michele Dondi wrote:
OTOH all these discussions seem to imply that there is some demand (by
me, for one!) for a set-like builtin data-type as well as for the
already existing hashes and junctions and of course for
interoperability between any two of them, e.g. in terms of automatic
As an exercise, I've been looking into what could be done in terms of
creating a complex numbers package that takes advantage of perl 6
technology. A couple of thoughts that I ran across:
When you take the square root of a number, you actually get one of two
possible answers (for instance,
To me, the distinguishing feature between the role and class concepts
has always been that roles lack internal structure: you don't have to
worry about any hierarchies of what went into creating the role; you
just have to pay attention to what attributes and methods it will add
to whatever class
On 10/28/05, Luke Palmer [EMAIL PROTECTED] wrote:
Here's how I see roles. This is just an attempt to formalize our
concepts so that the answer becomes an obvious truth rather than a
decision.
A role is an interface with some default implementations.
-snip-
Now we ignore the inner workings
Yuval Kogman wrote:
Stevan Little wrote:
If we allow the class to decide if things break or not, then we
potentially allow for the system to be in a very unstable state. A
method conflict means that neither method gets consumed, and at
that point we have a gapping hole in our class.
Rob Kinyon wrote:
1. choose one of a set of available methods to call its own.
2. create a version of its own.
3. pass the buck.
#1 and #2 are identical. Stevan and I have always viewed #1 as a
special case of #2. If you want to choose a method to call, then
create a method of your own
Jonathan Scott Duff wrote:
People keep using the word hierarchy when talking about roles and I
keep thinking that it is the one word that definitely does NOT apply.
Heirarchies are for classes and inheritance relationships, not roles
and composition.
In my world view, a role that is composed
First off: is there a way to declare a method as being private to a role?
Second: can a role reclassify as private a method that is composed
into it from another role?
--
Jonathan Dataweaver Lang
The following is an attempt to put a number of Perl6 concepts into
practice, in order to see how useful and intuitive they actually are.
Complex numbers come in two representations: rectilinear coordinates
and polar coordinates:
class complexRectilinear {
has $.x, $.y;
method infix:+ ($a is
Luke Palmer wrote:
Just some initial thoughts and syntax issues. I'll come back to it on
the conceptual side a little later.
I'm looking forward to it.
Jonathan Lang wrote:
method coerce:complexPolar () returns complexPolar {
return new complexPolar ($.x * $.x + $.y * $.y, atn($.y
Doug McNutt wrote:
As for complex operations which have multiple results I think a principle
value approach makes more sense than a list. It's well established for the
inverse trigonometric functions. Leave RootOf( ) to Maple and Mathematica.
In the hypothetical module that I'm describing, the
Luke Palmer wrote:
Recently, I believe we decided that {} should, as a special case, be
an empty hash rather than a do-nothing code, because that's more
common.
However, what do we do about:
while $x-- some_condition($x) {}
Here, while is being passed a hash, not a do-nothing code.
Luke Palmer wrote:
Whatever solution we end up with for Junctions, Larry wants it to
support this:
if $x == 1 | 2 | 3 {...}
And I'm almost sure that I agree with him. It's too bad, because
except for that little detail, fmap was looking pretty darn nice for
junctions.
Not really. If
I think there might be a discrepency between S3 and S4.
S3:
In order to support parallel iteration over multiple arrays,
Perl 6 has a zip function that builds tuples of the elements of
two or more arrays.
for zip(@names; @codes) - [$name, $zip] {
print Name: $name; Zip code:
Instead of
multi sub *infix:~(ArabicStr $s1, ArabicStr $s2) {...}
multi sub *infix:~(Str $s1, ArabicStr $s2) {...}
multi sub *infix:~(ArabicStr $s1, Str $s2) {...}
could you say
multi sub *infix:~(ArabicStr $s1, ArabicStr | Str $s2) | (Str
$s1, ArabicStr $s2) {...}
or something
Rob Kinyon wrote:
To me, this implies that junctions don't have a complete definition.
Either they're ordered or they're not. Either I can put them in a =
expression and it makes sense or I can't. If it makes sense, then that
implies that if $x = $y is true, then $x $y is false. Otherwise,
Me no follow. Please use smaller words?
--
Jonathan Dataweaver Lang
Dave Whipp wrote:
An Int is Enumerable: each value that is an Int has well defined succ
and pred values. Conversely, a Real does not -- and so arguably should
not support the ++ and -- operators. Amonst other differences, a
Range[Real] is an infinite set, whereas a Range[Int] has a finite
Luke Palmer wrote:
That's good, because that's what it does. A range object in list
context expands into a list, but in scalar context it is there for
smart-matching purposes:
3.5 ~~ 3..4 # true
4 ~~ 3..^4 # false
etc.
The only remaining problem is that we have no syntax
Larry Wall wrote:
On Thu, Jan 12, 2006 at 08:29:29PM +, Luke Palmer wrote:
: The only remaining problem is that we have no syntax for ...3, which
: doesn't make sense as a list, but does make sense as a range.
Well, it could be a lazy list that you only ever pop, I suppose.
In any event,
Audrey Tang wrote:
Assuming num uses the underlying floating point semantic (which may
turn 0/0 into NaN without raising exception), what should the default
Num do on these forms?
0/0
0*Inf
Inf/Inf
Inf-Inf
0**0
Inf**0
1**Inf
Mark Reed wrote:
Perl6 .split(/whatever/) is equivalent to split(/whatever/,) in Perl5.
I'm hoping that the perl 5 syntax will still be valid in perl 6.
--
Jonathan Dataweaver Lang
. :)
--
Jonathan Lang
carries so far.
That said, I very rarely set $/, so this aspect of 'say' doesn't
really affect me.
--
Jonathan Lang
Consider my Dog $spot. From the Perl6-to-English Dictionary:
Dog: a dog.
$spot: the dog that is named Spot.
^Dog: the concept of a dog.
Am I understanding things correctly?
If so, here's what I'd expect: a dog can bark, or Spot can bark; but
the concept of a dog cannot bark:
can Dog
Stevan Little wrote:
Yes, that is correct, because:
Dog.isa(Dog) # true
$spot.isa(Dog) # true
^Dog.isa(Dog) # false
In fact ^Dog isa MetaClass (or Class whatever you want to call it).
At least that is how I see/understand it.
OK. To help me get a better idea about what's going on
Stevan Little wrote:
Jonathan Lang wrote:
OK. To help me get a better idea about what's going on here, what
sorts of attributes and methods would ^Dog have?
Well, a metaclass describes the behaviors and attributes of a class,
and ^Dog is an *instance* of the metaclass. So actually ^Dog
Stevan Little wrote:
Jonathan Lang wrote:
OK; apparently, what I meant when I asked what methods and attributes
does ^Dog have? is what you're talking about when you speak of which
methods ^Dog will respond to. To me, an object has whatever methods
that it responds to.
I disagree
Thomas Sandlass wrote:
or maybe
method Dog.bark () { ... }
Yes that works too.
Shouldn't that read Dog::bark? Why the dot?
Because I'm not 100% with the proper syntax of things. The intent was
to add a bark() method to Dog during runtime.
--
Jonathan Dataweaver Lang
Piers Cawley wrote:
And backwhacking braces in generated code is *not* a pretty solution
to my eyes. I'd *like* to be able to have a quasiquoting environment
along the lines of lisp's backquote (though I'm not sure about the
unquoting syntax):
Let me see if I understand this correctly:
Brad Bowman wrote:
Jonathan Lang wrote:
Let me see if I understand this correctly: Instead of interpolation
being enabled by default with backwhacks selectively disabling it, you
want something where interpolation is disabled by default with
anti-backwhacks selectively enabling it. Right
Brad Bowman wrote:
I don't like the idea of sharing the adverb between escaping and
force-interpolating since stacking other adverbs can turn q into qq
and vice-versa. That's a minor quibble though.
And a reasonable one as well. I was trying to minimize the
proliferation of adverbs, but I
If you're going to have versions of sqrt in S29 that deal with Complex
numbers, you ought to do likewise with a number of other functions:
multi sub abs (: Complex ?$x = $CALLER::_ ) returns Num
should return the magnitude of a complex number. abs($x) :=
$x.magnitude, or whatever the
between sqrt($x) (which returns the principle
value) and any sqrt($x) (which returns a disjunction of every
possible result): more flexible and more readable than trying for
implicit junctional return values.
--
Jonathan Lang
Doug McNutt wrote:
Jonathan Lang wrote:
Technically, the result set is one element (the principle value),
since a mathematical function - by definition - produces a single
result for any given input.
Please be careful of definitions like that. Computer science has quite
different ideas
Larry Wall wrote:
A multi sub presents only an MMD interface, while a multi method presents
both MMD and SMD interfaces. In this case, there's not much point in the
SMD inteface since .. used as infix is always going to call the MMD interface.
So:
multi method : MMD and SMD
multi sub: MMD
Stevan Little wrote:
Jonathan Lang wrote:
Can subs be declared within classes? Can methods be declared without
classes?
I would say yes.
Having subs inside classes makes creating small utility functions
easier. You could also use private methods for this, but if I dont
need to pass
Stevan Little wrote:
Jonathan Lang wrote:
Steven Little wrote:
$object does unattached_method;
^Object does unattached_method;
(Wouldn't that be ^$object does unattached_method;?)
No, I am attaching the method (well role really) to the class ^Object.
There is no such thing
Damian Conway wrote:
One might argue that it would be more useful to return a result object whose
boolean value is the success or failure, whose numeric and string values are
the number of files *un*changed, and whose list value is the list of those
*un*changed files.
Then you could write:
Mark Overmeer wrote:
* Larry Wall ([EMAIL PROTECTED]) [060327 01:07]:
On Sun, Mar 26, 2006 at 02:40:03PM -0800, Larry Wall wrote:
: On the original question, I see it more as a junctional issue.
: Assuming we have only chmod($,$), this sould autothread:
:
: unless chmod MODE,
? Or provide adverbs for the junctive
functions that can be used to change their short-circuiting behavior.
Or both.
--
Jonathan Lang
1 - 100 of 329 matches
Mail list logo