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
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.
/Henrik
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
