Seg, 2008-04-28 às 10:15 -0700, Jon Lang escreveu:
Ah; that clears things up considerably. If I understand you
correctly, John is using '£' to mean use Duck Typing here. _That_,
I can definitely see uses for.
hrmm... I might just be overlooking something... but...
sub foo (Point $p) {...}
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
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 quite clear
[ 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
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' operator
Ter, 2008-04-29 às 21:03 -0500, John M. Dlugosz escreveu:
In response to questions on my whitepaper, I made this companion
to bring people up to speed on the issue.
http://www.dlugosz.com/Perl6/web/isa-inheritance.html
Very interesting reading... :)
It actually made me think that it would be
Qua, 2008-04-30 às 15:55 +0200, TSa escreveu:
But the type system is part of the language core.
As such 'isa' and 'like' or assignment and binding semantics
need a definition.
Actually, this is one of the hardest parts of implementing Perl 6,
because even 'isa', 'like', assignment and binding
Qua, 2008-04-30 às 08:56 -0700, Ovid escreveu:
I had initially thought this, but think about the case where someone
wants to rewrite something to be compliant to another interface. If I
pass a CGI::Simple object to a method expecting a CGI object, there's
an excellent chance that it will
Sex, 2008-05-02 às 14:38 +0200, TSa escreveu:
Ovid wrote:
However, the CGI/CGI::Simple example I posted earlier doesn't fulfill
this. CGI::Simple offers a subset of CGI.pm's functionality and it's
guaranteed to be identical
Then, since classes are open, the programmer can easily say
Qua, 2008-04-30 às 12:53 -0400, Brandon S. Allbery KF8NH escreveu:
It occurs to me that this shouldn't be new keywords, but adverbs, i.e.
``is :strict Dog''.
I don't really see what this is :strict means in the runtime
environment. Perl 6 takes OO so deeply that even the type checking is
Sex, 2008-05-02 às 18:55 +0200, TSa escreveu:
For me, too. But note that we should keep does the ultimate
type checker that first checks the declared presence of a role,
then falls back to a declared class inheritance and then falls
back to a declared emulation. What else should be in this
Sex, 2008-05-02 às 21:49 +0200, TSa escreveu:
Daniel Ruoso wrote:
In fact, it simply means that it's up to that object's metaobject to
answer that, and not to a supra-meta-model to be able to answer to all
of the possible metamodel implementations.
Since all three forms are derived from
Sex, 2008-05-02 às 09:08 -0500, John M. Dlugosz escreveu:
A syntax is needed for this express concept: accept B as a substitute
for A, without changing A.
Which I'm advocating as
class CGI::Simple realises CGI { ... }
or
CGI::Simple is also { realises CGI }
or even...
Sex, 2008-05-02 às 21:22 +0200, TSa escreveu:
Or do you mean backwards in the sense that the priority is with the
object somehow?
In fact, it simply means that it's up to that object's metaobject to
answer that, and not to a supra-meta-model to be able to answer to all
of the possible
Hi,
When implementing prototype OO, the HOW for objects with different
behaviours will be shared. This issue is not new, but before we thought
that it would be possible to solve that by forcing $foo.HOW to be a
proxy object that would rewrite the call putting $foo as the invocant.
Me and
Sáb, 2008-06-07 às 16:01 +0200, Stéphane Payrard escreveu:
what is the equivalent convention for yadayadayada in regex. Cuz ...
is alread meaningful in regex. Should I use ... or {...} ?
Should the first be predefined?
If I understand correctly, {...} should already be parsed as a yada yada
Seg, 2008-06-09 às 23:36 +0100, Ovid escreveu:
--- Jonathan Worthington [EMAIL PROTECTED] wrote:
By default, block parameters (including $_) are readonly,
I hope that is a deep readonly? In other words, if $_.position returns
an array reference, can I mutate a value in that reference and the
Seg, 2008-06-09 às 17:51 -0700, Larry Wall escreveu:
On Sat, Jun 07, 2008 at 09:49:03PM +0100, Daniel Ruoso wrote:
: 2) Assume the capture-translation and define that
: $foo.HOW.can($foo,'bar') keeps the $how as the invocant and must receive
: the referring object as first argument.
I prefer
Sáb, 2008-06-14 às 09:20 -0700, Larry Wall escreveu:
On Sat, Jun 14, 2008 at 01:46:10PM +0200, Moritz Lenz wrote:
: Fallback semantics in S12 suggest that since no matching multi method is
: found, subs are tried - that is, the expression is interpreted as
:join('str', 'other_str')
:
Qui, 2008-06-26 às 16:03 +0200, Moritz Lenz escreveu:
In the test suite there are some tests like this:
is(1.WHAT, 'Int', '1 as a literal is an Int);
This seems to imply that we guarantee the direct type of literals. But
do we?
Actually I see no need for that. All my programs work fine if the
Ter, 2008-09-09 às 10:10 -0500, Patrick R. Michaud escreveu:
I think my question can be best understood by example -- what
does the following produce?
my @a = 1,2,3,4,5;
for @a { .say; @a = (); }
The problem actually becomes more evident with
my @a = 1,2,3,4,5;
for @a { .say;
Qui, 2008-09-11 às 12:13 -0700, Larry Wall escreveu:
And I guess the fundamental underlying constraint is that a list cannot
be considered immutable unless its feeds can be considered immutable,
at least in some kind of idempotent sense. This conflicts with the
whole point of reactive
Ter, 2008-09-16 às 18:04 +0200, TSa escreveu:
I think that mutating methods of immutable value types just have
to modify the identity. The problem is how that relates to references.
Take e.g. the Str type
I really think we are looking at this problem from the wrong
perspective.
For an Object
Qui, 2008-09-18 às 18:11 +0200, TSa escreveu:
Shouldn't there be a warning in B that $!B::bar overwrites $!A::bar
without an accessor?
Actually, $!B::bar doesn't overwrite $!A::bar... the problem is simply
that $!A::bar is not visible from inside B, and therefore, there's
nothing to be
Sex, 2008-09-19 às 17:49 +0200, TSa escreveu:
Daniel Ruoso wrote:
Qui, 2008-09-18 às 18:11 +0200, TSa escreveu:
Shouldn't there be a warning in B that $!B::bar overwrites $!A::bar
without an accessor?
Actually, $!B::bar doesn't overwrite $!A::bar... the problem is simply
that $!A::bar
Sex, 2008-09-19 às 17:49 +0200, TSa escreveu:
Daniel Ruoso wrote:
Qui, 2008-09-18 às 18:11 +0200, TSa escreveu:
Shouldn't there be a warning in B that $!B::bar overwrites $!A::bar
without an accessor?
Actually, $!B::bar doesn't overwrite $!A::bar... the problem is simply
that $!A::bar
Sex, 2008-09-19 às 10:25 -0700, Jon Lang escreveu:
Daniel Ruoso wrote:
In SMOP, it is handled based on the package of the Class, the private
storage inside the object is something like
$obj.^!private_storageA::$!bar
and
$ojb.^!private_storageB::$!bar
Note that this ought only
Qui, 2008-10-02 às 12:55 +0100, Tim Bunce escreveu:
Like applying XPath to an XML DOM, only more general and taken
further.
By more general and taken further I'm thinking of the same kind of
evoltion from simple regular expressions in perl5 to grammars in perl6.
An XPath query is like a perl5
Hi,
First of all, sorry for breaking the thread, but I had some trouble with
my mail provider, and couldn't hit the reply button.
To the point...
I think there are some things that are simply not solved by abstraction.
Some problems are concrete problems that need concrete solutions,
filesystem
Timothy S. Nelson wrote:
Should laziness/eagerness be a property of the operator?
I'm inclined to believe that the level of lazyness or eagerness is
determined by the operators in question, at least that had worked for
assignment and feeds, I can't think of a case where something else
determines
Sex, 2008-11-28 às 14:23 -0300, Daniel Ruoso escreveu:
You write: my $item = =$foo;
Does that get one item from the iterator object?
It depends on the iterator in question, but it certainly gets something
(unless the iterator is over, of course), I'm thinking on the following:
I thought
Em Seg, 2008-12-01 às 18:21 -0800, Darren Duncan escreveu:
I'm wondering how to write anonymous value literals of some Perl 6 basic
types,
and I didn't see mention of this in synopsis 2.
Getting away from your question entirely, I think the issue here is that
while Perl 6 has support for
Em Dom, 2008-12-07 às 18:10 +0100, Carl Mäsak escreveu:
The above reasoning raises the following question for me: how do I
return from a sub or a method from within a map block?
I suppose what you want can be achieved with last, it probably should
work in map as well, since map and for are
Em Seg, 2008-12-08 às 12:08 +0100, Carl Mäsak escreveu:
Daniel (), Carl ():
That is all good and well for exiting the map itself; but what I want
to achieve is to exit the surrounding sub or method block. Example:
Er... I mean actually the opposite... it should always return from the
Hi,
I've been thinking about how I would implement module loading in SMOP
and reached some points that I think need some clarification. The most
important of them being about the EXPORTALL routine.
While all the default exportation is done by the population of the
EXPORT inner package, that
Em Sex, 2008-12-12 às 18:40 -0600, Patrick R. Michaud escreveu:
On Fri, Dec 12, 2008 at 08:42:05PM -0300, Daniel Ruoso wrote:
[...]
While all the default exportation is done by the population of the
EXPORT inner package, that doesn't happen from the outside, S11 implies
that it happens
Hi,
One of the hardest features in Perl 6 is the slice context. It is
undoubtfully usefull, since it provides semantics to acces each
iteration of a map, for instance.
But there's one thing in the spec that makes not only slices, but the
lists themselves considerably harder to implement, and
Em Ter, 2008-12-16 às 18:47 +0100, TSa escreveu:
# the following will require a flatenning to get the actual index
say @a[3];
Could we not shift the problem into a more complicated form
of the size of the array? Here it has size 0+3+0 but each of the
summands could be lazy and hence
Em Qua, 2008-12-17 às 15:00 +1100, Timothy S. Nelson escreveu:
My basic assumption is that there's going to be some kind of packaging
system written around 6PAN.
Please take a look in some notes I've written some time ago:
http://www.perlfoundation.org/perl6/index.cgi?DistributionFormat
Em Qua, 2008-12-17 às 23:35 +1100, Timothy S. Nelson escreveu:
On Wed, 17 Dec 2008, Daniel Ruoso wrote:
Em Qua, 2008-12-17 às 15:00 +1100, Timothy S. Nelson escreveu:
My basic assumption is that there's going to be some kind of packaging
system written around 6PAN.
Please take a look
Em Qui, 2008-12-18 às 11:38 +0100, Mark Overmeer escreveu:
In the current state of affairs, CPAN is limited to Perl5 and strongely
entangled by Perl5 install tools. Do we want to have people install
Perl5 on their (maybe small) machine before they can install Perl6 stuff?
Rpm-tools and
Em Qui, 2008-12-18 às 13:08 +1100, Timothy S. Nelson escreveu:
My question is, what sort of information actually belongs in a final
version of the 6PAN spec? I'm assuming it will at least include 6PAN Package
format (layout, metadata, etc), and I'd suggest that it also include the
Em Seg, 2008-12-22 às 15:06 +1100, Timothy S. Nelson escreveu:
On Sat, 20 Dec 2008, Mark Overmeer wrote:
For ???B. In the current set-up, you use CPAN.pm to download, and then
install. The 'cpan' script is a wrapper around CPAN.pm. CPAN.pm starts
the install tool. A more convient
Hi,
As smop and mildew now support ControlExceptionReturn (see
v6/mildew/t/return_function.t), an important question raised:
sub plural { return 1,2 }
sub singular { return 1 }
my @a = plural();
my $b = plural();
my @c = singular();
my $d = singular();
What should @a, $b, @c and $d
Em Dom, 2008-12-28 às 00:31 -0500, Jeff Horwitz escreveu:
the modules it uses assume they're embedded in an apache process,
dlfunc'ing a bunch of apache API functions.
I think that means the 'dlfunc' calls need to be in INIT and not in
BEGIN.
right now it is impossible to compile such a
Hi,
Captures are sensitive things, they can only be used as-is inside a
scalar, otherwise you have to enforce a context and it is no longer a
capture, but one of the views of its content.
for instance...
sub foo {
...
return @thingy, :named($value);
}
sub bar($capture) {
my
Em Sex, 2009-01-02 às 08:34 -0300, Daniel Ruoso escreveu:
token routine_def:coro {...}
Actually, I was just looking at STD, and the correct token would be
token routine_declarator:coro { sym routine_def }
I was also looking at the spec files, and I realized that DRAFT S17
mentions
Em Qui, 2009-01-01 às 12:34 -0800, Geoffrey Broadwell escreveu:
In the below Perl 5 code, I refactored to pull the two halves of the PID
file handling out of init_server(), but to do so, I had to return a sub
from pid_file_handler() that acted as a continuation. The syntax is a
bit ugly,
Em Dom, 2009-01-04 às 14:53 +0100, Carl Mäsak escreveu:
$ parrot languages/perl6/perl6.pbc --target=pir --output=B.pir B.pm
$ parrot languages/perl6/perl6.pbc --target=pir --output=A.pir A.pm
Remember, remember, the fifth of November
current instr.: 'die' pc 14950
Em Seg, 2009-01-05 às 07:57 -0800, Dave Whipp escreveu:
my $ace = 1 | 11;
my $seven = 7;
my @hand = $ace xx 3, $seven;
my $junc_value = [+] @hand; ## any( 10, 20, 30, 40 )
There are a bunch of possible values in the junction. The one we care
about is the largest that is not
Em Seg, 2009-01-05 às 20:32 +0100, Moritz Lenz escreveu:
Daniel Ruoso wrote:
would force item context in the capture, and here is the problem, as a
capture in item context was supposed to return the invocant.
Maybe we could have a different rule for captures in scalar contexts
that don't
Em Ter, 2009-01-06 às 11:28 -0800, Jon Lang escreveu:
Of course, that's only a third of the problem. What should people
expect with each of these:
Hmm... I think that takes the discussion to another level, and the
question is:
what does a capture returns when coerced to a context it doesn't
Em Qui, 2009-01-08 às 13:42 +1100, Timothy S. Nelson escreveu:
On Wed, 7 Jan 2009, Jon Lang wrote:
How would I define the method for writing to an iterator?
I guess I'd assumed that writing to an iterator wouldn't be possible,
as there are kinds of iterators where writing to them makes
Em Seg, 2009-02-02 às 09:37 -0800, Larry Wall escreveu:
It's also not clear how this should interact with buffering systems
like stdio. But in any case, speaking directly to the IO stack is
likelier to give consistent results than playing mix-n-match with
various calls on the IO stack that
Em Seg, 2009-02-02 às 13:51 +0100, Leon Timmermans escreveu:
On Mon, Feb 2, 2009 at 1:05 PM, pugs-comm...@feather.perl6.nl wrote:
-the latter case C$! is set).
+the latter case C$! is set). The C:async flag lets the call
+return an undefined value if no character is immediately available.
Em Seg, 2009-02-02 às 15:12 -0800, Larry Wall escreveu:
Roles are good, but what is this Char thing of which you speak? It
seems good neither for Unicode characters nor for keystroke sequences. :)
I meant exactly in the sense of providing one of those abstractions, let
me rephrase it:
role
Em Ter, 2009-02-03 às 10:34 +0300, Richard Hainsworth escreveu:
f) radical suggestion:
if the syntax '=$filehandle' lazily takes something from the file
handle, then
$filehandle = output;
should send something to it.
Problem is that this meeses up with assignment, which is an operation in
Em Qua, 2009-02-04 às 16:45 +, Aaron Crane escreveu:
pugs-comm...@feather.perl6.nl writes:
+=item method Int read($buf is rw, int $length)
I'm not sure that using a native int is the right thing here. If
whatever the implementation uses as int is narrower than size_t, that
forces the
Em Sex, 2009-02-06 às 02:07 -0500, Brandon S. Allbery KF8NH escreveu:
+=head2 IO::POSIX
+
+Indicates that this object can perform standard posix IO operations.
I don't like that wording, but getting it right seems tricky.
Do we want/need to deal with POSIX conformance levels?
When I
Em Sáb, 2009-02-14 às 17:39 +1100, Timothy S. Nelson escreveu:
Hi. I've been trying to help reorganise the draft S16, as I'm also in
the process of writing something roughly equivalent to Net::Cmd in Perl6. I
have some questions.
First question, how do IO::Encoded and eg.
Em Sáb, 2009-02-14 às 18:01 +0100, Leon Timmermans escreveu:
On Sat, Feb 14, 2009 at 6:38 AM, pugs-comm...@feather.perl6.nl wrote:
+=head2 IO::Openable
+This role implies that the object can be connected to, or listened on.
I'm not sure if I really hate or love this. I'm not quite convinced
Em Seg, 2009-02-16 às 17:28 +1100, Timothy S. Nelson escreveu:
Say I wanted to write a POP3 server. I want to receive a username and
password from the client. I want things to be interruptable during this, but
it's also impossible to sensibly roll things back like they were before the
Em Seg, 2009-02-16 às 21:21 -0800, Darren Duncan escreveu:
marking it as consisting of just immutable values, and in the
routines case marking it as having no side effects
The problem is that you can't really know wether a value is immutable or
not, we presume a literal 1 to be immutable, but
Em Ter, 2009-02-17 às 09:19 -0300, Daniel Ruoso escreveu:
multi infix:+ (int where { 2 } $i, int where { 2 } $j) {...}
As masak++ and moritz++ pointed out, this should be written
multi infix:+ (int $i where 2, int $j where 2) {...}
daniel
Em Ter, 2009-02-17 às 22:38 +1100, Timothy S. Nelson escreveu:
My third thought is that it would be very useful also to have
date/time objects that integrate well with eg. ctime, mtime, and the like;
I'd
start with Time::Piece as a model.
Em Qui, 2009-02-19 às 22:57 +1100, Timothy S. Nelson escreveu:
Interesting. I'm happy to assume that $root is allowed to be
Undefined, I think. But let me ask a question; were you to represent an
unrooted tree in a computer, how would you do it so that, if you had to look
around the
Em Sex, 2009-02-20 às 11:19 +1100, Timothy S. Nelson escreveu:
if(! defined($footree.root)) { warn Unrooted tree; }
There are some other very interesting possibilities:
unless ($footree.can(root)) { warn Unrooted tree; }
or even better
unless ($footree ~~ RootedTree) { warn Unrooted
Em Qui, 2009-02-19 às 15:58 -0800, Larry Wall escreveu:
That being said, I'm thinking that all actual times represented by
floats in Perl are TAI time, not the Unix pseudo time with hidden
leap seconds. I sure wish they'd done away with civic leap seconds
in 2000 and said we'll put in a leap
Em Sex, 2009-02-20 às 10:40 -0600, Dave Rolsky escreveu:
On Fri, 20 Feb 2009, Daniel Ruoso wrote:
If we're going to use an epoch, it should be the Operating System's
epoch. Anything else will lead to confusion and disorder ;P
And which OS epoch would that be?
The one where the program
Em Sex, 2009-02-20 às 10:17 -0800, Larry Wall escreveu:
By the by, I'm also inclined to agree with those who prefer Instant
to DateTime on aesthetic grounds.
I should note that I'm insisting on DateTime just as the reference p5
module in CPAN, I don't oppose it being called Instant in Perl 6.
Em Sex, 2009-02-20 às 10:53 -0800, Larry Wall escreveu:
Perhaps we could just go with Instant and Duration as top-level roles
since they're rather fundamental to lots of computing. As builtins
they would presumably come with appropriate operators predefined. And
as roles they could be
Em Seg, 2009-02-23 às 19:49 -0800, Larry Wall escreveu:
On Tue, Feb 24, 2009 at 04:01:40PM +1300, Martin D Kealey wrote:
: Conceptually I think they should all go in add-on(s), however I suspect that
: when an exception is thrown inside a signal handler, cleanly unwinding the
: call chain will
Em Ter, 2009-02-24 às 13:34 -0800, Jon Lang escreveu:
Daniel Ruoso wrote:
if $y ~~ [..] $x ± $epsilon {...}
Junctions should not return individual values in list context,
It is not the junction that is returning the individual values, but the
infix:± operator...
daniel
Em Qui, 2009-02-26 às 22:26 +1100, Timothy S. Nelson escreveu:
given(any(@!)) {
}
using junctions on exception handling doesn't seem like a good idea to
me, because it is too much of a basic feature... but...
for @! {
}
might provide the needed semantics...
OTOH, I think it would be sane to
Em Qui, 2009-02-26 às 08:55 -0300, Daniel Ruoso escreveu:
for @! {}
might provide the needed semantics...
After sending this mail I've just realized I don't know exactly which
are the needed semantics...
what happens if you have several unthrown exceptions in the block, does
it throw every one
Em Qui, 2009-02-26 às 17:01 +0100, TSa escreveu:
$y.error = 0.001;
$x ~~ $y;
Looking at this I just started wondering... why wouldn't that be made
with:
my $y = 10 but Imprecise(5%);
$x ~~ $y;
daniel
Em Seg, 2009-03-02 às 17:04 +1100, Timothy S. Nelson escreveu:
Hi. I note that we have $?OS, $?VM, and $?DISTRO (and their $*
counterparts). I'd like to recommend that we eliminate $?OS, and replace it
with $?KERNEL (ie. Linux) and maybe $?ARCH (ie. i386). Thoughts?
The usual way to
Em Seg, 2009-03-02 às 23:47 +1100, Timothy S. Nelson escreveu:
On Mon, 2 Mar 2009, Daniel Ruoso wrote:
So, I think the proper name to the variables would be
$?ARCH and $*ARCH
Where they would stringify to the arch triplet, while providing
convenience methods for .cpu, .platform and .os
Em Seg, 2009-03-02 às 10:39 -0300, Daniel Ruoso escreveu:
Em Seg, 2009-03-02 às 23:47 +1100, Timothy S. Nelson escreveu:
Are we talking about $?VM vs. $?XVM here?
Well, yes... that adresses $?HOST_PERL and $?TARGET_PERL... but still
leaves $?HOST_ARCH and $?TARGET_ARCH, assuming not all
Em Qui, 2009-03-05 às 12:58 -0300, Daniel Ruoso escreveu:
What really got me confused is that I don't see what problem this change
solves, since it doesn't seem that a signature that expects an invocant
(i.e.: cares about invocant) will accept a call without an invocant, so
method foo($b,$c
Em Qui, 2009-03-05 às 18:43 -0800, Jon Lang escreveu:
OK; let me get a quick clarification here. How does:
say Hello, World!;
This is the equivalent to
say.postcircumfix:( )( \(Hello, World) );
differ from:
Hello, World!.say;
This is just
Hello, World!.say;
Meaning, the first
Em Sex, 2009-03-06 às 18:51 +0100, TSa escreveu:
I know that the use of 'is also' is called monkey patching but I can't
understand why this is regarded as a bad thing. Having a class assembled
from multiple modules is a rather normal affair.
You're describing Roles here, which is something you
Em Dom, 2009-03-08 às 21:31 -0700, Larry Wall escreveu:
I think the basic rule has to be simply can the signature bind to
the remaining arguments. If not, we get a warning on unused arguments.
Just to put here an idea I sent on irc...
What if Signature.ACCEPTS set $/ with the matched
Em Seg, 2009-03-09 às 12:24 -0700, Larry Wall escreveu:
On Mon, Mar 09, 2009 at 02:40:43PM -0300, Daniel Ruoso wrote:
: ... $capture ~~ $signature ...;
: my $args_matched = @($/).elems;
: code.(|$/);
That API still would not tell the match whether signature must match the
entire
Em Qui, 2009-03-12 às 10:28 -0700, Larry Wall escreveu:
On Thu, Mar 12, 2009 at 08:51:45AM -0700, Ovid wrote:
: From: David Green david.gr...@telus.net
: I suppose, but is there a reason why you want to apply roles instead of
coercing
: the results?
: Because I am coming from Moose
Em Qui, 2009-03-12 às 19:07 +0100, Jonathan Worthington escreveu:
IIRC, that's a special syntactic form that only counts when it is on the
RHS of but or does. (And yes, in this case it fails if the role has more
than one attr...) I think in all other cases, it's a coercion.
hmm...
for some
Em Qui, 2009-03-12 às 11:49 -0700, Larry Wall escreveu:
In addition to what Jonathan said, it is possible that the ability
to coerce multiple arguments depends on the type itself, since we
probably want to allow Foo(1,2,3) and such for listy types that
don't necessarily want to use the [1,2,3]
Em Qua, 2009-03-18 às 18:50 -0700, Larry Wall escreveu:
On Wed, Mar 18, 2009 at 06:32:18PM -0700, Jon Lang wrote:
: +method !eigenstates (Junction $j: -- List)
:
: Shouldn't that be lowercase-j junction?
Maybe, though there might be a Junction role involved for subtype
matches like
Em Sex, 2009-03-20 às 14:08 +0100, Jonathan Worthington escreveu:
It's probably a minor issue, but part of me wants Junction to be OK too
for explaining stuff. Telling people the default parameter type is Any,
to accept anything they can write Object and to accept just junctions
you write
Em Seg, 2009-03-23 às 21:47 -0700, Darren Duncan escreveu:
If you're going for sciencey or mathey illustrations, then I think its
important
to include something that speaks quantum physics in there, since quantum
superpositions aka Junctions are one of the big central user features that
Em Ter, 2009-03-24 às 09:01 -0300, Daniel Ruoso escreveu:
A zombie cat?
While I wasn't really serious about it...
attachment: cat.svg
Em Ter, 2009-03-24 às 09:17 -0400, Mark J. Reed escreveu:
Are we seeking a logo for Perl 6 in general or Rakudo in particular?
It seems like the latter should be derived from the former, perhaps
with the Parrot logo mixed in.
are you suggesting that the cat should be eating a parrot in the
Em Qua, 2009-03-25 às 23:11 -0500, jason switzer escreveu:
S01 says that perl5 code will be supported via use v5. Can someone confirm
that embedded perl5 code is still required of any valid implementation?
I wouldn't think it would be a really bad idea if inline use v5 inside
Perl 6 code to be
Em Sex, 2009-03-27 às 13:36 +0300, Richard Hainsworth escreveu:
On #perl6, rouso, masak and moritz_ explained that I am incorrectly
thinking about junctions as sets and that for this task I should be
using another perl idiom, namely lists.
Sorry for not taking each individual point on your
Em Sex, 2009-03-27 às 08:57 -0300, Daniel Ruoso escreveu:
So I get that we do need some cool support for sets as well, I mean...
no collapsing, no autothreading... but maybe some specific behaviors...
As an aditional idea...
multi infix:⋃(Set $a, Set $b) {...}
multi infix:⋂(Set $a, Set $b
Em Sex, 2009-03-27 às 09:17 -0400, Mark J. Reed escreveu:
From a high-level perspective, the blackjack example seems perfect for
junctions. An Ace isn't a set of values - its one or the other at a
time. It seems to me if you can't make it work with junctions - f you
have to use sets instead
Em Sáb, 2009-03-28 às 16:17 +1100, Damian Conway escreveu:
Nested heterogeneous junctions are extremely useful. For example, the
common factors of two numbers ($x and $y) are the eigenstates of:
all( any( factors($x) ), any( factors($y) ) )
I think that's the exact case where we should be
Em Sáb, 2009-03-28 às 13:36 +0300, Richard Hainsworth escreveu:
Daniel Ruoso wrote:
The thing is that junctions are so cool that people like to use it for
more things than it's really usefull (overseeing that junctions are too
much powerfull for that uses, meaning it will lead to unexpected
Em Dom, 2009-03-29 às 22:57 -0700, Mark Lentczner escreveu:
What I see here is that there is a tendency to want to think about,
and operate on, the eigenstates as a Set, but this seems to destroy
the single value impersonation of the Junction.
Further, if one ever calls .!eigenstates() on
Em Ter, 2009-03-31 às 22:54 -0700, Jon Lang escreveu:
Yes, I know that there is no S08. I'm working on writing one, and I'd
like some feedback to help me do so.
++
My draft is going to be about Signatures and Captures. Thus, my questions:
Invocants:
The concept of invocant only exists in
1 - 100 of 158 matches
Mail list logo
