Hmm. Wild guessing here, so don't sue me if it goes horribly wrong.
You'd need one large text field to display text and one text imput field. Store the text somewhere as lines (whole paragraphs, which would wrap automatically, anyway), then make a text scrolling engine that just adds and removes lines as requested, while keeping everything 'logged'. For that purpose, list object would be immensely useful (not the windows list thingy), but I guess you'll have to make an use of array or something else (hashtable), which means a lot of extra work.
For input, basically another text field. It would catch keys typed and type letters out - you'd have to do that manually with events, which is quite a bit of work again, but worth the experience - then submit the text to parser at a press of Enter key.
The parser would then use the text manipulator to search for strings, find key words, spit 'em out. Then you'd just compare them to the context, execute whichever actions are appropriate etc.; if it is not clear enough, spit an error message out or something along lines of "That is a silly thing to do!" or "Huh?".
So, yeah, you'd have to reinvent the wheel a few times. Such is Construct in its infancy - not many generic plugins that would simplify the work flow. For example, in this case you'd need a list object (to log text) and text input field for DX runtime (not app). That would save you hours of messing with events just to work a couple basic features out!
Oh, there is Timeline object, maybe you can make an use of it.