Docstoc

Syntax-Semantics

Document Sample
Syntax-Semantics Powered By Docstoc
					                      Grammars
                                      Help to
                                         determine ??


Determine                                   Ambiguities


             Syntax    !=        Semantics


 9/25/2012                  ITK 327                     1
Ambiguity in English

        I saw an airplane with a telescope.

        I saw a girl with her boyfriend.

        I saw a boy scout with a telescope
        on the mountain top.

        I saw a pretty girl with a telescope
        on the mountain top.

9/25/2012                  ITK 327             2
            Ambiguity in Programming
                  Languages
            if (a > 2)
               if (b > 1)
                    b++;
               else
                    a++;
                                Dangling else

            if (a > 2)
               if (b > 1)
                   b++;
            else
               a++;



9/25/2012                   ITK 327             3
              Three “Equivalent” Grammars

G1:    <subexp> ::= <subexp> - <subexp> | a | b | c



G2:    <subexp>     ::= <var> - <subexp> | <var>
        <var>       ::= a | b | c


G3:    <subexp>     ::= <subexp> - <var> | <var>
       <var>        ::= a | b | c


      They are equivalent! (what does that mean?)

  9/25/2012                ITK 327                  4
         Parse a-b-c using G1
 G1:           <subexp> ::= <subexp> - <subexp> | a | b | c

         <subexp>                                    <subexp>

<subexp>        -    <subexp>                 <subexp>   -   <subexp>


  a            <subexp> - <subexp> <subexp> - <subexp>          c

                 b              c     a                  b


                      G1 is an ambiguous grammar


   9/25/2012                        ITK 327                             5
Left and Right Association rules


       Right associative rule:

       a-b-c-d = a – (b-(c-d))



      Left associative rule:

      a-b-c-d = ((a–b)-c)-d




9/25/2012                      ITK 327   6
         G2 and G3 Grammars
                                                          <subexp>
G2: <subexp> ::= <var> - <subexp> | <var>
    <var>    ::= a | b | c                        <var>     -        <subexp>
                                 G2 parse tree:    a       <var>        -       <subexp>
Right associative rule:
                                                             b                   <var>

                                                                                   c

G3: <subexp> ::= <subexp> - <var> | <var>                             <subexp>
    <var> ::= a | b | c

                                                           <subexp>         -     <var>

Left associative rule:           G3 parse tree: <subexp>         -     <var>        c

a-b-c-d = ((a–b)-c)-d                             <var>                     b

                                                    a

 9/25/2012                           ITK 327                                             7
    A grammar for Arithmetic Expressions

              <exp> ::= <exp> + <exp> |
                       <exp> * <exp> |
                       ( <exp> ) |
                       a | b | c




            Example: ((a+b)*c)



9/25/2012                      ITK 327     8
    What is the meaning of a+b*c
Using left--most               We prefer this
derivation

                   <exp>                            <exp>

            <exp> * <exp>                       <exp> + <exp>

                           c
     <exp> + <exp>                              a    <exp> * <exp>

        a           b                                 b         c


                           Using right-most derivation doesn’t help

     9/25/2012                        ITK 327                         9
   The problem is too much freedom
              <exp>           <exp>

      <exp> * <exp>                               Call this a term
                          <exp> + <exp>
                      c                         And term does not
<exp> + <exp>             a    <exp> * <exp>
                                                generate exp directly
  a            b                 b         c

   Solution: restricting <exp> from generating * directly.
      A term is an exp: a*b               <exp> ::= <term>
      An exp may not be a term: a+b
                                          <term> ::= <exp>

                                         <term> ::= (<exp> )
  9/25/2012                    ITK 327                         10
An unambiguous grammar for Arithmetic Expressions

<exp> ::= <term> + <exp> | <term>                <exp>
<term> ::= <fact> * <term> | <fact>
                                           <term> + <exp>
<fact> ::= ( <exp> ) |
               a | b | c                <fact>         <term>


 Example: a+b*c                           a      <fact> * <term>


                                                   b       <fact>


                                                                c
   9/25/2012                  ITK 327                      11
An unambiguous grammar for Arithmetic Expressions

<exp> ::= <term> + <exp> | <term>             <exp>
<term> ::= <fact> * <term> | <fact>
                                        <term> + <exp>
<fact> ::= ( <exp> ) |
               a | b | c
                                    <fact>   <term> + <exp>


                                        a             <term>
Example: a+b+c                               <fact>


Right association                              b      <fact>
      a+b+c = a+(b+c)
                                                         c
   9/25/2012                  ITK 327                    12
                Using ( and ) to alter the order
                                                          <exp>
<exp> ::= <term> + <exp> | <term>
                                                <term> + <exp>
<term> ::= <fact> * <term> | <fact>
<fact> ::= ( <exp> ) |                                        <term>
                                             <fact>
               a | b | c

                                                              <fact>
                                    (        <exp>    )
