Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - pkoppstein

#1
Anything else we might add? / JSON support
August 02, 2013, 09:53:10 PM
This is an enhancement request regarding support for JSON.  In brief, I would like newlisp to support a variant of json-parse that preserves the JSON/Javascript distinction between objects and arrays.



Apart from the intrinsic value of preserving the duality, another consideration is invertibility.  In other programming languages that have a "fromJSON" function, there is typically a converse (quasi-invertible) function for mapping back to JSON.



(For example: Javascript has JSON.stringify and JSON.parse; PHP has json_encode and json_decode; python has json.loads and json.dumps; R has fromJSON and toJSON, etc. )



Currently, json-parse cannot have such a quasi-invertible counterpart because it maps both JSON objects and arrays to newlisp lists. For example:



> (set 'a (json-parse [text][["a",2]][/text] ))

(("a" 2))

> (set 'o (json-parse [text]{"a":2}[/text] ))

(("a" 2))



> (= a o)

true



Since newlisp does have arrays, one option would be to map JSON arrays to newlisp arrays. Perhaps there are better options, but this is the most obvious one to me.



In any case, one important point is that maintaining the JSON duality can be accomplished without causing backward-compatibility issues, since json-parse does not currently take a second argument.



That is, (json-parse STRING true) could preserve the duality.



Thanks.
#2
Some good news: after I switched from the "homebrew" version of newlisp to the "official" (newlisp.org) version, the unexplained problems went away.  Notice in particular the difference in banners:



homebrew: newLISP v.10.5.3 64-bit on OSX IPv4/6 UTF-8, options: newlisp -h

official: newLISP v.10.5.3 64-bit on OSX IPv4/6 UTF-8 libffi, options: newlisp -h



That is, the homebrew version is missing "libffi".



Interestingly, the "official" version is not so fussy about the difference between "long" and "int", e.g.



 $ /usr/bin/newlisp

newLISP v.10.5.3 64-bit on OSX IPv4/6 UTF-8 libffi, options: newlisp -h



> (import "libc.dylib" "printf" "int" "char*" "double" "char*" "int" "char")

printf@7FFF92EAD222

> (printf "%g %s %d %cn" 1.23 "hello" 999 65)

1.23 hello 999 A

17

>



In light of all these complications, it seems to me that the newlisp documentation about the C-interface could be improved by pointing out its limitations with respect to printf and portability. Perhaps the following statement in the documentation should also be clarified:



"Programs written with extended import API will run without change on 32-bit and 64-bit newLISP and libraries."



Thanks for your patience.
#3
Thank you for your responses, but please note:



1) using the "extended syntax" also does not work in the Mac environment I am using (see below);

2) even the fixed-signature "atof" does not work properly, as is illustrated below as well.



Anyway, since "printf" is "polymorphic", it would seem there is no possibility of importing it in all its generality. If that's the case, then it seems to me the documentation should mention this limitation rather than giving "printf" as an example.



# The documentation says that the return type should be specified first, so these examples do so,

# but I have also tried other variations.



$ newlisp

newLISP v.10.5.3 64-bit on OSX IPv4/6 UTF-8, options: newlisp -h



> (import "libc.dylib" "printf" "int" "double")

printf@7FFF92EAD222

> (printf "%gn" 1.23)

4.30659e-314

13

>



$ newlisp

newLISP v.10.5.3 64-bit on OSX IPv4/6 UTF-8, options: newlisp -h



> (import "libc.dylib" "printf" "int" "double" "char*" "int" "char")

printf@7FFF92EAD222

> (printf "%g %s %d %cn" 1.23 "hello" 999 65)

Segmentation fault: 11

$



$ newlisp

newLISP v.10.5.3 64-bit on OSX IPv4/6 UTF-8, options: newlisp -h



> (import "libc.dylib" "atof" "double" "char*")

atof@7FFF92E72C8C

> (atof "1.23")

3

>
#4
$ newlisp

newLISP v.10.5.3 64-bit on OSX IPv4/6 UTF-8, options: newlisp -h



> (import "libc.dylib" "printf")

printf@7FFF92EAD222

> (printf "%s %d" "hola" 123)    

hola 1238

> (printf "%s %d %cn" "hello" 999 65)

hello 999 A

12

> (printf "%g" 1.2)

4.35711e-31412

> (printf "%g %s %d %cn" 1.23 "hello" 999 65)

Segmentation fault: 11

$



# I couldn't find a better "Forum" in which to file this bug report.  Sorry.