Re: "put" vs "say"

Thanks for the suggestions. I ran a couple of tests: my $data_list = 1..1001; say $data_list; produces 1..1000 real0m0.357s user0m0.435s sys 0m0.048s my $data_list = 1..1001; put $data_list; produces the list of integers from 1 to 1001 (obviously a single string). real

Re: "put" vs "say"

put is meant for machines, while say is meant for humans. this is implemented by having say call the .gist method and put calling the .Str method. Try using say and put on a list of a thousand elements or more and you'll see what I mean. HTH   - Timo On 21/10/2018 18:29, Parrot Raiser wrote: >

"put" vs "say"

"put" and "say" seem to be redundant, but I'm sure there's a good reason for having 2 output commands. Would anyone care to comment on how they differ and why, or point to an explanation?

Re: "temp" vs "my"

What you want is OUTER ... my $v = "original"; > { > my $v = OUTER::<$v>; > say $v; > $v = "new one"; > say $v; > } > say $v; It's how you access the outer scope from an inner scope. -Scott On Wed, Oct 3, 2018 at 1:10 AM yary wrote: > Reading and playing with

Re: "temp" vs "my"

Note that OUTER::<$v> only goes up one level. So to go up two levels OUTER::OUTER::<$v> There is also OUTERS::<$v> which will go up as many levels as it needs to find the variable { my $a = 1; my $b = 2; { my $a = 3; { say

Re: "temp" vs "my"

Thanks! Knew I'd seen the concept of OUTER but couldn't remember the keyword. -y On Wed, Oct 3, 2018 at 5:51 AM, Timo Paulssen wrote: > you can refer to the outer $v as OUTER::('$v'), that ought to help :) > On 03/10/2018 08:10, yary wrote: > > Reading and playing with

Re: "temp" vs "my"

you can refer to the outer $v as OUTER::('$v'), that ought to help :) On 03/10/2018 08:10, yary wrote: > Reading and playing with https://docs.perl6.org/routine/temp > > There's an example showing how temp is "dynamic" - that any jump > outside a block restores the value. All well and good. > >

"temp" vs "my"

Reading and playing with https://docs.perl6.org/routine/temp There's an example showing how temp is "dynamic" - that any jump outside a block restores the value. All well and good. Then I thought, what if I want a lexical temporary value- then use "my"- and this is all well and good: my $v =

Re: CALL-ME vs. Callable

I feel like you're focusing on the wrong thing somehow. The issue is not that what nqp is doing is somehow wrong. The issue is that the thing it is doing is necessarily an implementation detail, and as such should be isolated from the language level and any failures/errors exposed as language

Re: CALL-ME vs. Callable

I guess I wasn't clear in what I was asking: What, exactly, was it that NQP was doing? What were the inputs and what was the behavior that you observed? So far, all I have to go on is one example that you feel is not illustrating the broken behavior of NQP that you want to work around with a

Re: CALL-ME vs. Callable

On Mon, Nov 14, 2016 at 5:00 PM, Jon Lang wrote: > So what is the assuming method, and why is it in a callable role? What was > the logic behind that decision? It's perfectly sensible: it's how you implement partial application (which as sadly usual is mis-called

Re: CALL-ME vs. Callable

So what is the assuming method, and why is it in a callable role? What was the logic behind that decision? On Nov 14, 2016 1:38 PM, "Brandon Allbery" wrote: > This should probably have been cc-d to the list. > > Callable claims to be the thing we want. What it actually is,

Re: CALL-ME vs. Callable

This should probably have been cc-d to the list. Callable claims to be the thing we want. What it actually is, is a mix-in that adds the assuming method. I am not sure these can be conflated. Note that the current docs actually do claim it is what I want. This is because I first brought this up

Re: CALL-ME vs. Callable

On Mon, Nov 14, 2016 at 4:28 PM, Aaron Sherman wrote: > So, you said that the problem arises because NQP does something > non-obvious that results in this error. Can you be clear on what that > non-obvious behavior is? It sounds to me like you're addressing a symptom > of a

Re: CALL-ME vs. Callable

So, you said that the problem arises because NQP does something non-obvious that results in this error. Can you be clear on what that non-obvious behavior is? It sounds to me like you're addressing a symptom of a systemic issue. Aaron Sherman, M.: P: 617-440-4332 Google Talk, Email and Google

Re: CALL-ME vs. Callable

Fair points, all. I do think, though that if the concern is really with "the 4 cases when nqp hauls a CALL-ME out of its bowels" then that's what should be addressed... Aaron Sherman, M.: P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com Toolsmith, developer, gamer and life-long

Re: CALL-ME vs. Callable

Also... On Mon, Nov 14, 2016 at 3:06 PM, Aaron Sherman wrote: > Role-based testing seems very perl6ish. I'd suggest the role name be > "Invocable" with much the sort of signature as you've described. If it's Invokable then the method should probably be INVOKE. It still leaves

The use of $!attr vs self.attr in core libraries

In working with Range a while back, I was frustrated to find that writing a subclass that wanted to override an accessor (e.g. for $.min and $.max) was quite difficult because most methods ignored the accessors and called $!min and $!max or wrote to them directly. If I really wanted to change the

[perl6/specs] 627f2a: Fix - vs . method call typo in S17

: M S17-concurrency.pod Log Message: --- Fix - vs . method call typo in S17

state and = vs :=

implementing binding for Perl 5, but the syntax is different— \$x = \$y; (The reason for the different syntax is that, when we tried to use :=, we could not find a coherent way to handle edge cases [e.g., flattening vs not flattening]. Reusing existing Perl 5 syntax seemed the most

Re: state and = vs :=

., flattening vs not flattening]. Reusing existing Perl 5 syntax seemed the most straightforward and intuitive approach.) —and I am debating whether \state $x = \$y should bind only once or every time the surrounding code is executed. I could argue it either way (though I am leaning toward

Re: state and = vs :=

to handle edge cases [e.g., flattening vs not flattening]. Reusing existing Perl 5 syntax seemed the most straightforward and intuitive approach.) —and I am debating whether \state $x = \$y should bind only once or every time the surrounding code is executed. I could argue it either way (though

[perl6/specs] b608ca: Use Thread.start() consistently (vs. Thread.run())

paths: M S17-concurrency-jnthn.pod Log Message: --- Use Thread.start() consistently (vs. Thread.run()) Most examples use Thread.start(), but the early description uses Thread.run(). These should be consistent; since the method on a thread object is $thread.start(), it seems one

[perl6/specs] c49322: define normal order for init vs final phasers

paths: M S04-control.pod Log Message: --- define normal order for init vs final phasers

[perl6/specs] d5e738: gather/take user-vs-library considerations

paths: M S04-control.pod Log Message: --- gather/take user-vs-library considerations Incorporate feedback from awwaiid++, PerlJam++, sorear++.

[perl6/specs] 977d92: [S02] clarify * vs *-1 semantics for globbish ops

-bits.pod Log Message: --- [S02] clarify * vs *-1 semantics for globbish ops Globbish ops like .. and xx do not autocurry on Whatever but do autocurry on WhateverCode. Also mention that assignment and smartmatching don't autocurry because they're primitive pseudo-operators.

Re: Packed arrays and assignment vs binding

On 11/14/2010 03:46 AM, Mason Kramer wrote: I understand everything you've written except the following: On Nov 13, 2010, at 12:09 PM, Jonathan Worthington wrote: Hi, ... my Int @x; Where we get an array of scalar containers, each of which is only allowed to contain an Int

Re: Packed arrays and assignment vs binding

On Sun, Nov 14, 2010 at 2:54 AM, Moritz Lenz mor...@faui2k3.org wrote: On IRC, Jonathan said that 1 is basically an Int, which is something like a boxed int. So whatever operation works removes the box, and puts the result in the variable. However I wonder how well that's going to work, since

Packed arrays and assignment vs binding

Hi, Per S09, we can write in Perl 6: my int @x; And the idea is that we get a packed array - conceptually, a single lump of memory allocated and and storing a bunch of ints contiguously. Contrast this to: my Int @x; Where we get an array of scalar containers, each of which is only

Re: Packed arrays and assignment vs binding

Jonathan (): Per S09, we can write in Perl 6: my int @x; And the idea is that we get a packed array - conceptually, a single lump of memory allocated and and storing a bunch of ints contiguously. Contrast this to: my Int @x; Where we get an array of scalar containers, each of which is

Re: Packed arrays and assignment vs binding

On Sat, Nov 13, 2010 at 06:09:00PM +0100, Jonathan Worthington wrote: ... With packed arrays, however, I'm less clear what they mean. Since the point of a packed array is compact storage, there's no chance to actually have containers. Thus does assignment to a slot in a compact array ever make

Re: Packed arrays and assignment vs binding

On 11/13/2010 06:09 PM, Jonathan Worthington wrote: With packed arrays, however, I'm less clear what they mean. Since the point of a packed array is compact storage, there's no chance to actually have containers. Thus does assignment to a slot in a compact array ever make sense? There's not

Re: Packed arrays and assignment vs binding

to an already-existing container (e.g., @x[0] = $foo vs. @x[0] := $foo). With packed arrays, however, I'm less clear what they mean. Since the point of a packed array is compact storage, there's no chance to actually have containers. Thus does assignment to a slot in a compact array ever make sense

Re: Packed arrays and assignment vs binding

I understand everything you've written except the following: On Nov 13, 2010, at 12:09 PM, Jonathan Worthington wrote: Hi, ... my Int @x; Where we get an array of scalar containers, each of which is only allowed to contain an Int (strictly, something that Int.ACCEPTS(...) hands back

Lists vs sets

+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

Re: Lists vs sets

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

Re: Lists vs sets

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

Re: Lists vs sets

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, with the caveat that there's no guarantee about the order in which you'll get the set's members; only

Re: Lists vs sets

Mason Kramer wrote: But I don't think that thinking about who is subclassing whom is is how to think about this in Perl 6.  All of these types are capable of doing the Iterable role, and that is what methods that could operate on a List, Array, Bag, or Set, should be calling for. This.  

Re: Lists vs sets

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

Re: Lists vs sets

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

r31372 -[S06] spec processing of rw vs de-containerized return values

Author: lwall Date: 2010-06-19 04:24:36 +0200 (Sat, 19 Jun 2010) New Revision: 31372 Modified: docs/Perl6/Spec/S06-routines.pod Log: [S06] spec processing of rw vs de-containerized return values Modified: docs/Perl6/Spec/S06-routines.pod

Re: Documentaion Details (was: underscores vs hyphens)

Matthew Walton wrote: On Mon, Apr 12, 2010 at 1:22 PM, Shawn H Corey shawnhco...@gmail.com wrote: So, I'll ask again: Where in the official documentation does it state that Perl 6 names are case sensitive? I think it's more important to ask where it says that they aren't. 1) Perl 5 is case

Re: underscores vs hyphens (was Re: A new era for Temporal)

Damian Conway wrote: Personally, I'd prefer to see the English conventions carried over to the use of general use of hyphen and underscore in identifiers in the core (and everywhere else). By that, I mean that, in English, the hyphen is notionally a higher precedence word-separator than the

Re: underscores vs hyphens (was Re: A new era for Temporal)

Am I the only one who sees a hyphen and thinks binary minus? Just because the parser can disambiguate this use of it doesn't mean the reader's brain can do so as easily. (I assume we're talking about the same character, 0x2D, and not something from further afield in the Unicode tables,

Re: underscores vs hyphens (was Re: A new era for Temporal)

Peter Scott wrote: Am I the only one who sees a hyphen and thinks binary minus? Just because the parser can disambiguate this use of it doesn't mean the reader's brain can do so as easily. It's all a matter of practice. Since variables begin with sigils, and you should put whitespace

Re: underscores vs hyphens (was Re: A new era for Temporal)

Darren Duncan wrote: See http://perlcabal.org/syn/S02.html#Names for your answers. Thanks for the link but nowhere in it does it state tha Perl 6 names are case sensitive. The best the do is this, which implies it is but doesn't state it. Other all-caps names are semi-reserved. We may add

Re: underscores vs hyphens (was Re: A new era for Temporal)

On Mon, Apr 12, 2010 at 1:22 PM, Shawn H Corey shawnhco...@gmail.com wrote: Darren Duncan wrote: See http://perlcabal.org/syn/S02.html#Names for your answers. Thanks for the link but nowhere in it does it state tha Perl 6 names are case sensitive.  The best the do is this, which implies it

Re: underscores vs hyphens (was Re: A new era for Temporal)

On Sun, Apr 11, 2010 at 03:47:18PM -0700, Darren Duncan wrote: : Damian Conway wrote: : The relevant suggestion regarding hyphens vs underscores is: : : ...to allow both characters, but have them mean the same thing. : : That is, any isolated internal underscore can be replaced

Re: Documentaion Details (was: underscores vs hyphens)

On Mon, Apr 12, 2010 at 8:04 PM, Shawn H Corey shawnhco...@gmail.com wrote: Matthew Walton wrote: On Mon, Apr 12, 2010 at 1:22 PM, Shawn H Corey shawnhco...@gmail.com wrote: So, I'll ask again:  Where in the official documentation does it state that Perl 6 names are case sensitive? I

Re: underscores vs hyphens (was Re: A new era for Temporal)

). - Never use dash versus underscore notationally (e.g. a-b indicates that the identifier is to be used one way vs a_b indicates otherwise) - Allow only one such character in any given identifier That last item rolls into a whole rant of mine against ambiguity in identifiers. Most often

Re: underscores vs hyphens (was Re: A new era for Temporal)

On Mon, 2010-04-12 at 11:23 -0700, Larry Wall wrote: The standard parser will likely be pointing out spelling errors and conjecturing emendations for near misses. Whole-program analysis can even do this for any method names that look wrongish. The difference between Acme-X and Acme_X is no

RE: underscores vs hyphens (was Re: A new era for Temporal)

From: Mark J. Reed [mailto:markjr...@gmail.com] [...] Perl borrows vocabulary almost exclusively from English, but it is not English, and its conventions are not those of English. (And the conventions around hyphens that people are citing are quite specifically those of standard written

Re: underscores vs hyphens (was Re: A new era for Temporal)

On Sun, Apr 11, 2010 at 4:47 AM, Damian Conway dam...@conway.org wrote: And is it really so hard to teach: use underscore by default and reserve hyphens for between a noun and its adjective? Perhaps it *is*, but then that's a very sad reflection on our profession. If anything, it's a sad

Re: underscores vs hyphens (was Re: A new era for Temporal)

On Sat, Apr 10, 2010 at 5:14 AM, Mark J. Reed markjr...@gmail.com wrote: I'd much rather see a single consistent style throughout the setting than backwards compatibility with p5 naming conventions. If Temporal is the first setting module to use multiword identifiers, I vote for hyphens.

Re: underscores vs hyphens (was Re: A new era for Temporal)

on this list five years ago: http://www.mail-archive.com/perl6-language@perl.org/msg22675.html The relevant suggestion regarding hyphens vs underscores is: ...to allow both characters, but have them mean the same thing. That is, any isolated internal underscore can be replaced

Re: underscores vs hyphens (was Re: A new era for Temporal)

On Sat, 2010-04-10 at 17:20 -0700, yary wrote: Adjectives and nouns aren't English-only. So Damian's proposal is multi-culti. One could argue that Perl's identifiers, keywords, etc are based on English so that it is more difficult for a non-English speaker to discern why underscore is used in

Re: underscores vs hyphens (was Re: A new era for Temporal)

On Sun, Apr 11, 2010 at 10:54 AM, Damian Conway dam...@conway.org wrote: Hyphen/underscore equivalence would allow those (apparently elite few) who can correctly use a hyphen to correctly use the hyphen That's about the only advantage of this scheme that I can think of. The disadvantages, which

Re: underscores vs hyphens (was Re: A new era for Temporal)

Egad, no to the equivalence. We'd be back in case-insensitive-language land, only without the benefit of even that dubious tradition. And at least for me, the beef with mixing hyphens and underscores is not that the great unwashed masses can't handle it, but that there will inevitably be cases

Re: underscores vs hyphens (was Re: A new era for Temporal)

I can't help but agree with Damian. I don't see much of a point in making a distinction between - and _. More specifically, if a user were to define a function (say, i-hate-camel-case()), it would not be good to let them be the same. Readability would suffer when examining someone's code and

Re: underscores vs hyphens (was Re: A new era for Temporal)

Egad, no to the equivalence. We'd be back in case-insensitive-language land, only without the benefit of even that dubious tradition. And at least for me, the beef with mixing hyphens and underscores is not that the great unwashed masses can't handle it, but that there will inevitably be cases

Re: underscores vs hyphens (was Re: A new era for Temporal)

proposal that was made on this list five years ago: http://www.mail-archive.com/perl6-language@perl.org/msg22675.html The relevant suggestion regarding hyphens vs underscores is: ...to allow both characters, but have them mean the same thing. I was about to say that if hyphens

Re: underscores vs hyphens (was Re: A new era for Temporal)

Damian Conway wrote: The relevant suggestion regarding hyphens vs underscores is: ...to allow both characters, but have them mean the same thing. That is, any isolated internal underscore can be replaced with an isolated internal hyphen (and vice versa), without changing the meaning

Re: underscores vs hyphens (was Re: A new era for Temporal)

Em Dom, 2010-04-11 às 07:54 -0700, Damian Conway escreveu: The relevant suggestion regarding hyphens vs underscores is: ...to allow both characters, but have them mean the same thing. er... this smells like :: and ' in Perl 5... Which, while I find Acme::Don't amusing, cannot be stated

Re: underscores vs hyphens (was Re: A new era for Temporal)

On Sat, 10 Apr 2010, Mark J. Reed wrote: I'd much rather see a single consistent style throughout the setting than backwards compatibility with p5 naming conventions. Ditto! If Perl 6 style is hyphens, use hyphens everywhere. That transition from P5 DateTime to P6 will then be a simple

Re: underscores vs hyphens (was Re: A new era for Temporal)

${A-1} = 3.14159; $A = $A-1; $A = $A -1; $A-=2; $A = 123E-2; $A = Pi(); $B = sin ($A-1); $B = sin (${A}-1); $B = sin($A -1); -2**2 = -4 except when it comes out +4 as in MS Excel. _2**2 = +4 in some other languages that use _ as a unary minus operator. Will editors be bothered when I try to

Re: underscores vs hyphens (was Re: A new era for Temporal)

Doug McNutt wrote: ${A-1} = 3.14159; $A = $A-1; $A = $A -1; $A-=2; $A = 123E-2; $A = Pi(); $B = sin ($A-1); $B = sin (${A}-1); $B = sin($A -1); -2**2 = -4 except when it comes out +4 as in MS Excel. _2**2 = +4 in some other languages that use _ as a unary minus operator. Will editors be

Re: underscores vs hyphens (was Re: A new era for Temporal)

John (): Forgive me if this is a question the reveals how poorly I've been following Perl 6 development, but what's the deal with some methods using hyphen-separated words (e.g., day-of-week) while others use normal Perl method names (e.g., set_second)? I'd just like to point out that the

Re: underscores vs hyphens (was Re: A new era for Temporal)

I'd much rather see a single consistent style throughout the setting than backwards compatibility with p5 naming conventions. If Temporal is the first setting module to use multiword identifiers, I vote for hyphens. They're easier on the fingers and the eyes; underscores have always felt like an

Re: underscores vs hyphens (was Re: A new era for Temporal)

On Sat, Apr 10, 2010 at 6:14 AM, Mark J. Reed markjr...@gmail.com wrote: I'd much rather see a single consistent style throughout Yeah, that's was my main point/question. I wanted to know if it was it some intentional convention (e.g., all methods that change the object state use hyphens, and

Re: underscores vs hyphens (was Re: A new era for Temporal)

Mark (), John (): I'd much rather see a single consistent style throughout Yeah, that's was my main point/question.  I wanted to know if it was it some intentional convention (e.g., all methods that change the object state use hyphens, and all others use underscores) or if it was just

Re: underscores vs hyphens (was Re: A new era for Temporal)

Personally, I'd prefer to see the English conventions carried over to the use of general use of hyphen and underscore in identifiers in the core (and everywhere else). By that, I mean that, in English, the hyphen is notionally a higher precedence word-separator than the space (or than its

Re: underscores vs hyphens (was Re: A new era for Temporal)

On Sat, Apr 10, 2010 at 5:25 PM, Damian Conway dam...@conway.org wrote: Personally, I'd prefer to see the English conventions carried over to the use of general use of hyphen and underscore in identifiers in the core (and everywhere else). That's certainly an example of how hyphens might gain

Re: underscores vs hyphens (was Re: A new era for Temporal)

In English, hyphens normally indicate an extra level of reification, where e.g. what is normally a phrase is used in a context that requires a single word: The miller gave us the run of the mill. vs. It was a run-of-the-mill event. As such, examples like day?of?week are somewhat infelicitous

Re: underscores vs hyphens (was Re: A new era for Temporal)

John Siracusa commented: That's certainly an example of how hyphens might gain meaning in Perl 6 names, but I don't think I can endorse it as a convention.  People can't even use hyphens correctly in written English.  I have very little faith that programmers will do any better in code But

Re: underscores vs hyphens (was Re: A new era for Temporal)

On Sat, Apr 10, 2010 at 7:17 PM, Damian Conway dam...@conway.org wrote: And is it really so hard to teach: use underscore by default and reserve hyphens for between a noun and its adjective? Perhaps it *is*, but then that's a very sad reflection on our profession. I'm not sure if the

Re: underscores vs hyphens (was Re: A new era for Temporal)

On Sat, Apr 10, 2010 at 4:53 PM, John Siracusa sirac...@gmail.com wrote: I'm not sure if the intersection of people who speak English and people who program is better or worse than average when it comes to grammar, but I do know (from editing my share of writing) that the average is very bad

Re: underscores vs hyphens (was Re: A new era for Temporal)

Em Sáb, 2010-04-10 às 19:53 -0400, John Siracusa escreveu: I'm having trouble imaging any convention that involves mixing word separators being successful. But the convention Damian is proposing is simply use underscores. Basically camelCase and with_underscores are conventions on how to

Re: underscores vs hyphens (was Re: A new era for Temporal)

On Sat, Apr 10, 2010 at 8:23 PM, Daniel Ruoso dan...@ruoso.com wrote: Em Sáb, 2010-04-10 às 19:53 -0400, John Siracusa escreveu: I'm having trouble imaging any convention that involves mixing word separators being successful. But the convention Damian is proposing is simply use underscores.

Re: underscores vs hyphens (was Re: A new era for Temporal)

Agreed. Perl borrows vocabulary almost exclusively from English, but it is not English, and its conventions are not those of English. (And the conventions around hyphens that people are citing are quite specifically those of standard written English; other writing systems, even those using the

underscores vs hyphens (was Re: A new era for Temporal)

John Siracusa wrote: Forgive me if this is a question the reveals how poorly I've been following Perl 6 development, but what's the deal with some methods using hyphen-separated words (e.g., day-of-week) while others use normal Perl method names (e.g., set_second)? There are 2 answers to that

infinity literals - 'Inf' vs '+Inf'

I was studying the synopsis today for how Perl 6 uses infinities, and among the 48 occurrences of [|-|+]Inf in the synopsis, I noticed that in some places you seemed to use +Inf to mean positive infinity and other places you just say Inf. So are there just 2 canonical infinity values, -Inf

Re: infinity literals - 'Inf' vs '+Inf'

Darren (): I was studying the synopsis today for how Perl 6 uses infinities, and among the 48 occurrences of [|-|+]Inf in the synopsis, I noticed that in some places you seemed to use +Inf to mean positive infinity and other places you just say Inf. So are there just 2 canonical infinity

Re: infinity literals - 'Inf' vs '+Inf'

Darren Duncan wrote: I was studying the synopsis today for how Perl 6 uses infinities, and among the 48 occurrences of [|-|+]Inf in the synopsis, I noticed that in some places you seemed to use +Inf to mean positive infinity and other places you just say Inf. So are there just 2

Re: But vs. With

On 2009-Dec-3, at 8:42 pm, Jon Lang wrote: but _can_ change existing behavior, but doesn't have to. So with becomes the safe version of run-time composition, guaranteeing that whatever you mix in won't disturb existing behavior, and but becomes the unsafe version that you can fall back

But vs. With

I'm wondering whether we can make use of the contrary sense implied by the word but, and have it apply specifically to cases where something is being overridden. In cases where there isn't something to override we could use a different word, such as with. E.g. $x = Tue but Today;

Re: But vs. With

Lots of things will have default stringifications, say, that may not always merit the contrary force of but. Maybe but should be needed only when a method has already been mixed in anonymously. Oops, that would wreck the canonical example of 0 but true. Since the Bool(Int) method already

Re: But vs. With

On Thu, Dec 3, 2009 at 6:38 PM, David Green david.gr...@telus.net wrote: I'm wondering whether we can make use of the contrary sense implied by the word but, and have it apply specifically to cases where something is being overridden.  In cases where there isn't something to override we could

Re: But vs. With

David Green wrote: I'm wondering whether we can make use of the contrary sense implied by the word but, and have it apply specifically to cases where something is being overridden. In cases where there isn't something to override we could use a different word, such as with. I must admit to

program vs module (was Re: r28199 ...)

pugs-comm...@feather.perl6.nl wrote: +All package bodies (including module and class bodies) execute at the +normal execution time of the code in which they are embedded. For normal +mainline code, this is the normal flow of execution; if this is too late +to initialize something in the package

Implicit threading vs Imperative barriers

Hi, Following my last reasoning on implicit threading and implicit event-based programming[1], I came to two interesting realizations... 1 - Every object is potentially lazy, not only lists. 2 - Lazy doesn't mean wait until I need the data, but don't stall me because of that data. That

Re: Implicit threading vs Imperative barriers

HaloO, Daniel Ruoso wrote: So the questions are: * Are there any imperative barriers in Perl 6? I would think that at least every method call is a barrier. An object's lifetime is a sequence of states and methods are either returning information about the state or calculate a new state. The

Re: Implicit threading vs Imperative barriers

On Thu, Jun 4, 2009 at 9:57 AM, TSa thomas.sandl...@vts-systems.de wrote: HaloO, Daniel Ruoso wrote: So the questions are:  * Are there any imperative barriers in Perl 6? I would think that at least every method call is a barrier. An object's lifetime is a sequence of states and methods

$*DEFOUT vs. $*OUT

Smack me down if this has already been discussed to death, please... S16 (and now S28) say that $*DEFOUT, $*DEFIN and $*DEFERR are what most programs should use instead of $*OUT, $*IN and $*ERR. That seems anti-huffman to me, and I'll bet many programmers will use $*OUT when they should

Re: $*DEFOUT vs. $*OUT

On Sun, 22 Feb 2009, Chris Dolan wrote: Smack me down if this has already been discussed to death, please... S16 (and now S28) say that $*DEFOUT, $*DEFIN and $*DEFERR are what most programs should use instead of $*OUT, $*IN and $*ERR. That seems anti-huffman to me, and I'll bet many

CPAN6 vs. 6PAN (was: Re: 6PAN Spec question)

Mark, am I right in putting it like this? 6PAN: - Perl6 package format - Client-side part of CPAN CPAN6: - Server-side part of CPAN (with more stuff) Is that how you see it? :) - |

operator vs function

Off the top of one's head, since there is no particular difference between an operator and a function, can I see a function as a operator: (1, 2, 3, 4) elems(2, 3, 4, 5) #(2, 2, 2, 2) (1, 2, 3, 4) shift(2, 3, 4, 5) #(2, 3, 4, 5) Moreover, can I see a subroutine as a operator:

Re: Closure vs Hash Parsing

On 10 Aug., 00:58, [EMAIL PROTECTED] (Patrick R. Michaud) wrote: On Fri, Aug 08, 2008 at 07:32:52AM +0200, Carl Mäsak wrote: Jonathan (): That this means the { $_ = uc $_; } above would end up composing a Hash object (unless the semicolon is meant to throw a spanner in the

Re: Quick question: (...) vs [...]

John M. Dlugosz 提到: What is the difference between (1,2,3) and [1,2,3] ? One is a List and one is an Array; you cannot push into a list, but you can into an array. my @a := (1,2,3); my @b := [1,2,3]; @a.push(4); # fails @b.push(4); # works Cheers, Audrey

Re: Quick question: (...) vs [...]

On Fri, Aug 08, 2008 at 11:08:51PM -0400, Brandon S. Allbery KF8NH wrote: On 2008 Aug 8, at 22:53, John M. Dlugosz wrote: What is the difference between (1,2,3) and [1,2,3] ? IIRC one is a list, the other a reference to a list --- which in perl6 will be hidden for the most part. so

  1   2   3   4   5   6   7   >