Embedded perl or mini-language translator to perl

mp has asked for the wisdom of the Perl Monks concerning the following question:

In working on a web application, I am reaching the point at which I need to provide administrators with some limited scripting capability through a password protected web interface. Capabilities would initially need to include if...elsif...else, return, boolean logic, numeric expressions, retrieving and storing of data from/to a SQL database, and set operations (union, intersection, etc).

I have been exploring several alternatives:

represent structure in XML
- Disadvantage: ugly to edit, verbose
- Advantage: introspection is easy
build an API and allow full use of perl as the scripting language
- Disadvantage: few limits to power and flexibility; more training required.
- Advantage: few limits to power and flexibility
define a mini-language and write a translator to convert it to perl for execution
- Disadvantage: additional work over option 2 and less power and flexibility
- Advantage: introspection easier than option 2, power and flexibility can be limited appropriately; less training required than option 2.

I am leaning toward the third option -- minilanguage with translator to perl. Are there any major pitfalls with such an approach?

I have not found much written about writing a minilanguage translator in perl, though Template Toolkit does serve as an example. Can anyone point me to some good resources as to how to get started down this path?

I envision bulding the parser/translator in something like Parse::RecDescent or Parse::Yapp. Parsing speed is not very critical in this application because code would be parsed once and converted to perl, then used many times.

Comment on Embedded perl or mini-language translator to perl

Replies are listed 'Best First'.
Re: Embedded perl or mini-language translator to perl by eric256 (Parson) on Sep 01, 2004 at 16:35 UTC
You could look into use Safe to limit their abilities in perl. Then you provide them with just the basics, and you build an API and give them access to it. That should provide you with the power of perl and lower concerns about bad code some. If you build a broad enough API then you would be more teaching them the API than perl. The benefit is that there is already plenty of resources for people learning perl so you don't have to bear the full training load. ___________ Eric Hodges	[reply]
Re: Embedded perl or mini-language translator to perl by kvale (Monsignor) on Sep 01, 2004 at 16:59 UTC
I presume that your web application is in perl; if so, then using perl for scripting needs no additional resources. Personally, I do not understand the disadvantages of option 2. What is wrong with having the power of perl at your disposal? Training will be needed in any case, whether it is perl or your custom language, and I suspect that admins would be more willing to learn a language that is useful for other things than a single use custom language. But suppose you don't buy this argument. I would look first to Template Toolkit and/or Mason for ideas on how to implement your little language and integrate it with HTML. If those are not extendable to your needs, then a full parser is in your future. First, you will have to create a language and forge a grammar that has no pathologies and is unambiguous. P::RD is a good choice for the parser, as there are many example grammars out there to learn from. Another choice is to create your own top-down parser. Nonterninals are mapped to subs, terminals to regexes, and translation can either be done as you parse, or later walking the parse tree. Whether you use P::RD or roll your own, you will want to learn how to create good grammars, handle variables and symbol tables and detect all manner of syntax errors. The best book I know of for these tasks is Compilers: Principles, Techniques and Tools, by Aho, Sethi and Ullman. -Mark	[reply]
Re: Embedded perl or mini-language translator to perl by gmpassos (Priest) on Sep 01, 2004 at 19:36 UTC
I think that you should use the 2nd option, a Perl syntax with some limitations using a Safe compartment. I have worked a lot with Safe, and created the module Safe::World, where all the resources needed to create a internal representation of a Perl interpreter is implemented over Safe. Here's a simple example of how to create a compartment that only enables the use of variables, branch (if, elsif, else), loops (while, for), and IO (print, warn, die): Read more... (2 kB) One good thing of Safe::World is that if the user uses exit(), die(), any IO output or load a module, this will exists only inside the Safe::World compartment, making your outside safer. But you will need to play with the operators that you want to just enable what is really needed. Take a look in the module Opcode for the list. Graciliano M. P. "Creativity is the expression of the liberty". 20040907 Edit by ysth: readmore tags	[reply] [d/l]
Re: Embedded perl or mini-language translator to perl by ikegami (Patriarch) on Sep 01, 2004 at 16:44 UTC
Am I correct to assume the goal is to allow the users to do DB maniplations from a scripting language? Another alternative would be to have them DBD::Proxy (in DBI) and a SSH tunnel to give them access to the database from their own machine. In this case, the perl scripts would be running on their machine, and all you have to provide is the tunnel and documentation.	[reply]
Re^2: Embedded perl or mini-language translator to perl by mp (Deacon) on Sep 01, 2004 at 17:05 UTC
Manipulation of the DB is not really the end goal. What is more needed is the ability of the administrators (primarily non-programmers) to define blocks of code that fit into an existing framework and that will control the way in which the system interprets data from the DB, so that the system can controls the sequencing (and later, the appearance) of web pages based on data submitted by form POSTs (both current and previous POSTs) by a particular user. The current system has some capability to do this, but it is limited to parameterized subroutine calls, in which the administrators can specify the name and execution order of perl subroutines to call and can provide static parameters to those subroutines. The subroutines then have full access to the database. This, however, is very limiting because administrators have no way to stitch these together to do more complex operations, so new subroutines must continually be written by the programmer. By adding scripting support through a web interface, I am trying to move some of the coding from the programmer domain into the administrator domain, in a controlled manner.	[reply]