From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id yGc1Dg5y22OXxQAAbAwnHQ (envelope-from ) for ; Thu, 02 Feb 2023 09:19:26 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id EElNDg5y22OUBgEA9RJhRA (envelope-from ) for ; Thu, 02 Feb 2023 09:19:26 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id D6CC53F6FF for ; Thu, 2 Feb 2023 09:19:25 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pNUoH-0002XK-U0; Thu, 02 Feb 2023 03:19:09 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pNUoB-0002V1-Nz for guix-patches@gnu.org; Thu, 02 Feb 2023 03:19:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pNUoB-0008N9-EV for guix-patches@gnu.org; Thu, 02 Feb 2023 03:19:03 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pNUoB-0003QS-85 for guix-patches@gnu.org; Thu, 02 Feb 2023 03:19:03 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#61214] [PATCH guix-artwork] website: posts: Add Dissecting Guix, Part 2: The Store Monad. References: <20230201172821.3072-1-paren@disroot.org> Resent-From: Simon Tournier Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 02 Feb 2023 08:19:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61214 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: 61214@debbugs.gnu.org Cc: "\(" X-Debbugs-Original-To: "( via Guix-patches via" , 61214@debbugs.gnu.org Received: via spool by 61214-submit@debbugs.gnu.org id=B61214.167532589913084 (code B ref 61214); Thu, 02 Feb 2023 08:19:03 +0000 Received: (at 61214) by debbugs.gnu.org; 2 Feb 2023 08:18:19 +0000 Received: from localhost ([127.0.0.1]:60631 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pNUnR-0003Ou-VE for submit@debbugs.gnu.org; Thu, 02 Feb 2023 03:18:19 -0500 Received: from mail-wm1-f51.google.com ([209.85.128.51]:53219) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pNUnP-0003OT-8Q for 61214@debbugs.gnu.org; Thu, 02 Feb 2023 03:18:16 -0500 Received: by mail-wm1-f51.google.com with SMTP id k16so740050wms.2 for <61214@debbugs.gnu.org>; Thu, 02 Feb 2023 00:18:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=48jKcPMndQI0D7ZVGsI7FNZtsvOQgZDPcxxbIAvEUGc=; b=M7LXLu4MKrle4hSJ+ZahxSw+9gSqjZis4aZ9WIcRJG0qoH/7EuaY/erIsVi7i0uHYh gcT2QzHXShmCJiDvPHq/BYYHwiPFddL7eolGQavHato4Y+bpJQUtVouZSLOUaRyQemTB fviNgdsOwsEt6A+i71YbSYN0i7iBtY/I5l3RDgEzVE9RSG4c2A8KyRlRW8QII1Msk2OL pmBeLyL5XCdj89LYI8LH273dDaIiVLTHINQUX9eOIvSMmQB3V4/Np8gzavgM7FCC03x2 9wWKyimGcZ0BkyUSTc/ZEjRwyzGgKdROeJ4wz81IWrmL6bshi+MjRAdG11P7muBa7NZJ RzNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=48jKcPMndQI0D7ZVGsI7FNZtsvOQgZDPcxxbIAvEUGc=; b=oHsfiHCi5cS3HVEWe2c+IQdBJeziZ7H+8tsYqaedi+l0y1qsNr3FTIopbnzCyQJAYt 25D08QUmHb6dM19cdA6WNHDfwBE2ULOBR0phJfb+RyL7u4k2QRg4g/ZA1Dig1dkhsn6h hKs6HyiZfL8yVCyFrAN8yszQZ7y4szwWA5nge35aCVphEdjYoErYYnYABCybLWe/+mRu r1mf+2oPhM5PAv9CvWIPLia0BEgeLu02vbQ7kzmZcBhH4Y/3TurhvIMuSlMU/XrXnzux g91Hdts2jAhwtyBUZCsnIkmuqr9e4JvsTc4N88wzc3885Qgy8yvutbiBPe9dDjSZ7rak CyKA== X-Gm-Message-State: AO0yUKWhh1RY9vcvNbcjR+peBEyiWDezyasoaTDigfOYJOXgrybPLfRu fdyneP0ljHETw5VmZg4Ax24i4LyUZMAMGQ== X-Google-Smtp-Source: AK7set+3no+LVUJQ2NTBu+ydZfk0zI9ZpC6JeXcx1TfhDSWyWrLb8zX4jUpvhwOY2ZEpaivPluNVaA== X-Received: by 2002:a05:600c:43c4:b0:3dc:de85:4fed with SMTP id f4-20020a05600c43c400b003dcde854fedmr4454385wmn.0.1675325889504; Thu, 02 Feb 2023 00:18:09 -0800 (PST) Received: from lili ([188.44.71.158]) by smtp.gmail.com with ESMTPSA id i40-20020a05600c4b2800b003dc42d48defsm3734547wmp.6.2023.02.02.00.18.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Feb 2023 00:18:09 -0800 (PST) From: Simon Tournier In-Reply-To: <20230201172821.3072-1-paren@disroot.org> Date: Thu, 02 Feb 2023 09:17:54 +0100 Message-ID: <86wn50tr9p.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: guix-patches-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN ARC-Seal: i=1; s=key1; d=yhetil.org; t=1675325966; a=rsa-sha256; cv=none; b=MzdEtdi2frS6MbZ9+7RZC/LPIsgSqMwkuubCgrdrQMcpVqcORccOh7XT1zhxaUtzdVZK+D Nk6kf1T3OMo9RjjApbbZfBP8gwE581wiz7GJCcw37GJhXamOdVbzTVYeGttJSxHf5CG8ec Sozd+GD9yOghRMEU1AkGBt6w8uF3sCeY6fq0eRI2rR9aOdSbRKWYDHPeFuqVAf0lvy9/yJ ppVy/3Zb4isMRZf44wElsFQYMvEuFhjGmejvyHle5OXgZJApXMWrwyUuBc1BQCesySwDIy oeRCFDCVKjNkP2QWraZMEr0AMH8EN+Uwpp302hu5IsN9mu2XQwnPI4lHqNZ0uQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=M7LXLu4M; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1675325966; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=48jKcPMndQI0D7ZVGsI7FNZtsvOQgZDPcxxbIAvEUGc=; b=WPxrdLEW665ngSQ6ZIF4ZdPSC3SLaj2Jn/FLrwoiaEFGJVWkAPaLeaiJnQ/JuxDG4TLF4S g3lwZh89iHSDyd0gWkAY0uGvPjFvAajEqjUe6Va0oaWh1lq+J5Aa24JFZAtyS9hfKPDzqS msft7j3HJ+jk0mDIG0mfgTqWiXA9/zYzR/rxrmneCteaFO2RDwAp61dy+4kAh9q214YaZC WPYCJkmyUyR9IR/e5/aXAOo/ZsI8IgKWr93XjMYtv4QwAvHSyNkIPXaTQDBtN7I1270i9c N69zIs6yLOobA+Plt4V9KdajAnxodcNMVLVVUHKwMbncDsvJv/EtHDqDROWECg== X-Migadu-Spam-Score: -1.86 X-Spam-Score: -1.86 X-Migadu-Queue-Id: D6CC53F6FF X-Migadu-Scanner: scn0.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=M7LXLu4M; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-TUID: 8oi9vk6kD6ar Hi, Nice! Some minor comments which can be trashed if they are not helpful. :-) On Wed, 01 Feb 2023 at 17:28, "\( via Guix-patches" via wrote: > +Let's instead implement another M of functional programming, _`maybe`_ v= alues, > +representing a value that may or may not exist. `maybe` is a very common > +feature of strongly-typed functional languages, and you'll see it all ov= er the > +place in Haskell and OCaml code. However, Guile is not strongly typed, s= o we I would say =E2=80=9CGuile is dynamically typed=E2=80=9C or =E2=80=9Cis not= statically typed=E2=80=9D instead of =E2=80=9Cis not strongly typed=E2=80=9D. Because the terminolog= y =E2=80=9Cstrongly typed=E2=80=9D is probably confusing, for instance, quoting Wikipedia [1]: Smalltalk, Ruby, Python, and Self are all "strongly typed" in the sense that =E2=80=A6 The Lisp family of languages are all "strongly typed" in the sense that =E2=80=A6 Standard ML, F#, OCaml, Haskell, Go and Rust are statically type-checked, =E2=80=A6 1: > +(define (nothing) > + (make-maybe #f #f)) > +``` Here, I would mention that the value =E2=80=98#f=E2=80=98 is picked but any= thing else would also work as 'nothing. Well, to make the distinction with the previous part about #f or () for null values, I would use the symbol 'no-value or something like that. In all cases, I would mention that this #f is just useless. > +(define (remove-a ?str) > + (if (maybe-is? ?str) > + (let ((str (maybe-value ?str))) > + (if (eq? (string-ref str 0) #\a) > + (something (substring str 1)) > + (nothing))) > + (nothing))) Well, my personal preference would be a =E2=80=99match=E2=80=99 instead of = =E2=80=99let=E2=80=99. :-) Maybe, it is for smoothly introducing mlet? :-) > +Congratulations, you've reinvented `bind`, commonly written as the `>>= =3D` > +operator. And it turns out that a monadic type is just a container type= that > +can be used with `>>=3D`! >From my experience, what is often confusing for newcomer with =E2=80=9Cmona= dic notation=E2=80=9C is that =E2=80=99bind=E2=80=99 (>>=3D) appears magic sinc= e it is the same symbol for all the types. When it is attached to one type; here =E2=80=98maybe=E2= =80=98. Well, for what it is worth, it is the same kind of issue when one presents well-known arithmetic operators. At first, it is confusing that the symbol + in 1+2 and 1.2+3.4 does not have the same meaning and e.g. 1+2.3 is a third meaning. Well, I would write: =E2=80=9DCongratulations, you've implemented `bind` fo= r the record `maybe`. It is commonly denoted as the `>>=3D` operator. And it turns out that a monadic type is just a container type that can be used with this `>>=3D` operator defined for such type!=E2=80=9C > +# New Wheel, Old Wheel > + > +Now that we've reinvented the wheel, we'd better learn to use the origin= al > +wheel. Guix provides a generic, high-level monads API, along with three= monads, > +though `maybe` is not one of them, so let's integrate it into the Guix m= onad > +system! I think it is confusing because from my point of view, a piece is missing. Well, for what it is worth, I would end the previous section with a rough definition of monad: 1. one type constructor 2. one =E2=80=98bind=E2=80=98 operator 3. one =E2=80=99return=E2=80=99 function and that =E2=80=99bind=E2=80=99 and =E2=80=99return=E2=80=99 must satisfy t= he 3 laws of monad. Using =E2=80=99maybe=E2=80=99 as example, all is explicit and more or less concre= te. Maybe, the type constructor could be omitted; without loss in generality. Therefore, =E2=80=9Calong with three monads=E2=80=9D means that the API alr= eady provides a type constructor, =E2=80=99bind=E2=80=99 and =E2=80=99return=E2=80=99 for= each. I would write =E2=80=9Calong with the three monads commonly named identity and state monads=E2=80=9D. What is the third? :-) > +First we'll make the API available: > + > +```scheme > +(use-modules (guix monads)) > +``` > + > +To define a monad's API in Guix, we simply use the `define-monad` macro,= and > +provide two procedures: `bind`, and `return`. > + > +```scheme > +(define-monad %maybe-monad > + (bind maybe-chain) > + (return something)) > +``` IMHO, ending the previous section with a short paragraph explaining that a monad is a mathematical object defined with three/two components (type, bind and return) makes this define-monad API more meaningful; again IMHO. > +`bind` is just the procedure that we use to chain monadic procedure calls Instead of chain, I would write compose. Elsewhere too. > +There are also APIs for manipulating lists wrapped in monads; `mlist` cr= eates Do you mean =E2=80=99listm=E2=80=99? > +such a list, `anym` is a monadic `any`, `sequence` turns a list of monad= s into a > +monadic list, `mapm` is a monadic `map`, and `foldm` is a monadic `fold`. Well, here we are touching the limit of what Scheme can express. :-) Because for instance, reading, (mapm %state-monad (lift1 1+ %state-monad) '(0 1 2)) it does not appear clear to me what monad provides compared to just pass arguments around. ;-) > +# In a State > + > +Guix implements a monad called `%state-monad`, and it works with single-= argument > +procedures returning two values. Behold: > + > +```scheme > +(with-monad %state-monad > + (return 33)) > +;; #:1106:22 (state)> > +``` > > +The `run-with-state` value turns this procedure into an actually useful = value, > +or, rather, two values: > + > +```scheme > +(run-with-state (with-monad %state-monad (return 33)) > + (list "foo" "bar" "baz")) > +;; 33 > +;; ("foo" "bar" "baz") > +``` > + > +What can this actually do for us, though? Well, it gets interesting if w= e do > +some `>>=3D`ing: What appears to me hard to follow is that >>=3D is not explicitly used in the following. See below. > + > +```scheme > +(define state-seq > + (mlet* ((number (return 33))) > + (state-push number))) I guess %state-monad is missing in mlet*. > +result > +;; #:1484:24 (state)> > + > +(run-with-state state-seq (list 32)) > +;; (32) > +;; (33 32) > + > +(run-with-state state-seq (list 30 99)) > +;; (30 99) > +;; (33 30 99) > +``` > + > +What is `state-push`? It's a monadic procedure for `%state-monad` that = takes > +whatever's currently in the first value (the primary value) and pushes i= t onto > +the second value (the state value), which is assumed to be a list, retur= ning the > +old state value as the primary value and the new list as the state value. > + > +So, when we do `(run-with-state result (list 32))`, we're passing `(list= 32)` as > +the initial state value, and then the `>>=3D` form passes that and `33` = to Well, maybe instead of mlet*, it would ease the reading if state-seq explicitly uses >>=3D and mention again that instead it could be written using mlet*. It appears to me clearer with the text to have: (define state-seq* (with-monad %state-monad (>>=3D (return 33) state-push))) Or instead, maybe earlier, something like: --8<---------------cut here---------------start------------->8--- And there's `mlet` and `mlet*`, which can bind them, and is essentially equivalent to a chain of `(>>=3D MEXPR (lambda (BINDING) ...))`. Other said, (with-monad %maybe-monad (>>=3D (return "abad") remove-a remove-b remove-a)) is equivalent to: (mlet* %maybe-monad ((str -> "abad") ;non-monadic binding uses the -> symbol (str1 (remove-a str)) (str2 (remove-b str))) (remove-a str)) --8<---------------cut here---------------end--------------->8--- Maybe instead of some unrelated example earlier, I would write: --8<---------------cut here---------------start------------->8--- Now we can use the `with-monad` macro to tell Guix to use this specific `bi= nd` and `return`, and the `>>=3D` macro to thread monads through procedure call= s! ```scheme (with-monad %maybe-monad (>>=3D (something "aabbc") remove-a remove-a remove-b remove-b)) ;; #< is?: #t value: "c"> ``` We can also now use `return`: ```scheme (with-monad %maybe-monad (return 32)) ;; #< is?: #t value: 32> ``` But Guix provides many higher-level APIs than `>>=3D` and `return`, as we w= ill see. There's `mbegin`, which evaluates monadic expressions without binding= them to symbols, returning the last one: ```scheme (mbegin %maybe-monad (remove-a "abc")) ;; #< is?: #t value: "bc"> ``` And there's `mlet` and `mlet*`, which can bind them, and is essentially equivalent to a chain of `(>>=3D MEXPR (lambda (BINDING) ...))`, rewriting the previous example using the operator `>>=3D`: ```scheme (mlet* %maybe-monad ((str -> "aabbc") ;non-monadic binding uses the -> symb= ol (str1 (remove-a str)) (str2 (remove-a str1)) (str3 (remove-b str2)))=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20 (remove-b str3)) ;; #< is?: #t value: "c"> ``` --8<---------------cut here---------------end--------------->8--- > +`state-push`. What `%state-monad` allows us to do is thread together so= me > +procedures that require some kind of state, while pretending the state i= sn't > +there, and then retrieve both the final state and the result at the end! > + > +If you're a bit confused, don't worry. We'll write some of our own > +`%state-monad`-based monadic procedures and hopefully all will become cl= ear. I would add something along these lines for some context: --8<---------------cut here---------------start------------->8--- Consider the (Fibonacci sequence)[https://en.wikipedia.org/wiki/Fibonacci_number] where the next value is computed using the previous values. Let consider one `state` that stores the previous computed value, for instance, ```scheme (define (fibonacci-thing value) (lambda (state) (values (+ value state) value))) ``` Now, let=E2=80=99s evaluate the three first values of the sequence, starting with 1 and 0. (run-with-state (with-monad %state-monad (>>=3D (return 1) fibonacci-thing fibonacci-thing fibonacci-thing)) 0) ;; 3 ;; 2 Similarly, it is possible to compute the 6th and 7th term of the sequence (remind the 0th and first are given by 0 and 1), using equivalently mlet*. (run-with-state (mlet* %state-monad ((starting (return 1)) (n1 (fibonacci-thing starting)) (n2 (fibonacci-thing n1)) (n3 (fibonacci-thing n2)) (n4 (fibonacci-thing n3)) (n5 (fibonacci-thing n4))) (fibonacci-thing n5)) 0) ;; 13 ;; 8 ``` The `fibonacci-thing` monadic procedure takes the number passed, makes it t= he current state, and outputs the sum of the state and the number passed. This gives us a sort of Fibonacci-sequence-like behaviour, where the next number= in the sequence is given by the sum of the two before. --8<---------------cut here---------------end--------------->8--- > +This is all very nifty, and possibly useful in general, but what does th= is have > +to do with Guix? Well, many Guix store-based operations are meant to be= used > +in concert with yet another monad, called the `%store-monad`. But if we= look at > +`(guix store)`, where `%store-monad` is defined... > + > +```scheme > +(define-alias %store-monad %state-monad) > +(define-alias store-return state-return) > +(define-alias store-bind state-bind) > +``` > + > +It was all a shallow fa=C3=A7ade! All the "store monad" is is a special= case of the > +state monad, where a value representing the store is passed as the state= value. > + > +# Lies, Damned Lies, and Abstractions > + > +We mentioned that, technically, we didn't need monads for Guix. Indeed,= many > +(now deprecated) procedures take a store value as the argument: I think it is worth to mention that monad provides the correct framework to compose in a pure world some impure functions. The pure world is an isolated environment but that alone is useless. What make things useful is to have inputs from the outside impure world. All the question is thus to keep the control of impurity when composing. Well, this short video [1] is about Haskell but all the arguments apply, IMHO. I mean the kind of diagram seems to also make sense here. 1: > +```scheme > +(use-modules (guix derivations) > + (guix store)) > + > +(with-store store ;remember this? > + (build-expression->derivation store NAME EXPRESSION ...)) > +``` > + > +This procedure, being deprecated, should never of course be used. For o= ne > +thing, it uses the "quoted build expression" style, rather than gexps, w= hich we > +will discuss another time. The best way to create a derivation from som= e basic > +build code is to use the new-fangled `gexp->derivation` procedure, which= happens > +to be monadic! This paragraph appears to me confusing because it is not clear what is deprecated; with-store or build-expression->derivation? Well, I would drop build-expression->derivation. Instead, I would use this pattern: --8<---------------cut here---------------start------------->8--- Consider that we would like to build something and have it in the store, for instance some text file. Well, the procedure `text-file`, (define* (text-file name text ;string #:optional (references '())) "Return as a monadic value the absolute file name in the store of the file containing TEXT, a string. seems what we want. Therefore, we want to evaluate this monadic value in the context of the store, similarly as the previous run-with-state. `guix repl` provides a nice interface with the command `,run-in-store`: scheme@(guix-user)> ,run-in-store (text-file "unmatched-paren" "( ") $1 =3D "/gnu/store/v6smacxvdk4yvaa3s3wmd54lixn1dp3y-unmatched-paren" Unwrapping the machinery, it would reads, (with-store store (run-with-store store (text-file "unmatched-paren" "( "))) ;; "/gnu/store/v6smacxvdk4yvaa3s3wmd54lixn1dp3y-unmatched-paren" where `with-store` acts similarly as `with-monad` and `run-with-store` similarly as `run-with-state`. Note the order is reversed because the store is somehow unique. Now, consider we want to build a derivation. Let define one: ```scheme (use-modules (guix gexp) (gnu packages irc)) (define symlink-irssi (gexp->derivation "link-to-irssi" #~(symlink #$(file-append irssi "/bin/irssi") #$output))) ;; # ``` Remember that store and state are related. You don't have to understand the `#~(...)` form yet, only everything surrou= nding it. We can see that this `gexp->derivation` returns a procedure taking the initial state (store), just like our `%state-monad` procedures did. And to= pass this initial state, we used `run-with-state`. The equivalent for working w= ith the store is our old friend `run-with-store`! (with-store store (run-with-store store symlink-irssi))) ;; # /gnu/store/6a94niigx4ii0ldjdy33wx9anhifr25x-link-to-irssi 7fddb7ef5= 2d0> --8<---------------cut here---------------end--------------->8--- My 2 cents. Nice read of an hard topic. Well done! :-) Cheers, simon