[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [patch #5603] Separate command's parsing from their execution
From: |
John Darrington |
Subject: |
Re: [patch #5603] Separate command's parsing from their execution |
Date: |
Sun, 3 Dec 2006 12:24:44 +0900 |
User-agent: |
Mutt/1.5.4i |
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