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 17:30 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 12:04 UTC)
|
schemedoc/bibliography (Re: Readscheme, BibTeX and S-expressions vs JSON)
Amirouche Boubekki
(29 Feb 2020 06:35 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/