[DGD] Parsing grammar problem

[Jason Cone]

Greetings.

I've put together a seemingly correct grammar to parse mud-mode packets into
their respective values.  When testing, the grammar worked for all the test
strings I gave it.  However, upon trying to parse an actual mud-mode packet
(much longer than the ones I manually constructed), it would either run out
of ticks or, when given unlimited resources, occupy the entire CPU until I
manually killed the process.

As sure as I am that the grammar's more or less correct, it's entirely
possible that something's not quite right with it.  That's why I'd like
feedback on it.


The Grammar
===========

  whitespace = / /
  INT_CONST = /[0-9]+/
  INT_CONST = /[\-][0-9]+/
  FLOAT_CONST = /[0-9]+\\.[0-9]*/
  FLOAT_CONST = /[0-9]*\\.[0-9]+/
  FLOAT_CONST = /[\-][0-9]+\\.[0-9]*/
  FLOAT_CONST = /[\-][0-9]*\\.[0-9]+/
  STRING_CONST = /\"([^\\\"]*(\\.)*)*\"/

  grammar_sentence: variable_type

  variable_type: INT_CONST ? compose_int
  variable_type: FLOAT_CONST ? compose_float
  variable_type: STRING_CONST
  variable_type: array_value
  variable_type: mapping_value

  array_value: '({' element_list '})' ? compose_array
  mapping_value: '([' assoc_element_list '])' ? compose_mapping

  element_list:
  element_list: variable_type
  element_list: element_list ',' element_list

  assoc_element_list:
  assoc_element_list: variable_type ':' variable_type ? compose_association
  assoc_element_list: assoc_element_list ',' assoc_element_list


Callback Functions
==================

  static mixed *compose_int(mixed *mpTree)
  {
    return ({ (int) mpTree[0] });
  }


  static mixed *compose_float(mixed *mpTree)
  {
    return ({ (float) mpTree[0] });
  }


  static mixed *compose_array(mixed *mpTree)
  {
    int nIndex, nSize;
    mixed mReturnArray;

    if(!mpTree || sizeof(mpTree) == 2)
    {
      return ({ ({ }) });
    }
    else
    {
      mpTree -= ({ "({" });
      mpTree -= ({ "})" });

      mReturnArray = ({ });

      for(nIndex = 0, nSize = sizeof(mpTree); nIndex < nSize; nIndex += 2)
      {
        mReturnArray += ({ mpTree[nIndex] });
      }

      return ({ mReturnArray });
    }
  }


  static mixed *compose_mapping(mixed *mpTree)
  {
    int nIndex, nSize;
    mapping aReturnMap;

    if(!mpTree || sizeof(mpTree) == 2)
    {
      return ({ ([ ]) });
    }
    else
    {
      mpTree -= ({ "([" });
      mpTree -= ({ "])" });

      aReturnMap = ([]);

      for(nIndex = 0, nSize = sizeof(mpTree); nIndex < nSize; nIndex+=2)
      {
        aReturnMap += mpTree[nIndex];
      }

      return ({ aReturnMap });
    }
  }


  static mixed *compose_association(mixed *mpTree)
  {
    if(!mpTree || sizeof(mpTree) < 3)
    {
      return ({ "" });
    }
    else
    {
      return ({ ([ mpTree[0] : mpTree[2] ]) });
    }
  }



How would the above cause parse_string() to act the way it does?  I wouldn't
be totally surprised if parse_string() wasn't capable of parsing the driver
object's C file in the 1/4 second or so that it takes (driver ~= 10K,
mud-mode packet < 4K).

As a follow-up to our original dilemma regarding the string size, it was the
way in which we were parsing and storing the incoming mud-mode packets that
was causing the "String too long." errors.  We've since changed it, but it
would still be nice to have a larger string. ;)  Anyway, that's not the
concern - the above grammar is.  Thoughts, suggestions, guidance?


--
  Jason H. Cone
  Dept. Computer Science
  Texas A&M University
  jcone at cs.tamu.edu

  "Even in the gigantic and the ideal, the dream, which is
   completely spontaneous, takes and keeps the form of our
   mind."
                                             - Victor Hugo





List config page:  http://list.imaginary.com/mailman/listinfo/dgd