eval

if eval "command" fails, where can I get the error message ? aka $@ in P5 ? Gabor

EVAL?

Hi All, I am converting a program from Perl5 to Perl 6. This line else { eval "$RunSpecific"; } became this line else { EVAL "$RunSpecific"; } And threw this error $ perl6 -c GetUpdates.pl6 ===SORRY!=== Error while compiling /home/linuxutil/GetUpdates.pl6 EVAL

Should the use of eval recommend EVAL?

Hi, I just tried to use eval "say 19+23"; but I got: ===SORRY!=== Error while compiling a.pl Undeclared routine: eval used at line 3. Did you mean 'val'? Would it be possible to recommend 'EVAL' as well ? Gabor

Q: eval

I'd like to cleanup eval.pmc and dynamic code compiling a bit. But before that I'd like to know: Which granularity do we allow for eval()ed code? Can that be an expression or statement too or is it always at least an (anonymous) subroutine? Does the compiled code see Parrot regist

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

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

Fwd: eval

Oh "try"! I like that! But is CATCH implemented in pugs? Anyone care to give a working example of try/CATCH? --michael On 25/05/06, Yuval Kogman <[EMAIL PROTECTED]> wrote: To complement string eval with eval { } (now called try): try { die "f

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?

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 c

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

Re: EVAL?

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, you

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?

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

Re: EVAL?

<mailto:toddandma...@zoho.com>> 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 Th

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 wi

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 muc

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 > > ::('&' ~ $RunS

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 puttin

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 clari

Re: EVAL?

kudo and things like EVAL. Other all-uppercase names also generally represent "dangerous" actions or options. There are a few pragmas that are all lowercase instead of all uppercase; they also change the compiler's behavior, but are safer than the all-uppercase ones. "use lib&q

Re: EVAL?

ess to the mechanisms underneath / "supporting" Rakudo and things like EVAL. Other all-uppercase names also generally represent "dangerous" actions or options. There are a few pragmas that are all lowercase instead of all uppercase; they also change the compiler's behavior, bu

Re: EVAL?

d: This hint ("use the MONKEY-SEE-NO-EVAL pragma to override this error, but only if you're VERY sure your data contains no injection attacks") is rather terse for those who need it ... might it be better if the error message instead referenced documentation? Eirik

Re: EVAL?

ontrol various kinds of unsafe or > > dangerous behavior, including direct access to the mechanisms underneath > > / "supporting" Rakudo and things like EVAL. Other all-uppercase names > > also generally represent "dangerous" actions or options. > > > >

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

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

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

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?

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?

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?

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?

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

[perl6/specs] 9742c3: fossil eval replaced with EVAL

S32-setting-library/Basics.pod Log Message: --- fossil eval replaced with EVAL

[perl #128417] [BUG] eval-dies-ok/eval-lives-ok EVAL code in the wrong context

# New Ticket Created by Zoffix Znet # Please include the string: [perl #128417] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=128417 > The results of these tests should be reversed, the eval-dies-ok succeeding and e

Re: Q: eval

At 1:48 PM +0100 11/8/04, Leopold Toetsch wrote: I'd like to cleanup eval.pmc and dynamic code compiling a bit. But before that I'd like to know: Which granularity do we allow for eval()ed code? Can that be an expression or statement too or is it always at least an (anonymous) subrou

Re: Q: eval

Dan Sugalski wrote: This was specified ages ago You have skipped one question: how would PIR code of this eval() look like, and specifically, what about that "goto"? # #! perl -w # my $i= 5; # LAB: #$i++; #eval("goto LAB if ($i==6)"); #print "$i\n";

Re: Q: eval

IR code of this eval() look like, and specifically, what about that "goto"? That goto's bogus and shouldn't work. I think it does right now, but I'm OK with making it not work -- it *shouldn't*, since in perl the eval's an anonymous sub, which means you've

Re: Q: eval

Dan Sugalski <[EMAIL PROTECTED]> wrote: > That goto's bogus and shouldn't work. I think it does right now, but > I'm OK with making it not work -- it *shouldn't*, since in perl the > eval's an anonymous sub, which means you've done a goto out of a sub > and into another, which... well, that's not

Re: Q: eval

At 6:23 PM +0100 11/9/04, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: That goto's bogus and shouldn't work. I think it does right now, but I'm OK with making it not work -- it *shouldn't*, since in perl the eval's an anonymous sub, which means you've done a goto out of a sub

RFE: eval documentation

Dear Perl6 Developers, https://docs.perl6.org/language/5to6-perlfunc#eval Would you please consider adding ::('&' ~ $RunSpecific)() &::($RunSpecific)() to the documentation, as well as an explanation of the error message when using EVAL ===SORRY!=== Error whi

[perl6/specs] 0b7df0: rename eval to EVAL to indicate specialness

-bits.pod M S04-control.pod M S05-regex.pod M S06-routines.pod M S11-modules.pod M S12-objects.pod M S29-functions.pod M S32-setting-library/Exception.pod M S99-glossary.pod Log Message: --- rename eval to EVAL to indicate specialness EVAL must have a

[perl #20315] [PATCH] eval

# New Ticket Created by Leopold Toetsch # Please include the string: [perl #20315] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=20315 > Attached is a first try towards eval. - interpreter has a new data mem

[CVS ci] eval #1

So I did it. Check in the first version of eval. First of all, I changed pdd06_pasm, the compile and compreg opcodes didn't fit really well into - well - my scheme of objects. A compiler is now a Parrot class, derived from NCI, living in interpreter->Parrot_compreg_hash. This also

eval {} or carp "blah: $@"

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 or undef when block dies, not cuz of magical tr

[CVS ci] eval changes

There is of course no "eval" in Parrot. Anyway: * the signature of a Parrot compiler PMC is now "PIt" - it returns a Sub PMC directly - or more precisely an Eval PMC, which is a Closure * attached onto this Closure is the compiled bytecode * this Closure's are named E

Blocks, continuations and eval()

Hi, (I'm sorry if this topic has already been discussed.) one day a friend asked if Perl 5 had a REPL facility. (Read-Eval-Print-Loop). I told him it has perl -de0, which is different in that it does not preserve the lexical scope across evaluated lines. This is because eval STRING create

variables inside an eval

If I have the following my $self = "some text"; my $nself = ~eval(q/"self is $self"/,:lang); then surely $nself should be "self is some text". But it is not. $self is not set inside the eval in pugs. But say ~eval(q/"self is $self"/); yields "self

[perl #61868] say eval ""

On Tue Dec 30 17:46:31 2008, si...@simon-cozens.org wrote: > This causes a null access in PMC, presumably because the eval is > returning the wrong kind of nothing. This should now be fixed in r34682, assigning to moritz++ so that we can verify there's a test for it. Thanks! Pm

[perl #61868] say eval ""

# New Ticket Created by Simon Cozens # Please include the string: [perl #61868] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=61868 > This causes a null access in PMC, presumably because the eval is returning the wr

Re: RFE: eval documentation

l6 Developers, > > https://docs.perl6.org/language/5to6-perlfunc#eval > > Would you please consider adding > > ::('&' ~ $RunSpecific)() > &::($RunSpecific)() > > to the documentation, as well as an explanation of > the error message when usin

Re: RFE: eval documentation

On 06/14/2018 10:45 AM, Brandon Allbery wrote: I think the message is obscure for a reason: the last thing you want is for someone to make an insecure module look "safe" by just dropping that pragma into it. You want to make them think about what they are doing. I hate always having to ask abo

Re: RFE: eval documentation

On 06/14/2018 10:31 AM, ToddAndMargo wrote: Dear Perl6 Developers, https://docs.perl6.org/language/5to6-perlfunc#eval Would you please consider adding ::('&' ~ $RunSpecific)() &::($RunSpecific)() to the documentation, as well as an explanation of the error messa

Re: RFE: eval documentation

jue., 14 jun. 2018 a las 20:12, ToddAndMargo () escribió: > On 06/14/2018 10:31 AM, ToddAndMargo wrote: > > Dear Perl6 Developers, > > > > https://docs.perl6.org/language/5to6-perlfunc#eval > > > > Would you please consider adding > > > > ::('&am

Re: RFE: eval documentation

On 06/14/2018 02:20 PM, JJ Merelo wrote: Can you please open an issue in perl6/doc? It's the best to track it, and also to check that it's been solved to everyone's satisfaction. If you can't for any reason, I can open it for you, but I'll have to keep coming back to see if it's OK when solved

Re: RFE: eval documentation

El jue., 14 jun. 2018 a las 23:34, ToddAndMargo () escribió: > On 06/14/2018 02:20 PM, JJ Merelo wrote: > > Can you please open an issue in perl6/doc? It's the best to track it, > > and also to check that it's been solved to everyone's satisfaction. > > > > If you can't for any reason, I can open

Re: RFE: eval documentation

On 06/14/2018 02:52 PM, JJ Merelo wrote: El jue., 14 jun. 2018 a las 23:34, ToddAndMargo (>) escribió: On 06/14/2018 02:20 PM, JJ Merelo wrote: > Can you please open an issue in perl6/doc? It's the best to track it, > and also to check that it's

[perl #122255] remove "eval"

# New Ticket Created by Will Coleda # Please include the string: [perl #122255] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=122255 > We tracked the initial spec switch to "EVAL", and left "eval" a

[perl #122255] remove "eval"

On Wed Jul 09 07:09:04 2014, coke wrote: > We tracked the initial spec switch to "EVAL", and left "eval" around > to allow folks to switch. > > Now that a suitable amount of time has passed, we should remove "eval" > and associated spec tests, and pr

[perl #122255] remove "eval"

On Tue Jul 15 05:41:54 2014, coke wrote: > On Wed Jul 09 07:09:04 2014, coke wrote: > > We tracked the initial spec switch to "EVAL", and left "eval" around > > to allow folks to switch. > > > > Now that a suitable amount of time has passed, we sho

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, an

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

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, whi

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 >

[perl #132015] [LTA] Backtraces for errors in EVAL print nonexistent paths (‘foo’.EVAL)

# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev # Please include the string: [perl #132015] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=132015 > Code: ‘foo’.EVAL Result: ===SORRY!=== Error while compiling /h

Re: [perl #20315] [PATCH] eval

Leopold Toetsch (via RT) wrote: # New Ticket Created by Leopold Toetsch # Please include the string: [perl #20315] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=20315 > Attached is a first try towards eval. I have

Re: [perl #20315] [PATCH] eval

Leopold Toetsch wrote: > 1) > The call function to the compiler/assembler is kept as a NCI. Better > would be a subclass of NCI (Compiler.pmc or so), which provides > invoke_keyed(key, next) Hmm, I don't know what a NCI is. Where (which files) can I find information about them? Jerome -- [EMAI

Re: [perl #20315] [PATCH] eval

try towards eval. - interpreter has a new data member Parrot_compreg_hash - parrot registers the PASM1 type i.e. what PDB_eval can parse - the new B opcode (ab)uses nci to build a function for calling PDB_eval - nci is extended (jit/i386 only), to understand an 'I' param as interpreter -

Re: [perl #20315] [PATCH] eval

In perl.perl6.internals, you wrote: > Leopold Toetsch wrote: >> 1) >> The call function to the compiler/assembler is kept as a NCI. Better >> would be a subclass of NCI (Compiler.pmc or so), which provides >> invoke_keyed(key, next) > Hmm, I don't know what a NCI is. Where (which files) can I find

Re: [perl #20315] [PATCH] eval

ent (PMC) look like? Ah, the big question. I'm not quite sure yet--let's try and work that out while I'm churning over objects. I did have a closer look at struct PackFile. I think we have some possiblities to actually eval()/invoke() the code, depending on the HL: - new inte

Re: [CVS ci] eval #1

Leopold Toetsch wrote: So I did it. Check in the first version of eval. Test status: make test succeeds, as well as -P, running the eval progs with JIT or with -t (trace)/-b (bounds) option fails, probably related to messing with the byte code. Fixed. bug in -j was triggered by garbage

Re: [perl #20315] [PATCH] eval

Leopold Toetsch wrote: So it seems, that for multiple code segments, we'll have to take the PackFile_ConstTable out of the structure and include file/line/debug/whatever information. This would look like: packfile aka interpreter->code: - constants - code_segment[] - byte_code - byte_c

Re: [perl #20315] [PATCH] eval

ot_Interp *); struct PackFile_ByteCode * Parrot_switch_to_cs(struct Parrot_Interp *, struct PackFile_ByteCode *); /* pop and destroy cs */ void Parrot_pop_cs(struct Parrot_Interp *); The eval code segs are named EVAL_{$n}. Further changes: - a PackFile_Constant is now a union, which saves a lot of

[perl #20400] [PATCH] ook.pasm eval

# New Ticket Created by Leon Brocard # Please include the string: [perl #20400] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=20400 > It's PASM1, not PASM. However, "make test" in languages/ook/ still segfaults for me atm.

Re: [perl #20315] [PATCH] eval

Leopold Toetsch wrote: I have it ready. - code is ready for debug information, I'll first do it in imcc, which could generate file/line info on the fly. Next would then be to extend the PBC format. And this is working too in imcc, including gdb-stepping into evaled code segments. Does

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 i

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 s

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 her

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

Re: Blocks, continuations and eval()

On Fri, Apr 08, 2005 at 05:03:11PM +0300, wolverian wrote: Hi wolverian, > one day a friend asked if Perl 5 had a REPL facility. > (Read-Eval-Print-Loop). I told him it has perl -de0, which is different > [...] > In Perl 6, the generic solution to fix this (if one wants to fix it) &g

Re: Blocks, continuations and eval()

At 10:03 AM 4/8/2005, wolverian wrote: To get to the real topic: In Perl 6, the generic solution to fix this (if one wants to fix it) seems, to me, to be to add a .eval method to objects that represent scopes. I'm not sure if scopes are first class values in Perl 6. Are they? How do you ge

Re: Blocks, continuations and eval()

On Fri, Apr 08, 2005 at 08:35:30AM -0700, David Storrs wrote: > I'm unclear on what you're looking for. Are you trying to get a way > to do interactive coding in P6? Or the ability to "freeze" a scope > and execute it later? Or something else? Neither in itself. I'm looking for a way to refer t

Re: Blocks, continuations and eval()

On Fri, Apr 08, 2005 at 12:18:45PM -0400, MrJoltCola wrote: > I cannot say how much Perl6 will expose to the high level language. That is what I'm wondering about. I'm sorry I was so unclear. > Can you tell me what your idea of a "scope" is? I'm thinking a > continuation, and if that is what you

Re: Blocks, continuations and eval()

wolverian <[EMAIL PROTECTED]> writes: > On Fri, Apr 08, 2005 at 12:18:45PM -0400, MrJoltCola wrote: >> I cannot say how much Perl6 will expose to the high level language. > > That is what I'm wondering about. I'm sorry I was so unclear. > >> Can you tell me what your idea of a "scope" is? I'm thin

Re: Blocks, continuations and eval()

On Tue, Apr 12, 2005 at 11:36:02AM +0100, Piers Cawley wrote: : wolverian <[EMAIL PROTECTED]> writes: : : > On Fri, Apr 08, 2005 at 12:18:45PM -0400, MrJoltCola wrote: : >> I cannot say how much Perl6 will expose to the high level language. : > : > That is what I'm wondering about. I'm sorry I was

Re: Blocks, continuations and eval()

Larry Wall <[EMAIL PROTECTED]> writes: > On Tue, Apr 12, 2005 at 11:36:02AM +0100, Piers Cawley wrote: > : wolverian <[EMAIL PROTECTED]> writes: > : > : > On Fri, Apr 08, 2005 at 12:18:45PM -0400, MrJoltCola wrote: > : >> I cannot say how much Perl6 will expose to the high level language. > : > >

Re: Blocks, continuations and eval()

On Tue, Apr 12, 2005 at 04:17:56AM -0700, Larry Wall wrote: > We'll make continuations available in Perl for people who ask for > them specially, but we're not going to leave them sitting out in the > open where some poor benighted pilgrim might trip over them unawares. Sorry for replying so late,

Re: Blocks, continuations and eval()

On Thu, Apr 21, 2005 at 04:30:07PM +0300, wolverian wrote: : On Tue, Apr 12, 2005 at 04:17:56AM -0700, Larry Wall wrote: : > We'll make continuations available in Perl for people who ask for : > them specially, but we're not going to leave them sitting out in the : > open where some poor benighted

Re: Blocks, continuations and eval()

On Thu, 21 Apr 2005 08:36:28 -0700, [EMAIL PROTECTED] (Larry Wall) wrote: > > Hmm, maybe that's not such a bad policy. I wonder what other "dangerous" > modules we might have. Ada had UNCHECKED_TYPE_CONVERSION, for instance. > How about use RE_EVAL; # or should that be REALLY_EVIL? >

Re: Blocks, continuations and eval()

have read-eval loop, a necessary condition for rapid learning and development. Functional languages like haskell or ocaml are very powerful but needs massive wetware reconfiguration to get used to the syntax and semantic. So I will make do a presentation of Perl6 and Parrot features to make my p

Re: Blocks, continuations and eval()

On Fri, Apr 22, 2005 at 08:13:58PM +0200, Stéphane Payrard wrote: > On Fri, Apr 22, 2005 at 09:32:55AM -0700, Larry Wall wrote: > > Thank you for your detailled answer. I still don't get what you mean > by "[] pattern matching arguments". > Do you mean smart pattern matching on composite value

Re: Blocks, continuations and eval()

ymore. Indeed C and C++ are memory : allocation nightmare; Java and C# don't have read-eval loop, a : necessary condition for rapid learning and development. Functional : languages like haskell or ocaml are very powerful but needs massive : wetware reconfiguration to get used to the syntax an

Re: Blocks, continuations and eval()

On Fri, Apr 22, 2005 at 09:32:55AM -0700, Larry Wall wrote: Thank you for your detailled answer. I still don't get what you mean by "[] pattern matching arguments". Do you mean smart pattern matching on composite values? > > A lot of features are making it into Perl 6 that have historically

Re: variables inside an eval

在 Oct 29, 2006 4:34 PM 時，Richard Hainsworth 寫到： If I have the following my $self = "some text"; my $nself = ~eval(q/"self is $self"/,:lang); then surely $nself should be "self is some text". But it is not. $self is not set inside the eval in pugs. The lexi

Re: variables inside an eval

在 Oct 29, 2006 4:34 PM 時，Richard Hainsworth 寫到： If I have the following my $self = "some text"; my $nself = ~eval(q/"self is $self"/,:lang); then surely $nself should be "self is some text". But it is not. $self is not set inside the eval in pugs. But say ~ev

test failure: t/pmc/eval

On win32, XP, I get the following test failure, with output: t/pmc/eval..ok 1/17 t/pmc/eval..NOK 10/17# Failed test 'eval.get_string - same file' # at t/pmc/eval.t line 319. # Exited with error code: 1 # Received: #

  1   2   3   >