Re: Contribution to SES (resend)

[Vincent Belaïche]

Thanks for your kind feedback.

>> I would like to make a contribution to SES, a user of which I am.
>
>I like it, but I have a few comments:
>- What's the difference btw ses-range and ses-list?  I mean, ses-list
>  seems like a superset, so why not extend ses-range instead?

This was my orginal idea, but then I thought that ses-range being a
slightly faster implementation, it might be valuable to keep it. 

Actually the very main reason for both to coexist is that the default
orientation for ses-range is `<^', while the default for ses-list is
`>v'. I find it very convenient to have >v because this is the usual
orientation in the Western world (even though this is not universal, I
am a westerner after all). And all spreadsheets I know have cell (0,0)
in the top left corner, so it is good to have this orientation by
default.

On the other hand, some people might have already used ses-range with
`apply' of non commutative operators, so changing the orientation of
ses-range is not backward compatible. I don't think it would be a good
idea.

In a nutshell, this is why some ses-range + ses-list co-existance is
needed.

Maybe there could be some message like "ses-range" is deprecated, use
"ses-list", and some function to replaced all (ses-range X Y) by
(ses-list X Y <^). I don't know. Maybe some people want to keep the
speed and code simplicity of ses-range (but how faster is ses-range over
ses-list ?)

>- Hmmm.... #N= + #N# in source code ... I'd rather avoid it.

Does the compiler factorize code well ? If yes I am OK to make that
change, although duplication of code is *EVIL*, and too many defsubst
may not be a good idea either (for it creates an intern symbol memory
overhead).

On the other hand the only reason for those #N= #N# is to make `or''s,
so if I replace (see your next comment) `(eval (assq ...))' by `(cond
...)', I would just do or's or eq's.

>- Do we really need to distinguish ^> from >^ when the user can just
>  (reverse ...) the result?  I guess it's OK.

Well, we have to keep in mind that simple emacs speadsheet documents,
and spreadsheet documents in general, are often quick hacks, and should
remain so. A complex spreadsheet is very hard to maintain, when you
reach this complexity limit of ease of maintenance it is better to make
some small script program for the same purpose. This is one reason why I
like SES, it obliges you too make only simple spread sheets.

So, having said that, I frankly prefer to type `(ses-list X Y >^)' than
`(nreverse (ses-list X Y <v))'. BTW `^>' is not the reverse of
`>^'. Take the following example:

 | 1 | 2 |
 |---+---|
 | 3 | 4 |
 
^> readout is (3 1 4 2), and >^ readout is (3 4 1 2).


>- please use `case' rather than assq+eval (I usually dislike `eval').

Do you mean `cond', not `case' ? Please clarify.

Why do you dislike `eval' ? (I am a curious one).

The motivation for the assq was that I thought it was faster than a
cond, because the eq is done in C.

>- The !0 and !. should be replaced by a single flag that comes with
>  the default value to use.

OK, I like your idea. So `!' could be to remove nil and *skip* and `_ 0'
would replace them by 0, and, if `_' is last, default of default would
be 0. Would this be fine (notably `_' to mean blanking by some default).

>- I'm not convinced I like those special symbols (but I don't have
>  a good counter-proposition either).
>

Please feel free to make one. I was thinking first of taking the picture
orientation symbols > < ^ . / \ ' and `. But then I find that those I
proposed are easier to understand: you don't read a table in diagonal,
don't you (I don't know whether you can say that in English "lire en
diagonale", to mean "read without carefull attention").

Maybe we could also have those shorthands :

 | one letter symbol | meaning |
 |-------------------+---------|
 | >                 | >v      |
 | <                 | <v      |
 | v                 | v>      |
 | ^                 | ^>      |
 
Would this make sense (notably for one row, or one col tables where you
don't care the other direction) ?

>
>        Stefan
>
>

I will wait for your feedback, and that we converge one some conclusion
before making any updates (including texinfo manual).

  Vincent.

PS: I have not yet tested the rellocation is not broken, this was a
first disclosure to get feedback on the idea.