Re^4: Can someone please write a *working* JSON module

I agree, your 1st snippet is bad form. And also the 3rd snippet looks better than the 2nd but the handle_overall_error() must include (for me) the logic of 2nd snippet in order to deduce what really happened, in which step the error really is. In theory it looks nice and compact. In practice, grouping step_1, 2 3 and 4 like this just happens in toy-cases and if they are grouped naturally like this then why not grouping them in a sub. Anyway. I get the point and thanks for the demonstration.

By the way, why do you dislike eval? I mean, I don't like eval EXPR either, but what's wrong with eval BLOCK?

yes I was talking about eval BLOCK as well. Micro-optimisation mostly (mea culpa), I think it spawns a new interpreter right? I am this kind of person that I hate taking the car to the corner shop because I visualise horror: the engine metals screaching, burning, rubbing together, aching and suffering just because I am in need of a cigarette. So I invariably walked until I gave it up altogether.

Comment on Re^4: Can someone please write a working JSON module Select or Download Code

Replies are listed 'Best First'.
Re^5: Can someone please write a working JSON module by dave_the_m (Monsignor) on Oct 27, 2021 at 10:47 UTC
I think it spawns a new interpreter right It definitely doesn't. eval BLOCK just pushes a 'EVAL' context onto the context stack, in a similar way that a sub call pushes a 'SUB' context, and a bare block pushes a 'LOOP_PLAIN' context. A context is just a type flag and a bit of saved state. On normal scope exit, the context is popped and the saved state restored (e.g. @_ restored on return from a sub). On an exception (die, croak etc), the perl interpreter keeps popping contexts (and restoring the saved state in each) until it hits an EVAL context or empties the context stack. The context stack is what caller() examines (in part). eval $string has a slow preceding step where it has to call the parser and compile the string into something resembling a sub, then it calls that 'sub' by pushing an EVAL context as with the block case. Benchmarks show that eval BLOCK has roughly the same overhead as calling a sub with no arguments. Dave.	[reply]
Re^6: Can someone please write a working JSON module by bliako (Monsignor) on Oct 27, 2021 at 16:17 UTC
thanks that clarifies it.	[reply]
Re^5: Can someone please write a working JSON module by Anonymous Monk on Oct 27, 2021 at 06:17 UTC
I think it spawns a new interpreter right? Well, `eval_sv` and `eval_pv` are related to `eval EXPR`, not `eval BLOCK`. There's obviously some performance lost, but not as much as `PerlInterpreter * my_perl = perl_alloc(); perl_construct(my_perl); perl_parse(my_perl, NULL, argc, argv, (char **)NULL); perl_run(my_perl); perl_destruct(my_perl); perl_free(my_perl);`. New interpreters are constructed for every thread, with tied variables handling access to shared variables, but I don't think a separate interpreter is needed for every eval. `eval EXPR` additionally spends time in the parser, but `eval BLOCK` uses the already-parsed data structures. I've spent a few minutes skimming the source. Perhaps the die() destination and the use feature 'try' entry point could be a good place to start, but I'm not enough of an expert to judge what's really happening here. Though I'm sure it's the same interpreter.	[reply] [d/l] [select]
Re^6: Can someone please write a working JSON module by bliako (Monsignor) on Oct 27, 2021 at 07:58 UTC
thank you for this answer.	[reply]


go ahead... be a heretic
	PerlMonks