Re: [patch #5653] Make the GUI's data sheet update itself properly, Phase 2

John Darrington <john@xxxxxxxxxxxxxxx> writes:

> On Sun, Dec 31, 2006 at 11:05:02PM +0000, Ben Pfaff wrote:
>
>      I didn't quite understand the change to src/ui/gui/syntax-editor.c.  Are 
> we
>      assured that there is always a data source at this point?  If not, then 
> this
>      is likely to confuse some commands.
>
> There are a number of issues here.
>
> 1. Basically, the answer to your question is yes.  In the GUI
> environment, there is always a data source.  But it might be one
> with no cases and no variables.  The  source is whatever has been
> typed in to the data and variable sheets (which might be nothing).

OK.

The possibility of no variables is interesting--I am not sure
that every command is prepared to tolerate that.  It might be
worth either (a) reviewing commands to make sure they can handle
it or (b) only using CMD_STATE_DATA if there is at least one
variable.  The latter probably makes more sense, seeing as it's
somewhat meaningless to attempt data analysis when there are no
variables.

Every command should already handle the possibility of no data.

> 2. I'm wondering if the third argument to cmd_parse is really needed.
> Would it not make more sense to have a state variable in struct
> dataset instead?   

The third argument to cmd_parse is only needed because of INPUT
PROGRAM (and FILE TYPE, whenever we implement it), which wants to
specify that the state is CMD_STATE_INPUT_PROGRAM.  In other
situations the state can be inferred from the dictionary and data
source's presence or absence.  I'm not really happy with the idea
of adding more redundancy (through a dataset variable), nor do I
really like the current situation where the caller must specify
the state.  Perhaps there could be two interfaces to the command
parser: cmd_parse, which infers the state, and
cmd_parse_in_state, which takes the state as an argument.

> If this variable had the same type as the state
> variable in struct command, then it would simplify
> src/language/command.c ; the in_correct_state and
> report_state_mismatch functions in this file seem overly complex too
> me.

The in_correct_state function would be slightly simplified by
making them the same (it would reduce to "a & b != 0") but I
don't think report_state_mismatch would really change
meaningfully.

> 3. This highlights an incompatibility between PSPP and spss (at least
> later versions thereof).  
>
> In PSPP it is possible to run syntax such as 
>
> DATA LIST LIST /x *.
> BEGIN DATA.
> 1
> 2
> END DATA.
>
> DATA LIST LIST /y *.
> BEGIN DATA.
> 3
> 4
> END DATA.
>
> whereas in the Other Software, this is not allowed, unless one puts
> NEW FILE. before the second DATA LIST command.
>
> I'm not sure that other software allows the following either:
>
> DATA LIST LIST /x *.
> LIST.
> BEGIN DATA.
> 1
> 2
> END DATA.
>
> Which we have in several places in our tests.

I'm surprised.  Both of these work well in old versions of SPSS
(I checked again just now to verify).  We can disallow or warn
about them in compatibility mode, if you like.
-- 
"MONO - Monochrome Emulation
 This field is used to store your favorite bit."
--FreeVGA Attribute Controller Reference