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

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

   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

   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.


UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe

Reply via email to