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 :)
/Henrik
On Thu, Sep 3, 2009 at 7:51 AM, Alexander
Hello,
On Thursday 03 September 2009 02:00:39 Henrik Sarvell wrote:
Hello everyone, I sat down tonight and ugly coded a Pico to JSON
converter in JS, I documented it here:
http://www.prodevtips.com/2009/09/02/pico-lisp-to-json-with-javascript/
Pretty nifty idea IMHO :)
The part of your
Thanks Mateusz, I'll try it out.
/Henrik
On Thu, Sep 3, 2009 at 11:52 AM, Mateusz Jan
Przybylskidexen.devr...@gmail.com wrote:
Hello,
On Thursday 03 September 2009 02:00:39 Henrik Sarvell wrote:
Hello everyone, I sat down tonight and ugly coded a Pico to JSON
converter in JS, I documented
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
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]]
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
