[View] [Edit] [Attachments] [History] [Home] [Changes] [Search] [Help]
Report 2003-01-16
Environment of development and execution
The LanguageGame is developed using Squeak environment on
Windows 2000. But by the multi-platform nature of the Squeak, it can
operate in other environments. And in the present version, the TGen
package is used as a table driven parser generation library.
The snapshot of LanguageGame is available here(But end of line is CRLF maybe you should translate CR). It need TGen
( http://minnow.cc.gatech.edu/squeak/1419 )
Development status
First, in order to clearfy character of a LanguageGame, I developed
the simple prototype (code name Higurashi) which it showed in September.
Although this prototype is a one with a very low function, but it showed
directly the directivity to which the LanguageGame progresses.
The function included in the prototype of the first version is as
follows.
- BNF notation support
- Simple shift-reduction parser engine
- The sentence after analysis can be desplayed in the tree form
- The block of Smalltalk can be embedded as an attribute grammar (action part)
- The reference to a morph is embedded to gramar and can be controlled
Next, I developed the following version (code name GGame) based on
the prototype. The development target in this new version is follows.
- As a table driven parser generator, using TGen engine.
For a practical parser generation, the table driven parser is
required. This time, using TGen took as an parser generation system
which can be used on Smalltalk. And many of parts which consititute
the new LanguageGame ware made as subclass of class in TGen.
- Cooperation with a tile scripting system in Squeak.
Squeak tile scripting system is a very fun and interesting feature.
By linkage of the system, the application range of the LanguageGame
will spread more. To realize this, I read the source of the tile
system and made it reference.
- Develop of simple delay execution engine
For make parser generation more interasting, A user plays happily
the grammar which he made. In order to realize calculation,
execution, and a repetition for a sentence by the simpleest way,
I decided to use not a naked BlockContext but a wrappar object of block.
Details of parse tree operation
Honest, although reveals first. Adoption of TGen was failure.
Since the function of TGen is too abundant, the structure of a new
LanguageGame has become complicated. However, to study operation
of a table driven parser, I thing it was useful.
At the beginning, I thought that I would use LR parser of TGen in
the system. But because top-down parsing is suitable to describe
BNF using tile scripter, I decided to use LL parser in the version.
In new LanguageGame, user can input BNF and user text using like
tile scripting system with mouse operation. There are some
advantages using tile scripting to input. First, Using mouse operation
is friendly for user, and it can reduce a possibility of mistaking
because it GUI operation can restrict a choice than keybord.
Additionaly, a tile operation and LL parser led interesting feature,
real-time tree building. Usually, when a parser interprets a input
sequence, it recognizes one word at a time from a head. But in
the LanguageGame, when user change a code, a parser can modify
a middle node of a point of modifying, not to read again
from the begining. In the LL parser, it is easy because a first symbol
in righthand determines a production rule, but in the LR parser,
there is a great deal of complexity.
For real time parsing, LangageGame uses a node object which has
a reference of its parser. A node (kindOf: GNode) knows how to parse
itself when another node want to join him. For example, when
user drop a tile to scripter to make a code. The original node
judges whether the tile is correct or wrong, and if correct, it
will join it to itself. the hierachy of GNode is shown below.
DerivationTreeNode #('symbol' 'children')
GNode #('parent' 'parser')
GEpsilon #()
GCRNode #()
GNonterminal #('production')
GTerminal #('value')
Details of a semantic analysis
In first version prototype, it used Smalltalk BlockContext for
implementation of attribute grammar like here.
E : E + E [:a :b :c | a + c]
E : number [:a | a]
It is a simple way but it is impossible to represent lazy evaluation
like loop or conditional because a node is evaluated immediately.
Then I make a simple wrapper of block named GMonad. It can behave
a string when you want a string or a number, or behave a block
when you want a loop or so like this.
exp : repeat exp [ :a :b | 1 to: 2 do: b ]
exp : croak [ self beep: 'croak' ]
Additionaly, I hava a plan to develop a debugger named 'mole'
for this system. Like a mole digging, it will explore a code
slowly using a morph stepping system. Now I am drowing mole icon.
Please wait for pleasure.
