Hugh,

the one thing I didn't see in your posting is a statement about the 
language.  What capabilities should it have?  If it's just assigning 
constants to vars (like often needed for configurations) then Regexp is 
probably fine.  From what you write I'm guessing that your envisioned 
language is more complex - but how complex?  Maybe it's a special case for 
which someone somewhere has a solution already.

Regards

    robert


"Hugh Sasse Staff Elec Eng" <hgs / dmu.ac.uk> schrieb im Newsbeitrag 
news:Pine.GSO.4.60.0501261622400.24999 / brains.eng.cse.dmu.ac.uk...
>I seem to have run into my parsing problem again.  Whatever I'm
> doing I usually end up having to parse non-simplistic input, and I'm
> still not happy about the apparently available solutions to this.
> So I'm wondering what other people do.
>
> The application is immaterial at the moment, but the problem is that
> I need to do more than can be done with a simple case statement, and
> if I were to use case statements managing the problem would get too
> big.
>
> The conventional wisdom is to use some form of parser
> generator (Yacc, Bison, Racc, Rockit,...) but I don't have
> confidence in my ability to get these working well.[1].
> I have had great difficulty in the past, certainly.
>
> Other possibilities I have considered and tried are to lash together
> some form of Lisp [cf Greenspun's 10th rule of programming] or Forth,
> but I don't consider myself fluent in either of those languages, and
> they are not as easy a user interface for other people as Ruby would
> be.  I can get something working, but find it hard to maintain or
> improve. [2]
>
> So the next possibility is to use something like
>
>         input = nil
>         File.open("input.txt"){|f|
>           input = f.read
>         }
>         Thread.new(input){|source|
>           $SAFE=5
>           instance_eval source
>         }.value
>
> or something, and actually make the commands in the language methods
> of some Ruby object.
>
> It is often observed that it is difficult to add security to a
> system, compared to building it in from the start.  Can I do this
> and still have a good level of security?  Should I make the parser
> object (whose method's I'm using) a subclass of Nil, to limit it as
> much as possible?  I need to give people enough rope to hold their
> input together, but not enough to hang themselves (or me). I don't
> want people to be able to execute arbitrary code, or fiddle with
> objects they should not need to touch.
>
> Is there another way to handle input flexibly that I have completely
> missed?  I've googled for things to do with little languages and parsing, 
> but have found nothing enlightening.
>
>         Thank you,
>         Hugh
>
> [1] I find that thinking in the manner of a shift/reduce parser is
> particularly unnatural to me.  This might just be a weakness on my
> part or may have something to do with people's difficulties in
> handling modal interfaces: it is hard to switch contexts rapidly.
> Maybe there is something I can read which will turn the problem
> around, so it becomes easy to handle?
>
> [2] Immensely powerful and fast systems have been written in Forth,
> and Lisp is very powerful in the right hands.  I just don't have the
> experience with these to be effective, yet.
>
>