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.