GITFNS gets prc information in JSON form #1689
Conversation
prc uses the simple JSON parser in the new lispusers file JSON to convert the json string into a lisp data structure. Maybe the commonlisp package YASON that Matt looked at would be more general, but perhaps also requires more understanding. With this change, drafts should be marked with D, approves should be marked with A.
There was a problem hiding this comment.
I'm delighted to see an attempt at a JSON parser but uncomfortable with the chosen representation in Lisp of the JSON results.
In Lisp, JSON values can be represented as Lisp objects. Here's a brief overview of how JSON is represented in Lisp:
I asked "how do people represent JSON in LIsp" and got:
- Keywords: JSON uses three keywords:
true,null,false. In Lisp,trueis represented by the symbolt. By default, the remaining two are represented, respectively, by the symbols:nulland:false¹. - Numbers: JSON only has floating-point numbers. They can represent both Lisp integers and Lisp floating-point numbers¹.
- Strings: JSON strings are always Unicode strings encoded in UTF-8. Lisp strings can contain non-Unicode characters¹.
- Arrays: JSON has only one sequence type, the array. JSON arrays are represented using Lisp vectors¹.
- Objects: JSON has only one map type, the object. JSON objects are represented using Lisp hashtables, alists or plists¹.
Please note that while any JSON value can be converted to a Lisp object, the reverse is not always true¹. If some Lisp object can't be represented in JSON, the serialization functions will signal an error of type wrong-type-argument¹.
There are libraries like YASON for Common Lisp and GNU Emacs Lisp Reference Manual for Emacs Lisp that provide functions to convert between Lisp objects and JSON values¹². These libraries also handle parsing and generating JSON values¹².
Source: Conversation with Bing, 4/30/2024
(1) Parsing JSON (GNU Emacs Lisp Reference Manual). https://www.gnu.org/software/emacs/manual/html_node/elisp/Parsing-JSON.html.
(2) YASON - A JSON encoder/decoder for Common Lisp - GitHub Pages. http://phmarek.github.io/yason/.
(3) Parsing and Generating JSON Values - Elisp - W3cubDocs. https://docs.w3cub.com/elisp/parsing-json.html.
(4) JSON and Lisp-Like Queries | Skirtle's Den. https://www.skirtlesden.com/articles/json-lisp-queries.
|
Just to be clear... In the Pull Request |
|
If someone wants to take this on and figure out all the interactions, that would be a good thing. This seems to be enough for this particular purpose (if in fact, when you load it, you see D’s for drafts and A’s for approved).
… On Apr 30, 2024, at 4:08 PM, Larry Masinter ***@***.***> wrote:
@masinter commented on this pull request.
I'm delighted to see an attempt at a JSON parser but uncomfortable with the chosen representation in Lisp of the JSON results.
In Lisp, JSON values can be represented as Lisp objects. Here's a brief overview of how JSON is represented in Lisp:
I asked "how do people represent JSON in LIsp" and got:
Keywords: JSON uses three keywords: true, null, false. In Lisp, true is represented by the symbol t. By default, the remaining two are represented, respectively, by the symbols :null and :false¹.
Numbers: JSON only has floating-point numbers. They can represent both Lisp integers and Lisp floating-point numbers¹.
Strings: JSON strings are always Unicode strings encoded in UTF-8. Lisp strings can contain non-Unicode characters¹.
Arrays: JSON has only one sequence type, the array. JSON arrays are represented using Lisp vectors¹.
Objects: JSON has only one map type, the object. JSON objects are represented using Lisp hashtables, alists or plists¹.
Please note that while any JSON value can be converted to a Lisp object, the reverse is not always true¹. If some Lisp object can't be represented in JSON, the serialization functions will signal an error of type wrong-type-argument¹.
There are libraries like YASON for Common Lisp and GNU Emacs Lisp Reference Manual for Emacs Lisp that provide functions to convert between Lisp objects and JSON values¹². These libraries also handle parsing and generating JSON values¹².
Source: Conversation with Bing, 4/30/2024
(1 <https://www.gnu.org/software/emacs/manual/html_node/elisp/Parsing-JSON.html>) Parsing JSON (GNU Emacs Lisp Reference Manual). https://www.gnu.org/software/emacs/manual/html_node/elisp/Parsing-JSON.html.
(2) YASON - A JSON encoder/decoder for Common Lisp - GitHub Pages. http://phmarek.github.io/yason/.
(3) Parsing and Generating JSON Values - Elisp - W3cubDocs. https://docs.w3cub.com/elisp/parsing-json.html.
(4) JSON and Lisp-Like Queries | Skirtle's Den. https://www.skirtlesden.com/articles/json-lisp-queries.
—
Reply to this email directly, view it on GitHub <#1689 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJO2JU3DNEVVHHY35TLZAAQAVAVCNFSM6AAAAABHBDS36GVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDAMZSG43DQNBWGQ>.
You are receiving this because you authored the thread.
|
|
The UTF-8 encoding comes for free with our Unicode mappings and UTF-8 external format. The externalformat of the GITFNS command stream is provided by (SYSTEM-EXTERNALFORMAT), which has some UNIX-GETENV heuristics to guess whether UTF-8 is correct. If UTF-8 is specified in the JSON standard, then the low-level GITFNS functions should just assert it, at least when --json is specified in the call. Should that be done?
|
|
I'm tempted to approve #1638 rather than bake in the design choices in JSON (because I think we need JSON to do modern APIs). I think property lists are marginally better than alists for representing JSON objects. We may find sooner than expected the results of queries needing Emoji support. |
|
I suppose that would be more similar to the JSON layout, where the attributes are separated from their values by colons, and pairs are strong together in a flat sequence separated by commas.
On the other hand, the Lisp display of a property list is not as easy to interpret. Sedit and prettyprint don’t know how to recognize and format a property list in an intuitive way, but they do understand how to deal with alists.
… On May 1, 2024, at 2:24 PM, Larry Masinter ***@***.***> wrote:
I'm tempted to approve #1638 <#1638> rather than bake in the design choices in JSON (because I think we need JSON to do modern APIs).
I think property lists are marginally better than alists for representing JSON objects.
We may find sooner than expected the results of queries needing Emoji support.
I was thinking about mapping unicode characters that have no XCCS equivalent into the private use area, and then replacing the character with a "Unicode image object" which would display properly and might also map back to the original unicode when exporting.
—
Reply to this email directly, view it on GitHub <#1689 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJIKAOXTGPA7BLR433TZAFMSXAVCNFSM6AAAAABHBDS36GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBZGE3DGMRTGI>.
You are receiving this because you authored the thread.
|
|
Changing this to alist instead of plist is really easy. It wouldn't take me long to do that.
Would that be more comfortable?
Sent via the Samsung Galaxy S22+ 5G, an AT&T 5G smartphone
Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: rmkaplan ***@***.***>
Sent: Wednesday, May 1, 2024 3:17:14 PM
To: Interlisp/medley ***@***.***>
Cc: Matt Heffron ***@***.***>; Comment ***@***.***>
Subject: Re: [Interlisp/medley] GITFNS gets prc information in JSON form (PR #1689)
I suppose that would be more similar to the JSON layout, where the attributes are separated from their values by colons, and pairs are strong together in a flat sequence separated by commas.
On the other hand, the Lisp display of a property list is not as easy to interpret. Sedit and prettyprint don’t know how to recognize and format a property list in an intuitive way, but they do understand how to deal with alists.
On May 1, 2024, at 2:24 PM, Larry Masinter ***@***.***> wrote:
I'm tempted to approve #1638 <#1638> rather than bake in the design choices in JSON (because I think we need JSON to do modern APIs).
I think property lists are marginally better than alists for representing JSON objects.
We may find sooner than expected the results of queries needing Emoji support.
I was thinking about mapping unicode characters that have no XCCS equivalent into the private use area, and then replacing the character with a "Unicode image object" which would display properly and might also map back to the original unicode when exporting.
—
Reply to this email directly, view it on GitHub <#1689 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJIKAOXTGPA7BLR433TZAFMSXAVCNFSM6AAAAABHBDS36GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBZGE3DGMRTGI>.
You are receiving this because you authored the thread.
—
Reply to this email directly, view it on GitHub<#1689 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AB7BB4RDSYQQISL5F2AU5D3ZAFSWVAVCNFSM6AAAAABHBDS36GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBZGIZDIOJRHA>.
You are receiving this because you commented.Message ID: ***@***.***>
|
|
If this works for other people (prc menu's have a D for drafts, A for approved), then let's approve this even with my simple seems-to-work-at-least-in-this-case JSON parser. We can easily switch over later if we settle on one of the commonlisp packages. I want to get this out of the way, so I can push some other changes I have been making to the GITFNS prc interface, with better management of the prc menu. |
|
keyword plists are better because
|
|
Are the odd error cases in the RPLACD opcode? Is there something substantially different between LISTPUT and PUTASSOC ?
I don’t think there is a difference in APPEND.
… On May 1, 2024, at 10:58 PM, Larry Masinter ***@***.***> wrote:
keyword plists are better because
*cdr-coding makes rplacd more complicated,
fewer odd error cases
are everywhere in CL for keyword arguments
can be copied with APPEND
—
Reply to this email directly, view it on GitHub <#1689 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJMXWSNERXO4GXV5TK3ZAHIYHAVCNFSM6AAAAABHBDS36GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBZGY2DANJYGU>.
You are receiving this because you authored the thread.
|
|
I'd hope that the RPLACD opcode does not have implementation errors - yes, it's "more complicated", but are we worrying about the complexity of the implementation that is now complete? |
|
I think it already maps unmapped characters into a private user area, and displays them as black boxes. The effort to figure out how to render unmapped codes would be better spent getting proper fonts so we could get rid of XCCS internally.
The lingering problem, after we have made that transition, is the fact that our characters are SMALLPs so higher Unicode characters cannot be represented. We could extend the string/atom format to allow FATFAT characters…but all the character EQ tests in the system would be wrong. I suppose we could then use the private area to map down a limited number of such large codes to hide that problem, if we cared.
… On May 1, 2024, at 2:24 PM, Larry Masinter ***@***.***> wrote:
I'm tempted to approve #1638 <#1638> rather than bake in the design choices in JSON (because I think we need JSON to do modern APIs).
I think property lists are marginally better than alists for representing JSON objects.
We may find sooner than expected the results of queries needing Emoji support.
I was thinking about mapping unicode characters that have no XCCS equivalent into the private use area, and then replacing the character with a "Unicode image object" which would display properly and might also map back to the original unicode when exporting.
—
Reply to this email directly, view it on GitHub <#1689 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJIKAOXTGPA7BLR433TZAFMSXAVCNFSM6AAAAABHBDS36GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBZGE3DGMRTGI>.
You are receiving this because you authored the thread.
|
|
@MattHeffron , I've lost track of where you put your double-quote updates to GITFNS. If you point me to it, I'll merge those changes into my current version. |
|
@rmkaplan In Pull Request #1693 -- Branch mth8--GITFNS-quote-branch-names-in-git-commands |
|
Superseded by #1695 |
prc uses the simple JSON parser in the new lispusers file JSON to convert the json string into a lisp data structure. Maybe the commonlisp package YASON that Matt looked at would be more general, but perhaps also requires more understanding.
With this change, drafts should be marked with D, approves should be marked with A.