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 $!

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 { >$exception = $_; >

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 throw on failures anyway? (Noodling >> with the p

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 noodling can matter. -- br

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, causing the "die" to execu

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 langua

Re: Rationale for $!

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

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 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 vari

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 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 sc

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: 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 cons

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 docu

Rationale for $!

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 documented in Try::Tiny’s POD. Perl 6 seems to give

Re: Definitions: compiler vs interpreter [was: Rationale for a VM + compiler approach instead of an interpreter?]

ke we agree (minus perhaps my misunderstanding of how perl handles begin and end blocks, or bytecode..). G. -- Original Message -- Received: 08:32 AM EST, 12/10/2014 From: Aristotle Pagaltzis To: perl6-us...@perl.org Subject: Re: Definitions: compiler vs interpreter [was: Rationale for

Re: Definitions: compiler vs interpreter [was: Rationale for a VM + compiler approach instead of an interpreter?]

* Parrot Raiser <1parr...@gmail.com> [2014-12-07 22:40]: > The practical distinction, surely, is that the output of a compiler > is usually kept around, to be run one or more times, whereas the an > interpreter always works with the original human-readable source. Yes, surely that’s it. We all con

Re: Definitions: compiler vs interpreter [was: Rationale for a VM + compiler approach instead of an interpreter?]

ually what was run. So a compilation step, and an interpreting step. -- Original Message -- Received: 04:37 PM EST, 12/07/2014 From: Parrot Raiser <1parr...@gmail.com> To: Aristotle Pagaltzis Cc: perl6-us...@perl.org Subject: Re: Definitions: compiler vs interpreter [was: Rationa

Re: Definitions: compiler vs interpreter [was: Rationale for a VM + compiler approach instead of an interpreter?]

The practical distinction, surely, is that the output of a compiler is usually kept around, to be run one or more times, whereas the an interpreter always works with the original human-readable source. The distinction mattered a lot more when compiling even a trivial program involved at least the

Re: Rationale for a VM + compiler approach instead of an interpreter?

On Sun, Dec 07, 2014 at 07:58:06AM +0530, Mayuresh Kathe wrote: > > I am training for computer science, and as a "rite of passage", my > mentor + guide has asked me to write either an interpreter or a > compiler for any language of my choice. Would prefer to work on Perl6. Perhaps write either an

Re: Rationale for a VM + compiler approach instead of an interpreter?

, JVM and Rakudo). Is there any rationale for going with the above approach instead of an interpreter based one? First of all, the lines between interpreters and compilers a bit blurry. People think of Perl 5 as an interpreter, but actually it compilers to bytecode, which is then run by a runloop

Definitions: compiler vs interpreter [was: Rationale for a VM + compiler approach instead of an interpreter?]

* Moritz Lenz [2014-12-06 20:05]: > First of all, the lines between interpreters and compilers a bit > blurry. People think of Perl 5 as an interpreter, but actually it > compilers to bytecode, which is then run by a runloop. So it has > a compiler and an interpreter stage. This is sort of a tang

Re: Rationale for a VM + compiler approach instead of an interpreter?

Hi, On 06.12.2014 18:55, Mayuresh Kathe wrote: Hello, I have been reading up (a bit) on Perl6 and found most articles mentioning Parrot + Rakudo as the primary tools for development using the language. Well, these days we have three backends (MoarVM, JVM and Rakudo). Is there any rationale

Rationale for a VM + compiler approach instead of an interpreter?

Hello, I have been reading up (a bit) on Perl6 and found most articles mentioning Parrot + Rakudo as the primary tools for development using the language. Is there any rationale for going with the above approach instead of an interpreter based one? Also, would there be community

Re: Some rationale for the mixed encoding scheme

At 10:06 AM -0400 6/15/04, Andy Dougherty wrote: On Mon, 14 Jun 2004, Dan Sugalski wrote: I do realize that the Big ICU Patch tossed a lot of the infrastructure for this, which broke parrot for folks who can't/won't do ICU. (And there are a number of folks shut out of development because they c

Re: Some rationale for the mixed encoding scheme

On Mon, 14 Jun 2004, Dan Sugalski wrote: > I do realize that the Big ICU Patch tossed a lot of the > infrastructure for this, which broke parrot for folks who can't/won't > do ICU. (And there are a number of folks shut out of development > because they can't get ICU going) That'll be put back over

Some rationale for the mixed encoding scheme

Since I know this is going to come up, I figure I should pre-empt it and be done with it. (Though I should've put this in the string document. Ah, well. Hopefully timing isn't everything, or I am *so* in trouble...) Why aren't we converting to Unicode on the edge? Since, after all, any Sane La