Dave Whipp wrote:
I'm thinking that the solution to this issue may be a little more
radical than to-date: don't permit junctions to be stored in $
variables! Instead, require junctions to use a twiggle, to alert the
reader that the surprises may be lurking.
my $x = 1|2; #error
my $|x = 1|2; #
cdumont wrote:
> In japanese it could even be :
>
> wa {
> '' no baai ni { ... }
> }
>
> Getting rid off the thema or I guess here taking $_ as the default.
>
> is this possible :
>
> given $operator {
> '' {}
> '' {}
> }
>
> ?
>
>
If Larry doesn't mind me elbowing into th
Paul Seamons wrote:
On closer inspection, is it even possible to add a Role to a Class at
runtime?
If it isn't now, I would certainly like to have a hook available through
MOP (which is, to the best of my knowledge, still unspecified).
I thought that Class and Role composition outside
Aaron Sherman wrote:
In the RFC, I was trying to develop a method by which a module could
assert a stricture (consider this part of "use strict" in Perl 6 if you
will) that would constrain the CALLER of that module (as well as the
module itself, of course) to a particular signature template for
Aaron Sherman wrote:
I certainly hope not, as I agree with you! That's not the goal at all,
and in fact if that were a side effect, I would not want this to be
implemented. The idea of having types AT ALL for protos was something
that I threw in because it seemed to make sense at the end. The re
TSa wrote:
> role Set[::T = Item] does Collection[T] where {
> all(.members) =:= one(.members);
> };
Nice usage of junctions!
But buggy - one means *exactly* one. So for an array of more than 1
element, all(@array) never equals one(@array) - if they're all the same,
it's more tha
[EMAIL PROTECTED] wrote:
+=head1 Cross operators
+
+The final metaoperator is the C metaoperator. It applies the
+modified operator across all permutations of its list arguments. All
+C operators are of list infix precedence, and are list associative.
+
+The bare form of C is considered an ope
[EMAIL PROTECTED] wrote:
We can't. The problem is that:
foo .bar
has to mean:
foo($_.bar)
So the only way to allow whitespace in dot operations is to put it
after the dot.
Damian
I believe Larry's latest updates to Synopses allow for some syntactic
categories to be disabled in
[EMAIL PROTECTED] wrote:
: class Dog {
: method tail { "brown and short" }
: };
:
: class Chihuahua is Dog {
: has $.color;
: method tail { $.color _ " and short" }
: };
:
: You can say Dog.tail, Dog.new.tail, Chihuahua.new.tail, but not
: Chihuahua.tail. That's extremely counter-int
[EMAIL PROTECTED] wrote:
Jonathan Lang wrote:
Instead of
multi sub *infix:<~>(ArabicStr $s1, ArabicStr $s2) {...}
multi sub *infix:<~>(Str $s1, ArabicStr $s2) {...}
multi sub *infix:<~>(ArabicStr $s1, Str $s2) {...}
as S13 say
multi sub infix:<+> (Us $us, Them $them) is c
[EMAIL PROTECTED] wrote:
If so then my and Eric's wishes are answered:
when { $_ > 5 } { ... }
when { .caloric_value > $doctors_orders } { ... }
This isn't implemented in pugs yet, but I guess it can be once this is
clarified.
Actually
when $_ > 5 { ... }
when .caloric_valu
[EMAIL PROTECTED] wrote:
U... I'm not sure that allowing $. injection from the nested
blocks is a good thing. I don't think it's ambiguous, but to me it
looks weird and confusing - if a user put the variable in the nested
block like that, it's almost certain he actually meant to write
Disclaimer: I don't ~~ @larry :)
[EMAIL PROTECTED] wrote:
class Bar {
our $.bar;
{
my $.foo;
}
}
I assume that the leading "$." is what makes the difference, however,
IIRC the "$." is just part of the name, and no more special than
that. Which means that I can choose th
[EMAIL PROTECTED] wrote:
I think what bothers me most about this is that it seems there is no
way to tell the difference between class methods and instance
methods. That the distinction is only made when the body of the
method does something which is is not supposed to do (method called
[EMAIL PROTECTED] wrote:
Stuart Cook skribis 2005-10-10 22:58 (+1100):
@args = (a => 1, get_overrides());
foo([EMAIL PROTECTED]);
Not if you want that a=>1 to be a named argument.
Under the proposal, the only ways to pass a named argument are:
1) By using a literal pair in the synt
[EMAIL PROTECTED] wrote:
Would this work too?
0 but role {}
Most certainly, but you would have no way to refer to that role later,
so it is questionable how useful that construct is. No, it's not
questionable. That is a useless construct.
Luke
Can an inline role be named?
0 b
[EMAIL PROTECTED] wrote:
I'm not bashing your idea, because I think it has uses. But I'll
point out that all of these can be easily accompilshed by writing a
wrapper for open(). That would be the usual way to abstract this kind
of thing.
My take on this: resumable exceptions break encaps
Playing with pugs, I ran into this corner case:
sub f($x) { say $x; }
f {1}.(); # ok, outputs 1
sub f([EMAIL PROTECTED]) { say @_; }
f {1}.(); # outputs block, tries to call a method from the return of say,
dies
Whitespace after f doesn't change the behaviour (in either case). Is this
behaviour
[EMAIL PROTECTED] wrote:
And that was never quite resolved. The biggest itch was with
operators that have no identity, and operators whose codomain is not
the same as the domain (like <, which takes numbers but returns
bools).
Anyway, that syntax was
$sum = [+] @items;
And the more genera
[EMAIL PROTECTED] wrote:
So how *do* I pass an unflattened array to a function with a slurpy parameter?
I don't ~~ @larry, but my guess(es) would be bar([EMAIL PROTECTED]) or
bar([EMAIL PROTECTED])
Miro
[EMAIL PROTECTED] wrote:
I don't think that a role has a long and a short name. This is
because they aren't subject to MMD. I think of them more as
beeing expanded like C++ templates even though the actual mechanism
will be much more sophisticated. Actually I think of them as F-bounds
as well ;)
Uh
[EMAIL PROTECTED] wrote:
Er, isn't that not just the wrong way around? The point is to do the
bookkeeping that an object is needed that does .meth() and that it
is stored in $a, and to complain when that is not the case when it
should be. The earlier the better.
I don't understand why writing 'my X
[EMAIL PROTECTED] wrote:
pugs too lazy
Miroslav Silovic noticed that closing a file handle in pugs did not
force all the thunks associated with the file. While this was a bug in
pugs, it led to conversation about whether = should be lazy or eager.
Larry thinks that it will be safer
[EMAIL PROTECTED] wrote:
On the other hand, we can alternatively specify that closing a
file handle must force all thunks associated to it, i.e. in this
case fill @lines with real data. Pugs can do that just fine, but I
have no idea how parrot is to achieve that...
But it gets worse.
my $lines
[EMAIL PROTECTED] wrote:
for [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] -> $x { say $x };
should work. Are there any non-slashy versions of this?
I'd guess
for @a; @b; @c -> $x { say $x;}
or
for (@a; @b; @c) -> $x { say $x;}
(are parens mandatory here?)
Miro
[EMAIL PROTECTED] wrote:
Ok. If you'd really need such random dispatch, it could be done like
this, when I interpret A12 correctly:
sub run_random_bar($x) {
my @meths = WALKMETH($x, :method('bar'));
my $meth = @meths[rand(@meths.elems)];
$meth($x);
}
or even with
my sub bar($x) {...}
[EMAIL PROTECTED] wrote:
What about multi subs? They can be defined everywhere. Given:
multi sub *foo(A $a, B $b) {...}
Is this something like:
%globals{"foo"} --> MultiSub{"foo_A_B" => Sub, ...}
What about a not so global multi:
multi sub foo(A $a, B $b) {...}
Thanks for clarifying,
leo
Uh
[EMAIL PROTECTED] wrote:
It would behave like a tied sub (or method), with a .dispatch method
to decide which of the contained routines should be called this
particular time. Manhattan would be the default. However, one can
override the dispatch logic; implementing Luke's Patterns idea, for
exa
[EMAIL PROTECTED] wrote:
i think so but i can't read larry's mind (nor would i want to! :)
XP = extreme programming
DBC = design by contract (or even designed by conway :)
MP = ??
Modular Programming
David
I think it's Metaprogramming. :)
Miro
[EMAIL PROTECTED] wrote:
What if junctions collapsed into junctions of the valid options under
some circumstances, so
my $x = any(1,2,3,4,5,6,7);
if(is_prime($x) # $x = any(2,3,5,7)
and is_even($x) # $x = any(2)
and $x > 2) # $x = any()
This is Just Wrong, IMO. How confusing is it going to be to f
[EMAIL PROTECTED] wrote:
Yes... but perhaps instead of the above transform we should just make
sure that < is transitive in the first place... so that no matter what
if a
Partial ordering relations are also transitive by definition.
Of course, you can overload '<' to be something other than orde
[EMAIL PROTECTED] wrote:
Well, we see the same kind of thing with standard interval arithmetic:
(-1, 1) * (-1, 1) = (-1, 1)
(-1, 1) ** 2 = [0, 1)
The reason that junctions behave this way is because they don't
collapse. You'll note the same semantics don't arise in
Quantum::Entanglement (whe
[EMAIL PROTECTED] wrote:
Yup. My mathematic intuition cannot suffer that:
4 < X < 2
to be true in any circumstances -- as it violates associativity.
If one wants to violate associativity, one should presumably *not*
use the chained comparison notation!
So Pugs will evaluate that to (#f|#f), by
[EMAIL PROTECTED] wrote:
pugs> ? 4 < (0 | 6) < 2
(#t|#f)
Here's my take on it.
Compare
my $a = (0 | 6);
say 4 < $a and $a < 2;
vs
say 4 < (0 | 6) and (0 | 6) < 2;
The difference is that in the first case the junction refers to the same
object, and the result should probably be expanded on
[EMAIL PROTECTED] wrote:
However, I wonder how to talk about an array that can contain elements
of any value type, but all the elements must have the same type.
Is Perl6 capable of expressing such a restraint?
Thanks,
/Autrijus/
The problem (in general) with this requirement is that it conflicts
[EMAIL PROTECTED] wrote:
I'll show you. Here are some of the generators. This is very dense,
functional code. Read at your own risk (but I'm certainly not writing
it to be executed!).
Quite. ;)
For the regexp /a aa aaa a aa/, this would sequentially
search through all possible ways
On Tue, 2004-09-21 at 02:52 -0600, Luke Palmer wrote:
> If you replace the first line:
>
> method Rule::Group::generate(Int $n) {
>
> With
>
> multi generate (Rule::Group $group: Int $n) {
>
> Everything ought still to work.
>
> I think the best you can do is to implement it as a routi
On Wed, 2004-09-15 at 12:47 -0700, [EMAIL PROTECTED] wrote:
> Grammar roles?
>
> Larry
Hmm, actually a few questions on the topic:
S5 doesn't specify whether grammars can have attributes. Can they? Can
they have methods, or at least local subs, to call from the code within
the rules?
Can gramma
38 matches
Mail list logo
