Basically LGTM except for one thing:  IMAO you should *not* attempt to parse or otherwise mess with names.  Worldwide, names are far too complex and variable to put in a lastname-firstname(s) straitjacket.  See my rant "Against Structured Names and Telephone Numbers" <> and the links at the bottom of the names section.

I don't see any need to be JSON-compatible.  The internal JSON representation is for ease of internal use, and the current conventions make it trivial to serialize as an S-expression in almost any Lisp.  JSON-compatible data structures should be serialized as JSON.

On Sat, Feb 22, 2020 at 6:49 AM Lassi Kortela <> wrote:
I tried converting some citations in the readscheme repo maintained by
Amirouche into an S-expression format that stores the same information
as the ubiquitous BibTeX format (

The really nice thing about BibTeX is that Google Scholar has a button
that gives you the BibTeX code for any paper in its search results. So
you can copy/paste that code, edit it lightly, and then add any missing
information from the existing Markdown entries. (Since Google Scholar
indexes tons of papers, its entries are often missing some information.)

Here's one BibTeX entry given by Google Scholar:

   title={Concurrency oriented programming in termite scheme},
   author={Germain, Guillaume and Feeley, Marc and Monnier, Stefan},
   booktitle={Erlang Workshop},

As an S-expression it could be:

((type inproceedings)
  (name germain2006concurrency)
  (title "Concurrency Oriented Programming in Termite Scheme")
  (author #(("Germain" "Guillaume")
            ("Feeley" "Marc")
            ("Monnier" "Stefan")))
  (booktitle "2006 Workshop on Scheme and Functional Programming")
  ;; (booktitle "Erlang Workshop")
  (pages 20)
  (year 2006) ;; September
  (organization "Citeseer")
  (pdf "")

I made some edits based on Amirouche's readscheme Markdown:

- Capitalized the paper's title - it's capitalized in the PDF.

- Split the authors into a list. This may be a good or bad idea. BibTeX
does not split them as far as I can tell.

- The paper has been presented in both the Scheme and Erlang workshops.
Google gives the Erlang workshop, whereas Readscheme gives the Scheme

- Added the month of the year as a comment (September). Does BibTex
support months?

- Added PDF URLs where one can download the paper. This will be very
important for usability if we generate web pages and other tools based
on this stuff. IMHO it's good to have alternative URLs, as some copies
sometimes disappear from the internet.


In particular, since the JSON SRFI (180) is being done right now, and
there seems to be widespread agreement that Scheme should represent JSON
objects as alists and JSON arrays as vectors by default, it might make
sense to use a S-expression syntax that mirrors that.

But will such a syntax be intuitive to read and write by humans? In
particular, JSON-object-as-alist means we would use the consing dot a
whole lot:

((type . "inproceedings")
  (name . "germain2006concurrency")
  (title . "Concurrency Oriented Programming in Termite Scheme")
  (author . #(((last-name . "Germain") (first-names . "Guillaume"))
              ((last-name . "Feeley")  (first-names . "Marc"))
              ((last-name . "Monnier") (first-names . "Stefan"))))

We also can't use symbols as values if we want to be JSON-compatible,
since JSON can only do string values.

Probably it'd be nice to have some lightweight schema that would let us
write some more idiomatic S-expressions:

   (type inproceedings)
   (name germain2006concurrency)
   (title "Concurrency Oriented Programming in Termite Scheme")
       (last-name "Germain")
       (first-names "Guillaume"))
       (last-name "Feeley")
       (first-names "Marc"))
       (last-name "Monnier")
       (first-names "Stefan")))

I would prefer to write something like the latter if we can find a way
to write some automated translation rules to convert it to the
JSON-equivalent thing.