HaloO,
John M. Dlugosz wrote:
C++ worked on that issue for years in committee. CLOS has decades of
hindsight. Proposing ranking rules is a challenge for another day, but
those are my source material thus far.
Hmm, C++ dispatch rules are rather trivial. From the static type of the
pointer an
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
Where do you get the information from that the second is more
specific than the former? Consider
constant Num $c = 3; # Num here is funny
my Num $n = 3;
my Int $i = 3;
my Any $a = 3;
And now $i is more specific than
HaloO,
John M. Dlugosz wrote:
You want a way to declare the function to accept both lvalue and
non-lvalue items, and determine at run-time whether it can write back to
it.
Yes, but as a general feature. Any assignment checks the constraint
of the lvalue. A non-writeable lvalue is simply havin
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
Ohh, conceptually we should split the 'r' and 'w' in 'rw'.
The r part is for the value going in. The w part is conceptually
part of the *return* type of the function. The convenience for the
caller lies in the fact that she doesn't have to extract
HaloO,
John M. Dlugosz wrote:
But, I'm thinking along the lines of Pascal and C++. You can't pass a
non-lvalue "by reference", period. (5)++ is just plain wrong.
Hmm, I would like the error to show up *within* the body of ++. Your
idea is to statically derive the error from the 'is rw' trait
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
Finally combine that with the wish to allow literals of class A. Let's
assume the grammar is patched to parse integer literals as As. Then
with the above 7.inc gives an error because 7 is not mutable. So as
I outlined before I want to care for the
HaloO,
John M. Dlugosz wrote:
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
multi infix:<=> (Any $lhs, A $rhs)
{
$lhs.STORE($rhs.clone); # or .cow if that's not automatic
}
$lhs.VAR.STORE.
I guess I also forgot the is rw to get a binding to the caller's
container not
HaloO,
Daniel Ruoso wrote:
[ I'm using this message to reply, because I didn't receive your
reply... I'm taking it from the list history... There really seems to be
something wrong with this list... ]
I see all your messages arrive twice.
This is not specced apparently to leave room for dec
Ter, 2008-04-29 às 14:21 +0200, TSa escreveu:
> Daniel Ruoso wrote:
> > Not really... 'does' is a composition operation, 'realises' would be
> > just a type annotation that doesn't change the actual composition.
> OK, but that is not in the spec yet. To me that is like the
> proposed 'like' operato
[ I'm using this message to reply, because I didn't receive your
reply... I'm taking it from the list history... There really seems to be
something wrong with this list... ]
TSa wrote:
> BTW, is WHICH globally unique? Or is that also an
> implementation detail?
This is not specced apparently to
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
multi infix:<=> (Any $lhs, A $rhs)
{
$lhs.STORE($rhs.clone); # or .cow if that's not automatic
}
$lhs.VAR.STORE.
My readings have been that = just copies the ref. Unless it's a "value
type" or "immutable" which just means
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
HaloO,
Daniel Ruoso wrote:
Not really... 'does' is a composition operation, 'realises' would be
just a type annotation that doesn't change the actual composition.
OK, but that is not in the spec yet. To me that is like the
proposed 'like' opera
HaloO,
Daniel Ruoso wrote:
So...
class A { has $.a; method inc { $.a++ } };
$a = A.new( a => 0);
$b = $a;
$b.inc();
$a.inc();
say $a.a; # 2
say $b.a; # 2
Will work as expected.
Depends a bit on one's expectations :)
So infix:<=> has shallow copy semantics.
HaloO,
Daniel Ruoso wrote:
Not really... 'does' is a composition operation, 'realises' would be
just a type annotation that doesn't change the actual composition.
OK, but that is not in the spec yet. To me that is like the
proposed 'like' operator but with the programmer taking full
responsibi
Hmm, I'm not seeing the message from Daniel, just this reply.
I like the idea of having a class method primitive to provide some
functionality. But type matching is more complex, as you can list
multiple types juxtaposed.
sub foo (A B £ C ::T $param)
and the actual match means does A, do
Ter, 2008-04-29 às 11:54 +0200, TSa escreveu:
> > If we are to define an operator to declare that some arbitrary object
> > conforms to some API, I would think the following as saner...
> > sub foo(Point $p) {...};
> > FoxPoint $fp = ...;
> > $fp realises Point;
> > foo($fp);
> Here the spec is q
Ter, 2008-04-29 às 09:28 +0200, TSa escreveu:
> The thing is the .^does traverses the meta information
> to find the *named* concept Point. The FoxPoint in John's
> example doesn't have that and thus nominally fails the
> Point test. The idea is now to also have
.^does *might* traverse the infor
HaloO,
Daniel Ruoso wrote:
.^does *might* traverse the information as well as simply return true if
the object says so.
Let's not regard the problem of meta level interoperation for now.
That is we have *one* meta level. The spec says that .^does asks
this meta system. Now the meta system does
HaloO,
Daniel Ruoso wrote:
hrmm... I might just be overlooking something... but...
sub foo (Point $p) {...}
means...
$signature ~~ $capture
means...
Point $p := $capture[0]
means...
$capture[0] ~~ Point
means...
$capture[0].^does(Point)
The thing is the .^does traverses the meta info
19 matches
Mail list logo
