Apr 24, 2012 at 9:37 AM
Edited Apr 24, 2012 at 4:43 PM
Keep in mind that supporting console mode (REPL) is optional, even if evaluation is supported. Like SearchGrammar - you can evaluate input query (and produce converted SQL) but it does not make much sense to start REPL session.
I'm not currently speaking about REPL, it's another thing. Consider the following grammar sample:
WriteLine("Type in yor name: ");
Name = ReadLine();
WriteLine("Hello, ", Name, "!");
Think of it as a console application that uses IConsoleAdaptor (ScriptApp.Console property) for I/O.
When executed by the GrammarExplorer, these operations are performed by ConsoleTextBox.
In the CommandLine app, they are directed to a native system console.
I propose to extend ICanRunSample in a way that it supports both I/O directions,
so the GrammarExplorer can run samples like the above.
Supporting REPL would be another task.
So grammar must somehow indicate that it supports REPL/console, and secondly, create and return the ComandLine instance.
I think that the console should be provided by the application, not by the grammar.
When we run console application, the window is created for us by the operating system —
we use STDIN/STDOUT and don't care whether it's a real console window or a file.
One option is to extend (and rename) ICanRunSample interface, to allow it to a) create full-blown interactive console, and/or b) provide one-time evaluation of the script in the editor panel.
Looks like it should be two different interfaces :)
ICanRunSample supports one-time evaluation, and, say ICanRunREPL supports interactive console.