FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

adding eval

 
Post new topic   Reply to topic     Forum Index -> The Language Machine
View previous topic :: View next topic  
Author Message
Nod



Joined: 21 Jul 2005
Posts: 5

PostPosted: Thu Aug 18, 2005 12:26 pm    Post subject: adding eval Reply with quote

Hi Peri, terribly sorry my absence, it was entirely not my choice, I assure you.

I may have some time to work on LM now, and would like to begin by adding an eval functionality. That is, making the following pseudocode work:

results = lm_eval(<grammarfile>, <inputfile>);

Where results is a class containing the main output, as well as any side-effect outputs and/or variables.

From the LM source I take that, in broad terms: I must instantiate an engine object, feed it LM rules and input, and somehow catch the output(s).

I'd really appreciate some pointers regarding the specifics. Yeah, I'm lazy :)

Later, -Nod-
Back to top
View user's profile Send private message Send e-mail
mpah



Joined: 18 Jul 2005
Posts: 29
Location: UK

PostPosted: Fri Aug 19, 2005 12:51 am    Post subject: Reply with quote

Nod - strange you should ask this, as I have been thinking about finding the most usable way to do this, so as to make it easy to provide LM services to scripting languages.

If you look at application.d you will see that it wraps command-line option and argument handling round an instance of the engine. If an embedded application is just a special kind of application object, we can go on using the args array as a way of specifying options.

Esssentially we need to create an application object that gives us control of its input-output streams. Then:

  • the engine should always take standard input from its input stream object
  • "out" should always send output to the engine's output stream object
  • "uri" should always send output to the engine's output stream object
  • "urd" should always send output to the engine's output stream object
  • "err" should always send output to the engine's error stream object

Output is generated for the builtin output symbols by their 'match' functions, which are called with the engine as argument. For the present I suggest we ignore diagnostic and trace output, and assume that that will continue to go direct to standard output and standard error.

For these purposes, and for scripting in general we can add options to:

  • treat the next string in the args array as a string to be processed as rules
  • treat the next string in the args array as a string to be processed as input

To get the resulting output you would just provide a buffer output stream as the output handler and then grab the contents of the buffer.

Essentially we need two additional application constructors:
Code:
this(char[][] args, <input>, <output>, <error>){ ... }
this(char[][] args, loadprocedure, <input>, <output>, <error>){ ... }

where the <input>, <output>, and <error> represent stream objects. We need to modify
  • engine.d to set up defaults that can be overridden by these stream objects
  • engine.d to get its standard input from the <input> object
  • the output element definitions in element.d to use the <output> and <error> objects

I would need to go and do some homework on the recent changes in the stream io handling - I think it should now be easier to use than it was when I first wrote the code.

At present we need these two different forms because there are different ways of initialising a ruleset - perhaps we need to mask these differences behind an object or interface.

In your pseudocode, if the return value is the engine object itself, that gives us access to the state of things at the end of the analysis. You could either fish the output and error buffers out of that, or just keep separate references to them.

I think we also need a way of defining, setting, and getting global variables in the engine - these are just LM variables that are created in the outermost context so that they are visible to all inner contexts. These can be used to hold

  • strings and arguments provided from the environment
  • output material collected by setting them up for use as output buffers
  • summary values, counts and what-have-you

We talked before about unifying the builtin output symbols with the system of buffer variables. But on balance I think it's best to retain the distinction - the builtin symbols provide a very direct patth to the output stream, with no variable search, so they will always provide the most efficient way of generating output from a ruleset.

Your comments and suggestions are very welcome, of course.
_________________
The Language Machine - a toolkit for language and grammar
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> The Language Machine All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group