Loading ...
Sorry, an error occurred while loading the content.

Re: [rng-users] Generating _1 = element * { notAllowed } any ideas why?

Expand Messages
  • Alex Muir
    Yeah so what s involved to code this. Has anyone spent some time looking into it? ... -- Alex Muir Program Organizer - University Technology Student Work
    Message 1 of 13 , Feb 16, 2012
    View Source
    • 0 Attachment
      Yeah so what's involved to code this. Has anyone spent some time looking into it?

      On Thu, Feb 16, 2012 at 6:33 PM, Tara Athan <taraathan@...> wrote:
      Unfortunately there has not yet been a developer to step up to this task.



      --
      Alex Muir
      Program Organizer - University Technology Student Work Experience Building
      University of the Gambia

      http://sites.utg.edu.gm/alex/

      Come visit Gambia enjoy the sun and culture and help out! Software Engineering Lecturers needed!
      Join UTSWEB do local contract work or give a student a contract remotely for slow, cheap and good work http://sites.utg.edu.gm/utsweb/

      Some fantastic African/Canadian Fusion  http://bafila.bandcamp.com/

    • Alex Muir
      Something I still don t understand is whether this is a solution that I should use and what is it doing. thanks ... Is this the final recommended fix for the
      Message 2 of 13 , Feb 17, 2012
      View Source
      • 0 Attachment
        Something I still don't understand is whether this is a solution that I should use and what is it doing.

        thanks

        On Thu, Feb 16, 2012 at 2:24 PM, Alex Muir <alex.g.muir@...> wrote:
        _1 = element conflict { notAllowed }

        Is this the final recommended fix for the problem?

        Regards
        --
        Alex Muir
        Program Organizer - University Technology Student Work Experience Building
        University of the Gambia

        http://sites.utg.edu.gm/alex/

        Come visit Gambia enjoy the sun and culture and help out! Software Engineering Lecturers needed!
        Join UTSWEB do local contract work or give a student a contract remotely for slow, cheap and good work http://sites.utg.edu.gm/utsweb/

        Some fantastic African/Canadian Fusion  http://bafila.bandcamp.com/

      • Tara Athan
        Regarding the replacement of _1 = element * {notAllowed} with _1 = element conflict { notAllowed } to avoid certain error message that arise when _1 is used in
        Message 3 of 13 , Feb 17, 2012
        View Source
        • 0 Attachment
          Regarding the replacement of
          _1 = element * {notAllowed}
          with
          _1 = element conflict { notAllowed }
          to avoid certain error message that arise when _1 is used in interleave, such as
          A = element A { B* & _1? }
          B = element B { ...}
          


          If the entire content of an element is notAllowed, then the corresponding pattern is equivalent to notAllowed.
          For this effect, it is irrelevant what the name of the element is.
          Therefore the name of the element can be changed to anything that avoids the syntactic conflict caused by the *. hence the recommendation to use
          _1= element conflict {notAllowed}
          That the name is "conflict" is not significant - it could be any name that is not used elsewhere in the grammar.

          This is the preferred solution, instead of
          _1 = notAllowed
          because applying jing -s to the resulting grammar would produce further simplications, with potentially other occurrences of this problem.

          So using
          _1 = element conflict { notAllowed }
          produces a grammar that will not be further modified if jing -s is applied, a property called "idempotency", which is considered a desirable thing.

          Tara


          Alex Muir wrote:
           

          Something I still don't understand is whether this is a solution that I should use and what is it doing.

          thanks

          On Thu, Feb 16, 2012 at 2:24 PM, Alex Muir <alex.g.muir@...> wrote:
          _1 = element conflict { notAllowed }

          Is this the final recommended fix for the problem?

          Regards
          --
          Alex Muir
          Program Organizer - University Technology Student Work Experience Building
          University of the Gambia

          http://sites.utg.edu.gm/alex/

          Come visit Gambia enjoy the sun and culture and help out! Software Engineering Lecturers needed!
          Join UTSWEB do local contract work or give a student a contract remotely for slow, cheap and good work http://sites.utg.edu.gm/utsweb/

          Some fantastic African/Canadian Fusion  http://bafila.bandcamp.com/


        • Alex Muir
          Okay thanks very much,, created a little script to adjust that at the end of the process. Regards ... -- Alex Muir Program Organizer - University Technology
          Message 4 of 13 , Feb 17, 2012
          View Source
          • 0 Attachment
            Okay thanks very much,, created a little script to adjust that at the end of the process.

            Regards

            On Fri, Feb 17, 2012 at 5:32 PM, Tara Athan <taraathan@...> wrote:
             

            Regarding the replacement of

            _1 = element * {notAllowed}
            with
            _1 = element conflict { notAllowed }
            to avoid certain error message that arise when _1 is used in interleave, such as
            A = element A { B* & _1? }
            B = element B { ...}
            


            If the entire content of an element is notAllowed, then the corresponding pattern is equivalent to notAllowed.
            For this effect, it is irrelevant what the name of the element is.
            Therefore the name of the element can be changed to anything that avoids the syntactic conflict caused by the *. hence the recommendation to use
            _1= element conflict {notAllowed}
            That the name is "conflict" is not significant - it could be any name that is not used elsewhere in the grammar.

            This is the preferred solution, instead of
            _1 = notAllowed
            because applying jing -s to the resulting grammar would produce further simplications, with potentially other occurrences of this problem.

            So using
            _1 = element conflict { notAllowed }
            produces a grammar that will not be further modified if jing -s is applied, a property called "idempotency", which is considered a desirable thing.

            Tara


            Alex Muir wrote:
             

            Something I still don't understand is whether this is a solution that I should use and what is it doing.

            thanks

            On Thu, Feb 16, 2012 at 2:24 PM, Alex Muir <alex.g.muir@...> wrote:
            _1 = element conflict { notAllowed }

            Is this the final recommended fix for the problem?

            Regards
            --
            Alex Muir
            Program Organizer - University Technology Student Work Experience Building
            University of the Gambia

            http://sites.utg.edu.gm/alex/

            Come visit Gambia enjoy the sun and culture and help out! Software Engineering Lecturers needed!
            Join UTSWEB do local contract work or give a student a contract remotely for slow, cheap and good work http://sites.utg.edu.gm/utsweb/

            Some fantastic African/Canadian Fusion  http://bafila.bandcamp.com/





            --
            Alex Muir
            Program Organizer - University Technology Student Work Experience Building
            University of the Gambia

            http://sites.utg.edu.gm/alex/

            Come visit Gambia enjoy the sun and culture and help out! Software Engineering Lecturers needed!
            Join UTSWEB do local contract work or give a student a contract remotely for slow, cheap and good work http://sites.utg.edu.gm/utsweb/

            Some fantastic African/Canadian Fusion  http://bafila.bandcamp.com/

          Your message has been successfully submitted and would be delivered to recipients shortly.