Re: Help mechanism in REPL?

There was some talk in the past about having `.WHY` look up the descriptions in the POD6 doc ( so that we don't have to bloat Rakudo with that information ) On Fri, Sep 9, 2016 at 6:30 PM, Alex Elsayed wrote: > On Wednesday, 7 September 2016 17:57:32 PDT Parrot Raiser

Re: Help mechanism in REPL?

On Fri, 09 Sep 2016 16:30:28 -0700 Alex Elsayed wrote: > On Wednesday, 7 September 2016 17:57:32 PDT Parrot Raiser wrote: > > This isn't a request for a feature, merely a thought experiment. > > We're still in the phase where it's more important to ensure that > > existing

Re: Help mechanism in REPL?

On Wednesday, 7 September 2016 17:57:32 PDT Parrot Raiser wrote: > This isn't a request for a feature, merely a thought experiment. We're > still in the phase where it's more important to ensure that existing > features work properly than add new ones. > > How difficult would it be to include a

Re: Justification for the "reversed" instruction format

Ah, nice, good to know my concern was unwarranted. On Thu, Sep 8, 2016 at 3:04 PM Aaron Sherman wrote: > In Perl 6, we apply those constraints when you pass off the call to the > ultimate recipient, and that's important because that recipient can have > multiple signatures (and

Re: Justification for the "reversed" instruction format

On Thu, Sep 8, 2016 at 9:23 AM Aaron Sherman a...@ajs.com wrote: I don't know Haskell, but isn't flip just: > > sub flip() { -> $b, $a, |c { f($a, $b, |c) } } > > And then: > > perl6 -e 'sub flip() { -> $a, $b, |c { f($b, $a, |c) } }; my = flip > yas(1,2,3)' > 213 >

Re: Justification for the "reversed" instruction format

In Perl 6, we apply those constraints when you pass off the call to the ultimate recipient, and that's important because that recipient can have multiple signatures (and signatures can be added *after* you define the flip). For example: $ cat foo.p6 sub flip() { -> $b, $a, |c { f($a, $b, |c) }

Re: Justification for the "reversed" instruction format

I don't know Haskell, but isn't flip just: sub flip() { -> $b, $a, |c { f($a, $b, |c) } } And then: perl6 -e 'sub flip() { -> $a, $b, |c { f($b, $a, |c) } }; my = flip yas(1,2,3)' 213 Aaron Sherman, M.: P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com Toolsmith, developer,

Re: Justification for the "reversed" instruction format

On Wed, Sep 7, 2016 at 6:08 PM, Parrot Raiser <1parr...@gmail.com> wrote: > There is a "flip" in P6, to reverse the characters in a string, and a > "reverse", to return the elements of a list. Would either of those be > an equivalent? > Not without an "apply" mechanism used for function / method

Re: Justification for the "reversed" instruction format

There is a "flip" in P6, to reverse the characters in a string, and a "reverse", to return the elements of a list. Would either of those be an equivalent? On 9/6/16, Trey Harris wrote: > There’s a very common functional programming pattern, usually called flip; > its

Re: Justification for the "reversed" instruction format

There’s a very common functional programming pattern, usually called flip; its implementation in Haskell is simply: flip :: (a -> b -> c) -> b -> a -> cflip f x y = f y x Getting the same behavior out of a bespoke function in Perl 6 would be easy for any particular case, but writing a

Re: Justification for the "reversed" instruction format

Oh, and note that you can pass R'd reductions as if they were normal prefix ops: $ perl6 -e 'sub dueet(, *@list) { op @list }; say dueet :<[R-]>, 1..100' -4850 On Tue, Sep 6, 2016 at 12:51 PM, Aaron Sherman wrote: > > > $ perl6 -e 'my @numbers = 1..100; say [-]

Re: Justification for the "reversed" instruction format

$ perl6 -e 'my @numbers = 1..100; say [-] @numbers; say [R-] @numbers' -5048 -4850 In general, it's kind of pointless with bare infix ops, as you can just reverse the arguments, but when reducing or the like, it becomes much more valuable. On Tue, Sep 6, 2016 at 12:43 PM, Parrot Raiser

Re: Intalling Perl6

On Sun, Jun 26, 2016 at 1:51 PM, Julian Brown wrote: > I search for packages on Debian Jessie for Perl 6 and found Rakudo and > Parrot. > > Does everyone install per user and not system-wide? > Does anyone use Parrot instead of Moar? > Debian is, as always, way behind. The

Re: can a method name contain a funny character?

Thanks for the in-depth analysis. My misunderstanding was about what an identifier considers a number; I have no well-thought-out ideas on the subject of what an identifier ought to be. Having the docs mention that "number" means only characters with a Unicode Property GeneralCategory of Nd might

Re: can a method name contain a funny character?

On Fri, May 20, 2016 at 09:39:30AM -0400, yary wrote: : On Tue, Apr 12, 2016 at 6:12 PM, Brandon Allbery : wrote: : > I was explaining why some "symbols" are acceptable to the parser. Which : one : > is more appropriate is not my call, : : I was thinking about what exactly

Re: can a method name contain a funny character?

To be clear, I expect that "number" in "followed by zero or more word characters (alphabetic, underscore or number)" means "if Unicode thinks it's numeric, you can use it in an identifier after the first character." I don't expect that every numeric codepoint in Unicode must evaluate to number in

Re: can a method name contain a funny character?

On Tue, Apr 12, 2016 at 6:12 PM, Brandon Allbery wrote: > I was explaining why some "symbols" are acceptable to the parser. Which one > is more appropriate is not my call, I was thinking about what exactly are valid identifiers in Perl6/rakudo's implementation. The docs

Re: Unwanted failure and FAILGOAL

Hi, On 05/11/2016 07:45 AM, Richard Hainsworth wrote: I have the following in a grammar rule TOP{ ^ + $ }; rule statement { '=' | { { self.panic($/, "Declaration syntax incorrect") } } }; rule endvalue { '(' ~ ')'

Re: Unwanted failure and FAILGOAL

Hi Richard, Not a complete answer to your question; just an observation about your grammar: > rule TOP{ ^ + $ }; > > rule statement { '=' > | { { self.panic($/, "Declaration syntax incorrect") } } > }; > > rule endvalue { '(' ~ ')' >

Re: A practical benchmark shows speed challenges for Perl 6

On Wed, Mar 30, 2016 at 3:20 PM, Elizabeth Mattijsen wrote: > Thanks for your thoughts! > > I’ve implemented $*DEFAULT-READ-ELEMS in > https://github.com/rakudo/rakudo/commit/5bd1e . > > Of course, all of this is provisional, and open for debate and bikeshedding. Thanks! And

Re: A practical benchmark shows speed challenges for Perl 6

> On 30 Mar 2016, at 16:06, yary wrote: > > Cross-posting to the compiler group- > > On Wed, Mar 30, 2016 at 8:10 AM, Elizabeth Mattijsen wrote: >> If you know the line endings of the file, using >> IO::Handle.split($line-ending) (note the actual character,

Re: A practical benchmark shows speed challenges for Perl 6

Cross-posting to the compiler group- On Wed, Mar 30, 2016 at 8:10 AM, Elizabeth Mattijsen wrote: > If you know the line endings of the file, using > IO::Handle.split($line-ending) (note the actual character, rather than a > regular expression) might help. That will read in

Re: Perl 6 mentions on Wikipedia

I want in. I'm working on a production project for cloud computing that fuses 5 and 6 together. It's proving very useful... Sent from my iPhone > On Feb 25, 2016, at 4:26 PM, Damian Conway wrote: > > Dear fellow revellers in the dawning Golden Age of Perl 6, > > I just

Re: Blogging on Perl6 anonymous proto/multi

I made a comment on your blog which is awaiting moderation. Anyways here it is for people on the mailing list: I agree that being able to compose dispatchers and candidates procedurally is very useful. And you can sorta do it. Check out:

Re: It's time to use "use 6.c"

On Sat, Feb 06, 2016 at 08:20:14PM -0500, yary wrote: > Thanks all... I expect hiccups... just venting to help (future coders > and current self)... while we're on this topic > > a) lwp-download.pl doesn't have a "use 6". Since Windows ignores the > shebang, it invokes perl5 which is registered

Re: It's time to use "use 6.c"

On Tue, Feb 9, 2016 at 5:38 AM, Peter Pentchev wrote: > For the record, just to clear up some possible confusion, "use 6.c" > doesn't work in source files; you need "use v6.c". > Clarifying: yary seems to have been confused by the fact that META6.json (only) needs to use

Re: It's time to use "use v6.c"

The windows p6doc fix at http://perl6.org/downloads/ has been updated. On 6 February 2016 at 21:17, Steve Mynott wrote: > Are you using windows? > > From the recently updated http://perl6.org/downloads/ > > "p6doc was broken on Windows. Fix is to, with Git in the %PATH%,

Re: It's time to use "use v6.c"

"panda --force install p6doc" fixed it for me!

Re: It's time to use "use v6.c"

On 2016-02-06 11:35 AM, Brandon Allbery wrote: On Sat, Feb 6, 2016 at 2:30 PM, yary wrote: this morning I installed the 2016.01 R*. Now I'm at the NYC perl6 study group, and a helpful neighbor asked me to start up p6doc. This is something of an edge case. It is

Re: It's time to use "use v6.c"

On Sat, Feb 6, 2016 at 2:30 PM, yary wrote: > this morning I installed the 2016.01 R*. Now I'm at the NYC perl6 > study group, and a helpful neighbor asked me to start up p6doc. > This is something of an edge case. It is reasonable for stuff that is supposed to ship *with*

Re: It's time to use "use v6.c"

Are you using windows? >From the recently updated http://perl6.org/downloads/ "p6doc was broken on Windows. Fix is to, with Git in the %PATH%, "panda --force install p6doc" and delete C:\rakudo\bin\p6doc.bat." S On 6 February 2016 at 19:30, yary wrote: > this morning I

Re: It's time to use "use 6.c"

Thanks all... I expect hiccups... just venting to help (future coders and current self)... while we're on this topic a) lwp-download.pl doesn't have a "use 6". Since Windows ignores the shebang, it invokes perl5 which is registered to handle "pl" files, and gives a bunch of syntax errors. If it

Re: Are proposals for new language methods considered?

The language is intended to evolve; the specification will change as we go. If you have a proposal, go ahead and make it, see what traction it gets on the list. On Sun, Jan 31, 2016 at 8:27 AM, Tom Browder wrote: > I would like to propose some new Str and IO::Path methods

Re: Are proposals for new language methods considered?

On Sun, Jan 31, 2016 at 5:01 PM, Will Coleda wrote: > The language is intended to evolve; the specification will change as we go. > > If you have a proposal, go ahead and make it, see what traction it > gets on the list. Is there any specific format for a proposal? If not, is

Re: Are proposals for new language methods considered?

Nope. Most people just show up on #perl6 and chat, or make a pull request or open an RT. On Sun, Jan 31, 2016 at 6:10 PM, Tom Browder wrote: > On Sun, Jan 31, 2016 at 5:01 PM, Will Coleda wrote: >> The language is intended to evolve; the specification

Re: Are proposals for new language methods considered?

On Sun, Jan 31, 2016 at 5:20 PM, Will Coleda wrote: > Nope. Most people just show up on #perl6 and chat, or make a pull > request or open an RT. Gotcha, thanks. -Tom

Re: Rationale for $!

Hi, On 01/28/2016 04:06 PM, Todd C. Olson wrote: > Is there a way to make the exception be thrown eagerly, at the devision > statement rather than waiting until use, at the say statement? Yes, 'use fatal;' Cheers, Moritz

Re: Rationale for $!

On Wed, Jan 27, 2016 at 11:00 AM, Felipe Gasper wrote: > Unrelated, but, does open() not throw on failures anyway? (Noodling with > the perl6 REPL just now seems inconclusive.) There have been issues with failures in sink context not throwing, IIRC? So how you were

Re: Rationale for $!

On Wed, Jan 27, 2016 at 11:06 AM, Felipe Gasper wrote: > On 27 Jan 2016 11:03 AM, Brandon Allbery wrote: >> >> On Wed, Jan 27, 2016 at 11:00 AM, Felipe Gasper > > wrote: >> >> Unrelated, but, does open() not

Re: Rationale for $!

Slight change in focus of question ... > On We 2016-01-27, at 09:15, Felipe Gasper wrote: > --- > use v6; > > my $x = 10; > my $y = 0; > > my $z = $x / $y; > > my $exception; > { >{ >say $z; >CATCH { >default { >

Re: Rationale for $!

On Wed, Jan 27, 2016 at 10:32:46AM -0500, Felipe Gasper wrote: [snip] > But, what is the point of $! at all? The exception is given to the CATCH > block as $_. If I want access to it outside CATCH, isn’t the expected > workflow to save CATCH{$_} to a variable, the way my example does it? Well, it

Re: Rationale for $!

On 01/27/2016 04:32 PM, Felipe Gasper wrote: On 27 Jan 2016 10:15 AM, Moritz Lenz wrote: On 01/27/2016 03:15 PM, Felipe Gasper wrote: So, what *is* the scoping of $!? Scoped to a routine, iirc (sub, method, regex) Interesting. JavaScript programmers that I’ve known bemoan that their

Re: Rationale for $!

On 27 Jan 2016 10:56 AM, Moritz Lenz wrote: But, what is the point of $! at all? Convenience. It makes it easy to write commonly-used constructs much faster. My mostly unscientific approach to gather usage of try vs. CATCH in the ecosystem: moritz@hack:~/p6/perl6-all-modules$ git grep --word

Re: Rationale for $!

On 27 Jan 2016 11:03 AM, Brandon Allbery wrote: On Wed, Jan 27, 2016 at 11:00 AM, Felipe Gasper > wrote: Unrelated, but, does open() not throw on failures anyway? (Noodling with the perl6 REPL just now seems inconclusive.)

Re: Rationale for $!

On 27 Jan 2016 10:44 AM, Peter Pentchev wrote: On Wed, Jan 27, 2016 at 10:32:46AM -0500, Felipe Gasper wrote: [snip] But, what is the point of $! at all? The exception is given to the CATCH block as $_. If I want access to it outside CATCH, isn’t the expected workflow to save CATCH{$_} to a

Re: Rationale for $!

On 27 Jan 2016 10:15 AM, Moritz Lenz wrote: On 01/27/2016 03:15 PM, Felipe Gasper wrote: So, what *is* the scoping of $!? Scoped to a routine, iirc (sub, method, regex) Interesting. JavaScript programmers that I’ve known bemoan that their language uses function scoping rather than block

Re: Rationale for $!

On Wed, Jan 27, 2016 at 11:00 AM, Felipe Gasper wrote: > Could it not be: > > try my $f = open(...) or die … > Don't need a "try" there to make it work. An exception object/failure is false, so "my $f = open(...) or die" will assign the exception to $f, which is false,

Re: Rationale for $!

Hi, On 01/27/2016 07:17 AM, Felipe Gasper wrote: Hello, What is the purpose of having $! in Perl 6? The global variables in Perl 5 are a constant headache, prompting us to need to local()ize variables like $@, $!, and $? to avoid unforeseen consequences like RT #127386 and those

Re: Rationale for $!

On 27 Jan 2016 7:15 AM, Moritz Lenz wrote: On 01/27/2016 07:17 AM, Felipe Gasper wrote: Hello, What is the purpose of having $! in Perl 6? The global variables in Perl 5 are a constant headache, prompting us to need to local()ize variables like $@, $!, and $? to avoid unforeseen

Re: Rationale for $!

On 01/27/2016 03:15 PM, Felipe Gasper wrote: So, what *is* the scoping of $!? Scoped to a routine, iirc (sub, method, regex)

Re: confused about 'try'

Hi, On 11/24/2015 06:39 AM, brad clawsie wrote: > Been playing with perl6 and it is truly amazing. > > I'm somewhat confused as to when I should should wrap subroutine > invocations with `try`. My `CATCH` clauses seem to be able to catch > thrown Exception instances if I use `try` or not.

Re: Exploit the versioning (was Re: Backwards compatibility and release 1.0)

Short answer: everything must declare which semantics it expects- everything in Panda/CPAN at least. And we already knew it, just need to do it. Full post: This thread points to a bigger problem, which has a solution that is both cultural and technical. Perl5 has a colossal code corpus, humbling

Re: Backwards compatibility and release 1.0

On 10/15/2015 10:47 AM, Smylers wrote: Moritz Lenz writes: On 10/13/2015 10:52 AM, Richard Hainsworth wrote: Following on the :D not :D thread, something odd stuck out. On 10/13/2015 03:17 PM, Moritz Lenz wrote: We have 390+ modules, and hand-waving away all trouble of maintaining them

Re: Backwards compatibility and release 1.0

> On 15 Oct 2015, at 12:57, Mark Overmeer wrote: > > * Elizabeth Mattijsen (l...@dijkmat.nl) [151015 10:43]: >> FWIW, I’m with FROGGS on this. >> use variables :D; > > In the first response to this message, Moritz spoke about > use invocant :D; > and use parameters :D; >

Re: Backwards compatibility and release 1.0

> On 15 Oct 2015, at 11:06, Tobias Leich wrote: > Am 15.10.2015 um 10:47 schrieb Smylers: >> Moritz Lenz writes: >> >>> On 10/13/2015 10:52 AM, Richard Hainsworth wrote: >>> Following on the :D not :D thread, something odd stuck out. On 10/13/2015 03:17 PM,

Re: Backwards compatibility and release 1.0

Am 15.10.2015 um 10:47 schrieb Smylers: > Moritz Lenz writes: > >> On 10/13/2015 10:52 AM, Richard Hainsworth wrote: >> >>> Following on the :D not :D thread, something odd stuck out. >>> >>> On 10/13/2015 03:17 PM, Moritz Lenz wrote: We have 390+ modules, and hand-waving away all trouble

Re: Backwards compatibility and release 1.0

Moritz Lenz writes: > On 10/13/2015 10:52 AM, Richard Hainsworth wrote: > > > Following on the :D not :D thread, something odd stuck out. > > > > On 10/13/2015 03:17 PM, Moritz Lenz wrote: > > > > > > We have 390+ modules, and hand-waving away all trouble of > > > maintaining them seems a bit

Re: Backwards compatibility and release 1.0

On 10/13/2015 03:17 PM, Moritz Lenz wrote: >... We have 390+ modules, and hand-waving away all > trouble of maintaining them seems a bit lofty. > ... a large percentage of the module updates are done by group of > maybe five to a dozen volunteers. ... 5 people updating 70% of 390 > modules.

Re: Backwards compatibility and release 1.0

Moritz rant away! Actually, I think this it is a very significant milestone in the development of a language and its ecosystem when backwards compatibility becomes an issue. There will always be modules that have bit rot, insufficient documentation, inadequate testing, no reviews, etc. The

Re: Exploit the versioning (was Re: Backwards compatibility and release 1.0)

On 2015-10-15 5:27 AM, yary wrote: Short answer: everything must declare which semantics it expects- everything in Panda/CPAN at least. And we already knew it, just need to do it. I believe this is something Perl 6 should require in general, if it doesn't. That is, it should be MANDATORY for

Re: Backwards compatibility and release 1.0

On 10/13/2015 10:52 AM, Richard Hainsworth wrote: Following on the :D not :D thread, something odd stuck out. On 10/13/2015 03:17 PM, Moritz Lenz wrote: But hopefully none of them breaking backwards compatibility on such a large scale. The last few backwards incompatible changes still cause

Re: Backwards compatibility and release 1.0

* Moritz Lenz (mor...@faui2k3.org) [151014 09:54]: > In Practice, there's a small number of people who try to update modules to > match when the compiler changed. Most module authors don't hang out in > #perl6, eager to update their modules to the lastest rakudo change. With the relatively small

Re: To :D or not to :D

Hi Patrick, thank you for your thoughts. I needed a bit more time for the response ;-) * Patrick R. Michaud (pmich...@pobox.com) [151013 01:05]: > On Tue, Oct 13, 2015 at 12:32:01AM +0200, Mark Overmeer wrote: > > Yes, that what I started realizing when I saw all the pain Perl6 goes to > >

Exploit the versioning (was Re: Backwards compatibility and release 1.0)

I have a proposal. Unlike with say the GLR, perhaps this whole :D thing may be a good test case for the Perl 6 feature of explicit language versioning. How about we don't make the :D change now, and give more thought as to whether we actually want to do it at all. If we do decide it is

Re: Exploit the versioning (was Re: Backwards compatibility and release 1.0)

On 2015-10-14 6:14 AM, Parrot Raiser wrote: Is this particular change one that could be implemented algorithmically, or at least partially so? (E.g. For all modules check for the presence of a ":D". If it's there, no action. If not, insert a line of code. Run a test. If

Re: To :D or not to :D

> * Patrick R. Michaud (pmich...@pobox.com) [151013 01:05]: >> On Tue, Oct 13, 2015 at 12:32:01AM +0200, Mark Overmeer wrote: >>> Yes, that what I started realizing when I saw all the pain Perl6 goes to >>> ignore the existence of a real "undef" in the language. (I follow Perl6 >>> from a short

Re: Exploit the versioning (was Re: Backwards compatibility and release 1.0)

Is this particular change one that could be implemented algorithmically, or at least partially so? (E.g. For all modules check for the presence of a ":D". If it's there, no action. If not, insert a line of code. Run a test. If successful, post change. If not, alert a

Re: To :D or not to :D

On 10/12/2015 09:51 PM, Mark Overmeer wrote: * Moritz Lenz (mor...@faui2k3.org) [151012 15:32]: . are they using :D correctly? Yes, though not everybody uses :D as much as they do. Do you check that all the parameters that your Perl 5 methods/subs receive are defined? If not, you

Re: To :D or not to :D

* Moritz Lenz (mor...@faui2k3.org) [151013 07:18]: > >In Perl5, you get slower code when you test for definedness... in Perl6 > >you get faster (better optimized) code. That's a big difference. > > Do you? Did you actually measure that? For Perl6? Well, Liz tells us that it can be optimized

Re: Backwards compatibility and release 1.0

I had a related thought. We want Perl 6 to be the best it can be out of the gate when it is declared production ready at Christmas or whatever. If it is better for the default to be that parameters must be defined where not explicitly declared otherwise, then that is what Perl 6 should

Re: To :D or not to :D

Hi, On 10/12/2015 03:41 PM, Mark Overmeer wrote: > > Hi all, > > Liz and Tux demonstrate powerful Perl6 code at each monthly meeting of > our Mongers in Amsterdam. Looking at their examples, I collected a few > questions of which I want to discuss the first one in this thread. > > > When I

Re: To :D or not to :D

* Moritz Lenz (mor...@faui2k3.org) [151012 15:32]: > > . are they using :D correctly? > > Yes, though not everybody uses :D as much as they do. Do you check that > all the parameters that your Perl 5 methods/subs receive are defined? If > not, you wouldn't use :D in Perl 6 either. In Perl5,

Re: To :D or not to :D

On Mon, Oct 12, 2015 at 09:51:13PM +0200, Mark Overmeer wrote: > > method new(MyClassHere:U: *@args) { ... } > > > > in the constructor, which would be quite hostile to newbies. It's still > > not clear to me how to avoid that. > > It is also unclear to me what this means. It is a method

Re: To :D or not to :D

* Patrick R. Michaud (pmich...@pobox.com) [151012 20:25]: > > > method new(MyClassHere:U: *@args) { ... } > Keep in mind that what Perl 6 calls a "type object" isn't quite the > same as class objects in other languages -- a Perl 6 typename is > really an undefined instance of a class. In other

Re: To :D or not to :D

On Tue, Oct 13, 2015 at 12:32:01AM +0200, Mark Overmeer wrote: > Yes, that what I started realizing when I saw all the pain Perl6 goes to > ignore the existence of a real "undef" in the language. (I follow Perl6 > from a short distance since its start, read all original designs, but > this penny

Re: Does Perl 6 use $a and $b in sorting?

sort accepts something callable with an arity of 2. Subroutines, blocks and pointies will do: say sort { $^a cmp $^b }, 5, 3, 2, 6, 4 OUTPUT«(2 3 4 5 6)␤» say sort { $^left cmp $^right }, 5, 3, 2, 6, 4 OUTPUT«(2 3 4 5 6)␤» say sort -> $a, $b { $a cmp $b }, 5, 3, 2, 6, 4 OUTPUT«(2 3 4 5 6)␤»

[perl6/specs] de53e4: Initial work on an S07 re-write.

paths: M S07-lists.pod Log Message: --- Initial work on an S07 re-write. This is a work in progress, and I'll be filling out the rest in the coming days. It could do with some proof-reading; patches to fix any issues are welcome.

Re: [perl6/specs] 614b6f: doc with/without

Is there an error in the cascade? Shouldn't the indices be 'a', 'b', 'c'; not 'a','a','a' ? On 08/10/2015 11:26 PM, yary wrote: with, without look awesome. -y On Sat, Aug 8, 2015 at 2:38 PM, GitHub nore...@github.com mailto:nore...@github.com wrote: Branch: refs/heads/master

[perl6/specs] 982eda: Prevent some confusion re a b c

) Changed paths: M S04-control.pod Log Message: --- Prevent some confusion re a b c

Re: [perl6/specs] 614b6f: doc with/without

If this is about: These may be cascaded: with $s.index(a) { Found a at $_ } orwith $s.index(b) { Found b at $_ } orwith $s.index(c) { Found c at $_ } else { Didn't find a, b or c” } then the code is correct. What would be the point of searching for “a” again

Re: [perl6/specs] 614b6f: doc with/without

with, without look awesome. -y On Sat, Aug 8, 2015 at 2:38 PM, GitHub nore...@github.com wrote: Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 614b6f36e1cae4c787e378bc6ab2afa1f86de1f0

Re: Language design

Darren Duncan wrote On 2015-06-16 2:15 PM, The Sidhekin wrote: On Tue, Jun 16, 2015 at 10:52 PM, Michael Zedeler mich...@zedeler.dk wrote: ...and unpredictable performance is a cost you're willing to pay?     I don't write performance-critical applications, but even if I

Re: Language design

On Tue, Jul 14, 2015 at 12:04 AM, Michael Zedeler mich...@zedeler.dk wrote: So far, almost every other language has behaved this way, and it has worked. I can see that Rats do solve a problem, but if you'd claim that it is very severe then I'd disagree. This is a minor nuisance that I'd only

Re: Types for Perl 6: request for comments

to access the c instance variable of the argument $b thus yielding a run-time error - instead Perl6 more correctly complains that it was expecting a ColPoint, but got a Point instead. Indeed one cannot generally replace a subtype with its parent type, only the other way around. Can correct by re

Re: Types for Perl 6: request for comments

with its parent type, only the other way around. Can correct by re-writing along the lines of This fails to dispatch because ColPoint's equal method requires a ColPoint argument, but we are calling it with the supertype Point, which does not compose with the method's signature. (Furthermore

Re: Types for Perl 6: request for comments

On Fri, Jun 26, 2015 at 4:32 AM, Giuseppe Castagna g...@pps.univ-paris-diderot.fr wrote: my $sub = do { proto foo (|) { * } multi foo (Int $x) { $x + 1 } multi foo (Str $y) { $y ~ 'a' } foo; } Oh yes, nice ... I think I will add it in my paper (and if you send me

Re: Types for Perl 6: request for comments

is ambiguous, due to your use of ;; there. And sumI /should/ be ambiguous, because the caller sumC(Int $x ;; $y) {sumI($x,$y)} means sumI will always be called with $x - Int and varying $y. That example could use a little re-working. Oh, right, Thank you, I apologize, I did some cutpaste errors

Re: Types for Perl 6: request for comments

The anon does something. For example this code prints bob my $routine = proto bar (|) { * }; multi bar (Int $x) { $x - 2 } multi bar (Str $y) { $y ~ 'b' } say $routine('bo'); but change the first line to my $routine = anon proto bar (|) { * }; and you get an error Cannot call 'bar'; none of

Re: Types for Perl 6: request for comments

Subs are lexical by default, so adding my to the function declarators does nothing. Not sure what anon is doing there. My guess is that anon in sink context does nothing, and Rakudo just builds another proto for foo when it sees the first multi. Protos are optional (but not in the compiler

Re: Anonymous multi-subs

On Wednesday, June 24, 2015, yary not@gmail.com wrote: Now that I've thought about it for 90 seconds (not fully-formed idea), if one were to have an anonymous multi-sub, it ought to be constructed from a list of *signature*, *body *pairs. And/or, any non-finalized sub could have a method

Re: Anonymous multi-subs

I'll just note that you can fake anon multi subs with lexical subs like this: my $sub = do { proto foo (|) { * } multi foo (Int $x) { $x + 1 } multi foo (Str $y) { $y ~ 'a' } foo; } say $sub(hello); The sub there is still named foo as attested by $sub.name, but isn't available

Re: Types for Perl 6: request for comments

of ;; there. And sumI *should* be ambiguous, because the caller sumC(Int $x ;; $y) {sumI($x,$y)} means sumI will always be called with $x - Int and varying $y. That example could use a little re-working. Note to Rakudo-porters: Can the error message remember the ;; in the sig ? The message from Rakudo * has

Re: Language design

On 2015-06-16 2:15 PM, The Sidhekin wrote: On Tue, Jun 16, 2015 at 10:52 PM, Michael Zedeler mich...@zedeler.dk wrote: ...and unpredictable performance is a cost you're willing to pay? I don't write performance-critical applications, but even if I did, why would I prefer getting the

Re: Rationalizing numeric types

Yary, There already is a Perl 6 continue fractions module. Spoiler alert: it doesn't work in the least. But I'd be happy to give you a commit bit. I don't think we should even begin to think about including something like that in the Perl 6 core before we have a complete, working

Re: Language design

I like the explanation of how Rats solve a class of rounding errors, 0.3 - (0.2 + 0.1) equals exactly 0 for example. On the other hand, it's still a compromise that's shifting closer to correctness, fixing a bunch of potential bugs, but not all in that class: Rakudo: say 2 - (sqrt 2) ** 2

Re: The invocation operators .* and .+

On Wed, Jun 17, 2015 at 1:29 PM, Aristotle Pagaltzis pagalt...@gmx.de wrote: * yary not@gmail.com [2015-06-17 17:10]: Perl6's TEARDOWN Sorry for the confusion. It’s not in Perl 6. I invented .teardown for this example because I didn’t want to call it .destroy – that’s all. That's good to

Re: The invocation operators .* and .+

* yary not@gmail.com [2015-06-17 17:10]: Perl6's TEARDOWN Sorry for the confusion. It’s not in Perl 6. I invented .teardown for this example because I didn’t want to call it .destroy – that’s all. -- Aristotle Pagaltzis // http://plasmasturm.org/

Re: The invocation operators .* and .+

A couple years ago I wrote a little Perl6 in response to a challenge, and it took me a while to figure out BUILD, BUILDALL, and new(). Learning the object model meant reading what was available on the web plus some time on the #perl6 IRC channel. I managed to get it all working properly for my

Re: Language design

I think Perl 6 tries to include too much rather than too little. It will be possible to just use a subset On 16 June 2015 at 10:32, Michael Zedeler mich...@zedeler.dk wrote: On 06/12/15 15:54, Parrot Raiser wrote: Has somebody been following the discussions on types? http://xkcd.org/1537/

Re: Language design

Subsets will be absolutely essential, if it is to be possible to learn it with a reasonable amount of time and effort. On 6/16/15, Paweł Murias pawelmur...@gmail.com wrote: I think Perl 6 tries to include too much rather than too little. It will be possible to just use a subset On 16 June

<    1   2   3   4   5   6   7   8   9   10   >