From 960e4410f76801356ebd42801c914b2910a302a7 Mon Sep 17 00:00:00 2001 From: EuAndreh Date: Mon, 18 Nov 2024 08:21:58 -0300 Subject: v0 migration to mkwb --- src/content/tils/2021/01/12/curl-awk-emails.adoc | 142 +++++++++++++++++++++ src/content/tils/2021/01/17/posix-shebang.adoc | 55 ++++++++ .../tils/2021/04/24/cl-generic-precedence.adoc | 137 ++++++++++++++++++++ src/content/tils/2021/04/24/clojure-autocurry.adoc | 135 ++++++++++++++++++++ src/content/tils/2021/04/24/scm-nif.adoc | 63 +++++++++ src/content/tils/2021/07/23/git-tls-gpg.adoc | 56 ++++++++ src/content/tils/2021/08/11/js-bigint-reviver.adoc | 100 +++++++++++++++ 7 files changed, 688 insertions(+) create mode 100644 src/content/tils/2021/01/12/curl-awk-emails.adoc create mode 100644 src/content/tils/2021/01/17/posix-shebang.adoc create mode 100644 src/content/tils/2021/04/24/cl-generic-precedence.adoc create mode 100644 src/content/tils/2021/04/24/clojure-autocurry.adoc create mode 100644 src/content/tils/2021/04/24/scm-nif.adoc create mode 100644 src/content/tils/2021/07/23/git-tls-gpg.adoc create mode 100644 src/content/tils/2021/08/11/js-bigint-reviver.adoc (limited to 'src/content/tils/2021') diff --git a/src/content/tils/2021/01/12/curl-awk-emails.adoc b/src/content/tils/2021/01/12/curl-awk-emails.adoc new file mode 100644 index 0000000..880ddf1 --- /dev/null +++ b/src/content/tils/2021/01/12/curl-awk-emails.adoc @@ -0,0 +1,142 @@ +--- + +title: 'Awk snippet: send email to multiple recipients with cURL' + +date: 2021-01-12 + +layout: post + +lang: en + +ref: awk-snippet-send-email-to-multiple-recipients-with-curl + +--- + +As I experiment with [Neomutt][neomutt], I wanted to keep being able to enqueue emails for sending later like my previous setup, so that I didn't rely on having an internet connection. + +My requirements for the `sendmail` command were: +1. store the email in a file, and send it later. +1. send from different addresses, using different SMTP servers; + +I couldn't find an MTA that could accomplish that, but I was able to quickly write a solution. + +The first part was the easiest: store the email in a file: + +```shell +# ~/.config/mutt/muttrc: +set sendmail=~/bin/enqueue-email.sh + +# ~/bin/enqueue-email.sh: +#!/bin/sh -eu + +cat - > "$HOME/mbsync/my-queued-emails/$(date -Is)" +``` + +Now that I had the email file store locally, I needed a program to send the email from the file, so that I could create a cronjob like: + +```shell +for f in ~/mbsync/my-queued-emails/*; do + ~/bin/dispatch-email.sh "$f" && rm "$f" +done +``` + +The `dispatch-email.sh` would have to look at the `From: ` header and decide which SMTP server to use. +As I [found out][curl-email] that [curl][curl] supports SMTP and is able to send emails, this is what I ended up with: + +```shell +#!/bin/sh -eu + +F="$1" + +rcpt="$(awk ' + match($0, /^(To|Cc|Bcc): (.*)$/, m) { + split(m[2], tos, ",") + for (i in tos) { + print "--mail-rcpt " tos[i] + } + } +' "$F")" + +if grep -qE '^From: .*$' "$F"; then + curl \ + -s \ + --url smtp://smtp.server1.org:587 \ + --ssl-reqd \ + --mail-from addr@server1.org \ + $rcpt \ + --user 'addr@server1.org:my-long-and-secure-passphrase' \ + --upload-file "$F" +elif grep -qE '^From: .*$' "$F"; then + curl \ + -s \ + --url smtp://smtp.server2.org:587 \ + --ssl-reqd \ + --mail-from addr@server2.org \ + $rcpt \ + --user 'addr@server2.org:my-long-and-secure-passphrase' \ + --upload-file "$F" +else + echo 'Bad "From: " address' + exit 1 +fi +``` + +Most of curl flags used are self-explanatory, except for `$rcpt`. + +curl connects to the SMTP server, but doesn't set the recipient address by looking at the message. +My solution was to generate the curl flags, store them in `$rcpt` and use it unquoted to leverage shell word splitting. + +To me, the most interesting part was building the `$rcpt` flags. +My first instinct was to try grep, but it couldn't print only matches in a regex. +As I started to turn towards sed, I envisioned needing something else to loop over the sed output, and I then moved to Awk. + +In the short Awk snippet, 3 things were new to me: the `match(...)`, `split(...)` and `for () {}`. +The only other function I have ever used was `gsub(...)`, but these new ones felt similar enough that I could almost guess their behaviour and arguments. +`match(...)` stores the matches of a regex on the given array positionally, and `split(...)` stores the chunks in the given array. + +I even did it incrementally: + +```shell +$ H='To: to@example.com, to2@example.com\nCc: cc@example.com, cc2@example.com\nBcc: bcc@example.com,bcc2@example.com\n' +$ printf "$H" | awk '/^To: .*$/ { print $0 }' +To: to@example.com, to2@example.com +$ printf "$H" | awk 'match($0, /^To: (.*)$/, m) { print m }' +awk: ligne de commande:1: (FILENAME=- FNR=1) fatal : tentative d'utilisation du tableau « m » dans un contexte scalaire +$ printf "$H" | awk 'match($0, /^To: (.*)$/, m) { print m[0] }' +To: to@example.com, to2@example.com +$ printf "$H" | awk 'match($0, /^To: (.*)$/, m) { print m[1] }' +to@example.com, to2@example.com +$ printf "$H" | awk 'match($0, /^To: (.*)$/, m) { split(m[1], tos, " "); print tos }' +awk: ligne de commande:1: (FILENAME=- FNR=1) fatal : tentative d'utilisation du tableau « tos » dans un contexte scalaire +$ printf "$H" | awk 'match($0, /^To: (.*)$/, m) { split(m[1], tos, " "); print tos[0] }' + +$ printf "$H" | awk 'match($0, /^To: (.*)$/, m) { split(m[1], tos, " "); print tos[1] }' +to@example.com, +$ printf "$H" | awk 'match($0, /^To: (.*)$/, m) { split(m[1], tos, " "); print tos[2] }' +to2@example.com +$ printf "$H" | awk 'match($0, /^To: (.*)$/, m) { split(m[1], tos, " "); print tos[3] }' + +``` + +(This isn't the verbatim interactive session, but a cleaned version to make it more readable.) + +At this point, I realized I needed a for loop over the `tos` array, and I moved the Awk snippet into the `~/bin/dispatch-email.sh`. +I liked the final thing: + +```awk +match($0, /^(To|Cc|Bcc): (.*)$/, m) { + split(m[2], tos, ",") + for (i in tos) { + print "--mail-rcpt " tos[i] + } +} +``` + +As I learn more about Awk, I feel that it is too undervalued, as many people turn to Perl or other programming languages when Awk suffices. +The advantage is pretty clear: writing programs that run on any POSIX system, without extra dependencies required. + +Coding to the standards is underrated. + +[neomutt]: https://neomutt.org/ +[curl-email]: https://blog.edmdesigner.com/send-email-from-linux-command-line/ +[curl]: https://curl.se/ diff --git a/src/content/tils/2021/01/17/posix-shebang.adoc b/src/content/tils/2021/01/17/posix-shebang.adoc new file mode 100644 index 0000000..5f5b897 --- /dev/null +++ b/src/content/tils/2021/01/17/posix-shebang.adoc @@ -0,0 +1,55 @@ += POSIX sh and shebangs + +date: 2021-01-17 + +layout: post + +lang: en + +ref: posix-sh-and-shebangs + +--- + +As I [keep moving][posix-awk-0] [towards POSIX][posix-awk-1], I'm on the process of migrating all my Bash scripts to POSIX sh. + +As I dropped `[[`, arrays and other Bashisms, I was left staring at the first line of every script, wondering what to do: what is the POSIX sh equivalent of `#!/usr/bin/env bash`? +I already knew that POSIX says nothing about shebangs, and that the portable way to call a POSIX sh script is `sh script.sh`, but I didn't know what to do with that first line. + +What I had previously was: +```shell +#!/usr/bin/env bash +set -Eeuo pipefail +cd "$(dirname "${BASH_SOURCE[0]}")" +``` + +Obviously, the `$BASH_SOURCE` would be gone, and I would have to adapt some of my scripts to not rely on the script location. +The `-E` and `-o pipefail` options were also gone, and would be replaced by nothing. + +I converted all of them to: +```shell +#!/bin/sh -eu +``` + +I moved the `-eu` options to the shebang line itself, striving for conciseness. +But as I changed callers from `./script.sh` to `sh script.sh`, things started to fail. +Some tests that should fail reported errors, but didn't return 1. + +My first reaction was to revert back to `./script.sh`, but the POSIX bug I caught is a strong strain, and when I went back to it, I figured that the callers were missing some flags. +Specifically, `sh -eu script.sh`. + +Then it clicked: when running with `sh script.sh`, the shebang line with the sh options is ignored, as it is a comment! + +Which means that the shebang most friendly with POSIX is: + +```shell +#!/bin/sh +set -eu +``` + +1. when running via `./script.sh`, if the system has an executable at `/bin/sh`, it will be used to run the script; +2. when running via `sh script.sh`, the sh options aren't ignored as previously. + +TIL. + +[posix-awk-0]: {% link _tils/2020-12-15-awk-snippet-shellcheck-all-scripts-in-a-repository.md %} +[posix-awk-1]: {% link _tils/2021-01-12-awk-snippet-send-email-to-multiple-recipients-with-curl.md %} diff --git a/src/content/tils/2021/04/24/cl-generic-precedence.adoc b/src/content/tils/2021/04/24/cl-generic-precedence.adoc new file mode 100644 index 0000000..8051232 --- /dev/null +++ b/src/content/tils/2021/04/24/cl-generic-precedence.adoc @@ -0,0 +1,137 @@ +--- + +title: Common Lisp argument precedence order parameterization of a generic function + +date: 2021-04-24 2 + +layout: post + +lang: en + +ref: common-lisp-argument-precedence-order-parameterization-of-a-generic-function + +--- + +When CLOS dispatches a method, it picks the most specific method definition to the argument list: + +```lisp + +* (defgeneric a-fn (x)) +# + +* (defmethod a-fn (x) :default-method) +# + +* (defmethod a-fn ((x number)) :a-number) +# + +* (defmethod a-fn ((x (eql 1))) :number-1) +# + +* (a-fn nil) +:DEFAULT-METHOD + +* (a-fn "1") +:DEFAULT-METHOD + +* (a-fn 0) +:A-NUMBER + +* (a-fn 1) +:NUMBER-1 +``` + +CLOS uses a similar logic when choosing the method from parent classes, when multiple ones are available: + +```lisp +* (defclass class-a () ()) + +# +* (defclass class-b () ()) + +# +* (defgeneric another-fn (obj)) + +# +* (defmethod another-fn ((obj class-a)) :class-a) +; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OBJ): +; Compiling Top-Level Form: + +# +* (defmethod another-fn ((obj class-b)) :class-b) +; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. OBJ): +; Compiling Top-Level Form: + +# +``` + +Given the above definitions, when inheriting from `class-a` and `class-b`, the order of inheritance matters: + +```lisp +* (defclass class-a-coming-first (class-a class-b) ()) +# + +* (defclass class-b-coming-first (class-b class-a) ()) +# + +* (another-fn (make-instance 'class-a-coming-first)) +:CLASS-A + +* (another-fn (make-instance 'class-b-coming-first)) +:CLASS-B +``` + +Combining the order of inheritance with generic functions with multiple arguments, CLOS has to make a choice of how to pick a method given two competing definitions, and its default strategy is prioritizing from left to right: + +```lisp +* (defgeneric yet-another-fn (obj1 obj2)) +# + +* (defmethod yet-another-fn ((obj1 class-a) obj2) :first-arg-specialized) +# + +* (defmethod yet-another-fn (obj1 (obj2 class-b)) :second-arg-specialized) +# + +* (yet-another-fn (make-instance 'class-a) (make-instance 'class-b)) +:FIRST-ARG-SPECIALIZED +``` + +CLOS has to make a choice between the first and the second definition of `yet-another-fn`, but its choice is just a heuristic. +What if we want the choice to be based on the second argument, instead of the first? + +For that, we use the `:argument-precedence-order` option when declaring a generic function: + +```lisp +* (defgeneric yet-another-fn (obj1 obj2) (:argument-precedence-order obj2 obj1)) +# + +* (yet-another-fn (make-instance 'class-a) (make-instance 'class-b)) +:SECOND-ARG-SPECIALIZED +``` + +I liked that the `:argument-precedence-order` option exists. +We shouldn't have to change the arguments from `(obj1 obj2)` to `(obj2 obj1)` just to make CLOS pick the method that we want. +We can configure its default behaviour if desired, and keep the order of arguments however it best fits the generic function. + +## Comparison with Clojure + +Clojure has an equivalent, when using `defmulti`. + +Since when declaring a multi-method with `defmulti` we must define the dispatch function, Clojure uses it to pick the method definition. +Since the dispatch function is required, there is no need for a default behaviour, such as left-to-right. + +## Conclusion + +Making the argument precedence order configurable for generic functions but not for class definitions makes a lot of sense. + +When declaring a class, we can choose the precedence order, and that is about it. +But when defining a generic function, the order of arguments is more important to the function semantics, and the argument precedence being left-to-right is just the default behaviour. + +One shouldn't change the order of arguments of a generic function for the sake of tailoring it to the CLOS priority ranking algorithm, but doing it for a class definition is just fine. + +TIL. + +## References + +1. [Object-Oriented Programming in Common Lisp: A Programmer's Guide to CLOS](https://en.wikipedia.org/wiki/Object-Oriented_Programming_in_Common_Lisp), by Sonja E. Keene diff --git a/src/content/tils/2021/04/24/clojure-autocurry.adoc b/src/content/tils/2021/04/24/clojure-autocurry.adoc new file mode 100644 index 0000000..c1e277f --- /dev/null +++ b/src/content/tils/2021/04/24/clojure-autocurry.adoc @@ -0,0 +1,135 @@ +--- + +title: Clojure auto curry + +date: 2021-04-24 1 + +updated_at: 2021-04-27 + +layout: post + +lang: en + +ref: clojure-auto-curry + +--- + +Here's a simple macro defined by [Loretta He][lorettahe] to create Clojure functions that are curried on all arguments, relying on Clojure's multi-arity support: + +```clojure +(defmacro defcurry + [name args & body] + (let [partials (map (fn [n] + `(~(subvec args 0 n) (partial ~name ~@(take n args)))) + (range 1 (count args)))] + `(defn ~name + (~args ~@body) + ~@partials))) +``` + +A naive `add` definition, alongside its usage and macroexpansion: + +```clojure +user=> (defcurry add + [a b c d e] + (+ 1 2 3 4 5)) +#'user/add + +user=> (add 1) +#object[clojure.core$partial$fn__5857 0x2c708440 "clojure.core$partial$fn__5857@2c708440"] + +user=> (add 1 2 3 4) +#object[clojure.core$partial$fn__5863 0xf4c0e4e "clojure.core$partial$fn__5863@f4c0e4e"] + +user=> ((add 1) 2 3 4 5) +15 + +user=> (((add 1) 2 3) 4 5) +15 + +user=> (use 'clojure.pprint) +nil + +user=> (pprint + (macroexpand + '(defcurry add + [a b c d e] + (+ 1 2 3 4 5)))) +(def + add + (clojure.core/fn + ([a b c d e] (+ 1 2 3 4 5)) + ([a] (clojure.core/partial add a)) + ([a b] (clojure.core/partial add a b)) + ([a b c] (clojure.core/partial add a b c)) + ([a b c d] (clojure.core/partial add a b c d)))) +nil +``` + +This simplistic `defcurry` definition doesn't support optional parameters, multi-arity, `&` rest arguments, docstrings, etc., but it could certainly evolve to do so. + +I like how `defcurry` is so short, and abdicates the responsability of doing the multi-arity logic to Clojure's built-in multi-arity support. +Simple and elegant. + +Same Clojure as before, now with auto-currying via macros. + +[lorettahe]: http://lorettahe.github.io/clojure/2016/09/22/clojure-auto-curry + +## Comparison with Common Lisp + +My attempt at writing an equivalent for Common Lisp gives me: + +```lisp +(defun partial (fn &rest args) + (lambda (&rest args2) + (apply fn (append args args2)))) + +(defun curry-n (n func) + (cond ((< n 0) (error "Too many arguments")) + ((zerop n) (funcall func)) + (t (lambda (&rest rest) + (curry-n (- n (length rest)) + (apply #'partial func rest)))))) + +(defmacro defcurry (name args &body body) + `(defun ,name (&rest rest) + (let ((func (lambda ,args ,@body))) + (curry-n (- ,(length args) (length rest)) + (apply #'partial func rest))))) +``` + +Without built-in multi-arity support, we have to do more work, like tracking the number of arguments consumed so far. +We also have to write `#'partial` ourselves. +That is, without dependending on any library, sticking to ANSI Common Lisp. + +The usage is pretty similar: + +```lisp +* (defcurry add (a b c d e) + (+ a b c d e)) +ADD + +* (add 1) +# + +* (funcall (add 1) 2 3 4) +# + +* (funcall (add 1) 2 3 4 5) +15 + +* (funcall (funcall (add 1) 2 3) 4 5) +15 + +* (macroexpand-1 + '(defcurry add (a b c d e) + (+ a b c d e))) +(DEFUN ADD (&REST REST) + (LET ((FUNC (LAMBDA (A B C D E) (+ A B C D E)))) + (CURRY-N (- 5 (LENGTH REST)) (APPLY #'PARTIAL FUNC REST)))) +T +``` + +This also require `funcall`s, since we return a `lambda` that doesn't live in the function namespace. + +Like the Clojure one, it doesn't support optional parameters, `&rest` rest arguments, docstrings, etc., but it also could evolve to do so. diff --git a/src/content/tils/2021/04/24/scm-nif.adoc b/src/content/tils/2021/04/24/scm-nif.adoc new file mode 100644 index 0000000..f53451b --- /dev/null +++ b/src/content/tils/2021/04/24/scm-nif.adoc @@ -0,0 +1,63 @@ +--- + +title: Three-way conditional for number signs on Lisp + +date: 2021-04-24 3 + +updated_at: 2021-08-14 + +layout: post + +lang: en + +ref: three-way-conditional-for-number-signs-on-lisp + +--- + +A useful macro from Paul Graham's [On Lisp][on-lisp] book: + +```lisp +(defmacro nif (expr pos zero neg) + (let ((g (gensym))) + `(let ((,g ,expr)) + (cond ((plusp ,g) ,pos) + ((zerop ,g) ,zero) + (t ,neg))))) +``` + +After I looked at this macro, I started seeing opportunities to using it in many places, and yet I didn't see anyone else using it. + +The latest example I can think of is section 1.3.3 of [Structure and Interpretation of Computer Programs][sicp], which I was reading recently: + +```scheme +(define (search f neg-point pos-point) + (let ((midpoint (average neg-point pos-point))) + (if (close-enough? neg-point post-point) + midpoint + (let ((test-value (f midpoint))) + (cond ((positive? test-value) + (search f neg-point midpoint)) + ((negative? test-value) + (search f midpoint pos-point)) + (else midpoint)))))) +``` + +Not that the book should introduce such macro this early, but I couldn't avoid feeling bothered by not using the `nif` macro, which could even remove the need for the intermediate `test-value` variable: + +```scheme +(define (search f neg-point pos-point) + (let ((midpoint (average neg-point pos-point))) + (if (close-enough? neg-point post-point) + midpoint + (nif (f midpoint) + (search f neg-point midpoint) + (midpoint) + (search f midpoint pos-point))))) +``` + +It also avoids `cond`'s extra clunky parentheses for grouping, which is unnecessary but built-in. + +As a macro, I personally feel it tilts the balance towards expressivenes despite its extra cognitive load toll. + +[on-lisp]: http://www.paulgraham.com/onlisptext.html +[sicp]: https://mitpress.mit.edu/sites/default/files/sicp/index.html diff --git a/src/content/tils/2021/07/23/git-tls-gpg.adoc b/src/content/tils/2021/07/23/git-tls-gpg.adoc new file mode 100644 index 0000000..fd42c1c --- /dev/null +++ b/src/content/tils/2021/07/23/git-tls-gpg.adoc @@ -0,0 +1,56 @@ +--- + +title: GPG verification of Git repositories without TLS + +date: 2021-07-23 + +layout: post + +lang: en + +ref: gpg-verification-of-git-repositories-without-tls + +--- + +For online Git repositories that use the [Git Protocol] for serving code, you +can can use GPG to handle authentication, if you have the committer's public +key. + +Here's how I'd verify that I've cloned an authentic version of +[remembering][remembering][^not-available]: + +[^not-available]: Funnily enough, not available anymore via the Git Protocol, now only with HTTPS. + +```shell +$ wget -qO- https://euandre.org/public.asc | gpg --import - +gpg: clef 81F90EC3CD356060 : « EuAndreh  » n'est pas modifiée +gpg: Quantité totale traitée : 1 +gpg: non modifiées : 1 +$ pushd `mktemp -d` +$ git clone git://euandreh.xyz/remembering . +$ git verify-commit HEAD +gpg: Signature faite le dim. 27 juin 2021 16:50:21 -03 +gpg: avec la clef RSA 5BDAE9B8B2F6C6BCBB0D6CE581F90EC3CD356060 +gpg: Bonne signature de « EuAndreh  » [ultime] +``` + +On the first line we import the public key (funnily enough, available via +HTTPS), and after cloning the code via the insecure `git://` protocol, we use +`git verify-commit` to check the signature. + +The verification is successful, and we can see that the public key from the +signature matches the fingerprint of the imported one. However +`git verify-commit` doesn't have an option to check which public key you want +to verify the commit against. Which means that if a MITM attack happens, the +attacker could very easily serve a malicious repository with signed commits, +and you'd have to verify the public key by yourself. That would need to happen +for subsequent fetches, too. + +Even though this is possible, it is not very convenient, and certainly very +brittle. Despite the fact that the Git Protocol is much faster, it being harder +to make secure is a big downside. + + + +[Git Protocol]: https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols#_the_git_protocol +[remembering]: https://euandreh.xyz/remembering/ diff --git a/src/content/tils/2021/08/11/js-bigint-reviver.adoc b/src/content/tils/2021/08/11/js-bigint-reviver.adoc new file mode 100644 index 0000000..d71174d --- /dev/null +++ b/src/content/tils/2021/08/11/js-bigint-reviver.adoc @@ -0,0 +1,100 @@ +--- + +title: Encoding and decoding JavaScript BigInt values with reviver + +date: 2021-08-11 + +updated_at: 2021-08-13 + +layout: post + +lang: en + +ref: encoding-and-decoding-javascript-bigint-values-with-reviver + +--- + +`JSON.parse()` accepts a second parameter: a [`reviver()` function][reviver]. +It is a function that can be used to transform the `JSON` values as they're +being parsed. + +[reviver]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse#using_the_reviver_parameter + +As it turns out, when combined with JavaScript's [`BigInt`] type, you can parse +and encode JavaScript `BigInt` numbers via JSON: + +[`BigInt`]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt + +```javascript +const bigIntReviver = (_, value) => + typeof value === "string" && value.match(/^-?[0-9]+n$/) + ? BigInt(value.slice(0, value.length - 1)) + : value; +``` + +I chose to interpret strings that contains only numbers and an ending `n` suffix +as `BigInt` values, similar to how JavaScript interprets `123` (a number) +differently from `123n` (a `bigint`); + +We do those checks before constructing the `BigInt` to avoid throwing needless +exceptions and catching them on the parsing function, as this could easily +become a bottleneck when parsing large JSON values. + +In order to do the full roundtrip, we now only need the `toJSON()` counterpart: + +```javascript +BigInt.prototype.toJSON = function() { + return this.toString() + "n"; +}; +``` + +With both `bigIntReviver` and `toJSON` defined, we can now successfully parse +and encode JavaScript objects with `BigInt` values transparently: + +```javascript +const s = `[ + null, + true, + false, + -1, + 3.14, + "a string", + { "a-number": "-123" }, + { "a-bigint": "-123n" } +]`; + +const parsed = JSON.parse(s, bigIntReviver); +const s2 = JSON.stringify(parsed); + +console.log(parsed); +console.log(s2); + +console.log(typeof parsed[6]["a-number"]) +console.log(typeof parsed[7]["a-bigint"]) +``` + +The output of the above is: + +``` +[ + null, + true, + false, + -1, + 3.14, + 'a string', + { 'a-number': '-123' }, + { 'a-bigint': -123n } +] +[null,true,false,-1,3.14,"a string",{"a-number":"-123"},{"a-bigint":"-123n"}] +string +bigint +``` + +If you're on a web browser, you can probably try copying and pasting the above +code on the console right now, as is. + +Even though [`JSON`] doesn't include `BigInt` number, encoding and decoding them +as strings is quite trivial on JavaScript. + +[`JSON`]: https://datatracker.ietf.org/doc/html/rfc8259 -- cgit v1.2.3