in reply to Logical expressions

As well as writing a parser, you might be writing a language - and that can be hard and/or annoying.

Can I ask if you are also determining the format of the string, i.e. the logical language itself?

Also, may I ask how are you going to apply the hash you've built up?

It may be that there is an already existing sub-language which meets your needs.

Replies are listed 'Best First'.
Re^2: Logical expressions
by raptur (Acolyte) on Jun 06, 2007 at 02:27 UTC
    It may be that there is an already existing sub-language which meets your needs.

    sounds to me like there is an already existing full language which meets your needs: Prolog.

    yes it is a real language... we developed a fully general symbolic agenda-driven Earley parser in Prolog winter quarter :D

    Here is a perl-based interpreter (which I haven't used) and here is my favorite prolog interpreter.

Re^2: Logical expressions
by rsiedl (Friar) on Jun 06, 2007 at 02:27 UTC
    i am creating the string out of a set of terms which will not change. basically just adding them in with a bunch of AND|OR|NOT and parens.

    The idea is some articles contain a list of keywords and i'm trying to run the search string over them to find which ones match. it's not too hard until i got to recursive parens, which was where i decided to break it down to a hash of "rules" which are run individually (kinda from the inside out) making sure each one "passes" on the way.
      One problem you can find with 'little languages' on their own is that over time you get things like "it would be nice if you could use variables, or loops, or...".

      I've seen it a few times with web templating systems, test case specification languages, etc.

      If you can possibly make use of an existing 'full' language, then that may be better. One option is - perl (you have it to hand and know it well...)

      You can put together strings like "$foo and ($bar or $boo)". Instead of writing a language parser and evaluator, you write the code which sets up the $foo, $bar variables and then calls "eval $logical_expression".

      Such an approach would require less code (you'll have to set up the same foo/bar/boo whichever approach you take) and you also potentially have the full power of perl there if you ever need it. You're basically using 'eval' as your parser and evaluator.

      Some more of the rationale behind this approach is suggested in the documentation to Text::Template. You could even use that module as a way of helping set up your foo/bar/baz, since your logical expression could be seen simply as a text template evaluating to 1 or 0. :-)

      People sometimes talk about using Domain Specific Languages (DSLs) - and they *are* often a good idea. One point which sometimes gets missed is that DSLs are *embedded* in the full language they are created in, not just *implemented*. You can still escape to the full language and so don't have to re-invent precedence rules, loops, conditionals, variables and all that good stuff.