Re: $_ defaulting for mutating ops
On Fri, 28 Oct 2005, Ruud H.G. van Tol wrote: Or RPN-like: $x #= 2* 1+ 3/; Being a big fan of RPN myself (and considering it quite natural), I'd appreciate very much such a feature. I had asked myself about RPN features in P6, albeit in a probably unreasonable fashion: http://www.nntp.perl.org/group/perl.perl6.language/17556 Michele -- [about penis-enlargement spam] Suppose you (applies to male readers only!) had taken advantage of every offer of the above type received, and all had worked as claimed. Estimate how long it would be. - Derek Holt in sci.math (slightly edited)
Re: should roles be parameterized?
On Sat, 29 Oct 2005, Christopher D. Malon wrote: For the non-mathematically inclined: A field is a set with two binary operations, + and *. Under either operation (+ or *), the set is an abelian (= commutative) group, and a field has a distributive property: a * (b + c) = a*b + a*c. An easy example is the set of real numbers, with + being addition and * being multiplication. Not exactly. With the exception of _the_ trivial case (up to a natural isomorphism there's only one!) a field is _not_ a multiplicative group wrt its multiplication, given that the identity for the addition can't have a multiplicative inverse. This is of some relevance of so called Universal Algebra in which some commonly used structures (e.g. a group, a ring) can be described in terms of sets of n-ary operations obeying a set of algebraic identities, whereas certain other just as common structures (e.g. a field) can't - and a more complex approach is needed. This may be of some interest here too, since there's been some talking about the algebra of methods of a role that any class which Cdoes that role guarantees to obey by doing so. So this should take into account the possibility of algebrai relations not defined everywhere, which may bring a new level of complexity in realistic situations... Michele -- I'm finding now in my 40s that the less makeup I wear, the better. I think softer is better as you get older. With everything. Except men. - Kim Cattrall
Re: $_ defaulting for mutating ops
On Fri, 28 Oct 2005, John Williams wrote: But IMHO the reduction in typing for this relatively minor issue is not really worth the surprise to newbies at seeing operandless operators. I don't buy that argument as newbies are already exposed to all sorts of surprises including operandless operators. Including mutating operandless operators. What is s/// after all? Or is there a good reason for an asymmetry between different classes of operators? Michele -- = (But it is impossible to even imagine an operating-system which would = not crash before the sun has burned all of its hydrogen, let alone not = crash before the end of the universe.) I find it hard to imagine an operating system which would not crash before the end of the week - Gerry Myerson in sci.math
syntax-variants, RPN (was: Re: $_ defaulting for mutating ops)
Michele Dondi: Ruud H.G. van Tol: Or RPN-like: $x #= 2* 1+ 3/; Being a big fan of RPN myself (and considering it quite natural), I'd appreciate very much such a feature. I had asked myself about RPN features in P6, albeit in a probably unreasonable fashion: http://www.nntp.perl.org/group/perl.perl6.language/17556 I understand that Perl6 allows blocks with changed/enhanced syntax, so it is or will become possible (to add it) as if it was in the core language. Do I understand that right? Something as simple as a 'use RPN' in a block? (assuming that someone created such an RPN-pre-processor or -compiler) -- Grtz, Ruud
Re: $_ defaulting for mutating ops
On Wed, 2 Nov 2005, Michele Dondi wrote: On Fri, 28 Oct 2005, John Williams wrote: But IMHO the reduction in typing for this relatively minor issue is not really worth the surprise to newbies at seeing operandless operators. I don't buy that argument as newbies are already exposed to all sorts of surprises including operandless operators. Including mutating operandless operators. What is s/// after all? Or is there a good reason for an asymmetry between different classes of operators? Well, s/// is a term, for one thing. It is not so much an operator, as it is a subroutine with really strange syntax, and the side-effect of changing the $_ variable. You need to use an operator to get it to affect a different variable. It looks funny no matter how much you squint your eyes. Not that that is a bad thing of course, but I don't think it should be used as an example for operators to follow. ~ John Williams
Re: $_ defaulting for mutating ops
On Wed, 2005-11-02 at 11:46 -0700, John Williams wrote:
It is not so much an operator, as it is a subroutine with really strange
syntax, and the side-effect of changing the $_ variable. You need to use
an operator to get it to affect a different variable.
operators _are_ subroutines. There is no difference.
multi sub *infix:* (Set $one, Set $two) returns Set {
$one.intersection($two);
}
Sam.
Re: $_ defaulting for mutating ops
On Wed, 2005-11-02 at 09:03 -0500, Rob Kinyon wrote: I think the difference comes from the Principle of Least Surprise. The various operators being discussed in this thread are all operators which are in languages that have common use - C, C++, Java, the .Net stack, etc. Regexen and the various built-ins are generally considered to be Perl-specific, so if they're weird, this is just a Perl-ism. The PoLS doesn't apply. Yes, from a consistency point of view, ALL operators should default to $_ or some other sensible item ($*STDIN for , etc). However, the PoLS does need to guide our decisions. I think the PoLS should be applied firstmost and foremost to a person who is learning the language without any preconceptions of how previous languages work. The logical building blocks of how the language works should build on each other; the fewer exceptions relative to *those foundations* the better. Specifically, catering for the preconceptions of how the language behaves as a whole to those trained in lower order languages like you mention (though is .net a language?) should probably be avoided. That being said, there are probably other more pressing reasons that ops should not accept $_ as default; I would guess, for a start, it makes determining semantics very difficult. Does ++; mean postfix:++ or prefix:++ ? Sam.
Re: $_ defaulting for mutating ops
Sam Vilain skribis 2005-11-03 11:01 (+1300): Does ++; mean postfix:++ or prefix:++ ? I no longer think $_ defaulting for mutating ops is a good idea, but to answer your question, read the original post: all these would imply the LHS, so that makes ++ postfix. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Role Method Conflicts and Disambiguation
On Tue, Nov 01, 2005 at 04:02:04PM -0800, Jonathan Lang wrote:
True enough; but it needn't be true that d have the same tools
available to resolve the conflicts that c has.
There are three ways that a role can deal with a conflict:
1. choose one of a set of available methods to call its own.
2. create a version of its own.
3. pass the buck.
In the first case, the question is how we define the set of available
methods: do we make the full hierarchy of ancestors available to the
role, or do we say that only the immediate parents are available?
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 of two other roles has full
view of the methods/attributes defined in the roles that compose it
because the landscape is quite flat. There are no hills and valleys.
When it finally comes down to composing into a class, the class sees
all of the methods/attributes provided by each and every role even the
role inside a role inside a roles.
Another way to put this would be: should the DOESA list be treated
as public or private? (My preference: the DOESA list should be
private. You don't lose any capabilities by doing so, other than the
capability to access stuff not explicitly declared - a capability that
roles don't need, and probably shouldn't have.) If DOESA is
private, then d won't have access to anything from a or b without
explicitly including them in its own DOESA list. This seems to be
restrictive, and it is - but only in the same way that making an
attribute private is restrictive.
When you say:
role A { ... }
role B { ... }
role C does A does B { ... }
role D does C { ... }
roles A and B are composed into C at compile time. If both A and B
define a method foo(), then there is a conflict (immediately, at
compile time) unless you've somehow told perl that it should defer
composition until it's actually composing classes.
What's really at question I think is whether the _default_ is to compose
immediately or to postpone composition until there's a class to compose
into. If you have roles that are never composed into classes, then it
won't matter if there's a conflict as you can't instantiate a role (not
without first turning it into a class). So, on one hand it does make
sense to defer composition until there's a class to compose into. But
it also makes sense to deal with composition conflicts incrementally
too (as roles are composed into other roles).
The second case is pretty straightforward.
And isomorphic to the first case as it is the resolution to the first
case.
In the third case, I'd be inclined to say that passing the buck is
equivalent to creating an undefined version of your own - that is, not
addressing a conflict involving method x is equivalent to saying
method x ($arg) { ... }. IOW, a class that does a role that passed
the buck is faced with an undefined method complaint if it doesn't
do something about it, not an unresolved conflict complaint.
Nah, the third case is ye olde standard conflict, just perhaps occurring
at a different space+time than had the roles been composed immediately.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Role Method Conflicts and Disambiguation
On Wed, Nov 02, 2005 at 16:37:29 -0600, Jonathan Scott Duff wrote: On Tue, Nov 01, 2005 at 04:02:04PM -0800, Jonathan Lang wrote: True enough; but it needn't be true that d have the same tools available to resolve the conflicts that c has. There are three ways that a role can deal with a conflict: 1. choose one of a set of available methods to call its own. 2. create a version of its own. 3. pass the buck. In the first case, the question is how we define the set of available methods: do we make the full hierarchy of ancestors available to the role, or do we say that only the immediate parents are available? 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. Uh, roles are composed wrt to the hierarchy of who does who. In my world view, a role that is composed of two other roles has full view of the methods/attributes defined in the roles that compose it because the landscape is quite flat. There are no hills and valleys. When it finally comes down to composing into a class, the class sees all of the methods/attributes provided by each and every role even the role inside a role inside a roles. The composition is basically mixin with some exceptions, but there's still a hierarchy roles A and B are composed into C at compile time. If both A and B define a method foo(), then there is a conflict (immediately, at compile time) unless you've somehow told perl that it should defer composition until it's actually composing classes. Class composition also happens at compile time... There's no reason to make the error occur too early for usefulness to be around. As long as it's not too late ;-) -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: : neeyah! pgpABuzitn7pL.pgp Description: PGP signature
Re: Role Method Conflicts and Disambiguation
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 of two other roles has full
view of the methods/attributes defined in the roles that compose it
because the landscape is quite flat. There are no hills and valleys.
When it finally comes down to composing into a class, the class sees
all of the methods/attributes provided by each and every role even the
role inside a role inside a roles.
-snip-
When you say:
role A { ... }
role B { ... }
role C does A does B { ... }
role D does C { ... }
roles A and B are composed into C at compile time. If both A and B
define a method foo(), then there is a conflict (immediately, at
compile time) unless you've somehow told perl that it should defer
composition until it's actually composing classes.
Let's say you have this:
role A {method foo() { code1; } }
role B {method foo() { code2; } }
role C does A does B {
method foo() { A::foo(); }
method bar() { B::foo(); }
}
Should the following be valid?
role D does C { method foo() { B::foo(); } }
IMHO, it shouldn't, because D doesn't do B.
--
Jonathan Dataweaver Lang
Re: Role Method Conflicts and Disambiguation
On 11/2/05, Jonathan Lang [EMAIL PROTECTED] wrote:
Let's say you have this:
role A {method foo() { code1; } }
role B {method foo() { code2; } }
role C does A does B {
method foo() { A::foo(); }
method bar() { B::foo(); }
}
Should the following be valid?
role D does C { method foo() { B::foo(); } }
IMHO, it shouldn't, because D doesn't do B.
Of course it should. To me, role D does C says, not anything that
does D must do C, but anything that does D does C.
It makes sense if you think of them as interfaces. Say you have a
role Complexifiable (that is, this thing can behave like a complex
number). Then you have:
role Numifiable does Complexifiable {
...
}
Complexifiable is just an abstraction that is used rarely; most things
will implement Numifiable. But if you can behave like a real number,
certainly you can behave like a complex number. But you don't want
people to have to say:
class Foo {
does Complexifiable; # wtf? what does that mean
does Numifiable;
...
}
Haskell makes a distinction between the two cases we're talking about here:
-- You need to be Complexifiable before you can be Numifiable
class (Complexifiable a) = Numifiable a where
...
-- Anything that is Numifiable is also Complexifiable
-- (by these rules):
instance Numifiable a = Complexifiable a where
...
To me, does is much more like the latter. Maybe we have constraints
on roles that can do the former[1]:
role Numifiable {
where Complexifiable;
...
}
Or maybe we don't, and if you need them to implement Complexifiable
first, you just leave some methods undefined that they have to define
themselves, thus completing the interface. I was always annoyed at
Haskell because I had to define an instance of Eq before I could
define an instance of Ord, even though Ord's algebra implies that I
can compare things for equality (and especially, since Ord defines a
total order, that a = b and b = a implies a = b, so it could have
implemented that for me).
It kind of seems like a Perlish thing to do to blur the two behaviors
together.
Luke
[1] Which is just this theory, without any extensions:
theory Numifiable{^T} = Complexifiable{^T} {
...
}
So it would just be sugar in any case.
