-bits.pod
Log Message:
---
s/Failure/undefined/ for decrement on sets/bags
-setting-library/Containers.pod
Log Message:
---
say how to turn pairs/hashes into sets/bags
-setting-library/Containers.pod
Log Message:
---
sets and bags are object based, use === semantics
-setting-library/Containers.pod
Log Message:
---
sets and bags don't flatten in list context
:
---
[S02] be more explicit about iterating sets/bags
The intent has always been that when you use a set or bag as a list,
it behaves as a list of its keys, regardless of any underlying hash
interface it might also respond to. You must use .pairs explicitly
to get the hash pairs out of a
Darren Duncan wrote:
> If a list is a set, does that mean that a list only contains/returns each
> element once when iterated? If a list can have duplicates, then a list
> isn't a set, I would think. -- Darren Duncan
Thus Mason's point about Bags. Really, I think that Mason's right in
that we sh
yary wrote:
I think of a list conceptually as a subclass of a set- a list is a
set, with indexing and ordering added. Implementation-wise I presume
they are quite different, since a set falls nicely into the keys of a
hash in therms of what you'd typically want to do with it.
If a list is a set
alling for.
This. Really, as long as Set does Iterable, it's not as important if
it's treated as hash-like or list-like - though I'd still prefer to
deal with @sets rather than %sets. Conceptually, it feels like a
better fit.
--
Jonathan "Dataweaver" Lang
Sorry:
I meant capable *in theory*. It's not in the spec right now for Sets or Bags.
On Oct 25, 2010, at 08:41 PM, Mason Kramer wrote:
> That sounds like a subclass of Bag to me.
>
> But I don't think that thinking about who is subclassing whom is is how to
> think abou
ld be calling for.
On Oct 25, 2010, at 08:08 PM, yary wrote:
> +1 on this
> On Mon, Oct 25, 2010 at 4:56 PM, Jon Lang wrote:
>> As for the bit about sets vs. lists: personally, I'd prefer that there
>> not be quite as much difference between them as there currently is.
&g
yary wrote:
> +1 on this
> On Mon, Oct 25, 2010 at 4:56 PM, Jon Lang wrote:
>> As for the bit about sets vs. lists: personally, I'd prefer that there
>> not be quite as much difference between them as there currently is.
>> That is, I'd rather sets be usable w
+1 on this
On Mon, Oct 25, 2010 at 4:56 PM, Jon Lang wrote:
> As for the bit about sets vs. lists: personally, I'd prefer that there
> not be quite as much difference between them as there currently is.
> That is, I'd rather sets be usable wherever lists are called for, wit
On Sun, Mar 29, 2009 at 1:18 PM, John Macdonald wrote:
> On Sat, Mar 28, 2009 at 10:39:01AM -0300, Daniel Ruoso wrote:
>> That happens because $pa and $pb are a singular value, and that's how
>> junctions work... The blackjack program is an example for sets, not
>> junc
On Sat, Mar 28, 2009 at 10:39:01AM -0300, Daniel Ruoso wrote:
> That happens because $pa and $pb are a singular value, and that's how
> junctions work... The blackjack program is an example for sets, not
> junctions.
>
> Now, what are junctions good for? They're good
Henry Baragar wrote:
> The blackjack program is an excellent example for junctions (and not so good
> for sets, IMHO). The problem in the example above is that the calculation
> of the value of a hand was not completed. The complete calculation is as
> follows:
>
>
e, and that's how
junctions work... The blackjack program is an example for sets, not
junctions.
The blackjack program is an excellent example for junctions (and not so
good for sets, IMHO). The problem in the example above is that the
calculation of the value of a hand was not completed. The co
Thomas Sandlaß wrote:
> Set operations are with parens.
Which Synopsis is this in?
--
Jonathan "Dataweaver" Lang
On Sat, Mar 28, 2009 at 6:39 AM, Daniel Ruoso wrote:
> 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
>>
HaloO,
On Friday, 27. March 2009 12:57:49 Daniel Ruoso wrote:
> 1 - multi infix:<+>(Set $set, Num $a)
> This would return another set, with each value of $set summed with $a.
I think that this mixed case should numify the set to
the number of elements to comply with array semantics.
infix:<+> sho
= [+] @a;
my $pb = [+] @b;
if ($pa <= 21 && $pb <= 21) {
if ($pa > $pb) {
# B0RK3D
}
}
That happens because $pa and $pb are a singular value, and that's how
junctions work... The blackjack program is an example for sets, not
junctions.
Now, what are junctions
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
behaviors at some point).
What are the general boundaries for jun
On Fri, Mar 27, 2009 at 11:45 AM, Mark J. Reed wrote:
> Given two
> junctions $d and $p, just adding $d + $p gives you all the possible
> sums of the eigenstates. Given two sets D and P, is there an equally
> simple op to generate { d + p : d ∈ D, p ∈ } ?
Dropped a P there - shoul
it work with junctions - f you
>> have to use sets instead - then there's something wrong with the
>> implementation of junctions.
>
> That seems as naiive as saying "regular expressions are for parsing
> text, and if you can't parse XML with regular exp
Mark J. Reed wrote:
> 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 - then t
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
>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 - then there's something wrong with the
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:<
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
Mark Stosberg wrote:
> S12 describes a feature to call sets of methods at the same time:
>
> http://feather.perl6.nl/syn/S12.html#Calling_sets_of_methods
>
> I would like the spec to clarify what happens to the return values of
> all these methods.
>
> I'm fine
S12 describes a feature to call sets of methods at the same time:
http://feather.perl6.nl/syn/S12.html#Calling_sets_of_methods
I would like the spec to clarify what happens to the return values of
all these methods.
I'm fine with a simple answer, such as that they are not available, or
On Tuesday 29 August 2006 13:26, Jonathan Lang wrote:
> Perl6 handles both object-orientation (through inheritance) and
> role-playing (through composition).
What exactly does inheritance have to do with object orientation, except that
some OO systems support inheritance? Plenty of OO systems g
I accidently sent this directly to Richard. Sorry about that, folks...
-- Forwarded message --
From: Jonathan Lang <[EMAIL PROTECTED]>
Date: Aug 29, 2006 1:24 PM
Subject: Re: Classes / roles as sets / subsets
To: Richard Hainsworth <[EMAIL PROTECTED]>
Richard Hain
On 8/29/06, Daniel Hulme <[EMAIL PROTECTED]> wrote:
Perl up to 5 may be executable line
noise, but I can see Perl 6 being the closest thing yet to executable
maths, and I love it.
Funny, I could have sworn APL was the closest thing yet to executable maths.
( Hey, wait a minute, I'm American;
> See diagram case 2 (Class A and Class B intersect):
> & B are built from a role that represents their intersection ( Class
> A U Class B), and then code is added in the definitions of the
It may be just me being confused, but the symbol that looks like a U
(U+222a) is usually union; intersect
e' the png.
I find classes and roles, and multiple inheritance in general, difficult
to understand. Larry Wall talked about subsets, so I have tried to
analyse various situations using the idea of sets and subsets and Venn
diagrams for demonstrating the relations between sets and subsets. T
On Thu, 26 May 2005, Patrick R. Michaud wrote:
The continuing exchanges regarding junctions, and the ongoing tendency
by newcomers to think of them and try to use them as sets, makes
me feel that it might be worthwhile to define and publish a standard
C class and operations sooner rather than
Patrick R. Michaud wrote:
> The continuing exchanges regarding junctions, and the ongoing tendency
> by newcomers to think of them and try to use them as sets, makes
> me feel that it might be worthwhile to define and publish a standard
> C class and operations sooner rather than lat
nctions, and the ongoing tendency
by newcomers to think of them and try to use them as sets, makes
me feel that it might be worthwhile to define and publish a standard
C class and operations sooner rather than later in Perl 6
development. This might reduce the tendency to confuse junctions
with
;. It was pointed out recently how one could derive a
"Set" class from a Disjunction type, implementing the few things that Sets
can do that Disjunctions can't. Put this in a module, and a simple "use
Set" at the start of your script is all that
adding non-boolean predicates. For instance, some
Numeric predicates could be: min, max, sum, mode, median, mean, stdev.
String predicates could be: min, max, longest, shortest. Basically any
function which can take several results and merge it into a single value
again can be a predicate.
BT
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> my %seen is shape(IO) of Bool; # %seen maps IO objects to boolean
values
DC> while get_next_input_stream() -> $in {
DC> next if %seen{$in};
DC> $text ~= slurp $in;
DC> %seen{$in} = 1;
DC
%seen is shape(IO) of Bool; # %seen maps IO objects to boolean values
while get_next_input_stream() -> $in {
next if %seen{$in};
$text ~= slurp $in;
%seen{$in} = 1;
}
> In addition, a set evaluated in a list context returns it's members.
Err...then how do you cre
Aldo Calpini wrote:
Damian Conway wrote:
>@s = 'item' _ [EMAIL PROTECTED];
That's:
@s = 'item »_« @x;
(just checking that my unerstanding is correct, don't want to be
nitpicking :-)
assuming that you meant to prepend the string "item" to each element of
@x, isn't that:
@s = 'i
ssion in the 'unless'.
C< say > does not get the junction as a parameter. But C< say > needs to
be marked that it's a no-no to thread over it.
> - If you wanted to thread a junction in a non-boolean way, you probably
> didn't want a junction. You likely
Juerd writes:
> Damian Conway skribis 2005-02-22 22:13 (+1100):
> > >@x = func($a, [EMAIL PROTECTED]);
> > That's:
> > @x = ÂfuncÂ($a, @y);
> > But, y'know, this one almost convinces me. Especially when you consider:
> > sub func ($i, $j, $k) {...}
> > @x = func($a, [EMAIL PROTEC
On Tue, 22 Feb 2005, Larry Wall wrote:
On Mon, Feb 21, 2005 at 10:32:15PM -0800, Jonathan Lang wrote:
: ...then you've got the notion of Fuzzy Logic Sets, where the key would be
[snip]
But using values for degree of membership is an interesting idea.
On the other hand, if we ever have nu
Damian Conway wrote:
>@s = 'item' _ [EMAIL PROTECTED];
That's:
@s = 'item »_« @x;
(just checking that my unerstanding is correct, don't want to be
nitpicking :-)
assuming that you meant to prepend the string "item" to each element of
@x, isn't that:
@s = 'item' »~« @x;
?
furthe
Juerd wrote:
Naievely, I'd expect
my @a = @b = 1..3;
»foo«(@a, @b)
to result in
foo(@a[0], @b[0]),
foo(@a[1], @b[1]),
foo(@a[2], @b[2]);
but
foo([EMAIL PROTECTED], [EMAIL PROTECTED])
with the same arrays in
foo(@a[0], @b[0]),
foo(@a[0], @b[1]),
foo(@a[0], @b[2]),
Damian Conway skribis 2005-02-22 22:13 (+1100):
> >@x = func($a, [EMAIL PROTECTED]);
> That's:
> @x = »func«($a, @y);
> But, y'know, this one almost convinces me. Especially when you consider:
> sub func ($i, $j, $k) {...}
> @x = func($a, [EMAIL PROTECTED], @z);
Naievely, I'd ex
; protection is shallow. If the call is not in the text of the evaluated
> expression, it is not guaranteed to be tested.
I need to think about this. I'm not sure I'm convinced this isn't covered by
none(Junction) typing on parameters.
> - If you wanted to thread a junction in
On Mon, 21 Feb 2005, Jonathan Lang wrote:
There are a couple of problems: first, a hash's keys are limited to
strings; a set ought to be able to handle a wider range of data types.
Well, if I had learnt something about Perl6 it is that it is no longer
necessarily so.
Michele
--
It's also amazing
(25,14,32))) --->
any(is_prime(sqrt(25)),
is_prime(sqrt(14)),
is_prime(sqrt(32))
)
The rule for what to thread is to take the smallest enclosing boolean
expression around the junction as possible. This expansion cannot extend
past a single statement.
Sets
Despite
On Mon, Feb 21, 2005 at 10:32:15PM -0800, Jonathan Lang wrote:
: ...then you've got the notion of Fuzzy Logic Sets, where the key would be
: the prospective element and the value would be the degree of membership.
: For fuzzy sets, hashes seem to be a better fit than junctions, which have
Jonathan Lang <[EMAIL PROTECTED]> wrote:
> There are a couple of problems: first, a hash's keys are limited to
> strings; a set ought to be able to handle a wider range of data types.
Last time I checked, there was going to be a way to declare a
different data type for the key (which could easily
Larry Wall wrote:
> Michele Dondi wrote:
> : Jonathan Lang wrote:
> : > > If we want Sets in Perl, we should have proper Sets.
> : >
> : > I'll agree, depending on what you mean by "proper". I'd be
> : > interested in having some me
On Mon, Feb 21, 2005 at 11:01:45AM -0800, Larry Wall wrote:
>
> But rather than that, I suspect we'll see more use of constructs
> where the object to be mutated ends up being the topic, as in:
>
> some_complicated_lvalue() but= { .sortmyway(foo($_),bar($_)) }
>
> which would presumably do t
On Mon, Feb 21, 2005 at 03:07:34PM +0100, Michele Dondi wrote:
: On Sun, 13 Feb 2005, Jonathan Lang wrote:
:
: >> If we want Sets in Perl, we should have proper Sets.
: >
: >I'll agree, depending on what you mean by "proper". I'd be interested in
: >having s
On Mon, Feb 21, 2005 at 03:11:12PM +0100, Michele Dondi wrote:
: On Mon, 14 Feb 2005, Michele Dondi wrote:
:
: >Speaking of which, while I think that methods on the implicit topicalizer
: >and the C<.=> assignement operator are indeed cool, I wonder if any
: >provision will be made for a conveni
On Mon, 14 Feb 2005, Michele Dondi wrote:
Speaking of which, while I think that methods on the implicit topicalizer and
the C<.=> assignement operator are indeed cool, I wonder if any provision
will be made for a convenient stand in for "whatever is on the left side of
an assignment operator", e
On Sun, 13 Feb 2005, Jonathan Lang wrote:
If we want Sets in Perl, we should have proper Sets.
I'll agree, depending on what you mean by "proper". I'd be interested in
having some means to perform set operations in perl6: unions,
intersections, differences, membershi
Thomas Sandlaß wrote:
class Source[Language ::To] is Str {
multi sub *coerce:as (Any $data, To ::Lang) {
return Lang.serialize($data)
}
}
What is the return type of &*coerce:as?
Sorry, I was too lazy (well, I'd claim I was thinking at a much higher level,
but i
HaloO Damian,
you wrote:
Actually, I'd have thought that the type coercion mechanism might be a
more appropriate way to go here. After all, the serialization of a data
structure is merely a coercion to a subtype of Str. Specifically, I
imagine a parameterized Source subtype:
class Source[Langua
Larry wrote:
> Actually, I'm thinking we should just go with a single method and
> have it merely default to :lang. But .repr is rather ugly.
> How 'bout .pretty instead? If we made the language the first optional
> argument you could have $x.pretty('Lisp'), $x.pretty('C#'), etc.
Hm, maybe we
On Wed, Feb 16, 2005 at 10:12:43PM -0800, Larry Wall wrote:
: On Wed, Feb 16, 2005 at 10:07:34PM -0800, chromatic wrote:
: : On Wed, 2005-02-16 at 08:54 -0800, David Wheeler wrote:
: :
: : > And what of .c#?
: :
: : It's an alias for .java.
:
: I'm sorry, but neither of those is powerful enough
On Wed, Feb 16, 2005 at 10:07:34PM -0800, chromatic wrote:
: On Wed, 2005-02-16 at 08:54 -0800, David Wheeler wrote:
:
: > And what of .c#?
:
: It's an alias for .java.
I'm sorry, but neither of those is powerful enough to represent Perl
data structures. ;-)
Larry
On Wed, 2005-02-16 at 08:54 -0800, David Wheeler wrote:
> And what of .c#?
It's an alias for .java.
-- c
On Feb 15, 2005, at 11:16 PM, Larry Wall wrote:
I admit that calling the .brainf*ck method is problematic several
ways...
And what of .c#?
Regards,
David
On Tue, Feb 15, 2005 at 09:34:31PM -0600, Patrick R. Michaud wrote:
> On Tue, Feb 15, 2005 at 07:20:53PM -0600, Jonathan Scott Duff wrote:
> > > Patrick R. Michaud wrote:
> > > >OTOH, what happens with...?
> > > >
> > > > sub nofun($x is rw) {
> > > > $x += 2;
> > > > }
> > > >
> > > >
On Tue, Feb 15, 2005 at 07:20:53PM -0600, Jonathan Scott Duff wrote:
: For the case where a junction is stringified, I would imagine that the
: Junction's C or C (ala python) method gets called and it does
: something appropriate.
The C method is called C<.perl> in Perl, assuming you want a
Perl r
On Tue, Feb 15, 2005 at 07:20:53PM -0600, Jonathan Scott Duff wrote:
> > Patrick R. Michaud wrote:
> > >OTOH, what happens with...?
> > >
> > > sub nofun($x is rw) {
> > > $x += 2;
> > > }
> > >
> > > $y = 3 | 4;
> > > nofun($y);
>
> That's either an error ("Can't modify constant") o
On Tue, Feb 15, 2005 at 05:49:44PM -0600, Rod Adams wrote:
> >As you've written things above, C is autothreaded (your option #3),
> >and we'll see two C output lines if $DEBUG is set.
>
> The case of Damian's response in a prior message:
> [...]
> Could easily be achieved with a single layer of
On Tue, Feb 15, 2005 at 05:49:44PM -0600, Rod Adams wrote:
> Damian Conway wrote:
> >
> >That would be disturbing if that's what happened.
> >C is just a shorthand for C.
> >So saying a junction is the same as printing it, which is a run-time
> >error.
>
> Could easily be achieved with a single l
Patrick R. Michaud wrote:
On Tue, Feb 15, 2005 at 03:07:53PM -0600, Rod Adams wrote:
I see it this way:
When perl sees a function call, and one of the arguments is a junction,
there are three basic options:
1) If the junction is wrapped up in some larger container, like a slurpy
list, pass it
David Storrs writes:
> On Tue, Feb 15, 2005 at 11:06:51AM -0800, Larry Wall wrote:
> >
> > But what y'all are talking about above is the other end--the return
> > type. And maybe we need to enforce a newbie-friendly invariant on
> > that end as well. I suppose we could default to not accepting
>
On Tue, Feb 15, 2005 at 11:06:51AM -0800, Larry Wall wrote:
>
> But what y'all are talking about above is the other end--the return
> type. And maybe we need to enforce a newbie-friendly invariant on that
> end as well. I suppose we could default to not accepting junctional
> return values by de
Larry Wall wrote:
Or perhaps
the problem isn't returning junctions per se, but storing them into
a variable that the user is thinking of as a simple scalar value.
That was the largest, perhaps only, reason I made my "Sets vs Junctions"
post.
Although my solution to the issu
On Tue, Feb 15, 2005 at 03:07:53PM -0600, Rod Adams wrote:
> I see it this way:
> When perl sees a function call, and one of the arguments is a junction,
> there are three basic options:
> 1) If the junction is wrapped up in some larger container, like a slurpy
> list, pass it on as is.
> 2) If t
Damian Conway wrote:
>Rod Adams wrote:
>
>> However, what if what you're calling a non-Perl Parrot based function?
>> Do we disable junctions from playing with non-PurePerl functions? Or do
>> we autothread over them? How do we tell if a non-Perl function outputs
>> to determine if we should be abl
On Feb 15, 2005, at 11:06 AM, Larry Wall wrote:
So maybe the actual pragma name is
use qubits;
Note: the pragma is not "use junctions", since they're already allowed
to use junctions, as long as they don't try to observe them. :-)
To quote Noah, what's a qubit?
http://www.jr.co.il/humor/noah
On Sun, Feb 13, 2005 at 04:10:08PM -0600, Jonathan Scott Duff wrote:
: On Sun, Feb 13, 2005 at 11:10:20AM -0600, Patrick R. Michaud wrote:
: > Autothreading, even if enabled by default, doesn't happen until a
: > junction is created and used somewhere. Thus the only time our hypothetical
: > new
Jonathan Lang wrote:
Maybe "set" should be an operator akin to "any", "all", "one", and "none",
at least in terms of "&" and "|". That is, if junctions are special cases
of sets, why not allow for the creation of gen
On Feb 13, 2005, at 3:54 PM, David Storrs wrote:
Ok, so it requires actually overriding the rand function and providing
your own implementation. I was hoping for something a bit more
automagical (probably involving a property or role, since they seem to
be the answer to everything these days), but
On Mon, Feb 14, 2005 at 10:43:21AM +1100, Damian Conway wrote:
> David Storrs OOC'd:
>
> >OOC, will there be a way to control where C gets its randomness
> >from? (e.g. perl's builtin PRNG, /dev/random, egd, etc)
>
> Sure:
>
> # Use RBR (Really Bad Randomness) algorithm...
> temp *rand
On Sat, 12 Feb 2005, Damian Conway wrote:
@xyz = uniq @xyz;
or better still:
@xyz.=uniq;
Speaking of which, while I think that methods on the implicit topicalizer
and the C<.=> assignement operator are indeed cool, I wonder if any
provision will be made for a convenient stand in for "wh
Rod Adams wrote:
> Now that I've gotten some feedback from my original message (on list and
> off), and have had some time to think about it some more, I've come to
> some conclusions:
>
>Junctions are Sets. (if not, they would make more sense if they
> were
David Storrs OOC'd:
OOC, will there be a way to control where C gets its randomness
from? (e.g. perl's builtin PRNG, /dev/random, egd, etc)
Sure:
# Use RBR (Really Bad Randomness) algorithm...
temp *rand (Num ?$max = 1) {
return $max/2;
}
my $guess = @data.pick;
Damian
Rod Adams wrote:
However, what if what you're calling a non-Perl Parrot based function?
Do we disable junctions from playing with non-PurePerl functions? Or do
we autothread over them? How do we tell if a non-Perl function outputs
to determine if we should be able to autothread into them or not?
Jonathan Scott Duff wrote:
Perhaps. I'm not so sure it's the rare case that programmers aren't
prepared to deal with implicit parallelization. :-)
Of course. But I'm saying it's a rare case where they've have to. Or, at
least, where it will bite them if they don't.
use warnings 'autothreading
On Sun, Feb 13, 2005 at 11:10:20AM -0600, Patrick R. Michaud wrote:
> Autothreading, even if enabled by default, doesn't happen until a
> junction is created and used somewhere. Thus the only time our hypothetical
> new programmer would be forced to become aware of junctions (without
> himself/h
On Sat, Feb 12, 2005 at 06:39:01PM +1100, Damian Conway wrote:
> pick - select at random from a list, array, or hash
OOC, will there be a way to control where C gets its randomness
from? (e.g. perl's builtin PRNG, /dev/random, egd, etc)
--Dks
--
[EMAIL PROTECTED]
On Sat, Feb 12, 2005 at 05:24:04PM -0600, Jonathan Scott Duff wrote:
> > >Because of this, I'd suggest that autothreading of user-defined routines
> > >not be the default, but rather enabled via a pragma of some sort (or, of
> > >course, via an "autothreaded" trait). For the built-in routines this
t; >Umm, what's wrong with...?
> >
> > $l = 'cat'|'dog'|'mouse';
> > @extract = $l.values(); # ('cat', 'dog', 'mouse')
> >
> >
> The fact that it didn't exist until now.
Damian Conway wrote:
Rod Adams wrote:
I also find the following incredibly disturbing:
>perl6 -e "$x = 'cat'|'dog'; say $x;"
dog
cat
That would be disturbing if that's what happened.
C is just a shorthand for C.
So saying a junction is the same as printing it, which is a run-time
error.
So we ha
On Sun, Feb 13, 2005 at 09:53:36AM +1100, Damian Conway wrote:
> Jonathan Scott Duff wrote:
> >The down side is that programmers need to be more aware of
> >subroutine/method side effects and write their programs accordingly.
>
> This is a *down*-side??? ;-)
Indeed ;-)
I'm using "programmer"
Jonathan Scott Duff wrote:
Let's set aside for the moment the fact that slurpy arrays/hashes
aren't autothreaded and talk about a user-defined routine:
sub foo ($alpha) { ... }
It doesn't take much imagination to come up with a mechanism for Perl6
programmers to stop the autothreading:
sub
On Sat, Feb 12, 2005 at 12:19:46PM -0600, Rod Adams wrote:
> I reread S09, and I believe "autothreading" is the wrong term for the
> iteration that a junction incurs (Even though it appears in the section
> immediately after Junctions. Autothreading is something far weirder,
> dealing with part
Autrijus wrote:
FWIW, I also find it incredibly disturbing. Although I don't have
to deal with it yet in the side-effect-free FP6, I think one way
to solve this is for the "say" to return a junction of IO actions.
No. It just throws an exception:
Can't output a raw junction
(did yo
Rod Adams wrote:
I also find the following incredibly disturbing:
>perl6 -e "$x = 'cat'|'dog'; say $x;"
dog
cat
That would be disturbing if that's what happened.
C is just a shorthand for C.
So saying a junction is the same as printing it, which is a run-time error.
Can a junction hold values of
Patrick R. Michaud wrote:
On Sat, Feb 12, 2005 at 01:18:53PM -0600, Rod Adams wrote:
My issue is less that lists and sets are radically different. It is much
more a matter of Junctions and Scalars are radically different. Getting
me to accept that a Scalar holds several different values at once
On Sat, Feb 12, 2005 at 02:20:45PM -0600, Patrick R. Michaud wrote:
: > And I've yet to receive a good answer for what C<3/any(0,1)> does to $!.
:
: I'm sure that 3/any(0,1) throws some sort of divide by zero exception;
: same as 3/0 would, and places the exception into $!. I don't know
: that $!
1 - 100 of 120 matches
Mail list logo
