Re: EVAL?

On Fri, 15 Jun 2018 at 06:13, Trey Harris wrote: Thanks for the nice examples of IntStr and friends. I was intrigued with this statement at the end: > Also note that using s/printf at all is not encouraged Could you expand on that? > ​ > -- Norman Gaywood, Computer Systems Officer School o

Re: EVAL?

On 06/14/2018 01:13 PM, Trey Harris wrote: Just a small stylistic thing to mention: On Thu, Jun 14, 2018 at 1:59 AM Todd Chester > wrote: p6        if not $dir.IO.d.bool {}        for  slice  "\n", $WebStr   ->  $Line { }   and on and on and so

Re: EVAL?

On 06/14/2018 11:10 AM, Elizabeth Mattijsen wrote: We are all maintainers of the glossary. Patches / Pull Requests are welcome. Hi Elizabeth, My favorite definition I found was: http://www.yourdictionary.com/pragma (computing, programming) A compiler directive; data embedded in so

Re: EVAL?

Just a small stylistic thing to mention: On Thu, Jun 14, 2018 at 1:59 AM Todd Chester wrote: p6 >if not $dir.IO.d.bool {} >for slice "\n", $WebStr -> $Line { } > > and on and on and so forth. I know a lot of them by heart now. > By .bool, I assume you meant .Bool, but in

Re: EVAL?

We are all maintainers of the glossary. Patches / Pull Requests are welcome. > On 14 Jun 2018, at 20:03, Brandon Allbery wrote: > > I'm trying to not second-guess whoever maintains the glossary. And by that > message also pointing up the omission. > > On Thu, Jun 14, 2018 at 2:01 PM The Sidhe

Re: EVAL?

I'm trying to not second-guess whoever maintains the glossary. And by that message also pointing up the omission. On Thu, Jun 14, 2018 at 2:01 PM The Sidhekin wrote: > On Thu, Jun 14, 2018 at 7:57 PM, Brandon Allbery > wrote: > >> You can never be certain in *any* case. Check if you're not sure

Re: EVAL?

On Thu, Jun 14, 2018 at 7:57 PM, Brandon Allbery wrote: > You can never be certain in *any* case. Check if you're not sure what it > means. Because sometimes languages use some term in a way you don't expect, > whether because they drew it from some specific discipline (Haskell uses a > lot of te

Re: EVAL?

Not to mention "language designer isn't from your culture, and the word has different connotations in theirs". The eastern (or for that matter western) US does not define the world. On Thu, Jun 14, 2018 at 1:57 PM Brandon Allbery wrote: > You can never be certain in *any* case. Check if you're n

Re: EVAL?

On Thu, Jun 14, 2018 at 7:46 PM, ToddAndMargo wrote: > On 06/14/2018 10:43 AM, The Sidhekin wrote: > >> >>More relevant, Perl 6 documentation: https://docs.perl6.org/languag >> e/pragmas >> > > You are presuming I knew the word was a Perl word. > I though it was English, as in pragmatic >

Re: EVAL?

You can never be certain in *any* case. Check if you're not sure what it means. Because sometimes languages use some term in a way you don't expect, whether because they drew it from some specific discipline (Haskell uses a lot of terminilogy from abstract mathematics, for example) or for some reas

Re: EVAL?

On 06/14/2018 10:49 AM, Brandon Allbery wrote: That's actually the origin of it: pragmatic / real-world behavior, as opposed to idealized situations. I can't always tell when things are English and when things are Perl.

Re: EVAL?

That's actually the origin of it: pragmatic / real-world behavior, as opposed to idealized situations. On Thu, Jun 14, 2018 at 1:47 PM ToddAndMargo wrote: > On 06/14/2018 10:43 AM, The Sidhekin wrote: > > > >More relevant, Perl 6 documentation: > > https://docs.perl6.org/language/pragmas > >

Re: EVAL?

On 06/14/2018 10:43 AM, The Sidhekin wrote:   More relevant, Perl 6 documentation: https://docs.perl6.org/language/pragmas You are presuming I knew the word was a Perl word. I though it was English, as in pragmatic

Re: EVAL?

That's just a different variant of an old shell "hack": drop a program named "test" somewhere where root might run a shell script. Which is why root's path no longer includes the current directory, and these days nothing outside the system directories. On Thu, Jun 14, 2018 at 1:37 PM ToddAndMargo

Re: EVAL?

On Thu, Jun 14, 2018 at 7:21 PM, ToddAndMargo wrote: > 2) what the heck is a "pragma"? Way to obscure. > I thought you knew. From the Perl 5 documentation: "A pragma is a module which influences some aspect of the compile time or run time behaviour of Perl, such as strict or warnings." Mo

