Whichever VHLL does this will lack eval, which will make it distinctly less HL...
There are ways around this. First, some of the things
we currently do in Perl via eval can be done in other
ways. *Almost* anything you can do with the block
form of eval could be done another way; Perl6 is
adding some features in this regard. The string form
of eval of course can do some things that would break
this, so a solution is still needed for eval. There
are a couple of options, and a hybrid approach that
I would personally favour. The first approach is to
provide an optimizing compiler for a subset of the
language that does not provide the string form of
eval. Thus, any program that doesn't use that could
be compiled. The second approach is to compile all
the rest of the code in the usual way but *also*
then bundle an interpreter or JIT compiler, so that
string eval and things like it would be possible.
The hybrid approach is to only bundle the compiler
or interpreter if the code being compiled uses the
string eval.
I favor the hybrid approach, but really I don't think
this is a big deal. The real problem is convincing
anyone (well, anyone capable of doing anything about
it) that political reasons and the views of C/C++
programmers are good reasons to write _and maintain_
an optimizing compiler despite that for almost the
entire existing userbase the existing vm-based
solution is the way to go.
;$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$;[-1]->();print