kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Tue, May 06, 2014 at 07:28:22PM +0100, John Beard wrote:
> I think it would be a good idea to allow unknown fields in the
> s-expression formats so that an older KiCad doesn't choke on things it
> doesn't understand, and doesn't need to.

Good luck convincing Dick on this :D

Jokes aside, the current parser is more or less a recursive descent one,
and it needs to know the grammar of the expression beforehand. That's
also because the specctra expression (the ones implemented by kicad) are
not fully self-typing; for example, given the sexp (type round) you
don't know (without some known syntax) if type is a keyword (or symbol,
in sexp parlance), while round could be a symbol or a string. (type
"round") could be unequivocally a symbol/string (*if* we agree that
strings are always quoted). Also something like 12ab would be something
hard to handle even for a lisp reader (it has a name: maybe-number; it's
simply forbidden:D) Modifying the sexp writer to generate
unambiguos sexps is easy (done it and can be almost directly (read) by
common lisp...) but the patch wasn't accepted. In fact these always
quoted expressions are compatibles with the current reader, anyway.

The other big difference is that typically sexps are slurped by the
(lisp) reader and then processed in core (more or less like DOM); kicad
insteads read them token by token and 'expects' something, depending on
the grammar (like SAX, but needs a grammar for the sexp). This is IMHO
a good decision anyway, since doing otherwise in C++ would be... well,
uneasy:P

That said, I think that *if* the sexp reader can traverse automatically
a generic sexp (without having a grammar, only tokenising) we could
decide that it could 'skip' each subexpression starting with an unknown
token. Maybe with warnings:D

I don't know if the current parser is flexible enough to handle a thing
like that (the common lisp reader is actually quite simple, if you
exclude macro characters and programmable readtables), Dick can explain
better the reason/problems behind it. Or maybe it simply can be done
without problems...

-- 
Lorenzo Marcantonio
Logos Srl