semantics. Hyperoperations
take their "magnitude" from that of their operand(s).
I would have expected the above example needed to be:
my ($a, $b) = ^new (Foo,Foo);
or maybe:
my ($a, $b) = ^new Foo x 2;
Damian
Dog $dog is rw { $dog = new Doberman }
> Err, whatever.
That works too:
for $spot, $rover{ $_ = new Doberman err whatever() }
Damian
are creating 2 new Dog
> objects.
To each his own, I guess.
> now there is no need for the rw property on $_
Not that there ever was... ;-)
> also if that is working code, then my head is getting twisted in the
> right direction. :)
Looks like. :-)
Damian
> }
>
> $sis.feed();
>
> I gave way too much thought to that. I need to go, now...
"Once you start down the Perl 6 path, forever will it dominate
your coding; consume you it will!"
;-)
Damian
rr] = $var;
or:
@arr[@arr.length] = $var;
or maybe just :
@arr[.length] = $var;
(if an array were to be made the topic inside its own accessor brackets).
Damian
PS: Thanks for the ideas, Mike! :-)
huge population of programmers out there who already use
> this notation. I frankly admit that I think of PHP as a great idea that
> wasn't done quite right.
I agree. Including that notation! ;-)
Damian
since the current topic then doesn't
hang around long enough to actually be useful. I suspect that it the clincher
against this idea.
Damian
$scalar> syntax), or you could just create a new operator with
something like:
module BinaryPush;
my sub operator:<-- is exported (@array is rw, $scalar) {
push @array, $scalar;
}
# and elsewhere...
use BinaryPush;
@arr <-- $val;
Damian
write
the same thing something like:
class Foo {
attr any(str,int) $bar;
method SETUP(any(str,int) $newBar) {
$bar = $newBar;
}
}
Damian
grammar?
Using "pattern" for the contents and "rule" for the container.
But not being too much of a stickler about either. ;-)
Damian
Trey Harris asked:
> Another one...
>
> class Foo is Bar;
>
> method a {
> setup();
> }
>
> 1;
> # EOF
>
> (Is the 1 still required?
No.
> I think I heard Damian say it was going away.)
Yes.
> The question is, is this valid, if Bar defines a
is that Errno is str, int?),
Multiple inheritance will be:
class Derived is Base1 is Base2
or possibly:
class Derived is Base1 Base2
Damian
ove a redefinition?
No. But it will surely to a compile-time error to declare two
public attributes with the same symbolic name, unless you also
declare a method of the same symbolic name (which would then
suppress the two colliding implicit method creations).
Damian
Piers Cawley wrote:
> Damian Conway <[EMAIL PROTECTED]> writes:
>
>>Multiple inheritance will be:
>>
>> class Derived is Base1 is Base2
>>
>>or possibly:
>>
>> class Derived is Base1 Base2
>
>
> How about clas
l the entire surrounding group
f #Then match an f
]
So a single colon has the same effect as the Perl 5 (?>...) metasyntax.
> I don't see why Larry describes one as "if-then", but not the other.
> Basically, I don't think I'm sure what : "gives up".
It gives up tracktracking the immediately preceding atom.
The behaviour is explained quite well in E5 I think.
Damian
ch {
print $possible_match{match}, "\n";
}
A more intriguing possibility is that the top-level match object ($0 itself)
would *also* have a 'match' key...whose value contained a superposition of all
the possible hypotheticals. So you could also just write:
print egs( $0{match} _ "\n" );
Bwah-ha-ha-ha-hah!!
Damian
Paul Marquess wrote:
> Is that the "soon to be released" E5?
No, that's the "to be released today" E5.
;-)
Damian
}
;
In other words, the second is the same as:
foo rule {$arg}, sub{ $var := <$arg> };
> Notwithstanding C<< -> >>, which I now understand to be nothing
> more than a different spelling of C.
It's a little more than that. A C<< -> >> uses different delimiters
(now *there's* a parallel!) for its parameter list. Whereas C
requires {...}, C<< -> >> allows either (...) or
Damian
track fails whole match
>
> So even shorter version:
> :/::/:::/ makes backtrack fail current atom/group/rule/match.
That's certainly a good enough approximation for everyday usage
(though the explanation of : is a little forced to fit the pattern).
Damian
hers on list] Hands up those of you who were just
> about to suggest that example, but wanted Damian to move first? :)
Ah, how kind of you all to humour an old man. ;-)
>>It's a little more than that. A C<< -> >> uses different delimiters
>>(now *there's*
equivalent "win" in allowing
subroutines to be arbitrarily delimited.
So I very much doubt we'll see it.
Damian
terns are no longer regular, but if rx isn't a
> short form of regex, what is it a short form of?
Rule eXpedient.
Damian
perhaps $x<$y, 0.25 { print "Happened to be less than\n"}
perhaps $x>$y, 0.50 { print "Happened to be greater than\n"}
without the trailing semicolons.
Damian
:=(\S+) ]/;
BTW, that doesn't actually *do* the match. It merely puts a reference
to a rule object into $stuff.
Perhaps we all actually meant variants on:
my $stuff = m/^\s* [ "$0:=(.*?)" | $0:=(\S+) ]/;
???
Damian
};
Of course, this example is trivially done with a hyperoperation:
@ squares = @nums ^** 2;
But more complex examples could easily be constructed where even C
looks clunky and a list context C would be a nice solution.
It would also solve the problem of early escape:
@smallsquares = for @nums { last if $_ > 10; $_**2 };
Damian
..} closure.
Indeed, to get a rule in a closure to even continue matching from the same
point in the string, you would need to write:
rule expr1 {
{ m:cont/@operators/ or fail }
}
Backtracking would just step back over the rule as if it were atomic
(or followed by a colon).
Damian
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
ther");
then you get:
%hash4{"Something"} = "mixing";
%hash4{"pairs"} = "and";
%hash4{"scalars"} = "together";
Damian
}
} @nums;
P6:
@special = for @nums {
next unless is_prime($_) && $_**2 % 3;
@fp1 = factors($_+1);
@fm1 = factors($_-1);
next unless @fp1=~@fm1 && @fp1>2 && @fm1>2;
$_;
}
Damian
s when we bind the result of a capturing group to a
> numeric match variable?
That's my understanding. If you *explicitly* bind a captured group to a
numbered hypothetical, then the capture doesn't also implicitly bind to
a numbered hypothetical.
Damian
/<[17]>/;
>
> or do I have to
>
> $roundor7 = rx /|<[17]>/;
Neither. You need:
$roundor7 = rx /<+[17]>/
That is: the union of the two character classes.
Damian
g and
that there's nothing actually wrong with:
my Date $date = Date.new('June 25, 2002');
And, furthermore, that you could easily define special semantics
for void-context constructor calls via undef'd but typed variables,
so that you could just write:
(my Date $date).new('June 25, 2002');
and have the interpreter autovivify the object.
Damian
tic way to select the hash assignment style
C
> and a proper definition of the default style.
See above.
And my other post on this topic.
Damian
ong::Package::Name::Ugh;
my Date $date = Date.new('June 25, 2002');
Damian
s invoked(:decomment) {
method SETUP ($data, $rule) {
...
}
# etc.
}
But, as I said, the details aren't worked out.
Or, at least, Larry hasn't revealed them, if they are. ;-)
Damian
is there any way to
> manage that?
Sure. Just use the pairs as explicit keys and values:
# Pairs as key/values...
%hash = (a=>1, b=>2);
%hash = @pairs;
# Pairs as keys and then values...
%hash{a=>1} = b=>2;
for @pairs -> $k, $v { %hash{$k} = $v }
Damian
that's the case you could call static functions as $date.foo() instead of
> Date.foo(), and therefore your constructor call would be simply
>
> my Date $date .= new('Jun 25, 20002');
H. That's a very interesting idea.
I like it.
Damian
al issue.
No. It would be creating special case syntax for
a *special* case of a general issue. ;-)
But I must say I now like Adam's
my Date $date .= new('June 25, 2002');
much more than my own proposal.
Damian
t to aliasing Really::Long::Package::Name::Ugh
> under the name 'Date', simply because the subclass hasn't redefined any
> behavior of the parent.
Yes.
> But it *is* a separate class
Yes.
> unless Damian was saying that there would be some special casing when a clas
es at all, that is.
Though I expect he probably will, since treating classes as
"first class" entities in Perl 6 implies that capability
(amongst many others).
Damian.
:= Really::Long::Package::Name::Ugh;
Damian
nd in other cases you want any pairs to remain as single
> elements be they key or pair (default behavior?).
Pairs are *always* single elements. By default when a hash is initialized with
one, it internally unpacks it. If you want anything else, you have to tell the
hash to act (i.e. by keyed) differently. Or act (i.e. code) differently yourself.
Damian
t requires binding.
> Both of them will be "undone" during backtracking. It's more
> efficient to bind, but the copy guarantees changes to $x and $1
> are independent.
This is not what Larry has said previously. He said that only
binding can be used with C variables and that only C
variable assignments are undone on backtracking.
Damian
t version of one special case,
> no?
No. It's the *only* way to set hypotheticals. Of course, you *can* always
do:
/ (gr\w+) { $x = Gr_Thing.new($1)} /
without the C, but that won't be undone on backtracking.
Damian
have to support named character
classes like , , , etc.
Damian
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
; sub hidden (int $force_tainted is named($force))
>
> # can use force_tainted as argument:
> sub hidden (int $force_tainted is aka($force))
Yes, that was the idea. :-)
Damian
n very consistent in discussions that
hypothetical bind, rather than assigning.
Perhaps he's changed his mind since, but I haven't heard anything to that
effect.
Damian
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.sama
;s what I'd like to see too. Indeed, I'd like to see the scalars
turn up in C<$o{'$name_with_dollar"}> as well. TMTOPTSI [*]
Damian
[*] There's More Than One Place To Store It. ;-)
;s plain wrong. C properties are
compile-time features. They can only be specified on declarations.
> Weird. C seems perfectly reasonable to me.
To us too. That's why we chose them for parameter defaulting as well.
Damian
ee much
greater use of C when people start developing new
algorithms and programming idioms with Perl 6.
Damian
ndard behaviour.
I find:
sub hidden (str $name, int $force is aka($override)) {...}
*much* more readable, since I can read it in English.
Damian
hy is that scalar
> different from any other scalar? Because it's hypothetical.
Yes. Because it's "reversible".
> Suddenly we've a new "class" of variable that people have to be aware of)
Yes.
Damian
expected to manipulate that structure
representation. The final state of the representation
would be used as the (post-modified) rule.
For example, perhaps the modifier would be passed the
$0 from the parser rule that parsed the rule contents.
Damian
> support for building mini languages on top of Perl 6,
> but it really looks like Perl 6 is going to become
> the de facto language prototyping tool. (Bye bye
> yacc!)
I certainly hope so!
Damian
the hands of the programmer
is generally a Bad Idea.
It's also a matter of syntactic consistency. It has to be := for
"inlined" bindings (i.e. rx/ $name:= /) because otherwise
we make = meta (which is *not* a good idea). So it probably should be
:= for explicit Cs as well.
Damian
more useful in reverse:
sub foo (@bar is aka($baz)) {
# now @bar is an array
# and $baz is an array ref
}
> Then again, if you have good reasons for the other syntax, I would be
> more than happy to hear those as well.
Then I hope this made you happy. ;-)
Damian
gils. (To allow the elimination of typeglobs)
The part about sigils being part of symbol table keys is indeed correct.
Damian
@b
> $a += $b[0], $a += $b[1], $a += $b[2], ...
I can't remember what side I argued last October (I can't remember last
October! %-) I have to say that I'm with John here. That interpretation
certainly seems more DWIM to me.
Damian
ver mind - my head just exploded.
Hang in there. If these "mixed number" Cs were allowed then I'd suggest
the semantics be that they indicate that *either* a scalar or array is
acceptable in the corresponding argument slot. The scalar variant of the
parameter would be bound to a scala
;
# so-called "active comment"...
# documents why improbable value
# used but can also be retrieved
# programmatically
$name = "Damian" but We_bette
erties must
> be part of a predefined set,
There is no such requirement. Indeed, there will almost certainly
be possible to define an property yourself (note the
capitalization). And it could quite easily cause any value assigned
to it to be ascribed C.
Damian
LT, $RX
>
> (those names aren't convincing me either, sorry).
I still think $0 is the right name for it.
> If nothing else, this would at least get rid of "one more cryptically named
>variable".
But only at the expense of adding one more arbitrarily named variable. :-(
Damian
are lazy. :-)
Damian
ion -- or
perhaps two -- that will satisfy everyone's concerns in this area (or, at
least, make everybody equally unhappy ;-)
Damian
imizes that sequence away (which probably means it can't do that
optimization in the first place (which means it should act as though it were
trying each branch and loop in the normal sequence %-))).
Of course, LMMV.
Damian
I take it that what I've learned from _Mastering_Regular_Expressions_
> doesn't quite apply here? From that interpretation I'd think it'd print
> "111\n" since the second part of the alternation wouldn't be tried.
No. It would fail to match the final C in the pattern and start
backtracking.
Damian
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 a
str
But I guess that's no worse than:
$x-=10;
and
$x=-10;
which doesn't seem to be a problem for people in Perl 5.
Damian
urns a new string with substitution performed (without affecting
the original string):
print 'He said "$( s($statement,/\.$/,"") )", but we didn't believe him.';
Damian
e ..Inf)
I'd much prefer the latter.
But note that that semantics changes it from an binary to a postfix unary operator.
trinary operators:
Nit pick: s/s//
'...' "..." `...` /.../ << >>
q qq qx qr qw
s/qr/rx/
but - [op?]val properties
Yes, it's an operator.
Damian
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 cov
themselves be larger (i.e. more easily detected).
I just need some kind soul to pat me on the head and
tell me it's OK.
;-)
(Please excuse the Monash staff member, it's been a difficult week.)
For ex-Monash staff members too. :-(
Damian
seems a lot more appealing. :)
More appealing than:
all(@array) > 6
???
No wonder you put a smiley there. ;-)
Damian
the double angles for a qw synonym.
I was hoping we'd be able to generalize << from the heredoc introducer to
the file slurp operator. But I can certainly see the attraction of:
use enum <>;
;-)
: (heredocs) - (exact format unknown)
I have a paper (coming) on that.
Damian
prod
~cat
generic reduce
Damian
r their eigenstates, in which case $x1 would give you
three states (C<1>, C<2>, and C<3>) and $x2 would give you two states
(C and C<3>).
Damian
hat the last does not work because given take only one argument.
That's right. But this does:
for "/home/temp/", $f
-> str $x , int $n {
$x ~ ["one, "two", ... , "hundreed"][$n]
}
Damian
makes it
easy to be sure when you're not sure:
+$x .| +$y # definitely bitwise OR
~$x .| ~$y # definitely charwise OR
If one were going to generalize that, one would be tempted to go the Ada
route of specifying the radix explicitly:
0123 # decimal
2:0110 # binary
8:123 # octal
16:123 # hex
256:192.168.1.0 # base 256
Amen!
Damian
e write any(any(1,2),3) if that's the
weird thing they want. I think | and & should automatically reduce
as long as you're combining similars.
Agreed.
Damian
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.
nice as this:
if $x ^ $y ^ $z == 7 {...}
which means everyone will probably write:
if none($x,$y,$z) == 7 {...}
which is probably the right solution anyway ;-)
Damian
|=^= - conjunctive, disjunctive, exclusive
all any one none - conjunctive, disjunctive, exclusive, dismissive
~~ !~- smart match, smart non-match
Damian
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
is that also bind for tr///?
That's still being discussed at the moment.
Damian
hink alike.
Acme::DWIM <http://search.cpan.org/author/DCONWAY/Acme-Bleach-1.12/lib/Acme/DWIM.pm>
gave Perl5ers exactly that, 18 months ago. ;-)
Damian
rd.
It's just set theory with a few interesting behaviour variations
that make it act more like natural English.
Much more on this in the next few posts.
Damian
operators, surely you could just do
use ops ':superpositions';
in an appropriate lexical scope. Am I missing something?
Yes. That superpositions are going to be so widely used once people
catch on, that users going to curse us every time they have to
write C at the start of every scope.
;-)
Damian
>>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 f
"orval"|"exval"|"nonval",
"opval"=> "allval"|"anyval"|"oneval"|"noneval",
"set" => "andset"|"orset"|"xorset"|"nandset",
"set" => "andset"|"orset"|"exset"|"nonset",
"set" => "allset"|"anyset"|"oneset"|"noneset",
"junction" => "conjunction"|"disjunction"|"exclusion"|"rejection",
"junctive" => "conjunctive"|"disjunctive"|"exclusive"|"dismissive",
)
Damian
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
es = $x | $y & $z;
print $out: $res, "\n"; # OOPS!
}
chmod S_IRWXU|S_IRGRP|S_IXGRP|S_IROTH|S_IXOTH, $outfile;
Damian
ll.
But does it somehow skip all entries
before/after the delimiter?
No. For that you'd want:
my $seen = $start & $finish;
for <> -> $next {
print $next if $next != $seen && $start < $next < $finish;
$seen &= $next;
}
Damian
ed to discriminate the *type* of the superposition:
letters: !any [0, 1, 2]
digits: !all
- 0
- 1
- 2
names: !one ["Brian", "Ingy", "Mr Inline"]
sane: !none
- "Larry"
- "Damian"
- "Brian"
...
Damian
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
ant:
for split(//,$instring) -> $input {
$state = $ndaTable{$state}{$input};
last unless $state;
}
print "Input string $instring has more than 3 letters and 2 digits\m"
unless $state;
Damian
PS: Is anyone collecting these examples. It would make writing that perl.com
article much easier for me ;-)
no-one's said which order they apply in. That is,
which of these should I type:
@x [+]= @y;
@x [+=] @y;
Of course, the rule ordering didn't matter with the "add a leading ^ to
hype" rule.
I think I prefer the first one, by the way -- it strikes me as more
obviously a vector add.
Yep.
Damian
would solve everything for me...and I knew
this was valid syntax.
So is this vertical layout, which I think will become fairly standard
amongst those who care about readability:
for @a ; @b
-> $x is rw ; $y { $x = $y[5] };
Damian
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
901 - 1000 of 1296 matches
Mail list logo
