From: Tomas Volf <~@wolfsden.cz>
To: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
Cc: "Jérémy Korwin-Zmijowski" <jeremy@korwin-zmijowski.fr>,
guile-user@gnu.org
Subject: Re: How to gradually write a procedure using Guile?
Date: Thu, 16 May 2024 20:25:50 +0200 [thread overview]
Message-ID: <ZkZPrujd9zJgimoh@ws> (raw)
In-Reply-To: <87h6ffyv1s.fsf@web.de>
[-- Attachment #1: Type: text/plain, Size: 2003 bytes --]
Hi,
(and apologized for slightly later response)
On 2024-05-03 13:49:35 +0200, Dr. Arne Babenhauserheide wrote:
> [..]
>
> Jérémy Korwin-Zmijowski <jeremy@korwin-zmijowski.fr> writes:
>
> > [..]
Thank you both for the useful tips. I experimented with the workflow for few
weeks and, with your suggestions, reached the following process.
For simple, (semi-)pure functions, that can be easily tested in REPL, I evaluate
the whole definition and run in manually in the REPL to see the result. I
already was doing this before, and it seems to work fine, so I am sticking to
it.
For long, totally non-pure functions (motivation for my original email), I
accepted the fact that I will have to modify the code to make it REPL-friendly.
So, for example, instead of
(define (foo)
(let ((bar 1))
...))
I am using
(define (foo)
(define bar 1)
...)
While less elegant, it allows me to do the setup once (evaluating the procedure
one expression after another) in the REPL, and then I can just continue adding
new expressions while evaluating them one by one. The end result is slightly
harder to reason about, but still worth it in my case[0].
The obvious down-side is the top-level pollution, but with bit of care it seems
to be manageable. Sometimes, when I mess up, it requires restarting the REPL,
but I can skip the expensive parts of the setup, so it is pretty fast.
Thank you both again and have a nice day,
Tomas Volf
0: The full procedure is an install script for a server and runs for about 45
minutes having many side-effects, like installing packages, compiling
external programs and configuring the system. Yes, it would be possible to
split it into multiple separate procedures, but the state passing gets
annoying quickly and the resulting code is less straight forward.
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2024-05-16 18:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-03 0:24 How to gradually write a procedure using Guile? Tomas Volf
2024-05-03 8:45 ` Jérémy Korwin-Zmijowski
2024-05-03 11:49 ` Dr. Arne Babenhauserheide
2024-05-16 18:25 ` Tomas Volf [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZkZPrujd9zJgimoh@ws \
--to=~@wolfsden.cz \
--cc=arne_bab@web.de \
--cc=guile-user@gnu.org \
--cc=jeremy@korwin-zmijowski.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).