Re: EVAL?

On 06/14/2018 10:30 AM, Brandon Allbery wrote: In short, pragmas are all-same-case "use" names; instead of loading code, they tell the compiler to change its behavior. The MONKEY-* pragmas generally control various kinds of unsafe or dangerous behavior, including direct access to the mechanism

Re: EVAL?

In short, pragmas are all-same-case "use" names; instead of loading code, they tell the compiler to change its behavior. The MONKEY-* pragmas generally control various kinds of unsafe or dangerous behavior, including direct access to the mechanisms underneath / "supporting" Rakudo and things like

Re: EVAL?

On 06/13/2018 12:27 PM, Brandon Allbery wrote: Exactly what it says: eval is a code injection attack waiting to happen. If you actually need it, you get to do your own data sanitization, and you tell Perl 6 you did so with "use MONKEY-SEE-NO-EVAL;". Hi Brandon, Thank you for clarifying. My h

Re: EVAL?

On 06/14/2018 09:11 AM, Timo Paulssen wrote: If it's literally just the name of a sub that you'll immediately invoke, you can side-step EVAL completely     ::('&' ~ $RunSpecific)() should do the trick. ::("&foo") will give you the sub object, and putting () after it will immediately call it.

Re: EVAL?

> On 14 Jun 2018, at 18:19, The Sidhekin wrote: > > On Thu, Jun 14, 2018 at 6:11 PM, Timo Paulssen wrote: > If it's literally just the name of a sub that you'll immediately invoke, > you can side-step EVAL completely > > ::('&' ~ $RunSpecific)() > > should do the trick. > > I haven't

Re: EVAL?

On Thu, Jun 14, 2018 at 6:11 PM, Timo Paulssen wrote: > If it's literally just the name of a sub that you'll immediately invoke, > you can side-step EVAL completely > > ::('&' ~ $RunSpecific)() > > should do the trick. > I haven't been much into Perl 6 lately, but isn't this just the same

Re: EVAL?

If it's literally just the name of a sub that you'll immediately invoke, you can side-step EVAL completely     ::('&' ~ $RunSpecific)() should do the trick. ::("&foo") will give you the sub object, and putting () after it will immediately call it. It will allow access to all subs, even from the

Re: EVAL?

> wrote: On 06/13/2018 12:27 PM, Brandon Allbery wrote: use MONKEY-SEE-NO-EVAL; Thank you. Someone had fun with that name! Do I presume there is not other way around the issue? On 06/14/2018 05:21 AM, The Sidhekin wrote: On Thu, Jun 14,

Re: EVAL?

On Thu, Jun 14, 2018 at 8:01 AM, Todd Chester wrote: > > > On 06/13/2018 12:27 PM, Brandon Allbery wrote: > >> use MONKEY-SEE-NO-EVAL; >> > > Thank you. Someone had fun with that name! > > Do I presume there is not other way around the issue? > That depends on your use case. EVAL/eval is pow

Re: EVAL?

On 06/13/2018 12:27 PM, Brandon Allbery wrote: use MONKEY-SEE-NO-EVAL; Thank you. Someone had fun with that name! Do I presume there is not other way around the issue?

Re: EVAL?

On Wed, 13 Jun 2018 15:23:56 -0700 yary wrote > Pet peeve, "$RunSpecific" with the quotes on either side is exactly the same as $RunSpecific without the quotes. Perl isn't shell. > > -y Hi Yary, Chuckle. Missed one. What?? Or two or three ... This program that I have been co

Re: EVAL?

It is in this situation, but not necessarily always: “$foo” is equivalent to $foo.Str $foo is exactly what $foo is. my $foo = 42;:wq dd $foo; # Int $foo = 42 dd “$foo” # “42" > On 14 Jun 2018, at 00:23, yary wrote: > > Pet peeve, "$RunSpecific" with the quotes on either side is exact

Re: EVAL?

Pet peeve, "$RunSpecific" with the quotes on either side is exactly the same as $RunSpecific without the quotes. Perl isn't shell. -y On Wed, Jun 13, 2018 at 12:27 PM, Brandon Allbery wrote: > Exactly what it says: eval is a code injection attack waiting to happen. > If you actually need it, yo

Re: EVAL?

