y 1e0.WHICH; say (1e0 + 4e-15).WHICH'
> Num|1
> Num|1
>
> Nothing to do with Sets/Bags/Mixes/object hashes.
>
>> On 20 Oct 2017, at 17:02, Victor ADAM (via RT)
>> <perl6-bugs-follo...@perl.org> wrote:
>>
>> # New Ticket Created by Victor ADAM
>&g
The problem is that both these values have the same .WHICH:
$ 6 'say 1e0.WHICH; say (1e0 + 4e-15).WHICH'
Num|1
Num|1
Nothing to do with Sets/Bags/Mixes/object hashes.
> On 20 Oct 2017, at 17:02, Victor ADAM (via RT) <perl6-bugs-follo...@perl.org>
> wrote:
>
> # New Ticket
ers.” The sets’ elements aren’t equal, or even approximately equal
(≅), and yet ACCEPTS (~~) returns `True`.
Note that other set methods show similar behavior: `1e0 ⊖ (1e0 +
4e-15)` is the empty set, `set(1e0, 1e0 + 4e-15)` only has one
element…
Version information
---
This is Rakudo vers
(False)`.
>
> Actual behavior
> ---
>
> Prints `True(False)`.
>
> This contradicts the documentation of the Setty ACCEPTS method:
> “Returns True if $other and self contain all the same elements, and no
> others.” The sets’ elements aren’t equal, or even appr
(False)`.
>
> Actual behavior
> ---
>
> Prints `True(False)`.
>
> This contradicts the documentation of the Setty ACCEPTS method:
> “Returns True if $other and self contain all the same elements, and no
> others.” The sets’ elements aren’t equal, or even appr
t: ", $num_set.perl;
> say "4 is in set: ", 4 ∈ $num_set; # False
> say "IntStr 4 is in set: ", IntStr.new(4, "Four") ∈ $num_set; $ True
>
> As noted is the thread it's unexpected and a likely trap that's
> difficult to explain to beginners.
>
> The
d is the thread it's unexpected and a likely trap that's
difficult to explain to beginners.
The current implementation is supposed to make it easy to form sets of
general objects. But in practice even that's fragile. Consider:
my $v = 42;
my $s = set($v);
$v does role {};
say $v ∈ $s; # False
Appl
:
M S02-bits.pod
Log Message:
---
s/Failure/undefined/ for decrement on sets/bags
:
M S32-setting-library/Containers.pod
Log Message:
---
sets and bags don't flatten in list context
# New Ticket Created by Carl Mäsak
# Please include the string: [perl #115712]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=115712
mtymula here you have a guestion... why my *.pl file with utf-8
coding does
On Tue, Nov 13, 2012 at 04:29:08AM -0800, Carl Mäsak wrote:
masak we could even put it in the grammar, and just ignore it.
jnthn I suggest we make things just work.
masak me too.
+1. Just ignore any BOM at the beginning of the program.
Pm
On Tue Nov 13 04:29:08 2012, masak wrote:
masak I wonder why we shouldn't simply strip the BOM in Rakudo if we
find it.
The grammar now ignores BOM at the start of a compilation unit. Spectest
added. Resolving ticket.
rakudo 2c66f9: OUTPUT«{2 = 2}»
colomon okay, that's officially not at all what I expected
masak huh?
* masak submits rakudobug
Since Sets are unordered, the exact result of + probably wouldn't
be guaranteed. But it definitely shouldn't be a hash, it should
probably be a Set with four elements.
+1 on this
On Mon, Oct 25, 2010 at 4:56 PM, Jon Lang datawea...@gmail.com 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
yary wrote:
+1 on this
On Mon, Oct 25, 2010 at 4:56 PM, Jon Lang datawea...@gmail.com 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
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 datawea...@gmail.com 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
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 about this in Perl 6. All
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
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
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
-bits.pod
Log Message:
---
[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
# New Ticket Created by Moritz Lenz
# Please include the string: [perl #78510]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=78510
01:31 +p6eval rakudo d35769: OUTPUT«a = 1»
01:32 moritz_ rakudo: class A { method
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 for situation where it's
On Sun, Mar 29, 2009 at 1:18 PM, John Macdonald j...@perlwolf.com 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
junctions.
Now
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
) {
# 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 good for? They're good for situation where it's
collapsed nearby, which means, it is used in boolean
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:+ should
On Sat, Mar 28, 2009 at 6:39 AM, Daniel Ruoso dan...@ruoso.com 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
Thomas Sandlaß wrote:
Set operations are with parens.
Which Synopsis is this in?
--
Jonathan Dataweaver Lang
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 complete
calculation
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:
my $pa = ([+] @a).eigenstates.grep
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
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
implementation
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
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 expressions, there's
something wrong with them .
Well, I was being
On Fri, Mar 27, 2009 at 11:45 AM, Mark J. Reed markjr...@gmail.com 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
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 there's something wrong
# New Ticket Created by Seneca Cunningham
# Please include the string: [perl #57532]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57532
When attempting a 64-bit Intel build on OS X 10.5, the build fails
when the
Applied in r29959. tetragon++. Marking ticket resolved.
James E Keenan wrote:
1. Why is grapheme normalization form abbreviated as NFG rather than GNF?
The Unicode normalization forms are NFC, NFD, NFKC, and NFKD, so this
fits with the standard naming scheme.
2. If a character set is officially a deprecated term (by whom?),
won't our use of it
Will Coleda wrote:
- Which language targeting parrot requires graphemes? You say, A
grapheme is our concept., but then say, Parrot must support
languages which manipulate strings grapheme-by-grapheme ... but if
it's our own concept, surely there aren't any languages that can be
forcing us to
Gianni Ceccarelli wrote:
(Here follows various comments and opinions on PDD28 draft, written
while reading it)
As has been pointed out, the expression «A grapheme is our concept» is
not really clear. I think «The term grapheme in this document
defines a concept local to Parrot» or some such.
Mark J. Reed wrote:
As a ref point, AppleScript 2.0 (not that I know if anyone wants to
port that to Parrot) characters are defined as Unicode grapheme
clusters, e.g. the base grapheme and its diacriticals... Is that
similar to the concept of a Parrot_Rune?
That's straight from the Unicode
Leopold Toetsch wrote:
1) The Parrot internal character type
«Strings in Parrot's native string format will probably be an array of
Parrot_Runes.»
or iso-8859-1 or UCS-2.
To be more accurate: Parrot has *no* native string format. It stores
strings in whatever format you give it
I'm currently taking the architect and editor pass through the PDD, and
am integrating the comments from the list.
Thanks!
Allison
On Thu, Mar 13, 2008 at 5:46 AM, Simon Cozens [EMAIL PROTECTED] wrote:
Simon Cozens wrote:
I think I've finished doing what I can with
docs/pdds/draft/pdd28_character_sets.pod for the time being.
Please have a look at it, and let me know if there's anything wrong,
anything
(Here follows various comments and opinions on PDD28 draft, written
while reading it)
As has been pointed out, the expression «A grapheme is our concept» is
not really clear. I think «The term grapheme in this document
defines a concept local to Parrot» or some such.
I'm not sure that UTF-16 can
Am Samstag, 8. März 2008 13:59 schrieb Simon Cozens:
Hi folks,
I think I've finished doing what I can with
docs/pdds/draft/pdd28_character_sets.pod for the time being.
Please have a look at it, and let me know if there's anything wrong,
anything unclear, anything missing or
As a ref point, AppleScript 2.0 (not that I know if anyone wants to
port that to Parrot) characters are defined as Unicode grapheme
clusters, e.g. the base grapheme and its diacriticals... Is that
similar to the concept of a Parrot_Rune?
On 3/14/08, Leopold Toetsch [EMAIL PROTECTED] wrote:
Am
Simon Cozens wrote:
I think I've finished doing what I can with
docs/pdds/draft/pdd28_character_sets.pod for the time being.
Please have a look at it, and let me know if there's anything wrong,
anything unclear, anything missing or anything objectionable about it
Warnock Warnock
Simon Cozens wrote:
Simon Cozens wrote:
I think I've finished doing what I can with
docs/pdds/draft/pdd28_character_sets.pod for the time being.
Please have a look at it, and let me know if there's anything
wrong, anything unclear, anything missing or anything objectionable
about it
Hi folks,
I think I've finished doing what I can with
docs/pdds/draft/pdd28_character_sets.pod for the time being.
Please have a look at it, and let me know if there's anything wrong,
anything unclear, anything missing or anything objectionable about it.
Character set and encoding support is
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 with a simple answer
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
only
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
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. The
idea
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; intersection
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;
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 Hainsworth wrote:
I
FYI, the change sets you're seeing that have only modifications to the meta
info for 'trunk' are being generated by 'svk push', and I don't know why.
But they seem harmless enough.
--
Chip Salzenberg [EMAIL PROTECTED]
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
CSet class and operations sooner rather
as sets, makes
me feel that it might be worthwhile to define and publish a standard
CSet class and operations sooner rather than later in Perl 6
development. This might reduce the tendency to confuse junctions
with sets, by providing something that is more clearly a set and
that has operations more
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
CSet class and operations sooner rather than later in Perl 6
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 be
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
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
didn't want a junction. You likely either wanted an array or a set, and
some combination of hyper operators. See below.
Not convinced of this.
Sets
Despite several surface similarities between a set and a junction, they
are quite different. Sets actually contain other things. Junctions
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 expect
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],
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;
?
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 numeric
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 PROTECTED], @z);
. You likely either wanted an array or a set, and
some combination of hyper operators. See below.
Not convinced of this.
I am completely convinced of this. Please express your reservations so I
can address them.
Sets
Despite several surface similarities between a set and a junction
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 =
, a set evaluated in a list context returns it's members.
Err...then how do you create a list of sets???
grumble. Didn't think of that. I was looking for a simple way to say:
for $set {...}
without throwing all kinds of special cases around.
for values $set {...}
And the same hash function
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 }
but
, 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.
BTW, this example is what sets are good
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 would be needed to have full
Set functionality.
=
Jonathan Dataweaver Lang
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, membership checks, and subset/superset
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.g.
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 convenient
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 some means to perform set operations
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 the
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 means to perform set operations in perl6:
: unions, intersections
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
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
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
Larry wrote:
Actually, I'm thinking we should just go with a single method and
have it merely default to :langPerl. 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
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 Wed, 2005-02-16 at 08:54 -0800, David Wheeler wrote:
And what of .c#?
It's an alias for .java.
-- c
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 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
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?
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 able to
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 the
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 issue was different from
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
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
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
1 - 100 of 148 matches
Mail list logo
