> Bakul Shah <bakul@xxxxxxxxxxxxx> writes: > > > At least until the development of an open CAD program gets to > > a self-sustaining stage I'd use s-expressions to represent > > data. Here is a somewhat restricted definition: > > > > An s-expr is a list of atoms or s-exprs where the first > > element of the list defines the meaning of the whole > > s-expr. An atom is a number, string or symbol. An s-expr > > is written by enclosing its elements in parentheses. Massimiliano Mirra <mmirra@xxxxxxxxx> responds: > > As an Elisper rookie and a Scheme lover, I can share your attitude > towards sexp's. There's only one thing that kept me from jumping on > them for the geometry format (except the fact that I was mostly > exploring the higher level concepts): about all common text editing > tools are line-oriented. I wrote in a previous message that you > cannot grep through a db; you also cannot grep through a sexp (well > you can, it just won't be very useful). This doesn't mean I am > putting aside either; only that I have some more thinking ahead before > I can give them a try. :-) Is this your only objection?! It seems to me it wouldn't be hard to add sexp support to grep or even write sexpgrep from scratch! Example use of such a hypothetical program: $ cat foo (line 1 1) (square 5) (figure "sample" (square 1) (circle 2) (at 5 5) (square 10) (square 20)) # Note: this is just one possible output choice. See below $ grep --sexp -n square foo 2: (square 5) 5: (square 1) 6: (square 10) (square 20) As you can see, the main problem is figuring out exactly what to show.... Perhaps it should be the smallest enclosing context or the smallest enclosing context if the whole line is shown. Or overload -C <n> to provide <n> enclosing levels of context. In any case it can return a complete sexp which is a whole lot more useful. A sexp enabled sed can also be more intelligent about what is replaced. In effect you can specify how an sexp matching one pattern is replaced with another. Unix tools such as grep, awk & sed are fine for line oriented data but they don't handle nest structured data very well. I believe it wouldn't be too hard to extend exiting tools such that the record delimiter is a matching pair of parentheses. So one can still have a set of simple tools that can be combined in different ways. You don't have to buy into Lisp or Scheme if you don't want to -- use any language you want; just don't settle for a line oriented or unstructured or hard to parse interchange format (and don't settle for verbose formats like XML either)! -- bakul