On Fri, 4 Sep 2009, Henrik Sarvell wrote:
I just realized that there is an ambiguity here since I can't seem to
accomplish a pair looking like this:
("key" . (1 2 3)), no matter how I try I get: ("key" (1 2 3)), if the
Heh, I think the problem is quite obvious when looking to the list as what
it really is: a chain of cons.
("key" (1 2 3)) -> ("key" . ((1 . (2 . (3 . NIL)))))
that's equivalent to:
("key" . (1 2 3)) => ("key" (1 2 3))
first one is really impossible then any JSON converter will stumble on
it since it's impossible to know if ["key", [1, 2, 3]] or {"key": [1,
2, 3]} is the desired result.
What if:
("key" (1 2 3)) -> ["key", [1, 2, 3]]
(":key" (1 2 3)) -> {"key": [1, 2, 3]}
(I suggest the ':' to be put at the beginning of the key-word for conventions'
sake.)
On Thu, Sep 3, 2009 at 11:20 PM, Henrik Sarvell<hsarv...@gmail.com> wrote:
First of all, to offload the server from having to build json all the tim=
e.
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 lik=
e
=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
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
