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. I have done this in three cases: 1) Parsing sexp: function parse(S) in http://ondoc.logand.com/ondoc.js is not complete (dot notation is missing) and needs some improvements based on the lesson learned from the postscript parser bellow. OnDoc http://logand.com/sw/ondoc/index.html uses sexp completely for communication between client and server. Ideally, I would like to replace javascript by client-side picolisp (implemented in javascript) completely. I think it is feasible and could be efficient enough. Imagine having persistent symbols/objects 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 http://logand.com/sw/wps/wps.js WPS http://logand.com/sw/wps/index.html proved to me that implementing interpreters in javascript is reasonably efficient although not great for coding things in a tight loop (which is usually quite little code and could be implemented directly in 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. Json 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=unsubscribe
