[LEPL] JSON parsing with lepl?

[~flow]

hi guys,

has there anyone done a JSON parser using lepl? i couldn't find any.

lepl looks very exciting and reasonable to me. everything is done with
so much hindsight, and the documentation is terriffic. is there any
site where model solutions for the most common parsing chores (like
parsing a list literal, or a dictionary literal) are discussed?

cheers & ~flow

--
You received this message because you are subscribed to the Google Groups "lepl" group.
To post to this group, send email to le...@googlegroups.com.
To unsubscribe from this group, send email to lepl+uns...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lepl?hl=en.

[jazg]

have you found http://www.acooke.org/lepl/examples.html ?

[andrew cooke]

Hi,

Lepl is still relatively new (it's only the last few months that the
number of downloads have really picked up, although I've been
releasing for over a year now, I think).

A JSON parser would be a really nice project I would like to do at
some point (or, better, that someone else could submit).

I do have a few examples, including parsing a list, at
http://www.acooke.org/lepl/examples.html

For more examples, perhaps we could start using the Wiki?
http://code.google.com/p/lepl/w/list

Is that public writable? I guess not. [Pause].

OK, so it looks like I need to add people as "project members" and
then grant Wiki permissions. Please see http://code.google.com/p/lepl/wiki/WelcomeToLepl

Cheers,
Andrew

On May 5, 7:35 pm, "~flow" <wolfgang.l...@gmail.com> wrote:

[magcius]

Here's an oldie I written back in LEPL 2 days.

http://paste.pocoo.org/show/210875/

Andrew can probably improve it and make it up to date.

On May 5, 7:35 pm, "~flow" <wolfgang.l...@gmail.com> wrote:

[andrew cooke]

Actually, that looks like I wrote it! (I realise I didn't, but it's very like
my style).

Is that all that's necessary for JSON? Is it your code? If so, can you
confirm that the statements here are true -
http://elinux.org/Developer_Certificate_Of_Origin - where the licences are
described here - http://www.acooke.org/lepl/licence.html

And if that's all OK, thanks - I'll stick it in Lepl. :o)

Cheers,
Andrew

[jazg]

unicode_escape doesn't work, at least not with the current version.
(&) and (>) need to be changed to (+) and (>>):


unicode_escape = ("\\u" + Digit()[2:4,...]) >> methodcaller('decode',
'unicode_escape')



Also in Python 3 str.decode doesn't exist anymore.
The decoder function can be written like this:


def escape_decoder(s):
return bytes(s, "utf-8").decode("unicode_escape")

unicode_escape = ("\\u" + Digit()[2:4,...]) >> escape_decoder

[andrew cooke]

I just checked, and there's a json parser in Python's standard
library. I would suggest using that rather than writing your own!
Andrew

On May 5, 7:35 pm, "~flow" <wolfgang.l...@gmail.com> wrote:

[~flow]

to use the wiki as a forum to publish solutions could be a very good
idea. there are a great many recurrent problems in parsing with
solutions that are not so obvious for n00bs so i guess a lot of people
could profit from a solutions library.

[~flow]

yeah i would guess it will be much faster to use the standard
library’s or a third party JSON parser; i have seen a few and they all
go for feature-completeness and speed. BUT libraries such as
simplejson don't easily lend themselves for modifications of the
grammar (i tried before), which means you have to start from scratch
writing your own if what you want is ‘similar’ to JSON but not equal.

parsing JSON is interesting because its grammar is pretty much a
common subset of many popular programming languages, so having a
working JSON grammar means you can already ‘almost’ parse C,
JavaScript, or Python.

[magcius]

