V6 symbol library format

This is a trial to show the proposed S-expressions in EBNF what may be useful for script generated symbols. Comments welcome if it is wrong or inaccurate.
s_expr.pdf (318.3 KB)

Where did you derive the syntax from?

I wouldn’t normally put comments, white space into a syntax spec. I think your spec is overly restrictive, e.g keywords can contain upper case, comments can have any characters.

ETA: I assume the source is https://docs.google.com/document/d/1lyL_8FWZRouMkwqLiIt84rd2Htg4v1vz8_2MzRKHRkc/edit

I guess the code for V6 format is work in progress, but the code from master doesn’t currently place restrictions on symbols with regard to case.

I would propose the following :


/* KiCad v6 S-expression syntax for schematic and symbol files */

/* Note: whitespace and comment lines are ignored */

S-Expression ::= '(' Keyword ( Parameter )* ')'

Parameter ::= S-Expression | String | Number

/* Strictly speaking, keywords must be one of known identifiers e.g.
  anchor        |
  value         |
  footprint     |
  model         |
  keywords      |
  alternates    |
  property      |
  property_del  |
  pin           |
  pin_merge     |
  pin_swap      |
  pin_renum     |
  pin_rename    |
  route_pin_swap |
  polyline      |
  line          |
  rectangle     |
  circle        |
  arc           |
  bezier        |
  text
*/
Keyword ::= [a-z][a-z_]*

Number ::= '-'? [0-9.]+

/* TODO: Strings may contain escaped characters */
String ::= '"' [^"#xA]  '"'



Comment ::= WSP* '#' .* 'EOL'

WSP ::= [ #xA#xD#x9#x0]

Copy and paste to https://www.bottlecaps.de/rr/ui to see diagrams.

Yes, the source is derived from Waynes proposal using the bottlecaps generator and I kept as close as possible to the example/explanation. As you can see in the examples, expressions become quite long for possible recursion (a parameter is another S-expression) until terminating by value or string why they contain comments. Except the possiblity for comments and whitespace definitions your s-expressions seems equal. Whitespace seems not optional to separate number parameters.

Your keyword must not start with underscore. This could be ok but Waynes comment therefore is “keywords are comprised of lower case letters, numbers, and underscores” from what I cant derive this constraint.

For values (numbers?) I dont have syntax and I am going to add your syntax.

Regarding strings, they should be UTF8 what is practically all ascii up to 128. I agree about the delimiters but not shure about multi byte sequence with unicodes for national characters nor the C-style escape characters to show the delimiter inside string. Another thing not defined is the tilde character what is widely used for inverted signals in electronics.

Already started to do this for the symbols itself but examples seem to contain some unbalanced brackets

Just for reference, code for parsing S-expression files is https://github.com/KiCad/kicad-source-mirror/blob/master/common/dsnlexer.cpp and there is an early version of the Sweet parser based on previous version of the spec in https://github.com/KiCad/kicad-source-mirror/blob/master/new/sch_sweet_parser.cpp

Yeah, there are still several errors in that document, you have to read between the lines a bit. The final code will certainly end up slightly different to the spec.

4 posts were split to a new topic: Why does the new KiCad symbol format use s-expression?

The 1980s were the best decade. :slight_smile:

2 Likes

done:
all characters allowed for comments
typo for keyword a-f into a-z
value changed to number
indent changed to whitespace*
add whitespace, number, string
whitespace now contains EOL why EOL is removed for parameter separation

s_expr.pdf (251.0 KB)

According to the sources, strings are defined in a specctra doc where I dont have the link.
The unusual NUL in whitespace is derived from pcad and escape sequences are decoded
if the lexer is “non specctra” mode.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.