WEBVTT captioned by sachac, checked by sachac
NOTE Introduction
00:00:02.120 --> 00:00:07.399
Hello and welcome everyone on EmacsConf 2023.
00:00:07.400 --> 00:00:08.719
I'm Andrew Tropin.
00:00:08.720 --> 00:00:11.919
I work on operating systems and programming languages.
00:00:11.920 --> 00:00:16.639
Today, we discuss Lisps, Schemes, REPLs,
00:00:16.640 --> 00:00:18.139
interactive development,
00:00:18.140 --> 00:00:23.279
and how to make your own cozy development environment.
NOTE Interactive development
00:00:23.280 --> 00:00:26.319
Let's start from interactive development.
00:00:26.320 --> 00:00:29.519
Lisps are famous for a nice
00:00:29.520 --> 00:00:32.479
Interactive Development Experience.
00:00:32.480 --> 00:00:33.999
They have REPLs.
00:00:34.000 --> 00:00:40.119
Emacs Lisp has its own Lisp machine,
00:00:40.120 --> 00:00:44.719
and a lot of cool IDE with different functionality
00:00:44.720 --> 00:00:47.879
is already here and providing
00:00:47.880 --> 00:00:51.619
a nice and pleasant experience.
00:00:51.620 --> 00:00:56.839
The question is, is it enough?
00:00:56.840 --> 00:00:59.920
In most cases, yes, but for some languages,
00:00:59.921 --> 00:01:04.839
we have some white spaces, some missing pieces.
00:01:04.840 --> 00:01:08.299
And for example, in Scheme world,
00:01:08.300 --> 00:01:10.879
we already have a few tools.
00:01:10.880 --> 00:01:14.599
We have REPL, we have integration for REPL in Emacs,
00:01:14.600 --> 00:01:16.679
but is it enough?
00:01:16.680 --> 00:01:18.179
Let's see.
NOTE REPL: Read Eval Print Loop
00:01:18.180 --> 00:01:22.839
We know that Emacs is very good for Lisps and REPL.
00:01:22.840 --> 00:01:26.039
Lisp and Emacs should be a perfect setup.
00:01:26.040 --> 00:01:30.079
But let's see how REPL basically works.
00:01:30.080 --> 00:01:34.799
It's an event loop which does three things.
00:01:34.800 --> 00:01:37.279
It reads an expression, it evaluates the expression,
00:01:37.280 --> 00:01:40.739
and it prints the result.
00:01:40.740 --> 00:01:47.279
We can take a simple expression, input it into REPL,
00:01:47.280 --> 00:01:48.959
and evaluate it and see the result.
00:01:48.960 --> 00:01:50.819
Very nice, very convenient.
00:01:50.820 --> 00:01:55.339
You can experiment and see immediately what is happening.
00:01:55.340 --> 00:01:57.759
You can even run a long-running process
00:01:57.760 --> 00:01:58.919
which does something.
00:01:58.920 --> 00:02:07.199
You can interrupt it and everything will be okay.
00:02:07.200 --> 00:02:08.639
But the problem appears
00:02:08.640 --> 00:02:11.659
when you start to develop a bigger project.
00:02:11.660 --> 00:02:14.039
And in most cases, you don't do
00:02:14.240 --> 00:02:16.399
your whole development in REPL.
00:02:16.400 --> 00:02:18.460
You do only a small part of it.
00:02:18.461 --> 00:02:20.679
In most cases, you just write
00:02:20.680 --> 00:02:22.919
the source code in text files,
00:02:22.920 --> 00:02:26.399
and after that, you run those snippets of code
00:02:26.400 --> 00:02:30.520
from those text files, or run the whole project.
00:02:30.721 --> 00:02:33.719
It's not very convenient to copy and paste
00:02:33.720 --> 00:02:36.039
every time the snippets of code to the REPL,
00:02:36.040 --> 00:02:38.879
see the result, modify the snippet of code,
00:02:38.880 --> 00:02:41.199
copy it again, and so on.
00:02:41.200 --> 00:02:44.039
So people invented some integration
00:02:44.040 --> 00:02:46.079
between REPL and your text editor.
00:02:46.080 --> 00:02:51.599
So you can evaluate expressions inside your text editor
00:02:51.600 --> 00:02:53.719
and see the result here.
NOTE Long-lasting loops
00:02:53.720 --> 00:02:56.679
Works good so far, but what happens
00:02:56.680 --> 00:03:02.299
if we run a long-lasting loop,
00:03:02.300 --> 00:03:04.999
which does a lot of operations.
00:03:05.000 --> 00:03:07.839
As you can see here with a simple example,
00:03:07.840 --> 00:03:13.599
the output of the function,
00:03:13.600 --> 00:03:16.759
stdout of the function is presented here,
00:03:16.760 --> 00:03:18.799
and the resulting value is here.
00:03:18.800 --> 00:03:22.359
If you run a long-running process,
00:03:22.360 --> 00:03:24.639
you don't see anything happening.
00:03:24.640 --> 00:03:29.259
And you see there's a watch instead of my cursor.
00:03:29.260 --> 00:03:33.719
Maybe you don't see it, but nothing actually happens,
00:03:33.720 --> 00:03:36.379
at least from the point of view of the user.
00:03:36.380 --> 00:03:38.399
But if we interrupt the evaluation,
00:03:38.400 --> 00:03:41.439
we will see that some process in the background
00:03:41.440 --> 00:03:44.239
was launched, but we didn't see anything.
00:03:44.240 --> 00:03:51.039
Because the REPL is a single-threaded blocking process,
00:03:51.040 --> 00:03:54.319
which reads stdin and prints stdout,
00:03:54.320 --> 00:03:55.679
make the integration
00:03:55.680 --> 00:03:58.540
between the REPL and your text editor
00:03:58.541 --> 00:04:02.919
is not an easy task.
00:04:02.920 --> 00:04:04.320
And even if you do it,
00:04:04.321 --> 00:04:07.599
you have a lot of downsides, usually.
NOTE Not interruptible
00:04:07.600 --> 00:04:13.679
First of all, the process is not interruptible.
00:04:13.680 --> 00:04:18.479
If you have a remote process which listens on the socket
00:04:18.480 --> 00:04:21.939
to which you connect from your development environment,
00:04:21.940 --> 00:04:25.479
and you run some infinite loop, for example,
00:04:25.480 --> 00:04:28.299
you can't interrupt it.
00:04:28.300 --> 00:04:31.239
Because interruption is done via signals,
00:04:31.240 --> 00:04:35.039
and signals to remote processes are not usually
00:04:35.040 --> 00:04:38.759
the thing in such integrations.
NOTE Output is not interactive
00:04:38.760 --> 00:04:41.159
Output is also not interactive.
00:04:41.160 --> 00:04:45.319
Usually, for example, here you can see
00:04:45.320 --> 00:04:47.799
when I evaluate the expression,
00:04:47.800 --> 00:04:51.119
the output is captured on the evaluation side,
00:04:51.120 --> 00:04:53.719
and after that, after the whole evaluation
00:04:53.720 --> 00:04:56.179
of the whole expression finished,
00:04:56.180 --> 00:05:06.759
I get the result, all the stdout at once.
00:05:06.760 --> 00:05:09.919
And if I run the process which evaluates for 5 seconds,
00:05:09.920 --> 00:05:13.780
I will see the first signs of the life
00:05:13.781 --> 00:05:17.039
only after 5 seconds of evaluation.
00:05:17.040 --> 00:05:23.159
Okay, what else?
NOTE No protocol
00:05:23.160 --> 00:05:26.119
When you do such integrations, you have no protocol,
00:05:26.120 --> 00:05:29.759
you have just stdin and stdout.
00:05:29.760 --> 00:05:32.919
You print to stdin from your text editor.
00:05:32.920 --> 00:05:36.679
You read from stdout of the process.
00:05:36.680 --> 00:05:40.339
It's hard to tell if evaluation is finished,
00:05:40.340 --> 00:05:47.319
if it requires stdin, and how to extend the REPL
00:05:47.320 --> 00:05:51.479
to make it more featureful, and so on.
NOTE Not scalable
00:05:51.480 --> 00:05:57.359
And also, such integrations are usually not very scalable.
00:05:57.360 --> 00:06:14.699
For example, if you want to have a completion,
00:06:14.700 --> 00:06:17.460
you type something, you have the completion. Cool.
00:06:17.461 --> 00:06:22.039
But if you run the process and at the same time
00:06:22.040 --> 00:06:24.620
try to have a completion, you don't have it,
00:06:24.621 --> 00:06:29.799
because the evaluation is in progress,
00:06:29.800 --> 00:06:33.279
and you can't calculate the completion candidates
00:06:33.280 --> 00:06:35.519
at the same time. To make it more obvious,
00:06:35.520 --> 00:06:41.019
I will start a completion here.
00:06:41.020 --> 00:06:43.279
You see the completion pop-ups.
00:06:43.280 --> 00:06:46.159
I start the evaluation process,
00:06:46.160 --> 00:06:49.859
and when I try to complete something,
00:06:49.860 --> 00:06:53.119
the evaluation freezes and there is no completion.
00:06:53.120 --> 00:06:55.479
Not very convenient.
00:06:55.480 --> 00:06:58.119
Usually, you have some long-running processes
00:06:58.120 --> 00:07:01.399
and you want them to continue while you have
00:07:01.400 --> 00:07:08.579
your go to definition, completion, and other things.
00:07:08.580 --> 00:07:13.659
Overall, those issues make it quite inconvenient
00:07:13.660 --> 00:07:18.419
to integrate REPL in text editors or development environments,
00:07:18.420 --> 00:07:21.379
so you need something else
00:07:21.380 --> 00:07:25.859
to make the work comfortable.
NOTE nREPL
00:07:25.860 --> 00:07:28.979
There is already a solution called nREPL.
00:07:28.980 --> 00:07:31.119
It's a synchronous protocol which allows
00:07:31.120 --> 00:07:34.019
to send operations to the server
00:07:34.020 --> 00:07:37.759
and receive responses in a synchronous manner.
00:07:37.760 --> 00:07:42.159
And here is a simple example of a few operations.
00:07:42.160 --> 00:07:45.079
First one is cloning the existing session,
00:07:45.080 --> 00:07:49.240
and as a response you will get a new session.
00:07:49.241 --> 00:07:52.099
Also you send the evaluation request with code
00:07:52.100 --> 00:07:55.639
that you want to evaluate, and you get two responses.
00:07:55.640 --> 00:08:00.600
First one says that output is captured
00:08:00.601 --> 00:08:02.839
and it's equal to "hi\n",
00:08:02.840 --> 00:08:06.560
and after that, you receive an "Evaluation completed",
00:08:06.561 --> 00:08:12.439
the value of this expression.
00:08:12.440 --> 00:08:14.079
This protocol was developed
00:08:14.080 --> 00:08:15.879
for CIDER development environment.
00:08:15.880 --> 00:08:18.759
It's a Clojure development environment for Emacs.
00:08:18.760 --> 00:08:22.859
It's very cool, featureful, reliable,
00:08:22.860 --> 00:08:26.899
and I would say production-ready.
00:08:26.900 --> 00:08:31.499
A lot of professional Clojure developers use it.
00:08:31.500 --> 00:08:33.239
The nREPL protocol is very simple.
00:08:33.240 --> 00:08:38.219
It has a few operations out of the box,
00:08:38.220 --> 00:08:46.479
and you can extend it with any arbitrary operation you want.
00:08:46.480 --> 00:08:53.819
I work a lot on Guix codebase and other Scheme projects,
00:08:53.820 --> 00:08:57.299
so the experience I had previously with nREPL
00:08:57.300 --> 00:08:59.399
was not satisfying. I decided
00:08:59.400 --> 00:09:01.739
to just implement nREPL protocol.
NOTE Arei, Ares, and how to try
00:09:01.740 --> 00:09:05.719
First of all, I implemented nREPL server in Guile.
00:09:05.720 --> 00:09:11.339
I called it `guile-ares-rs`, and used it
00:09:11.340 --> 00:09:13.959
with a generic nREPL client for Emacs.
00:09:13.960 --> 00:09:14.719
It worked.
00:09:14.720 --> 00:09:18.639
It had some rough edges, but overall it was okay.
00:09:18.640 --> 00:09:21.639
And after that, to add more features
00:09:21.640 --> 00:09:25.079
to make the implementation more complete,
00:09:25.080 --> 00:09:33.219
I wrote my own nREPL client for Emacs and called it `arei`.
00:09:33.220 --> 00:09:40.179
And I got almost complete Guile IDE in two months.
00:09:40.180 --> 00:09:45.319
So `ares-rs` is nREPL server implementation.
00:09:45.320 --> 00:09:49.679
`arei` is Emacs client, which uses the same nREPL protocol.
00:09:49.680 --> 00:09:54.439
It utilizes `sesman` package for managing sessions,
00:09:54.440 --> 00:10:00.079
the association of buffers with nREPL connection.
00:10:00.080 --> 00:10:04.379
It has some roots.
00:10:04.380 --> 00:10:06.639
The implementation has some roots
00:10:06.640 --> 00:10:09.979
in Geiser, CIDER, Monroe, and Rail.
00:10:09.980 --> 00:10:15.279
I took small snippets for some parts of functionality.
00:10:15.280 --> 00:10:19.479
I used the CAPF and xref infrastructure
00:10:19.480 --> 00:10:23.079
for completion at point and cross-reference capabilities.
00:10:23.080 --> 00:10:27.679
And by the time of conference, I hope
00:10:27.680 --> 00:10:30.199
that README will be complete enough
00:10:30.200 --> 00:10:34.179
so you will be able to try it yourself.
NOTE Demo
00:10:34.180 --> 00:10:42.679
Let's see what is possible with it already.
00:10:42.680 --> 00:10:46.719
Let's connect to nREPL server.
00:10:51.900 --> 00:10:56.280
After that, you can evaluate the expression.
00:10:56.281 --> 00:11:02.319
And you see the stdout and the result.
00:11:02.320 --> 00:11:04.719
Very nice, very convenient.
00:11:04.720 --> 00:11:08.659
You have different expression, you evaluate it,
00:11:08.660 --> 00:11:10.359
you get the value of the evaluation.
00:11:10.360 --> 00:11:12.279
You can run an infinite loop
00:11:12.280 --> 00:11:15.639
which prints to stderr and stdout
00:11:15.640 --> 00:11:18.599
and you see all necessary stuff.
00:11:18.600 --> 00:11:19.299
Very cool.
00:11:19.300 --> 00:11:21.959
But also, you can interrupt the evaluation,
00:11:21.960 --> 00:11:25.159
which is very convenient if you accidentally
00:11:25.160 --> 00:11:27.639
run an infinite loop.
NOTE Continuations
00:11:27.640 --> 00:11:32.939
Also, do you remember here we have a few more examples
00:11:32.940 --> 00:11:34.079
that we didn't try yet?
00:11:34.080 --> 00:11:39.159
For example, on usual REPL implementation,
00:11:39.160 --> 00:11:47.599
if I evaluate this expression, I get return value.
00:11:47.600 --> 00:11:50.759
I make a continuation and save it to this variable
00:11:50.760 --> 00:11:52.859
and I try to call this evaluation
00:11:52.860 --> 00:11:55.339
and I get an exception,
00:11:55.340 --> 00:11:58.399
because the environment in which this continuation
00:11:58.400 --> 00:12:03.479
was created was different and it has redefined
00:12:03.480 --> 00:12:06.159
stdout and stderr to capture it.
00:12:06.160 --> 00:12:08.979
But when I run it one more time,
00:12:08.980 --> 00:12:12.199
when I resume the continuation,
00:12:12.200 --> 00:12:15.799
the environment changed and it doesn't work.
00:12:15.800 --> 00:12:17.419
What happens in `arei`?
00:12:17.420 --> 00:12:21.759
I define continuation, I save the continuation
00:12:21.760 --> 00:12:23.479
for the simple expression
00:12:23.480 --> 00:12:27.279
and I resume the continuation with a new argument,
00:12:27.280 --> 00:12:30.139
and you can see at the top of the screen
00:12:30.140 --> 00:12:32.459
that it works perfectly fine.
NOTE Reading from stdin
00:12:32.460 --> 00:12:35.559
Also, with a usual REPL implementation,
00:12:35.560 --> 00:12:40.319
let's see what happens when we have a process
00:12:40.320 --> 00:12:41.919
which reads from stdin.
00:12:41.920 --> 00:12:48.099
I evaluate the expression and nothing visible happens.
00:12:48.100 --> 00:12:52.999
I can try to type `C-g`, `C-c`,
00:12:53.000 --> 00:12:56.559
and after some time it will say user interrupt.
00:12:56.560 --> 00:13:00.439
What actually I expect in such a case
00:13:00.440 --> 00:13:04.679
to have a minibuffer which prompts me for the input.
00:13:04.680 --> 00:13:10.019
When I evaluate the same expression in the `arei`,
00:13:10.020 --> 00:13:12.199
you see the prompt at the minibuffer
00:13:12.200 --> 00:13:21.899
and here I can tell, "Hello I'm a message from minibuffer".
00:13:21.900 --> 00:13:26.099
Cool. You will see that this message is printed to stdout,
00:13:26.100 --> 00:13:28.679
and unspecified was returned
00:13:28.680 --> 00:13:33.419
as a result of this expression.
NOTE Fancy example with continuations
00:13:33.420 --> 00:13:37.319
Let's make some fancy example with continuations.
00:13:37.320 --> 00:13:45.079
Continuations is a very cool mechanism
00:13:45.080 --> 00:13:47.999
which is not the topic of today's talk,
00:13:48.000 --> 00:13:50.999
but you can find a lot of interesting information
00:13:51.000 --> 00:13:54.439
in Scheme documentation or in related books,
00:13:54.440 --> 00:13:58.339
and I advise you to do it because it's really nice thing
00:13:58.340 --> 00:14:00.119
that is actually applicable
00:14:00.120 --> 00:14:03.519
in many different programming languages.
00:14:03.520 --> 00:14:05.199
Here you can see the infinite loop
00:14:05.200 --> 00:14:09.159
which just prints values increasing one by one.
00:14:09.160 --> 00:14:13.299
And here we save a continuation on each iteration.
00:14:13.300 --> 00:14:18.059
I can call the continuation
00:14:18.060 --> 00:14:21.939
and it will resume from the previous saved step.
00:14:21.940 --> 00:14:27.679
And you can see, it resumed from the same step
00:14:27.680 --> 00:14:31.640
we interrupted earlier, but we provided a new value for it.
another value for it.
00:14:31.641 --> 00:14:33.920
We can provide another value
00:14:33.921 --> 00:14:39.199
and it resumed from the same spot it was saved earlier.
00:14:39.200 --> 00:14:42.579
But I also can provide a `read-i` value
00:14:42.580 --> 00:14:45.199
and if I provide `read-i` value,
00:14:45.200 --> 00:14:50.779
the infinite loop will read the input from stdin
00:14:50.780 --> 00:14:53.319
and will continue the evaluation
00:14:53.320 --> 00:14:56.679
with a different `i` provided in this input.
00:14:56.680 --> 00:15:03.039
So let's try to type some arbitrary value
00:15:03.040 --> 00:15:07.519
and you see that the loop continued with this value.
00:15:07.520 --> 00:15:08.039
Very nice.
00:15:08.040 --> 00:15:13.159
And every time we could easily interrupt it.
NOTE Guix API
00:15:13.160 --> 00:15:17.319
Okay, what most annoying thing that I had previously
00:15:17.320 --> 00:15:19.339
with the usual REPL implementation
00:15:19.340 --> 00:15:22.759
that I have a quite nice Guix API
00:15:22.760 --> 00:15:27.579
where I can build packages, systems and other stuff.
00:15:27.580 --> 00:15:35.359
But if I evaluate this expression, I will get an error.
00:15:35.360 --> 00:15:38.039
Okay. I will get an error
00:15:38.040 --> 00:15:44.479
because I don't have an appropriate environment.
00:15:44.480 --> 00:15:51.579
But what I can do, I can connect to the remote REPL
00:15:51.580 --> 00:15:55.059
by creating a server with `guix repl --listen` command
00:15:55.060 --> 00:15:58.619
and connecting to it with `geiser-connect` command.
00:15:58.620 --> 00:16:01.819
And now I can evaluate this expression.
00:16:01.820 --> 00:16:03.359
Right?
00:16:03.360 --> 00:16:10.479
Wow.
00:16:10.480 --> 00:16:14.339
Okay.
00:16:14.340 --> 00:16:19.039
It actually doesn't matter for my example.
00:16:19.040 --> 00:16:22.879
I will explain how it doesn't work easily.
00:16:22.880 --> 00:16:26.519
This is a long-running process which prints something
00:16:26.520 --> 00:16:29.579
and it can take up to a few minutes.
00:16:29.580 --> 00:16:33.359
And for the whole few minutes I don't see any results,
00:16:33.360 --> 00:16:38.719
the same as with this infinite loop which prints to stdout
00:16:38.720 --> 00:16:42.199
but I don't see anything interactively.
00:16:42.200 --> 00:16:45.619
With `arei`, I can run
00:16:45.620 --> 00:16:47.920
the evaluation of the same expression,
00:16:51.440 --> 00:16:54.119
and you will see instantly
00:16:54.120 --> 00:17:00.200
that stdout is presented here in slightly yellowish color.
00:17:00.201 --> 00:17:02.920
I can interrupt the evaluation
00:17:02.921 --> 00:17:06.039
if I don't want to wait until it's finished,
00:17:06.040 --> 00:17:15.779
and just after that, I can evaluate another value.
00:17:15.780 --> 00:17:23.359
So that's cool.
00:17:23.360 --> 00:17:25.959
And let's see one more thing.
00:17:25.960 --> 00:17:30.339
We have an infinite loop and we have some completion here.
00:17:30.340 --> 00:17:32.579
And completion still works,
00:17:32.580 --> 00:17:33.659
very nice,
00:17:33.660 --> 00:17:40.259
while the infinite loop is running.
00:17:40.260 --> 00:17:42.059
Okay.
NOTE Support
00:17:42.060 --> 00:17:44.919
Actually it took me around two months
00:17:44.920 --> 00:17:48.039
of full-time work funded by my own savings,
00:17:48.040 --> 00:17:51.599
and you can support and help to the project
00:17:51.600 --> 00:17:57.019
using OpenCollective or by contributing on SourceHut.
NOTE Future steps - Multiple simultaneous evaluations in different contexts
00:17:57.020 --> 00:17:58.699
The future steps for the project
00:17:58.700 --> 00:18:03.674
include an experimental workflow where you have
00:18:03.675 --> 00:18:07.539
multiple simultaneous evaluation in different contexts.
00:18:07.540 --> 00:18:11.959
For example, you have Fibers, you have Goblins,
00:18:11.960 --> 00:18:16.919
you have some HTTP server or some other thing,
00:18:16.920 --> 00:18:22.119
and you want to run all of them independently
00:18:22.120 --> 00:18:25.319
in slightly isolated sessions,
00:18:25.320 --> 00:18:29.799
and you want to have the ability
00:18:29.800 --> 00:18:30.959
to still interact with them.
00:18:30.960 --> 00:18:33.979
For example, if they require standard input
00:18:33.980 --> 00:18:39.239
or something else, you want to be able to provide it.
00:18:39.240 --> 00:18:42.519
You want to see the stderr and stdout
00:18:42.520 --> 00:18:46.219
of those long-running processes and so on.
NOTE Tree-sitter integration
00:18:46.220 --> 00:18:50.239
The second thing is tree-sitter integration
00:18:50.240 --> 00:18:53.399
for better syntax highlighting, code navigation,
00:18:53.400 --> 00:18:56.879
and other features.
NOTE Full-fledged debugger
00:18:56.880 --> 00:19:01.399
And after that, probably we will do a full-fledged debugger
00:19:01.400 --> 00:19:06.239
so you can jump expressions one by one
00:19:06.240 --> 00:19:10.779
and see the results and see some intermediate values
00:19:10.780 --> 00:19:13.079
during the evaluation.
00:19:13.080 --> 00:19:14.479
And it's very possible
00:19:14.480 --> 00:19:17.079
because nREPL is a very extensible protocol
00:19:17.080 --> 00:19:18.199
and you can implement
00:19:18.200 --> 00:19:22.759
whatever you want on top of it.
NOTE FAQ - Does it support other Scheme implementations?
00:19:22.760 --> 00:19:27.079
I will answer two probably very frequent questions.
00:19:27.080 --> 00:19:30.499
Does it support other Scheme implementations?
00:19:30.500 --> 00:19:32.279
At the moment, it doesn't,
00:19:32.280 --> 00:19:36.519
but the Scheme implementation is not restricted.
00:19:36.520 --> 00:19:40.639
You have a server which is implemented in your language
00:19:40.640 --> 00:19:43.974
and you have a client--in our case, `arei`--
00:19:43.975 --> 00:19:48.319
which communicates with this protocol.
00:19:48.320 --> 00:19:52.359
So if you implement nREPL server in a different language,
00:19:52.360 --> 00:19:58.379
it should work with already implemented `arei` client.
NOTE Is it possible to use it with other text editors?
00:19:58.380 --> 00:20:04.079
And is it possible to use the same functionality
00:20:04.080 --> 00:20:06.999
in other text editors, for example in VS Code,
00:20:07.000 --> 00:20:08.679
Vim, whatever?
00:20:08.680 --> 00:20:13.799
Yes, it's possible and the case is similar here.
00:20:13.800 --> 00:20:16.599
You have already implemented nREPL server
00:20:16.600 --> 00:20:19.359
and you can write your own nREPL client
00:20:19.360 --> 00:20:22.120
in a different text editor and it will work.
NOTE Conclusion
00:20:22.121 --> 00:20:26.759
I would like to thank the authors and maintainers
00:20:26.760 --> 00:20:30.439
and contributors of Guile, Geiser, CIDER, Clojure,
00:20:30.440 --> 00:20:33.359
and Emacs, and all other people
00:20:33.360 --> 00:20:38.779
who are somehow related to the work on those projects
00:20:38.780 --> 00:20:42.079
involved in this talk.
00:20:42.080 --> 00:20:45.879
And I hope the Scheme programming will be enjoyable.
NOTE Contacts
00:20:45.880 --> 00:20:47.239
If you want to contact me,
00:20:47.240 --> 00:20:49.799
join #tropin IRC channel at libera.chat,
00:20:49.800 --> 00:20:53.039
or drop me a message via email or feediverse
00:20:53.040 --> 00:20:55.879
using `andrew@trop.in` handle.
00:20:55.880 --> 00:21:00.680
I will see you in a bit in Q&A session.
