Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pretty Printer #3

Open
xurtis opened this issue Jun 25, 2017 · 3 comments
Open

Pretty Printer #3

xurtis opened this issue Jun 25, 2017 · 3 comments

Comments

@xurtis
Copy link
Owner

xurtis commented Jun 25, 2017

Currently, all output is through display and printed on a single line. It'd be good to have a pretty printer that nicely formats the output using the following rules:

  • Variable indentation rules (n-spaces or tabs)
  • Loose or tight bracing options
  • S-expressions with no child lists are printed on one line with either loose or tight bracing
  • S-expressions with child sub-lists:
    • Sparse formatting places the first brace on its own line. Each value is placed on its own line
      with indentation advanced beyond the brace.
    • Condensed format places the first brace on the same line as the first value. The first value
      is then indented beyond the brace to line up with the following arguments.
    • The last brace is always on its own line, unindented

Condensed format with tight bracing

( (blah blah blah)
  ( blah
    (blah blah blah)
  )
  blah
)

Sparse formatting with loose bracing

( 
  ( blah blah blah )
  ( 
    blah
    ( blah blah blah )
  )
  blah
)
@jashank
Copy link

jashank commented Jul 7, 2017

There is much prior art in s-expression pretty printing, though most of it focuses specifically on rules for Lisp-like languages. If that's your target here, you probably want to implement (something like) the X3J13 pretty-printing style or mimic the Guile or Racket pretty printers.

In summary, the former, tightly-braced style makes a good deal more sense as a starting point, but adding behaviours depending on symbols would be useful. Symbols should also always be tightly-braced before and after, as dangling parens or loose parens tend to look bad in the context of Lisps, so:

((blah blah blah)
  (blah
    (blah blah blah))
  blah)

@xurtis
Copy link
Owner Author

xurtis commented Jul 7, 2017

Let me propose a few rules.

Classifying Values

First, we classify every value as either code or data in an implicit manner.

  • A list is considered data when:
    • it is explicitly marked as data, or
    • it begins with an explicit data value, or
    • it begins with a non-symbol value.
  • Any list beginning with a symbol that is either explicitly marked as code or is not
    marked as data is itself considered to be code.
  • Symbols are considered code unless marked otherwise.
  • All other values are considered data.

Secondly, we classify the depth of each list as such:

  • Int, Float, and String all have a depth of 0.
  • The depth of a cons pair that is not a list is equal to the depth of its deepest member.
  • The depth of a list is equal to the depth of its deepest member + 1

The hard part after this is using this information to know when to indent an break lines...

@fwouts
Copy link

fwouts commented Jun 16, 2021

Hi there 👋 I'm a few years late to the party, but was wondering if you intended to merge that pretty-print branch? I've been looking for a Rust sexp pretty-printer and this looks like exactly what I need :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants