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. /Henrik On Thu, Sep 3, 2009 at 7:55 PM, Tomas Hlavaty<t...@logand.com> 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 http://ondoc.logand.com/ondoc.js > =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 http://logand.com/sw/ondoc/index.html 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 http://logand.com/sw/wps/wps.js > > =A0 WPS http://logand.com/sw/wps/index.html 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 > -- > UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=3dunsubscribe > -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
