Re: [patch #5603] Separate command's parsing from their execution

[Ben Pfaff]

John Darrington <address@hidden> writes:

> But I'm not happy with the idea, of the GUI producing code, and the
> code then being submitted to the lexer before it can be executed.  I
> guess my objection comes from :
>
> 1.  I consider syntax and gui both to be front-ends to the process of
>     getting PSPP to do things.   That is, they operate at the same
>     level, and are mutual alternatives.  Having one front-end call
>     another front-end seems to break this model.
>
> 2.  If and when we implement a client-server model like the Chicago
>     Company does,  we'll (like you indicated) need to
>     serialize/deserialize commands and send them across a TCP/IP
>     connection.  It would not make sense for the server to need a
>     lexer. 
>
> Your objections about casts, and memory allocation are valid,
> but this of course can be alleviated by making an interface
> which takes care of the casting, and the use of a memory pool
> can help to mitigate the run time cost of heap allocation.  It
> would also then become easy(er) to add serialise/deserialise
> methods to this interface if/when we need them.

For the record, I don't care about time or memory cost.  It's not
in an inner loop.  The casts are a worse problem, in my opinion.
I'd be happier with a void * pointer in the command struct.

As for the rest: I'm concerned about the number of conversions
that we'll need to write for each command.  If syntax is the
primary interface, we need the following chunks of code:

        * GUI needs to generate syntax.

        * Parser needs to accept syntax and execute it.

The server, if and when we build such a thing, can then accept
syntax as well.

If we add a separate specification object, then we need a lot
more:

        1. GUI needs to generate specifications.

        2. Parser converts syntax to specifications.

        3. Specifications need code to convert themselves to
           syntax.

        4. Specifications need code to convert themselves to a
           serialized form for the server (in the future).

        5. Specifications need code to convert themselves back
           from a serialized form for the server (in the future).

I mean, the latter is clearly the "clean" approach, but it's also
clearly a huge amount of work in comparison.  Will we ever get
any commands written with all the busy-work? :-)

I do have some thoughts on building an interface definition
language for PSPP, so that #4 and #5 above could be done
automatically.  Furthermore, I've had some thoughts recently
about how to automate parsing, so that #2 above could be done
without much manual labor.  All this is predicated on a lot of
"if"s though.

There's another issue with separating parsing from execution.
That's how to handle the side effects that some commands have on
the dictionary.  When we parse a transformation or a utility, we
often create variables, modify variables, etc.  Is that
considered part of parsing or execution?  If it's part of
parsing, then we'll need to have a way to back it out if the
command is destroyed without being executed.  (One possibility
would be to introduce a general "transactions" mechanism for
variables and dictionaries.  Destruction rolls back the
transaction, execution commits it.)  If it's part of execution,
then parsing becomes a lot harder for some commands.

Well, I guess I can accept the idea of doing it this way.

I'm starting to believe that we should not centralize the command
definitions in a single file (command.def).  They're getting to
be complicated enough that perhaps each one should be a structure
defined in the file that implements the command.
-- 
Ben Pfaff 
email: address@hidden
web: http://benpfaff.org