> I think I can distinguish :: from ::: - :: fails the current branch point,
> whereas ::: fails the entire rule.
Correct.
> I think I can distinguish between ::: and ; the implementation
> is a bit tricky, because ::: fails the current match - easy enough -
> whereas has to specify to all upp
Simon Cozens wrote:
> While I'm messing about with REs, is it specified how :any and hypotheticals
> interoperate?
>
>"ab" =~ rx:any / $match := (\w) /;
>print $match;
>
> Can that be undefined behaviour? Please? :)
I don't think so.
It would probably result in $0 containing an array
Paul Marquess wrote:
> Is that the "soon to be released" E5?
No, that's the "to be released today" E5.
;-)
Damian
Debbie Pickett wrote:
> So . . correct me if I'm wrong . . .
>
> C allows us to define both named and anonymous rules,
Yes.
> depending on context.
Depending on whether or not you provide a name.
> C allows us to define only anonymous rules.
Yes. And they can't take parameter lists.
> C
Markus Laire asked:
> So, would this be right short explanation:
>
> o: backtrack fails preceding atom (as atom fails, it's skipped)
> o:: backtrack fails surrounding group (OK)
> o::: backtrack fails rule (OK)
> obacktrack fails whole match
>
> S
>>Not quite arbitrary. Alphanumerics aren't allowed, nor are colon or
>>parens.
>
> Of course. I didn't want to poison my entire sentence with footnotes
> for the obvious exceptions.
Yes. It wasn't directed at you particularly, but at those for whom the
exception isn't obvious. The problem bei
Luke Palmer wrote:
> Hang on... I thought parens weren't allowed as delimiters. Or does that
> not apply to rx()?
Well, yes, we *did* say that in A5 and E5.
But we were thinking of m// and s/// in particular and of patterns with
modifiers (which might take argument lists) in general.
For an
Glenn Linderman asked:
> So one thing that bothers me in the whole discussion of rule vs rx
> differences and similarities, is that there was a previous discussion
> that said "regular expression" and "regex" should be deprecated terms
> because the rules and patterns are no longer regular, but i
Sean O'Rourke wrote:
> I hope this is wrong, because if not, it breaks this:
>
> if 1 { do something }
> foo $x;
>
> in weird ways. Namely, it gets parsed as:
>
> if(1, sub { do something }, foo($x));
>
> which comes out as "wrong number of arguments to `if'", which is just
> str
Piers wrote:
> Not exactly DWIM, but how about:
>
> my $stuff = /^\s* [ "(.*?)" | (\S+) ] : { $foo := $+ }/;
>
> Assuming $+ means 'the last capture group matched' as it does now.
>
Or just:
my $stuff = /^\s* [ "$foo:=(.*?)" | $foo:=(\S+) ]/;
BTW, that doesn't actually *do* the match
Larry wrote:
> sub while (&test is rx//, &body);
>
> or some such. That probably isn't sufficient to pick out of Perl's
> grammar rather than the current lexical scope.
I love the idea, but the property name needs to be more expressive
(and Huffmanly longer). Maybe:
sub while (
Ken Fox wrote:
> A question: Do rules matched in a { code } block set backtrack points for
> the outer rule?
I don't believe so. From A5:
A pattern nested within a closure is classified as its own rule,
however, so it never gets the chance to pass out of a {...} closure.
Indee
HellyerP wrote:
> This week I was fortunate enough to hear Damian speak twice, once on
> everything and once on Perl6. Damian, it was tremendous of you to come
> and speak to us in London - thank-you very much.
It was my pleasure.
> If he's coming to a city near you, book
> your seats now.
Nicholas Clark asked:
>%hash3 = @kv_array
>
> Is perl6 going to spot that @kv_array has an even number of entries, all
> are scalars (no pairs), and so do this
>
>for @kv_array -> key, value {
>%hash3{$key} = $value;
>}
Yes. Just like in Perl 5.
> Or is it going to treat
Trey Harris wrote:
>> sub repeat is multi ($desc is valued(1), &body) {
>> body(1);
>> }
>>
>> sub repeat is multi ($desc is valued(0), &body) {
>> }
>>
>> sub repeat is multi ($desc is valued(['A'..'F']), &body) {
>> die "Can't repeat hexadecimally";
Piers Cawley wrote:
> If I replace C<< ($key, $val) >> with
>
> @ary = m/<$pattern>/
>
> and the match succeeds, how many elements are there in @ary?
Zero. No explicit captures in that pattern.
> Suppose you want to use a hypothetical variable to bind a name to
> a capture
Aaron Sherman wrote:
> Is C<\n> going to be a rule (e.g. C<< >>)
There might be an named rule like that. But C<\n> will certainly
still be available.
> or is it implicitly translated to:
>
> <[\x0a\x0d...]>+
No. It will be equivalent to:
<[\x0a\x0d...]>
(no repetition)
> Al
Larry wrote:
> :my $date = Date.new('June 25, 2002');
>
> Assignment is wrong for conferring compile-time properties, I think.
Agreed. For a start, it's too late. The declaration is compile-time;
the assignment, run-time.
> We almost need some kind of topicalization:
>
> my Date $d
Uri Guttman wrote:
> but what simon was saying (and i agree) is the the pair IS a single
> item. it becomes the key and its value is 'scalars'.
No. If it's a PAIR, then its key is the key and its value is the value.
> hashes can now take objects as keys and won't just stringify them.
Correct.
David Wheeler wrote:
> Yes, but this:
>
>my Really::Long::Package::Name::Ugh $date is now {.init 'June 25,
> 2002' };
>
> Is shorter than this:
>
> my Really::Long::Package::Name::Ugh $date =
>Really::Long::Package::Name::Ugh.new( 'June 25, 2002' );
>
> It's not the short package nam
Ken Fox wrote:
> The thing I'd like to do right now is turn on :w
> for all rules. A Fortran grammar might want to turn
> on :i for all rules.
>
> Maybe add modifiers to the grammar declaration?
>
> grammar Fortran :i { ... }
Maybe. Or a property:
grammar Fortran is modified(:i) { ...
Uri Guttman wrote:
> so what that attribute does is force the hash to keep all pairs as
> single objects. but what about run time control of it? sometimes you
> might want a list of pairs to be handled like pairs and other times you
> want pairs to be scalars in a hash assignment. is there any wa
Adam D. Lopresto wrote:
> That's pretty close to what I was thinking of, but I don't think the
> constructors actually have to be special. What if "my Date $date;" lets the
> compiler know that $date belongs to the Date class, even if it's undef? If
> that's the case you could call static funct
Graham Barr wrote:
> I would say it is not always redundant to specify the type on both
> sides
>
> my Dog $dog = Greyhound.new('black');
Sure. But it's the redundant case we were trying to simplify.
>>And, furthermore, that you could easily define special semantics
>>for void-context con
Trey Harris wrote:
> An alias? Isn't
>
> class Date is Really::Long::Package::Name::Ugh;
>
> a new class declaration, declaring 'Date' as a subclass of
> Really::Long::Package::Name::Ugh?
Yes. It's not an alias.
> it will have a similar effect to aliasing Really::Long::Package::Name::Ugh
Nicholas Clark wrote:
> So, based on what I remember about variables, would
>
> class Date := Really::Long::Package::Name::Ugh;
>
> express aliasing of classes?
By analogy to:
my $date := $really::long::variable::name::ugh;
yes.
If Larry allows aliasing of classnames at all, that
Mike Lambert wrote:
> class Date is Really::Long::Package::Name::Ugh;
>
> class DateManipulator;
> our Date $date2manip;
> ...date manip methods here...
>
> An external class is thus unable to do:
> $DateManipulator::date2manip = new Really::Long::Package::Name::Ugh()
>
> Is that correct?
Ye
Uri Guttman wrote:
> but what about mixing pairs and scalars which was the core of this
> thread?
Then you get whatever behaviour you defined the hash to give.
> by default it seems assigning such a list to a hash would use
> the pairs as 2 elements
It's not the right way to think about wha
Ken Fox wrote:
>> / $x := (gr\w+) /vs/ (gr\w+) { let $x = $1 } /
>>
>>Shouldn't they both use C< := > ?
They should. The second version is a typo. It should be:
/ (gr\w+) { let $x := $1 } /
> Depends on what you want. The "$x :=" in the rule
Aaron Sherman wrote:
> Hmm... I had not thought of the copy aspect. Certainly, the code version
> is more flexible. You could define C<$x> above as anything. For example:
>
> / (gr\w+) {let $x = Gr_Thing.new($1)} /
>
> The binding version is just a simple, fast version of one special ca
Jonathan Scott Duff wrote:
> How can you be sure that is
> implemented as a character class instead of being some other arbitrary
> rule? An answer is that perl should know how these things are
> implemented and if you try arithmetic on something that's not a
> character class, it should carp a
Peter Behroozi wrote:
> Has anyone considered a syntax for allowing subroutines to have many
> different names for the same argument?
If it were allowed, it would probably be done via properties instead:
sub hidden (str $name, int $force, int $override is aka($force)) { ... }
Damian
[EMAIL PROTECTED] wrote:
>> sub hidden (str $name, int $force, int $override is aka($force))
>> { ... }
>
>
> Would the following be simpler...?
>
> sub hidden (str $name, int $force is aka($override))
>{ ... }
Yeah, that's what I meant.
Sorry. I've travelled 14,000 miles and given 93
Jonathan Scott Duff wrote:
> It seems odd to require two syntactic elements to achieve one semantic.
> And actually, after looking at A5, that's not what Larry wrote:
>
> my $x;
> / (\S*) { let $x = .pos } \s* foo /
A typo, I believe. He has been very consistent in d
Dan Sugalski wrote:
>> Dan, can you explain what "multimethod dispatch" is?
>
> Damian can explain it better than I can,
I thought you did a great job!
However, anyone who wants to know more about multiple dispatch
might also like to read:
http://www.samag.com/documents/s=1274/sam050
Trey Harris wrote:
>>So, each time I use a hypothetical, I have to be concious of which
>>variables are currently in scope? Perl can't help be with this task
>>because how does it know if I meant to hypothetically clobber that
>>lexical or store something in the match object. This is only reall
Trey Harris wrote:
> A more practical application would be:
>
> my $foo;
> # Code which might or might not set $foo...
> $foo //= 23;
> # or
> $foo is default(23);
>
> In such a case, the C just looks plain odd to me.
It is. More than that, it's plain wrong. C properties are
compil
Erik Steven Harrison wrote:
> Is it just me or is the 'is' property syntax a little
> too intuitive? Seems like everywhere I turn, the
> proposed syntax to solve a problem is to apply a
> property.
That's because most of the problems we're discussing are solved
by changing the semantics of
Erik Steven Harrison wrote:
> I know that the property syntax is pseudo established,
> but I'm beggining to become a bit jaded about all the
> built in properties were building. What about good ol'
> aliases?
>
> sub hidden (str $name, int $force := $override) {...}
I'm not keen on it becaus
Jonathan Scott Duff wrote:
> This continues to make no sense to me. The "hypotheticality" of a
> variable seems quite orthogonal to what you do with it (bind, assign,
> whatever). Why should these two things be intimate?
Because what you do with a hypothetical has to be reversible.
And binding
Ken Fox wrote:
> I'm messing around with regex code generation by
> converting first to a grammar. The modifiers seem
> to need intimate knowledge of regex -> grammar
> conversion. This may be a quirk of my approach.
> People using tree traversal or generating code
> directly from the regex might
Ken Fox wrote:
> Excellent. Will there be an abstract syntax for tree
> rewriting or is it Perl 6 all the way down?
I'd expect it to be Perl all the way down. Though a
tree rewriting module might make it seem abstract. ;-)
> This is really amazing stuff. I was expecting some
> support for
Jonathan Scott Duff wrote:
>>Because what you do with a hypothetical has to be reversible.
>
> I thought it was just the hypothetical's existence that has to be
> reversible.
That's not my understanding. You need to be able to cope with this too:
rule alias :w { \$ $name:= [is named \(
Peter Behroozi wrote:
>> sub hidden (str $name, int $force is aka($override)) {...}
>
>
> Hang on a moment! In your original answer to this question, you used
> the "is named('alias')" syntax, but now you are suggesting using the
> sigil in the syntax.
Yes, but for a *different* property.
Nicholas Clark wrote:
> Related, I think: no-one answered my question about what happens when I
> define
>
> sub dumb ($var, @var) {
> ...
> }
>
> and then call it with the pair var=>$thing
Exception, probably. Perhaps the error would be something like:
"Dumb ambiguous binding of dumb named
John Williams wrote:
> Back in October I suggested that $a ^+= @b would act like reduce,
> but in discussion
> it was decided that it would act like length
> I now pose the question: Is ^+= a "hyper assignment operator" or an
> "assignment hyper operator"?
> with a scalar involved
> the me
Erik Steven Harrison wrote:
> Just found this hidden in my inbox.
> I didn't think anyone was paying attention ;-).
Oh, we *always* pay attention. We just don't always respond. ;-)
>>What I most like about the C syntax is (like methods in
>>OO Perl), it associates a meaningful *name* with e
Erik Steven Harrison wrote:
> But still, what counts as a runtime property, other than true or
> false, as in the delightful '0 but true'? What other kind of runtime
> labels can I slap on a value?
Here's ten to start with...
for <> but tainted(0) {...} # note that external data
Steve Canfield wrote:
> I was under the impression that compile time properties, like runtime
> properties, can be arbitrarily invented and/or assigned.
Yes, but not purely lower-case ones. They're reserved for Perl 6 itself.
(i.e. only Larry can invent/assign them ;-)
> If that is
> correct,
David Helgason wrote:
> [worry #1]
> The hypothetical 'variables' we bind to aren't really variables but keys to a hash.
Welcome to Perl 6. Where *no* variable is really a variable, but all are keys to
a hash (which is known as the symbol table) ;-)
> Thus they shouldn't have sigils in thei
David Helgason wrote:
> Coming to think of it, why have a named variable at all? If the
> match object gets returned anyhow there is no need for a cleverly
> named magical variable ($0, $MATCH, ...).
Probably for the same reason that we have $1, $2, $_, etc.
Because people are lazy. :-)
Damia
Luke Palmer fretted:
> This is terrible. Calling foo which calls bar mysteriously overwrites
> $date? "Why is $date changing?" the programmer asks. He does an
> exhaustive search through his code and finally says "ohh," and has to
> change all references to the inner $date to something
Steve Fink wrote:
> What should this do:
>
> my $x = "the letter x";
> print "yes" if $x =~ /the { $x .= "!" } .* !/;
>
> Does this print "yes"?
If it's allowed at all, I think the match should succeed.
> print "yes" if "helo" =~ /hel { .pos-- } lo/;
This definitely has to work. But r
Josh Jore wrote:
>>>Would it be correct for this to print 0? Would it be correct for this
>>>to print 2?
>>>
>>> my $n = 0;
>>> "aargh" =~ /a* { $n++ } aargh/;
>>> print $n;
>>
>>Yes. ;-)
>
> Wouldn't that print 2 if $n is lexical
Err. It *is* lexical in this example.
> and 0 if it's local
On top of which, Damian has expressed an interest in ! for a
superpositional xor.
Which would behave how, exactly?
Well, that's still a matter for conjecture.
N-ary xor isn't particularly useful, because binary xor naturally generalizes
to: "an odd number of these N operands are true". (Hint:
Brent Dax wrote:
Can the new nefarious use be concat? Pretty please?
There was a brief period 18 months ago when tilde *was* the designated
Perl 6 concatenation operator.
I certainly wouldn't mind seeing it return to that role, now that
it's not needed elsewhere. And, of course, that would ac
Adam D. Lopresto wrote:
Really what I've been wishing for was an operator (or whatever) to let me do an
s// without changing the variable.
I would hope/expect that that's what the subroutine form of C would do.
That is, it takes a string, a pattern, and a replacement string,
and returns a new
Excellent (and valuble) work Michael. Thank-you.
My turn for a few comments:
& | ! - superpositional
all any one (none?)
Although there certainly are good uses for a C superpositional:
push @list, $newval
if $newval eq none(@list);
print "In range\n"
Brent Dax wrote:
Larry Wall:
# We're obviously missing the "force to string context, negate"
# operator. :-)
Which would create a superposition of all strings besides the given one,
right? (Oh crap, I think I gave Damian an idea... :^) )
The C<~none> operator covers that quite nicely:
$not_
Deborah Pickett wrote:
Which looks better?
if ($a == 1|2|3 || $b eq "x"|"y"|"z")
or
if ($a == 1||2||3 | $b eq "x"||"y"||"z"
?
No question thatthe former works better. Lower precedence operators govern
larger chunks, and so should themselves be larger (i.e. more easily detected).
I just n
Simon Cozens wrote:
I don't understand this, on several levels. The lowest level on which
I don't understand it is that testing whether an array is full of threes:
@array & 3
Err...that's not what that does. What you wrote creates a scalar value that
superimposes the scalar values C< \@
Larry mused:
Now I'm wondering whether these should be split into:
+&+|+! - bitwise operations on int
+&= +|= +!=
~&~|~! - bitwise operations on str
~&= ~|= ~!=
I think this is UME (Unnecessary Multiplication of Entities),
Simon Cozens wrote:
Ah, I see. So (x & y) is equivalent to all(x,y) ?
Yes. C, C, and C are the n-ary prefix versions
of binary infix C<|>, C<&>, C respectively.
One might imagine others of this ilk too, perhaps:
BinaryN-ary
+sum
*prod
~
Luke Palmer wrote:
You know, \ and friends as xor is appealing to me.
H. I quite like that too. :-)
Also, a question about superpositions: Is
$x = 1 | 2 | 3
equivalent to
$x = 1 | 2
$x |= 3
No. The precedence is wrong.
or
$x = (1 | 2) | 3
Yes.
or is there a
fearcadi wrote:
* do we have have an axcess to the signature of the
subroutine if we have been passed only its reference .
that is , for exemple , can
process( @x , &step )
guess how many arguments &step expects ?
I'd expect that Code objects would have a C or C method:
&subnam
Larry wrote:
And you get the C || and && for free
Yeah, but it's the same sense of "free" in which spam is "free".
You pay for it in other ways.
But distinguishing int ops from str ops fixes the really nasty rule
in Perl 5 that says "If this value (these values) has (have) ever
been used in
Larry wrote:
: H. I quite like that too. :-)
Except what about unary xor, i.e. 1's complement?
I was carefully ignoring that. ;-)
Besides, Windows programmers would continually be writing
$a / $b
and wonder why they don't get one($a,$b);
: > Also, a question about superpos
Larry Wall wrote:
By all accounts, a s/// is an odd thing to put in a smart match
anyway. You can't have a superposition of things with side effects,
for instance:
$str =~ s/a/b/ | s/b/c/
Though doubtless Damian can think of something indeterminate to make
it mean. :-)
Of course. That j
Scott Duff asked:
How do we get at the eigenstates of a superposition?
We obviously need another operator!
Actually, I think we need a universal method on scalars that
gives the eigenstates of that value. It might be C<$val.eigenstates>
or maybe just C<$val.states>. The method would work on
Oh boy, I just *hate* the idea of C for xor.
Hate it, hate it, hate it! Yuck, yuck, yuck!
But I do like Michael's idea of using C<@> as the hyperoperator marker
(the array connotation works well, I think). The only problem is that
we end up with too many C<@>'s in most expressions:
$count = @a +
Michael Lazzaro wrote:
Any ideas on what
{ $^a op $^b }
would become?
It would be unchanged. Placeholders have nothing to do with hyperoperators.
And never have had.
Damian
Uri Guttman wrote:
what is a string complement? bitwise? i take it the numeric is one's
complement.
String complement treats the value as a string then bitwise complements every
bit of each character.
Integer complement treats the value as a int then bitwise complements every
bit.
DC>
Simon Cozens wrote:
In this case I find the latter to be easier to decode and more
appealing. There are less chars and paretheses are seen much more
easily.
Ack, I guess that means we need a one character DWIM operator.
Although "..." comes pretty close, I suppose.
Great minds think alike.
Scott Duff wrote:
Actually, I think we need a universal method on scalars that
gives the eigenstates of that value. It might be C<$val.eigenstates>
or maybe just C<$val.states>. The method would work on non-superimposed
values as well, in which cases it would just return a list containing
the val
Piers Cawley wrote:
Whilst I don't wish to get Medieval on your collective donkey I must
say that I'm really not sure of the utility of the proposed infix
superposition ops. I'm a big fan of any/all/one/none, I just think
that
one(any($a, $b, $c), all($d, $e, $f))
Is a good deal more intent
>>If someone (named Damian :-)
wrote a superposition synopsis that showed the many and varied uses of
superpositions in contexts that ordinary programmers can relate to, it
would bother me less when people make claims about the usefulness of
superpositions.
I'll take one of those for perl.com!
Larry...
> would look favorably on finding a replacement for "superposition".
any(
"multivalue",
"multival",
"opval"=> "andval"|"orval"|"xorval"|"nandval",
"opval"=> "andval"|"orval"|"exval"|"nonval",
"opval"=> "allval"|"anyval"|"oneval"|"noneval",
"set" => "andset"|"orset"
David Wheeler wrote:
Well, I like "set operators," too, but what's the grammatical term for
the above "logically entangled list of nouns"?
"Superposition".
Damian
Larry wrote:
All other things being equal, I think people will find modal operators
more confusing than if we just make separate operators.
Agreed.
That being said, I'm still wondering whether we can finesse it.
We can get close. But that might actually be counterproductive.
> Damian's d
Austin Hastings wrote:
I confess, I don't get it.
Yes, you did. :-)
To me, it appears to iterate over the input,
printing unique values except that two values ($start, $finish) are
considered to have already been encountered.
If that's all, then okay.
Okay then. That's all.
But does it
Brian Ingerson wrote:
Speaking of persistence, I just realized I'll need to start thinking about
YAML serializations of superpositions. My first cut at it would be:
---
letters: !super [0, 1, 2]
digits: !super
- 0
- 1
- 2
...
Not quite. You also need to discri
Brian Ingerson wrote:
Oh! I just remembered the ultimate word for a container. It's "cozy", of
course!
Every eigenbunny needs a supercozy!
The plural of which is, presumable, "supercozens".
Now *I'm* really scared!
;-)
Damian
Buddha Buck wrote:
I was wondering...
How persistant are superpositions? How pervasive are they?
As I mentioned in a recent post, would expect them to be all-pervasive
and fully propagating.
I mean, will the following work?
I would certainly hope so! (modulo the syntax snafu)
In fact, i
Aaron Crane wrote:
Mmm, yummy. I do have a question though (and apologies if I've merely
missed the answer). We've got two productive operation-formation rules: one
saying "add a final = to operate-and-assign", and the other saying "wrap in
[] to vectorise". But no-one's said which order they
Dave Storrs wrote:
for @a; @b -> $x is rw; $y { $x = $y[5] };
I agree that it's an eyeful. How many of your issues could be solved
if the above were just written:
for (@a;@b) -> ($x is rw; $y) { $x = $y[5] };
Would that suffice to make it clearer?
Actually, yes, that would solve everyt
Larry Wall wrote:
: if we did go back to using ^ for hyper I have no clue what to do about
: xor. I'd suggest % but I use the modulus too much.
Gee, % looks kinda like an X.
Just put that alpha down and back away quietly, mister.
There's no need for anyone to get hurt here.
;-)
Damian
Brian Ingerson wrote:
Not quite. You also need to discriminate the *type* of the superposition:
Oh right. I was thinking that C and friends were operations, not types.
Oops.
YAML type-URIs are made up of a type-family with an optional format:
!domain.com/type#format
and:
!int
is s
Larry mused:
On Tue, 29 Oct 2002, David Whipp wrote:
: Larry Wall [mailto:larry@;wall.org] wrote:
: > : unary (postfix) operators:
: > :... - [maybe] same as ..Inf [Damian votes Yes]
: > : > I wonder if we can possibly get the Rubyesque leaving out of
: > endpoints by saying something l
Graham Barr wrote:
Now that we have gained ^ back from being a hyeroperator, could we not
have ^ as a polymorphic complement operator. It can always be combined
with ~ or + to force context, eg
$a = ^ +$b;
$a = ^ ~$b;
We would then have a complement operator that I would assume objects cou
Michael Lazzaro wrote:
Meaning that the list:
+ - force to numeric context
- - force to numeric context, negate
+^- force to numeric context, complement
~ - force to string context
~^- force to string context, complement
simply becomes:
^ - complement (type-
Austin Hastings wrote:
?& ?| ?^ - [maybe] C-like bool operations
?&= ?|= ?^= - (result is always just 1 or 0)
[?&][?|][?^] - (hyperversions)
[?&]= [?|]= [?^]=
[?&=] [?|=] [?^=]
Two possible differences between d
Brent Dax self-deprecated:
So, the love of my life is:
Function call found where operator expected at - line 1, near
""dark & "handsome"
That figures, actually, considering my social life...
Thanks. Would the hypothetical example collector please archive the
corrected version instead:
Larry elucidated:
In general, for any type, how do you write
[$min .. $max - $step : $step]
when you don't even necessarily have subtraction defined? We don't know
how to do "z" - 1 in Perl 5, for instance.
Okay. I buy that.
Damian
Larry wrote:
Never. Truth is relative in Perl. Having a "true" literal would
imply that objects couldn't decide whether they're true or not, unless
the true literal really means a superposition of all the possible
true values of every type. Which is kinda hard to write, especially
since a typ
Larry wrote:
The set features are a side effect of junctions, just as they're a side
effect of hashes. An "any" junction might well be implemented underneath
as a hash without values.
Yep.
Possibly we might even extend the notion of hash to any "junk".
%hash = 1 | 2 | 3;
So you're su
Larry wrote:
That's almost a reduce. Pity you have to include a variable.
But since rvalues are illegal on the left side of an assignment, we
*could* go as far as to say that
0 [+=] @b; # sum
1 [*=] @b; # product
'' [~=] @b; # cat
dwim into reduce operators rather than bein
Ed Peschko wrote:
Larry Wall writes:
I think decent formatting would make it clearer:
for@a; @b
-> $x is rw; y {
$x = $y[5];
}
But this isn't very scalable:
Sure it is. You just have to think more two-dimensionally...
for @a; @b; @c; @d; @e
-> $a_variabl
Austin Hastings wrote:
In the C that I learned, the &^| ops were bitwise.
Likewise, the && || ops were lazy booleans.
So what's a single-letter boolean act like? Is it lazy? Does it retain
its bitwise-ness but (since boolean) force evaluation for 1 or 0 first?
I just don't understand what the "
Simon Cozens wrote:
On the other hand, maybe I'm being as shortsighted as Thomas J Watson
[1] and that once the various operating systems do get their Unicode
support together and we see the introduction of the 50,000 key keyboard,
Of course, scary 50K keyboards aren't really necessary. All we
Piers Cawley wrote:
So, on the train this morning, I had a moment of Satori. What's wrong
with doing what we think of as bitwise operations using the flexops
and adding a 'bitwise' context? So, a bitwise op becomes:
bitwise ( $a | $b | $c & $d );
And the superposition will collapse in a 'mas
901 - 1000 of 1282 matches
Mail list logo
