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

[John Darrington]

On Sat, Dec 02, 2006 at 11:06:39AM -0800, Ben Pfaff wrote:
     
     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.

Promiscuous use of casts can certainly lead to problems, but they can
be minimised by an appropriate interface.

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

In that case, the 'server' isn't much more than an instance of pspp
with remote access.  I mean it wouldn't be much different from running
the gui over a X session.
     
     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 talk your point.  It's a considerable amount of extra work.
     
     
     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.

I'd assumed it would be done in the execution stage.  But the
transaction model is equally valid I suppose.

     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.

I agree.  Apart from anything else, changing one line in command.def
requires rebuilding *all* of the commands, even when they don't need
to be.

Why don't we let this patch rest, and see what common ground we have?

I think we agree that there is a need to seperate commands' execution
from their parsing.  How about we introduce a new directory
src/command which has no dependency on the lexer?  For example, the
chisquare.c and binomial.c from the NPAR patch can go there.

Also, perhaps we can come up with a scheme for spliting up
command.def, bearing in mind that doc/ni.texi currently depends upon
it. 

J'

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.

pgpqQ0iJgIRnR.pgp
Description: PGP signature