20 posts from February 2008

Read instruction: CALL p (1 arg/s)
argument: STACK: pop() -- new stack size: 2
type=3
Read instruction: END
Read instruction: PUSH INTEGER_LITERALSTACK: push() -- new stack size: 3

Read instruction: TARGET_CALL_BLOCK upto (1 arg/s)
STACK: pop() -- new stack size: 2
STACK: pop() -- new stack size: 1
argument: STACK: pop() -- new stack size: 0
type=3
Read instruction: END
Read instruction: PUSH INTEGER_LITERALSTACK: push() -- new stack size: 1

Read instruction: TARGET_CALL_BLOCK upto (1 arg/s)
STACK: pop() -- new stack size: 0
STACK: pop() -- new stack size: ffffffff
argument: STACK: pop() -- new stack size: fffffffe
type=3

This is what happens when you write a VM. You get a stack with length 0xfffffffe.

RubyExは今バイトコードをアウトプットします！
Now RubyEx outputs byte-code!

celtic@sohma:~/code/linux/rubyex/translator$ cat test.rb
puts "Hi there."
a = who_knows("Joe", 42 - (9 * sin(12)))
a.each do
  el { joe {}; q {} }
end

celtic@sohma:~/code/linux/rubyex/translator$ ./parser -b < test.rb
       puts
  Hi there.
a       who_knowsJoe
*-
   
       *
      sin

                                                       
aeach

        el
    joe
    q

簡単にデバッグのために、今サンプルパーサのアウトプットはコードです！たとえば：
For easier debugging, the sample parser's output is now code! For example:

a(b(c{t}){d}).q{e{h{|a|b}}}
Program: 1 expression(s).
a(b(c {t}) {d}).q {e {h {|a| b}}}

a(b).c
Program: 1 expression(s).
  FuncCallExpr: Expr.c
    FuncCallExpr: a(arguments)
      IdentifierExpr: b

簡単！
Simple!

a(b, c).d
a(b).c
Program: 2 expression(s).
  FuncCallExpr: Expr.d
    FuncCallExpr: a(arguments)
      IdentifierExpr: b
      IdentifierExpr: c
  FuncCallExpr: a(arguments)
    FuncCallExpr: Expr.c
      IdentifierExpr: b

"a(b, c).d"は正しくパースして、"a(b).c"が間違えるの！？パーサトレースするときだ！！
"a(b, c).d" is correctly parsed, and "a(b).c" is not?! Parser trace time!!

"a(b)"でもパースのは：
Even when parsing "a(b)", we get:

Shifting token ')' ()
Entering state 53
Reducing stack by rule 9 (line 60):
   $1 = token '(' ()
   $2 = nterm expr ()
   $3 = token ')' ()
-> $$ = nterm expr ()

直すときだ。。。。
Time to fix...

Here's the problem I'm having right now:

• "a b.c" correctly parses as "a(b.c)"
• "a(b).c" also - incorrectly - parses as "a(b.c)"

Since I'm relatively a novice at building parsers (this is my first), I'll try to step through my muddled fixing of the situation. I'm looking at the output of the various parser states that bison's given me, and here, I think, is the s/r conflict that needs to be fixed: (correct me if I'm wrong)

s/r conflict

We're starting to become more useful, with the addition of block arguments. Here's a sample bit of code that parses nicely:

fictional do |exp, evaller|
  exp.split(" ").map {|p| evaller.call(p)}
end
Program: 1 expression(s).
  FuncCallExpr: fictional(arguments) { BlockExpr }
    BlockExpr: |DefListExpr| 1 expression(s).
      DefListExpr: 2 identifier(s).
        IdentifierExpr: exp
        IdentifierExpr: evaller
      FuncCallExpr: Expr.split(arguments)
        IdentifierExpr: exp
        FuncCallExpr: Expr.map(arguments) { BlockExpr }
          LiteralTypedExpr<Ss>: 
          BlockExpr: |DefListExpr| 1 expression(s).
            DefListExpr: 1 identifier(s).
              IdentifierExpr: p
            FuncCallExpr: Expr.call(arguments)
              IdentifierExpr: evaller
              IdentifierExpr: p

• We have one FuncCallExpr, calling "fictional" (no arguments are specified in the tree, if you look carefully) with a block. I should probably make it not show '(arguments)' if there are none. :)
• Follows the BlockExpr, with a DefListExpr of block arguments, and an expression.
• The DefListExpr has two identifiers: exp, evaller. These are the block arguments, hello!
• Following the DefListExpr in the output of the BlockExpr is that 1 expression(s), a FuncCallExpr.
• This FuncCallExpr is a call to the `split' method of some Expr.
• That Expr is an identifier, exp.
• Under construction.
  

celtic@sohma:~/code/linux/rubyex/translator$ ./parser
puts -3
puts - 3
Program: 2 expression(s).
  FuncCallExpr: puts(arguments)
    LiteralTypedExpr<i>: -3
  FuncCallExpr: Expr.-(arguments)
    IdentifierExpr: puts
    LiteralTypedExpr<i>: 3
celtic@sohma:~/code/linux/rubyex/translator$

正しい結果です。もっと一つの問題な場合だけあります：
It's the correct result. We've just got one more problem case remaining:

puts-3
Program: 1 expression(s).
  FuncCallExpr: puts(arguments)
    LiteralTypedExpr<i>: -3

RubyExのlexerは今"-3"が読んだらLiteralTypedExpr<int>(-3)をemitします。以前は"3.-@"、でもこうはもっと柔軟だと思う。
RubyEx's lexer is now reading "-3" and emitting LiteralTypedExpr<int>(-3). Earlier it was emitting "3.-@", but this way is probably more flexible.

celtic@sohma:~/code/linux/rubyex/translator$ make
g++ -enable-rtti -I. -c -o out/tests.o tests.cpp
g++  -o ruby out/ruby.tab.o out/lex.yy.o out/expr.o out/global.o out/main.o out/pretty.o out/tests.o
8 test(s) run, 8 test(s) succeeded.
234 assertion(s), 234 assertion(s) succeeded.
celtic@sohma:~/code/linux/rubyex/translator$

There's almost full test coverage for what's parseable so far. Blocks are also included.

celtic@sohma:~/code/linux/rubyex/translator$ ./test
test: "identifier": failure: Assertion failed on line 53: p.expressions.size() == 0
1 test(s) run, 0 test(s) succeeded.
celtic@sohma:~/code/linux/rubyex/translator$

これでテストコードがある：
And here we have the test code:

void _identifier()
{
  Program p = parse_code("abc");
  ASSERT(p.expressions.size() == 0);
}