Exactly what it says: eval is a code injection attack waiting to happen. If you actually need it, you get to do your own data sanitization, and you tell Perl 6 you did so with "use MONKEY-SEE-NO-EVAL;". On Wed, Jun 13, 2018 at 3:22 PM ToddAndMargo wrote: > Hi All, > > I am converting a program f

Re: eval and try should be separate

Given that try can be used with a statement as well as a block, I'm fine with this. We want to discourage people from using eval anyway, so forcing people to use 'try eval' to get p5 behavior is okay too. Larry

Re: eval and try should be separate

+1 It's been up for discussion before in #perl6 (with a quick search, I find and ), but so far no-one has acted on the idea. Kudos for picking it up. // Carl On Wed, Jun 29, 2011 at 10:44

Re: eval and try should be separate

I agree with the change. Let "try" be for exceptions and "eval" be for runtime compile+run of code. These are very distinct concepts and should be separate. -- Darren Duncan Stefan O'Rear wrote: I intend to change the definition of "eval" such that it does not catch exceptions. String eval'

Re: eval should throw an exception on compile error

On 05/07/2011 07:45 AM, Michael G Schwern wrote: > I was just playing around with eval, trying to figure out if you can define an > operator overload at runtime (seems you can't, good) and noticed this in the > spec... [1] > > "Returns whatever $code returns, or fails." > > How does one get t

Re: eval should throw an exception on compile error

On Sat, May 07, 2011 at 03:45:02PM +1000, Michael G Schwern wrote: > I was just playing around with eval, trying to figure out if you can define an > operator overload at runtime (seems you can't, good) and noticed this in the > spec... [1] > > "Returns whatever $code returns, or fails." > >

Re: eval() and lexical introspection in Parrot

On Wed, Dec 19, 2007 at 10:57:27PM -0600, Patrick R. Michaud wrote: > On Wed, Dec 19, 2007 at 11:15:46PM +0100, Mehmet Yavuz Selim Soyturk wrote: > > > One temporary workaround that I considered for this problem > > > would be to have eval() use introspection on its caller to > > > create a "wrappe

Re: eval() and lexical introspection in Parrot

On Wed, Dec 19, 2007 at 11:15:46PM +0100, Mehmet Yavuz Selim Soyturk wrote: > > One temporary workaround that I considered for this problem > > would be to have eval() use introspection on its caller to > > create a "wrapper sub" that duplicates the lexical environment of > > the caller, and then u

Re: eval() and lexical introspection in Parrot

> One temporary workaround that I considered for this problem > would be to have eval() use introspection on its caller to > create a "wrapper sub" that duplicates the lexical environment of > the caller, and then use that as the target of an :outer() > flag when it's passed to imcc. For example,

Re: eval

Hi Michael, On 5/24/06, Michael Mathews <[EMAIL PROTECTED]> wrote: Oh "try"! I like that! But is CATCH implemented in pugs? Anyone care to give a working example of try/CATCH? I don't think CATCH is implemented in pugs yet: #!/usr/local/bin/pugs catcher; sub catcher { say "here"; try {

Re: eval

On Wed, May 24, 2006 at 06:54:53PM +0300, Gabor Szabo wrote: : if eval "command" fails, where can I get the error message ? : : aka $@ in P5 ? All error variables have been unified into $!, so it should show up there. Larry

Re: eval

On Wed, May 24, 2006 at 19:54:53 +0300, Gabor Szabo wrote: > if eval "command" fails, where can I get the error message ? > > aka $@ in P5 ? $! http://dev.perl.org/perl6/doc/design/syn/S04.html#Exception_handlers -- Yuval Kogman <[EMAIL PROTECTED]> http://nothingmuch.woobling.org 0xEBD2741

Re: eval (was Re: New S29 draft up)

Paul Seamons skribis 2005-03-18 9:46 (-0700): > eval slurp "foo"; That requires foo to have an #line directive (or whatever its Perl 6 equivalent will be) in order to be useful when debugging. See also http://tnx.nl/include (I want Perl 6 to have this function that evals a file such that in

Re: eval (was Re: New S29 draft up)

Larry Wall wrote: On Fri, Mar 18, 2005 at 10:28:18AM -0500, Aaron Sherman wrote: : Thus: : : eval read :file("foo"); : : There you have it. The problem being that it will now report errors in some random temporary string rather than at some line number in a file. Not good. Orthogonality strike

Re: eval (was Re: New S29 draft up)

Larry Wall wrote: On Fri, Mar 18, 2005 at 10:28:18AM -0500, Aaron Sherman wrote: : Thus: : : eval read :file("foo"); : : There you have it. The problem being that it will now report errors in some random temporary string rather than at some line number in a file. Not good. Orthogonality strike

Re: eval (was Re: New S29 draft up)

Larry Wall wrote: On Fri, Mar 18, 2005 at 10:28:18AM -0500, Aaron Sherman wrote: : Thus: : : eval read :file("foo"); : : There you have it. The problem being that it will now report errors in some random temporary string rather than at some line number in a file. Not good. Orthogonality strike

Re: eval (was Re: New S29 draft up)

On Fri, Mar 18, 2005 at 10:28:18AM -0500, Aaron Sherman wrote: : Thus: : : eval read :file("foo"); : : There you have it. The problem being that it will now report errors in some random temporary string rather than at some line number in a file. Not good. Orthogonality strikes again. Lar

Re: eval (was Re: New S29 draft up)

> eval read :file("foo") How about: eval slurp "foo"; Paul Seamons

Re: eval (was Re: New S29 draft up)

On Fri, 2005-03-18 at 10:28, Aaron Sherman wrote: > On Fri, 2005-03-18 at 05:42, Rod Adams wrote: > > > Hmm. maybe we just need a function that loads an entire file and returns > > a string of it, then feeds that to eval. > > Well, I wasn't getting into the IO stuff, but since you said it, this

Re: eval (was Re: New S29 draft up)

On Fri, 2005-03-18 at 05:42, Rod Adams wrote: > Hmm. maybe we just need a function that loads an entire file and returns > a string of it, then feeds that to eval. Well, I wasn't getting into the IO stuff, but since you said it, this crosses a line with many related IO operations. I would call t

Re: eval {} or carp "blah: $@"

Jim Cromie wrote: > with p5, Ive often written > > eval {} or carp "$@ blah"; > > it seems to work, modulo any block that returns false :-( > and it reads nicer (to my eye) than > > eval {}; if ($@) {} > > but I surmise that it works cuz the return-value from the block is non-zero, > f

Re: eval {} or carp "blah: $@"

At 02:33 PM 5/2/02 -0600, Jim Cromie wrote: >eval {} or carp "$@ blah"; > >it seems to work, and it reads nicer (to my eye) than > >eval {}; if ($@) {} % perl -le 'eval { print "No exceptions here"; 0 } or warn "$@ blah"' No exceptions here blah at -e line 1. -- Peter Scott Pacific Systems De

Re: eval {} or carp "blah: $@"

On Thu, May 02, 2002 at 02:33:42PM -0600, Jim Cromie wrote: > > with p5, Ive often written > > eval {} or carp "$@ blah"; You generally Don't Want To Do That. If the eval succeeds, but the last statement in the eval happens to come out as false, then it'll still carp: $a = 0; eval { 1 < $a

Re: eval {} or carp "blah: $@"

On Thu, 2 May 2002, Jim Cromie wrote: > > with p5, Ive often written > > eval {} or carp "$@ blah"; > > it seems to work, and it reads nicer (to my eye) than > > eval {}; if ($@) {} > > but I surmise that it works cuz the return-value from the block is non-zero, > for successful eval, and 0

Re: 'eval' odd thought

On Fri, 15 Sep 2000 12:01:55 -0400, Mark-Jason Dominus wrote: >When you translate a script, the translator should translate things so >that they have the same meanings as they did before. If it doesn't >also translate eval, then your Perl 5 scripts will be using the Perl 6 >eval, which isn't wha

Re: 'eval' odd thought

> eval should stay eval. Yes, and this is the way to do that. When you translate a script, the translator should translate things so that they have the same meanings as they did before. If it doesn't also translate eval, then your Perl 5 scripts will be using the Perl 6 eval, which isn't wha

Re: 'eval' odd thought

On Fri, 15 Sep 2000, Bart Lateur wrote: > On Thu, 14 Sep 2000 18:14:49 -0400, Mark-Jason Dominus wrote: > > >The perl 5 -> perl 6 translator should [recursively handle eval] > > Blech, no. eval should stay eval. People are responsible for generating > Perl6 compatible code, if they construct

Re: 'eval' odd thought

On Thu, 14 Sep 2000 18:14:49 -0400, Mark-Jason Dominus wrote: >The perl 5 -> perl 6 translator should replace calls to 'eval' with >calls to 'perl5_eval', which will recursively call the 5->6 translator >to translate the eval'ed string into perl 6, and will then eval the >result. Blech, no. eval