comments in rson files
bc
First, thanks for your quick response today. I've been going round
and round looking for a decent input/configuration file format for a
project at work. I had settled on a JSON format (or thought I had).
When I discovered RSON (through using rst2pdf) it seemed like a no
brainer to switch - all the advantages of JSON, with a much less error
prone syntax for editing. The addition of macros mean I don't need to
maintain any of my own code I was using for text substitution.
One thing I came across in my research on JSON was this blog entry on
comments (or lack there of) in JSON - http://blog.getify.com/json-comments/.
The author proposes an approach for handling comments in JSON and
there are implementations in a couple of languages at
https://github.com/getify/JSON.minify. The reason I bring it up is
just the different style of comments (c style) that are used. As JSON
is Java Script (which has c style comments) I am wondering if you
would like to include them in RSON, in addition to the python style
comments. So when RSON gains popularity (as I think it should) you
already support the comment style people *may* be using with JSON.
The minify function simply strips the comments out of the text you
pass to it. So it's possible to use this approach to strip out the
comments and then pass the text one to the rson parser (this is how I
was using it with the json parser - with the addition of python style
comments in it).
Thanks,
Brad
Patrick Maupin
> The minify function simply strips the comments out of the text you
> pass to it. So it's possible to use this approach to strip out the
> comments and then pass the text one to the rson parser (this is how I
> was using it with the json parser - with the addition of python style
> comments in it).
One of the purposes of the RSON project is to provide a reusable
toolkit that allows changes like this and allows people to easily
experiment with what works well and what doesn't. From that
perspective, I would certainly be open to adding hooks in the parser
for this if they aren't already there, and an option to enable the
hooks.
But, for example, I don't consider the macro facility to be "base"
RSON, because at the moment the base functionality is defined to be
fairly minimal (and fast), and I am not 100% convinced the way I have
done macros is the best way to add them on, or even if they need to be
added on for that many projects. It was more of a proof-of-concept
and example of how to extend the parser. Not that rsonmac can't be
used in production -- it's only a small (~200 line) extension to a
well-tested and working parser, but I think the bug you found makes it
pretty obvious that nobody is using rsonmac in production at the
moment.
Likewise, in the spirit of being minimal, I wouldn't want to modify
the base RSON functionality to deal with other comment styles
until/unless you can show a significant movement towards commented
JSON using C-style comments. But, as I mentioned, we could certainly
add a parser option to allow C-style comments.
To be considered a proper RSON option, this would have to be something
that is done inside RSON and not by a preprocessor such as minify,
unless the preprocessor were about as smart as RSON itself, because
one of the design goals of RSON is to use whitespace indentation (a la
Python) to allow encapsulation of any arbitrary strings inside RSON
code without horrendously complicated escaping.
For example, in RSON I can currently define the following:
bash_fragment =
if [ -z "$debian_chroot" ] && [ -r /etc/debian_chroot ]; then
debian_chroot=$(cat /etc/debian_chroot)
fi
c_fragment =
void main(void) {
/* Do something here */
return 0;
}
The former still works even in the rsonmac macro processor you are
using (it doesn't replace the escapes when processing the RSON), and
the latter should still work (returning the comment along with the C
fragment) even if we modify RSON to support C-style comments at the
top level, but probably won't work right (the comment will be
prematurely stripped) with the minify approach.
So, BTW, right there, we have a difference between RSON and JSON.
Although I haven't tried, I believe the macros won't work if you use
them inside pure JSON rather than RSON, but that you can probably make
the macro facility work fine with JSON by modifying the rsonmac
parse_unquoted_strings method. However, you probably can't do this
without breaking what I consider to be an RSON invariant -- the easy
encapsulation of strings from arbitrary languages without cumbersome
escape mechanisms. For your purposes, that may be fine, and maybe you
also want to use minify as a pre-processor and modify the
parse_unquoted_strings method, so that your program can accept C-style
comments and macros in both pure JSON and in RSON-style input, but I
think that would be an RSON variant, just as adding the comments is
considered to be a JSON variant.
Personally, I think one of the great strengths of JSON (and why I
decided to make RSON a superset) was the emphasis on minimalism. If
JSON had had free-flowing comments in the first place (and other
comparable embellishments) I might have decided it was too complicated
to use JSON as a base structure while providing all the features I
wanted to provide.
Regards,
Pat
bradlc...@gmail.com
Thanks for your thoughtful reply. My main point was just to make you aware of that effort. I do appreciate the minimalist approach and think that, when combined with the layered approach, gives a lot of flexibility. I agree that the core RSON (not rsonmac) is likely just where it needs to be. I will likely just stick with the currently supported comment style in RSON.
For my purposes I may take a whack at extending rsonmac a little bit (if I can wrap my head around it). I'm going to try to define a way to do some node replication. What I'm thinking is that, say you have a list called mylist in rson, if you use $mylist in another element but don't specify an index, then that element is copied and each version of the copy gets one of the values from mylist.
So:
mylist : [1,2,3,4]
someItem :
a : $mylist
might become:
mylist : [1,2,3,4]
someitem_1 :
a : 1
someitem_2 :
a : 2
someitem_3 :
a : 3
someitem_4 :
a : 4
I'm going to scratch my head about this for a while. I need to think about the semantics a little bit. I could always implement something internal to my code, but then I likely need two types of macro sytax... $ for rsonmac macros, and maybe a % for ones internally. That is not a very user friendly solution.
By the way, I put together a simple minded rson.dumps implementation. I'll post it if you would like.
Brad
Patrick Maupin
> For my purposes I may take a whack at extending rsonmac a little bit (if I
> can wrap my head around it). I'm going to try to define a way to do some
> node replication. What I'm thinking is that, say you have a list called
> mylist in rson, if you use $mylist in another element but don't specify an
> index, then that element is copied and each version of the copy gets one of
> the values from mylist.
>
> So:
> mylist : [1,2,3,4]
>
> someItem :
> a : $mylist
>
> might become:
[snip]
I think it might be easier (really easy, actually) to do something like:
mylist : [1,2,3,4]
someItem_%d :
a : mylist
> I'm going to scratch my head about this for a while. I need to think about
> the semantics a little bit.
Yeah, it's tough to create nicely reusable semantics.
> By the way, I put together a simple minded rson.dumps implementation. I'll
> post it if you would like.
Yeah, that might be interesting. That's another thing where it's hard
to come up with a good generic. I actually wrote a dumps that is part
of rst2pdf, and dumps in (what I think is a) nice format specific to
the needs of stylesheets. In fact, that's what Roberto used to
convert all the base stylesheets from JSON, IIRC. I forget the
syntax, but it's one of the rst2pdf command line options to dump all
the current styles after you load in whatever sheets you are using.
But I'm not at all confident that it's the right answer for a generic dump.
Thanks,
Pat