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)
>> wrote:
>>
>> # New Ticket Created by Victor ADAM
>> # Please include the string: [perl
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)
> wrote:
>
> # New Ticket Created by Victor ADAM
others.” 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 R
nts `False(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
nts `False(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
ot;, $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.
>
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
-bits.pod
Log Message:
---
s/Failure/undefined/ for decrement on sets/bags
-setting-library/Containers.pod
Log Message:
---
sets and bags don't flatten in list context
On Tue Nov 13 04:29:08 2012, masak wrote:
> 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.
On Tue, Nov 13, 2012 at 04:29:08AM -0800, Carl Mäsak wrote:
> we could even put it in the grammar, and just ignore it.
> I suggest we make things just work.
> me too.
+1. Just ignore any BOM at the beginning of the program.
Pm
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #115712]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org:443/rt3/Ticket/Display.html?id=115712 >
here you have a guestion... why my *.pl file with utf-8
coding does not fire whe
new(2, 42)).perl;
rakudo 2c66f9: OUTPUT«{"2" => 2}»
okay, that's officially not at all what I expected
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.
:
---
[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
# New Ticket Created by Moritz Lenz
# Please include the string: [perl #78510]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=78510 >
01:31 <+p6eval> rakudo d35769: OUTPUT«"a" => 1»
01:32 < moritz_> rakudo: class A { metho
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
# New Ticket Created by "Seneca Cunningham"
# Please include the string: [perl #57532]
# in the subject line of all future correspondence about this issue.
# 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 assem
Applied in r29959. tetragon++. Marking ticket resolved.
Leopold Toetsch wrote:
1) The Parrot internal character type
«Strings in Parrot's native string format will probably be an array of
"Parrot_Rune"s.»
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 (includi
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
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.
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
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 i
I'm currently taking the architect and editor pass through the PDD, and
am integrating the comments from the list.
Thanks!
Allison
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 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 an
(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 ca
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,
> > an
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
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 Warnoc
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
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
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
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
>
1 - 100 of 151 matches
Mail list logo
