First of all, to offload the server from having to build json all the time.

For me the real issue is not speed in the client, given that premise I
simply took a wild guess that building the json and then evaluating it
is a simpler road to take than actually building the composite objects
right away. For me it doesn't matter if the result is even ten times
slower as long as I can do as simple a solution as possible, people
sit on such powerful machines anyway.

Anyway, I've fixed things, incorporating Mateusz changes. However it
wouldn't work with recognizing single pairs/objects so quotes inside
keys are still a no no. This is hair splitting though, I don't even
know if they are legal in the keys. In any case I can't think of a
situation where I would have a string with quotes in it.

I've updated the article, looks like it's working, the string
evaluates OK and we can access values in the resulting object/array.


On Thu, Sep 3, 2009 at 7:55 PM, Tomas Hlavaty<> wrote:
> Hi Henrik,
>> That's exactly what I'm doing, ie stepping recursively, the regex is
>> just to determine which state to put the parser in. But yes, it looks
>> like I'm going to have to step through in order to determine type too
>> if no regex guru shows up :)
> as Alex suggests, regular expressions in this context are overkill.
>>> Instead, I would use a simple recursive parser (analog to the Lisp
>>> reader), which can analyze the expression step by step in a more
>>> flexible way.
> Yes. You can simulate peek, char, skip etc. functions in javascript
> closures and write a recursive parser. =A0I have done this in three
> cases:
> 1) Parsing sexp: function parse(S) in
> =A0 is not complete (dot notation is missing) and needs some
> =A0 improvements based on the lesson learned from the postscript parser
> =A0 bellow.
> =A0 OnDoc uses sexp completely
> =A0 for communication between client and server. =A0Ideally, I would like
> =A0 to replace javascript by client-side picolisp (implemented in
> =A0 javascript) completely. =A0I think it is feasible and could be
> =A0 efficient enough. =A0Imagine having persistent symbols/objects
> =A0 directly accesible in your client-side picolisp application;-)
> 2) Parsing PDFs in OnDoc: works surprisingly well & fast in picolisp.
> 3) Parsing postscript: function PsParser() in
> =A0
> =A0 WPS proved to me that
> =A0 implementing interpreters in javascript is reasonably efficient
> =A0 although not great for coding things in a tight loop (which is
> =A0 usually quite little code and could be implemented directly in
> =A0 javascript, similarly to picolisp falling back to C).
> I am not sure, why would you need to build json on the client side
> this way unless you send it to some 3rd party. =A0Json as such is a data
> transfer format and I guess I need the real objects on the client side
> and not yet another representation of them.
> Regards,
> Tomas
> --

Reply via email to