[FWP] syntax barriers?

[Marc Lehmann <pcg@goof.com> (by way of owner-fwp@technofile.org)]

>From fwp-l Fri May 11 20:58:50 2001

I'm not quite sure wether the subject makes sense, but here is a problem
that might be interesting: I do a lot of dynamical compilation of user
code, i.e. I create strings like these and evaluate them:

   #line 40 "hulla"
   {
    ## user code inserted here, which will be mostly
    ## package declarations, subroutine declarations but could
    ## be any perl code
   }

   #line 33 "otherfile"
   ...

now, when the "user code" is not correctly nested (a common error), the
actual error message by perl will mention the file "otherfile" instead
of "hulla" since that's where the nesting error has been detected. To
work around this, one could use more complicated ways of "bracketing",
therefore creating a kind of "required error sequence" that the user code
has to follow in order to generate the wrong error message ;) Example:

   [do{
     ## user code inserted here
   }];

The above will catch most unnested-"{"-errors, but of course not all. The
idea is that the nesting error will be detected by the parser much
earlier (i.e. still in the right file). It, however, might even add more
confusion. And the worst thing is, it alters the program, which is a
problem when the whole string gets wrapped into a "sub { xxx }" and the
"user code" is just subroutine declarations as well.

Can you improve the "[]" solution or even find the perfect "syntax/error
barrier"?


-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

==== Want to unsubscribe from Fun With Perl?  Well, if you insist...
==== Send email to <fwp-request@technofile.org> with message _body_
====   unsubscribe