Example: (a+b)+c
                                  <term> + <exp>                  c



                                    a                 b
   9/25/2012                       ITK 327                             13
 An unambiguous left associative grammar (?) for Arithmetic Exp.

No such thing called left associative grammar
                                                      <exp>
 A better way to say this:
 A grammar for left associative arithmetic exp. <exp> +       <term>
<exp> ::= <exp> + <term> | <term>
<term> ::= <term> * <fact> | <fact>        <exp> +   <term>     <fact>
<fact> ::= ( <exp> ) |
            a | b | c                      <term>    <fact>        c

   Example: a+b+c                          <fact>      b

                                             a                     14
     9/25/2012                   ITK 327
                             Too much freedom to generate
Dangling else                if statements from stmt
<stmt> ::= <if-stmt> | s1 | s2

<if-stmt> ::= if <expr> then <stmt> else <stmt>
             | if <expr> then <stmt>

<expr> ::= e1 | e2

             if e1 then if e2 then s1 else s2

  if (a > 2)                         if (a > 2)
     if (b > 1)                         if (b > 1)
         b++;                                b++;
     else                            else
         a++;                           a++;


 9/25/2012                 ITK 327                   15
                         <if-stmt>                             if (a > 2)
                                                                  if (b > 1)
 if       <exp>       then     <stmt>     else      <stmt>
                                                                       b++;
                 e1      <if-stmt>                    s2       else
                                                                  a++;

if       <exp>        then      <stmt>

            e2                      s1


                                                if (a > 2)
                         <if-stmt>
                                                   if (b > 1)
 if         <exp>       then        <stmt>
                                                        b++;
                                                   else
                 e1      <if-stmt>                      a++;


if      <exp>     then       <stmt>      else    <stmt>
                                                             Most languages: else goes with
            e2                 s1                   s2       nearest then
     9/25/2012                                   ITK 327                            16
          Eliminating The Ambiguity
                                      Numbers of then and
                                      else are the same
<stmt> ::= <if-stmt> | s1 | s2

<if-stmt> ::= if <expr> then <full-stmt> else <stmt>
             | if <expr> then <stmt>

<expr> ::= e1 | e2

<full-stmt> ::= <full-if> | s1 | s2


<full-if> ::= if <expr> then <full-stmt> else <full-stmt>


  9/25/2012               ITK 327                     17
             A Parse Tree for if-stmt

                                <if-stmt>

            if      <exp>   then            <stmt>

                     e1         <if-stmt>



        if       <exp>   then   <full-stmt>          else   <stmt>

                   e2              s1                        s2



9/25/2012                         ITK 327                            18
     Languages That Don’t Dangle
Algol: then part can’t be another if (a block
 is allowed)

Ada: if statement must be terminated with an
 end if



9/25/2012           ITK 327                19
Options to deal with ambiguity

• Rewrite grammar to eliminate ambiguity
• Leave ambiguity but explain in
  accompanying text how things like
  associativity, precedence, and the dangling
  else should be parsed
• Do both in separate grammars


9/25/2012            ITK 327                    20
               Abstract Syntax Tree
• Abbreviated version of the parse tree
• Details are implementation-dependent
• Usually, there is a node for every operation,
  with a subtree for every operand

            Most systems construct an AST instead



9/25/2012                     ITK 327               21
    parse tree       <exp>

            <exp>       +        <mulexp>

 <exp>       +      <mulexp>    <rootexp>

<mulexp>            <rootexp>        c

<rootexp>              b                          +
    a
                                          +           c
             abstract syntax tree

                                    a         b

9/25/2012                       ITK 327                   22
        Operators
• Special symbols for frequently-used simple
  operations like addition, subtraction,
  multiplication and division
• Usually predefined, but not always
• Usually a single token, but not always




9/25/2012           ITK 327                23
            Operands
• Operands are the inputs to an operator, like
  1 and 2 in the expression 1+2
• Unary operators take one operand: -1
• Binary operators take two: 1+2
• Ternary operators take three: a?b:c




9/25/2012            ITK 327                 24
             Operator Position

            • infix: a + b
            • prefix: + a b
            • postfix: a b +




9/25/2012                ITK 327   25
Operator Precedence
     The priority in In the competition of getting operands.

Most languages put * at a higher precedence level than +.
  a+b*c = a+(b*c)

              +    -       (sign, as unary operators)

              ^
              *    /   %
              +    -

              :=
  9/25/2012                    ITK 327                  26
            Precedence Examples in C


     a + b * c

     a = b < c ? * p + b * c : 1 << d ()
   a <= 0 || 100 <= a




9/25/2012             ITK 327              27
  Some conclusions from the textbook
                                          with (my view)

 • Grammars define syntax, and more (more?)
 • They define not just a set of legal programs, but
   the (a) parse tree for each program
 • The structure of a parse tree corresponds to the
   order (entity) in which different parts of the
   program are to be executed (as an entity)
 • Thus, grammars contribute (a little) to the
   definition of semantics


9/25/2012               ITK 327                        28

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:13
posted:9/25/2012
language:Latin
pages:28