Heh. I did indeed write it as my first project with LEPL (I've
actually
only done two, but I don't have parsing problems very often). I did it
because I couldn't find a JSON parser online, and not because I needed
a JSON parser, but because JSON is now a "Hello, World" of parsing,
because of the simple grammar, even more simple than a mathematical
evaluator with precedence climbing. So, to me, the simplejson module
isn't the point, it's the obvious solution, but writing a simple JSON
parser is a good test of LEPL's versatility and conciseness.

Even now I have trouble understanding what I wrote, it certainly needs
some documentation explaining the differences between ">" and ">>" and
why one is used in this situation over the other. I remember it being
mostly trial and error, as, no offense Andrew, the docs didn't explain
that very well, and I don't think they still do.

I guess I'll have to go back and look at what other stuff changed,
like
the semantics of "/", "&" and "+". And now there's that DroppedSpace
thing.

As an aside, my colleagues and I have discussed Python and the MPL.
MPL
uses a basis of "modifications", to determine whether code should be
open.
With Python, and mutable code and modules, you can circumvent the MPL
using those strategies. I use MPL for all my projects, and request
that
somebody contact me for more lenient terms. I think that somebody who
is coding based on my library's legal status and not its functionality
isn't worth bothering with, and neither is their code.

On May 6, 9:43 pm, andrew cooke <and...@acooke.org> wrote:
> Actually, that looks like I wrote it! (I realise I didn't, but it's very like
> my style).
>
> Is that all that's necessary for JSON?  Is it your code?  If so, can you

> confirm that the statements here are true -http://elinux.org/Developer_Certificate_Of_Origin- where the licences are
> described here -http://www.acooke.org/lepl/licence.html

[magcius]

Oh and just to say in case all of those words aren't clear enough, I
agree
with all of the terms.

> > confirm that the statements here are true -http://elinux.org/Developer_Certificate_Of_Origin-where the licences are

[andrew cooke]

Hi,

Thanks. Particularly agree on the >> stuff - this will be useful.

Cheers,
Andrew

[magcius]

Sorry to hijack this thread for doc improvements, but a couple things:

I think you should explain how the "..." operator is actually a real
operator in Python when in the context of slicing. The first time I
saw this I tried to click on the "..." in the docs a few times
thinking
it excluding something, before trying the line and having it
surprisingly not fail.

Oh, also, explain the slicing better than you do. The combination of
slicing with ":" and the tuple for options seems extremely, extremely
weird to someone who didn't write the library. One of my biggest
gripes with these types of docs is that they don't fully explain the
valid values for these types of things. Explain the syntax of Python
slicing and how the tuple is the lower precedence and the method for
parsing the special slicing syntax. Example: is Space[...,3:] allowed,
and what will that do?

Last time I checked, "/" was some kind of operator to include
whitespace,
however I found it was unusual because the length of the result would
change depending on the whitespace in the input. It wasn't including
the whitespace, it was the unreliable results of the operator.

> > > confirm that the statements here are true -http://elinux.org/Developer_Certificate_Of_Origin-where the licences are

[andrew cooke]

Thanks, I'll fix those, but...

Can you explain what you mean by "how the tuple is the lower precedence"
below? I don't understand what you're getting at there.

'/' is left over from when I was working things through in the early releases
(Lepl was motivated by my frustratinon with pyparsing's handling of spaces;
with time I understand pyparsing better ;o). I should perhaps think about how
to deprecate things... If I recall correctly, it consumes a *single* space
(// consumers multiple, and with DropSpaces() is almost always easier).

Cheers,
Andrew

[andrew cooke]

Thanks for this - I just spent way too long trying to understand decoders in
3. Andrew

[andrew cooke]

There's now a FAQ that explains >> and > -
file:///home/andrew/projects/personal/lepl/current/doc/faq.html#faq-apply

(still much more to do, but I hope that helps some)

Andrew

[andrew cooke]

On Sun, May 09, 2010 at 08:25:26AM -0400, Andrew Cooke wrote:
>
> There's now a FAQ that explains >> and > -
> file:///home/andrew/projects/personal/lepl/current/doc/faq.html#faq-apply

Ooops http://www.acooke.org/lepl/faq.html#faq-apply

> (still much more to do, but I hope that helps some)
>
> Andrew

[magcius]

Thank you, that was very, very helpful. You have a talent for writing
docs and explaining complicated things in a natural way. Even better,
you actually take the time to make your projects your usable, instead
of setting up wiki or say "submit a patch for doc improvements" to
except your users to do it. Thank you very, very much for
contributing so much to the open-source community.

I personally look forward to more doc improvements, mainly because you
make them easy and fun to read.

In case you weren't clear about the tuple/slicing precedence, I may be
be wrong, but I believe that with a slice like [3:4,5:6], it is
slice(3, (4,5), 6), not (slice(3, 4), slice(5, 6)). The slice has
"higher operator precedence", and that would help a little when
explaining all the things in the complicated features and options
in the repeat syntax.

Oh, a minor improvement on the home page, I don't like demos waiting
for people to type things. I wish there was a button to "fast-forward"
or reveal all.

[andrew cooke]

On Sun, May 09, 2010 at 01:01:51PM -0700, magcius wrote:
> Thank you, that was very, very helpful. You have a talent for writing
> docs and explaining complicated things in a natural way. Even better,
> you actually take the time to make your projects your usable, instead
> of setting up wiki or say "submit a patch for doc improvements" to
> except your users to do it. Thank you very, very much for
> contributing so much to the open-source community.
>
> I personally look forward to more doc improvements, mainly because you
> make them easy and fun to read.

thanks! (actually the json code helped me understand what was not being
understood, because i realised (i think?) that it was trying to avoid
lists...)

> In case you weren't clear about the tuple/slicing precedence, I may be
> be wrong, but I believe that with a slice like [3:4,5:6], it is
> slice(3, (4,5), 6), not (slice(3, 4), slice(5, 6)). The slice has
> "higher operator precedence", and that would help a little when
> explaining all the things in the complicated features and options
> in the repeat syntax.

oh wow - i didn't even know that was possible. does it work?! i very much
doubt it!?! i will add tests and extend as necessary...

> Oh, a minor improvement on the home page, I don't like demos waiting
> for people to type things. I wish there was a button to "fast-forward"
> or reveal all.

yeah, that's on the list, but low priority... :o)

cheers,
andrew

[magcius]

Oh whoops, I'm wrong:

>>> class A(object):
... def __getitem__(self, v):
... print v
...
>>> A()[3:4,5:6]
(slice(3, 4, None), slice(5, 6, None))