rishi/scryer-prolog
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Restructuring and improving documentation.

Browse Source
This commit is contained in:
panasenco
2021-04-28 22:22:00 -07:00
parent cb07074246
commit dfbf291725
5 changed files with 184 additions and 131 deletions
Download Patch File Download Diff File Expand all files Collapse all files

257
src/lib/serialization/json.pl Normal file
View File

@@ -0,0 +1,257 @@
/* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Written Apr 2021 by Aram Panasenco (panasenco@ucla.edu)
Part of Scryer Prolog.
`json_chars//1` can be used with [`phrase_from_file/2`](src/lib/pio.pl)
or [`phrase/2`](src/lib/dcgs.pl) to parse and generate [JSON](https://www.json.org/json-en.html).
BSD 3-Clause License
Copyright (c) 2021, Aram Panasenco
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice, this
list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
* Neither the name of the copyright holder nor the names of its
contributors may be used to endorse or promote products derived from
this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
:- module(json, [
json_chars//1
]).
:- use_module(library(dcgs)).
:- use_module(library(dif)).
:- use_module(library(lists)).
:- use_module(library(serialization/abnf)).
/* The DCGs are written to match the McKeeman form presented on the right side of https://www.json.org/json-en.html
as closely as possible. Note that the names in the McKeeman form conflict with the pictures on the site. */
json_chars(Internal) --> json_element(Internal).
/* Because it's impossible to distinguish between an empty array [] and an empty string "", we distinguish between
different types of values based on their principal functor. The principal functors match the types defined in
the JSON Schema spec here: https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.6.1.1
EXCEPT we don't yet support the integer type. There are plans for more JSON Schema support in the near future. */
json_value(pairs(Pairs)) --> json_object(Pairs).
json_value(list(List)) --> json_array(List).
json_value(string(Chars)) --> json_string(Chars).
json_value(number(Number)) --> json_number(Number).
json_value(boolean(Bool)) --> json_boolean(Bool).
json_value(null) --> "null".
/* We pull json_boolean out into its own predicate in order to take advantage of first argument indexing and not leave
choice points. For more details, watch this video on decomposing arguments: https://youtu.be/FZLofckPu4A?t=1648 */
json_boolean(true) --> "true".
json_boolean(false) --> "false".
json_object([]) --> "{", json_ws, "}".
json_object([Pair|Pairs]) -->
"{",
json_members(Pairs, Pair),
"}".
/* `json_members//2` below is implemented with a lagged argument to take advantage of first argument indexing.
This is a pure performance-driven decision that doesn't affect the logic. The predicate could equivalently be
implementes as `json_members//1` below:
```
json_members([Key-Value, Pair2 | Pairs]) --> json_member(Key, Value), ",", json_members([Pair2 | Pairs]).
```
That's a logically equivalent and equally clean representation to the lagged argument. However, it leaves
choice points, while using the lagged argument doesn't. For more info, watch: https://youtu.be/FZLofckPu4A?t=1737
*/
json_members([], Key-Value) --> json_member(Key, Value).
json_members([NextPair|Pairs], Key-Value) -->
json_member(Key, Value),
",",
json_members(Pairs, NextPair).
json_member(string(Key), Value) --> json_ws, json_string(Key), json_ws, ":", json_element(Value).
json_array([]) --> "[", json_ws, "]".
json_array([Value|Values]) --> "[", json_elements(Values, Value), "]".
/* Also using a lagged argument with `json_elements//2` to take advantage of first-argument indexing */
json_elements([], Value) --> json_element(Value).
json_elements([NextValue|Values], Value) -->
json_element(Value),
",",
json_elements(Values, NextValue).
json_element(Value) --> json_ws, json_value(Value), json_ws.
json_string(Chars) --> "\"", json_characters(Chars), "\"".
json_characters("") --> "".
json_characters([Char|Chars]) --> json_character(Char), json_characters(Chars).
/* Note on variable instantiation checks (`var/1` and `nonvar/1`) used below and in Prolog in general.
Instantiation checks should never be used to change the logic of your program. Instead, they are one of
many tools to adjust the 'control' or 'search strategy' used by Prolog to execute the logic of your program.
For a general overview of the idea, read Bob Kowalski's "Algorithm = Logic + Control":
https://www.doc.ic.ac.uk/~rak/papers/algorithm%20=%20logic%20+%20control.pdf
For an introduction to search strategies in Prolog, read: https://www.metalevel.at/prolog/sorting#searching
It's tempting to use instantiation checks to be more strict while generating and more relaxed while parsing.
In fact, the early version of this library aimed to return exactly one result when generating. However, doing that
is **wrong** and leads to difficult-to-catch bugs. Instead, adjust the search strategy to return the most ideal
and strictest answer FIRST and then return less ideal answers on backtracking.
As an example, consider a string containing just the forward slash. The JSON standard recommends the forward slash
be escaped with a backslash, but allows it to not be escaped. Attempting to force stricter behavior with
instantiation checks can lead to this confusing mess:
```
phrase(json:json_characters("/"), External).
External = "\\/".
?- phrase(json:json_characters(Internal), "/").
Internal = "/"
; false.
?- phrase(json:json_characters("/"), "/").
false.
```
To avoid such bugs, never use instantiation checks to reduce the number of right answers, but rather to adjust
the *path* used to traverse those answers. */
escape_char('"', '"').
escape_char('\\', '\\').
escape_char('/', '/').
escape_char('\b', 'b').
escape_char('\f', 'f').
escape_char('\n', 'n').
escape_char('\r', 'r').
escape_char('\t', 't').
json_character(EscapeChar) -->
{ escape_char(EscapeChar, PrintChar) },
"\\",
[PrintChar].
json_character(PrintChar) -->
[PrintChar],
{ dif(PrintChar, '\\'),
dif(PrintChar, '"'),
char_code(PrintChar, PrintCharCode),
PrintCharCode >= 32 }.
json_character(EscapeChar) -->
"\\u",
json_hex(H1),
json_hex(H2),
json_hex(H3),
json_hex(H4),
{ ( nonvar(H1) ->
EscapeCharCode is H1 * 16^3 + H2 * 16^2 + H3 * 16 + H4,
char_code(EscapeChar, EscapeCharCode)
; char_code(EscapeChar, EscapeCharCode),
H1 is (EscapeCharCode // 16^3) mod 16,
H2 is (EscapeCharCode // 16^2) mod 16,
H3 is (EscapeCharCode // 16^1) mod 16,
H4 is (EscapeCharCode // 16^0) mod 16
) }.
json_hex(Hex) --> abnf_hexdig(Hex).
json_hex(10) --> "a".
json_hex(11) --> "b".
json_hex(12) --> "c".
json_hex(13) --> "d".
json_hex(14) --> "e".
json_hex(15) --> "f".
/* I can't think of any alternatives to using `number_chars/2` when generating, though this leads
to under-reporting of correct solutions. At least matching solutions unify when both are instantiated...
```
?- phrase(json:json_number(N), "123E2").
N = 12300
; false.
?- phrase(json:json_number(12300), Cs).
Cs = "12300".
?- phrase(json:json_number(12300), "123E2").
true
; false.
```
*/
parsing, [C] --> [C], { nonvar(C) }.
json_number(Number) -->
( parsing ->
json_sign_noplus(Sign),
json_integer(Integer),
json_fraction(Fraction),
json_exponent(Exponent),
{ ( Exponent >= 0 ->
Base = 10
; Base = 10.0
),
Number is Sign * (Integer + Fraction) * Base ^ Exponent }
; { number_chars(Number, NumberChars) },
NumberChars
).
json_integer(Digit) --> abnf_digit(Digit).
json_integer(TotalValue) -->
json_onenine(FirstDigit),
json_digits(RemainingValue, Power),
{ TotalValue is FirstDigit * 10 ^ (Power + 1) + RemainingValue }.
json_digits(Digit, 0) --> abnf_digit(Digit).
json_digits(Value, Power) -->
abnf_digit(FirstDigit),
json_digits(RemainingValue, NextPower),
{ Power is NextPower + 1,
Value is FirstDigit * 10^Power + RemainingValue }.
json_onenine(Digit) --> abnf_digit(Digit), { dif(Digit, 0) }.
json_fraction(0) --> "".
json_fraction(Fraction) -->
".",
json_digits(Value, Power),
{ Fraction is Value / 10.0 ^ (Power + 1) }.
json_exponent(0) --> "".
json_exponent(Exponent) -->
json_exponent_signifier,
json_sign(Sign),
json_digits(Value, _),
{ Exponent is Sign * Value }.
json_exponent_signifier --> "E".
json_exponent_signifier --> "e".
json_sign_noplus(1) --> "".
json_sign_noplus(-1) --> "-".
json_sign(Sign) --> json_sign_noplus(Sign).
json_sign(1) --> "+".
/* Make `json_ws/0` greedy when parsing, lazy when generating */
json_ws_empty --> "".
json_ws_nonempty --> " ".
json_ws_nonempty --> "\n".
json_ws_nonempty --> "\r".
json_ws_nonempty --> "\t".
json_ws_greedy --> json_ws_nonempty, json_ws_greedy.
json_ws_greedy --> json_ws_empty.
json_ws_lazy --> json_ws_empty.
json_ws_lazy --> json_ws_nonempty, json_ws_lazy.
json_ws -->
( parsing ->
json_ws_greedy
; json_ws_lazy
).