Email list hosting service & mailing list manager

Readscheme, BibTeX and S-expressions vs JSON Lassi Kortela (22 Feb 2020 11:49 UTC)
Re: Readscheme, BibTeX and S-expressions vs JSON John Cowan (22 Feb 2020 20:55 UTC)
Re: Readscheme, BibTeX and S-expressions vs JSON Lassi Kortela (22 Feb 2020 18:02 UTC)
Re: Readscheme, BibTeX and S-expressions vs JSON Alaric Snell-Pym (23 Feb 2020 17:00 UTC)

Re: Readscheme, BibTeX and S-expressions vs JSON Alaric Snell-Pym 23 Feb 2020 12:04 UTC
On 22/02/2020 11:49, Lassi Kortela wrote:

> - 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.

(I am not an academic, so am clueless) Is there any convention of
attaching significance to whether people are joined "and", "," or "&"
like in script writing credits? There might be some need to represent
that sort of thing.

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

Is there a difference in citing one versus the other? Is it definitely
the same paper, down to the tiniest detail? Do people want to cite one
or the other in order to express their allegiance to their team? Will
funding bodies have rules about papers they fund citing things in their
favourite journals?

> Comments?

As a casual reader of papers, I like it!

> 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.

I say: Don't worry about JSON. If we want a JSON representation of
arbitrary Scheme objects, it'll need to deal with symbols and alists and
so on in a way that'll look nice in Scheme and ugly in JSON. If we want
a Scheme representation of arbitrary JSON objects, then it'll look great
in JSON and a bit ugly in Scheme :-) If you're designing an sexpression
format for something, designing it to look good in JSON, unless you're
trying to be compatible with some existing JSON standard, is probably
not a good idea.

--
Alaric Snell-Pym   (M7KIT)
http://www.snell-pym.org.uk/alaric/