Re: Small examples of string eval

Teaching newbies to use eval? What a concept... (like playing with knives) -- well, it's sure to be valuable as a learning experience.

The one thing where eval is basically unavoidable is the use of a string variable within the "tr///" operator. It's simple, basic, and has a bunch of obvious uses in "real-life".

(update: forgot to include an example...)

my %charmap = ( a => 'B', c => 'D', ) # ... could come from a config f
+ile

my $old = join '', keys %charmap;
my $new = join '', values %charmap;

while (<>) {
    eval "tr{$old}{$new}";
    if ( $@ ) {
        die "tr{$old}{$new} failed at line $.: $_";
    }
    print;
}
[download]

Comment on Re: Small examples of string eval Download Code

Replies are listed 'Best First'.
Re^2: Small examples of string eval by ikegami (Patriarch) on May 13, 2006 at 07:29 UTC
In my opinion, `eval EXPR` (as opposed to `eval BLOCK`) should be used only as a last resort. Your code is a prime example. It breaks as soon as someone places `-`, `}` or `\` in `%charmap`. The following does not, and avoids `eval EXPR` entirely: `while (<>) { s/(.)/exists $charmap{$1} ? $charmap{$1} : $1/seg; print; }` [download] (No, the `/e` is not the same as `eval EXPR`. There's no dynamic code generation. `/ee`, on the other hand, would be the same as `eval EXPR`.)	[reply] [d/l] [select]
Re^2: Small examples of string eval by spurperl (Priest) on May 13, 2006 at 07:28 UTC
By newbies I don't mean people who've learned to program Pascal yesterday, but rather programmers from other languages who don't yet grok the concepts of runtime evaluation and code generation. Thanks for the example, but it's not what I'm looking for. Your example is very idiomatic to Perl, I'd say it's a patch on a deficiency, because I have no trouble imagining tr/// implemented in such a way that allows the trick without eval. What I'm looking for is more in the code-generation league. Generate some code with eval, on the fly, and call it when necessary.	[reply]
Re^3: Small examples of string eval by ikegami (Patriarch) on May 13, 2006 at 07:44 UTC
Major code generation is usually used when a language is inept (or not particularly adept) at doing something. Off the top of my head, I can think of three reasons why a language would be inept at doing something 1) A language could be inept at doing something because it lacks the specialization that would make it adept. Querying databases (facilatitated by SQL), generating parsers (facilitated by BNF or similar) and generating object accessors would fall in this category. 2) A language could be inept at doing something because it lacks the generalization that would make it adept. For example, working with Java Bytecode is more tedious than working in Java, so we do the work in Java and generate the Java Bytecode. 3) A language could be inept at doing something because it is primarily text based and/or non-interactive, and a GUI and/or interactive solution would be more adept. For example, GUI builders are often used to build GUI code.	[reply]