how to write good CS paper

After struggling with yet another CS paper (clearly, I'm outsider;-), I'm trying to collect some recipies for writing a *readable* paper. Please share your ideas if you have some.

One spot that I noticed is indexing. It seems like researcher's tools for enumeration are extremely limited, so they use indexing everywhere. So we easily get tensor notation in a subject area which is quite simple otherwise. Example:

> 2. NOTATIONS
> Finite Structures and Logics. All structures are assumed to be finite.
> A relational signature 'sigma' is a set of relation symbols
> {R_1 , ..., R_l}, with associated arities p_i > 0.

Here we have some number of relations and authors use subscripts to enumerate them within a set. I object! Those indexes would stick to the rest of the paper and every orthogonal enumeration, a need for which is discovered later in the game, would have to be added on top of it. If the results of the paper don't depend on join operations why not to use a single relation 'A' (or universal relation?). Now, if joining is coming somewhere into the picture, then why not introducing 2 relations only: A and B? The effects where joining 3 relations produces something new are subtle, so more than 2 relations aren't probably needed in every paper.

Next comes enumeration of attributes within a relation. Advocates of excessive mathematical notation, again, would write something like P_i(a_1, ..., a_k) (keeping index from previois part, remember?-). Now, what advantages enumerating columns like this are? Are we going to use induction on the number of columns, or leverage ariphmetic properties of the subscript indexes somehow? Wouldn't results of the paper just be fine with relation EMP(name, salary), for example, even if some advanced results concerning complexity of queries are concerned? Received on Sun Jul 22 2001 - 01:26:00 CEST