Thanks for the input Thomas but I think I will just go with paired lists
instead, they are easier to manipulate with various list functions and
should therefore be preferable to basic objects anyway. +Entity objects are
on the list though.
>> This is oversimplified version as there are lots of special cases in
javascript to handle, e.g. you have to double-quote keys if they are
negative numbers if I remember well:<<
As far as I've been able to see any kind of key is double quoted in the json
string (so that is what happens now), at least in the examples I've looked
at.
Now the question is, should we do basic objects when converting from json or
paired lists. Basic objects are possible in that direction but that would
then "break" with the rule of only accepting +Entity objects and paired
lists for encoding.
I don't know how a paired list vs a basic object compare when it comes to
populating an +Entity object, any suggestions Alex? If an object is easier
then that could motivate the decision to go for object when decoding and
thus having different input and output formats.
/Henrik
On Fri, Aug 22, 2008 at 2:24 AM, Tomas Hlavaty <[EMAIL PROTECTED]> wrote:
> Hi Henrik,
>
> >> convert all Ts to true, and NILs to false in the JSON string.
>
> > With the NILs we run into a problem, because a property value of NIL
> > means that this property does not exist. So it can never be
> > extracted from the object itself.
>
> maybe the js <-> picolisp mapping false <-> NIL is not the right thing
> to do here? There are things like undefined, null, "" (empty string),
> NaN (maybe too?) or false you could represent as NIL but then you lose
> information during conversion and cannot rebuild the js data back
> again exactly.
>
> > To solve the problem with the NILs, you'll have to keep a separate
> > record of possible properties (as is done, for example, in the
> > '+Entity' objects).
>
> Or, you could create your own unique NIL which would be treated by
> picolisp as any other non-NIL value and interpret it yourself during
> picolisp -> javascript conversion as false, for example.
>
> : (setq MyNIL (new))
> (setq Tst (new))
> (put Tst 'a "hello")
> (put Tst 'b T)
> (put Tst 'c MyNIL) # swap false, null, undefined or even NIL for MyNIL
> (getl Tst)
> (mapcar '((X) (or (pair X) (cons T X))) (getl Tst) )
> (prog
> (prin "[")
> (for (I . X) (mapcar '((X) (or (pair X) (cons T X))) (getl Tst) )
> (when (< 1 I)
> (prin ", "))
> (prin (cdr X) ": ")
> (cond
> ((== (car X) MyNIL) (prin "false"))
> ((== (car X) T) (prin "true"))
> (T (print (car X)))))
> (prin "]"))
> -> $519715527
> : -> $519715537
> : -> "hello"
> : -> T
> : -> $519715527
> : -> (($519715527 . c) b ("hello" . a))
> : -> (($519715527 . c) (T . b) ("hello" . a))
> : [c: false, b: true, a: "hello"]-> "]"
>
> This is oversimplified version as there are lots of special cases in
> javascript to handle, e.g. you have to double-quote keys if they are
> negative numbers if I remember well:
>
> ["-1": "negative numbers as strings in key"]
>
>
> Alex, why does getl return a list of (property-value . property-name)
> and not a list of (property-name . property-value)?
>
> Cheers,
>
> Tomas
> --
> UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
>
------=_Part_44266_24757689.1219373194560
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<div dir="ltr"><br>Thanks for the input Thomas but I think I will just go with
paired lists instead, they are easier to manipulate with various list functions
and should therefore be preferable to basic objects anyway. +Entity objects are
on the list though.<br>
<br>>>
This is oversimplified version as there are lots of special cases in<br>
javascript to handle, e.g. you have to double-quote keys if they are<br>
negative numbers if I remember well:<<<br><br>As far as I've been
able to see any kind of key is double quoted in the json string (so that is
what happens now), at least in the examples I've looked at.<br><br>
Now the question is, should we do basic objects when converting from json or
paired lists. Basic objects are possible in that direction but that would then
"break" with the rule of only accepting +Entity objects and paired
lists for encoding. <br>
<br>I don't know how a paired list vs a basic object compare when it comes
to populating an +Entity object, any suggestions Alex? If an object is easier
then that could motivate the decision to go for object when decoding and thus
having different input and output formats.<br>
<br>/Henrik<br><br><div class="gmail_quote">On Fri, Aug 22, 2008 at 2:24 AM,
Tomas Hlavaty <span dir="ltr"><<a href="mailto:[EMAIL PROTECTED]">[EMAIL
PROTECTED]</a>></span> wrote:<br><blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex;
padding-left: 1ex;">
Hi Henrik,<br>
<div class="Ih2E3d"><br>
>> convert all Ts to true, and NILs to false in the JSON string.<br>
<br>
> With the NILs we run into a problem, because a property value of NIL<br>
> means that this property does not exist. So it can never be<br>
> extracted from the object itself.<br>
<br>
</div>maybe the js <-> picolisp mapping false <-> NIL is not the
right thing<br>
to do here? There are things like undefined, null, "" (empty
string),<br>
NaN (maybe too?) or false you could represent as NIL but then you lose<br>
information during conversion and cannot rebuild the js data back<br>
again exactly.<br>
<div class="Ih2E3d"><br>
> To solve the problem with the NILs, you'll have to keep a separate<br>
> record of possible properties (as is done, for example, in the<br>
> '+Entity' objects).<br>
<br>
</div>Or, you could create your own unique NIL which would be treated by<br>
picolisp as any other non-NIL value and interpret it yourself during<br>
picolisp -> javascript conversion as false, for example.<br>
<br>
: (setq MyNIL (new))<br>
<div class="Ih2E3d">(setq Tst (new))<br>
(put Tst 'a "hello")<br>
(put Tst 'b T)<br>
</div>(put Tst 'c MyNIL) # swap false, null, undefined or even NIL for
MyNIL<br>
(getl Tst)<br>
<div class="Ih2E3d">(mapcar '((X) (or (pair X) (cons T X))) (getl Tst) )<br>
</div>(prog<br>
(prin "[")<br>
(for (I . X) (mapcar '((X) (or (pair X) (cons T X))) (getl Tst)
)<br>
(when (< 1 I)<br>
(prin ", "))<br>
(prin (cdr X) ": ")<br>
(cond<br>
((== (car X) MyNIL) (prin "false"))<br>
((== (car X) T) (prin "true"))<br>
(T (print (car X)))))<br>
(prin "]"))<br>
-> $519715527<br>
: -> $519715537<br>
: -> "hello"<br>
: -> T<br>
: -> $519715527<br>
: -> (($519715527 . c) b ("hello" . a))<br>
: -> (($519715527 . c) (T . b) ("hello" . a))<br>
: [c: false, b: true, a: "hello"]-> "]"<br>
<br>
This is oversimplified version as there are lots of special cases in<br>
javascript to handle, e.g. you have to double-quote keys if they are<br>
negative numbers if I remember well:<br>
<br>
["-1": "negative numbers as strings in key"]<br>
<br>
<br>
Alex, why does getl return a list of (property-value . property-name)<br>
and not a list of (property-name . property-value)?<br>
<br>
Cheers,<br>
<font color="#888888"><br>
Tomas<br>
</font><div><div></div><div class="Wj3C7c">--<br>
UNSUBSCRIBE: mailto:<a
href="mailto:picolisp@software-lab.de";>picolisp@software-lab.de</a>?subject=Unsubscribe<br>
</div></div></blockquote></div><br></div>
------=_Part_44266_24757689.1219373194560--
--
UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
-------
