Switch from XML to S-Expressions file format

[ubruhin]

In #150 we decided to switch from XML to S-Expressions as primary file format. This issue can be used for discussions about the details of the new file format.

I already have a first question to discuss: When should S-Expression values be quoted and when not?

According to this IETF draft, double quotes can optionally be omitted if the value does not contain strings. So following two lines are considered as equivalent:

(key value)
(key "value")

But IMO it would be better to always use double quotes if the represented value is a string, and omit the quotes only if the represented type is a boolean or number. Examples:

(number -12.34)
(boolean true)
(string "foobar")

This way one can "see" the data type of the values in an S-Expressions file. This makes it also easier to support syntax highlighting in editors, because the syntax highlighter can distinguish between strings, numbers and booleans. This is how syntax highlighting could look like for our files:

Actually we can even go one step further: Should we define a set of basic data types used in S-Expression files? For example:

• Integer: A number without decimal point (e.g. -42)
• Float: A number with decimal point (e.g. -42.0)
• Boolean: Either true or false
• Enum item: A string without spaces, but not true or false (e.g. align_top)
• String: A string in double quotes (e.g. "Hello World!")

A syntax highlighter could then easily distinguish between all of these data types, so a LibrePCB S-Expressions file would look really nice in editors ;) In addition, such a file is even more expressive because the data type of every value is visible, like this:

[dbrgn]

But IMO it would be better to always use double quotes if the represented value is a string, and omit the quotes only if the represented type is a boolean or number.

Agree!

Should we define a set of basic data types used in S-Expression files?

Yes! I like your suggestions so far. With the "enum item" type we'll definitely be non-standard, but sexprs aren't really standardized anyways.

[dbrgn]

Ah, actually the IETF draft differentiates between quoted strings and tokens. Maybe we could try to fully implement that standard?

[ubruhin]

With the "enum item" type we'll definitely be non-standard

I think the enum type is allowed according the IETF draft, they call such strings "token".

But it seems that the non-quoted numbers are not allowed, because a token must not start with a digit :( But KiCad also does not quote numbers, so LibrePCB would not be the only non-"standard"-conform application xD

[dbrgn]

True, seems that the standard does not include non-quoted numeric types.

[ubruhin]

Another very important question: What file extension should we use for our S-Expression files?

• *.sexp or *.sexpr: If we believe that some time S-Expressions become more popular and thus editors automatically recognize this file extension and enable syntax highlighting ;) But I think this is "dangerous" as long as there is no official, stable file format specifications because if some time there are official specs available, our files may not be standard conform.
• *.sexp or *.sexpr: As described above, but with the difference that instead of waiting for official specifications, we could write them by ourselves 😄 But no time for that, so forget it...
• *.sexp or *.sexpr: As described above, but don't care about future official specifications ;)
• *.lpf (LibrePcb File): Quite short, probably already used by other applications?
• *.lpcb (LibrePCB): Maybe looks like it's a PCB file (even if it could be a schematic or something else)?
• *.lpcbf (LibrePCB File): Looks ugly? ;)
• *.lpse (LibrePcb S-Expressions): ?
• *.librepcb: Too long?
• Something else?

@dbrgn @rnestler Any opinions?

[dbrgn]

What about .lp? Is that already used? (Edit: See this. Don't think we need to care.)

[dbrgn]

The .sexp extension could in theory be problematic behind company or school firewalls that are a bit eager on content filtering. As an alternative, you could use .se.

[ubruhin]

What about .lp?

I like that! 😃 So far my favorites are .lp and .lpcb.