path: root/2024/captions/emacsconf-2024-transducers--transducers-finally-ergonomic-data-processing-for-emacs--colin-woodbury--answers.vtt

WEBVTT chapters by sachac

00:00:00.000 --> 00:00:07.559
Hopefully the internet goes well. It's a nice Monday

00:00:07.560 --> 00:00:31.999
morning here in Tokyo.

00:00:32.000 --> 00:00:37.879
Are we connected all right?

00:00:37.880 --> 00:00:40.879
Okay, I seem to be struggling still with my audio. One second...

00:00:40.880 --> 00:00:44.519
calling. Yeah, you were muted for a moment there. Okay,

00:00:44.520 --> 00:00:49.959
there we are. Okay. All right. Sorry about that. I got a mute

00:00:49.960 --> 00:00:55.119
out my, my back office chatter. That's kind of distracting

00:00:55.120 --> 00:00:58.079
me a little bit. All right. Sorry. I may have lost the plot a

00:00:58.080 --> 00:01:04.919
little bit. I think I did. However, find the 1st question.

00:01:04.920 --> 00:01:09.919
I got pretty distracted by conversation backstage. Yeah,

NOTE Q: When I tried comparing transducers.el to cl-lib and dash (benchmark-compiled), I got the following results

00:01:09.920 --> 00:01:15.879
no problem. So the first question here, someone's asking,

00:01:15.880 --> 00:01:22.279
when they first tried comparing transducers.el, the cl-lib

00:01:22.280 --> 00:01:27.959
and Dash bookmark compiled, and they give some detailed

00:01:27.960 --> 00:01:32.479
results we're sharing on the stream. Um, they expected

00:01:32.480 --> 00:01:36.679
transducers to be slower than CL loop, but faster than CL lib

00:01:36.680 --> 00:01:41.119
or dash. However, this isn't the case, any idea why. And so

00:01:41.120 --> 00:01:43.639
I'll, I'll come back into their data to show there's they're

00:01:43.640 --> 00:01:48.279
showing, um, you know, there's not a lot of detail on the, on

00:01:48.280 --> 00:01:52.199
the, on the use case here. We could certainly click through

00:01:52.200 --> 00:02:02.559
it, do it.

00:02:02.560 --> 00:02:06.999
Oh, I should've waited to zoom until I find my spot here.

00:02:07.000 --> 00:02:13.639
There we are.

00:02:13.640 --> 00:02:18.599
All right, so there's our example.

00:02:18.600 --> 00:02:23.759
Looks like we are doing a simple map and a sum.

00:02:23.760 --> 00:02:29.239
Mm-hmm. Yeah, that's right. Yeah, question about

00:02:29.240 --> 00:02:36.279
performance. So a case like this, a simple, I just want to rip

00:02:36.280 --> 00:02:40.279
through a collection of numbers and sum them all. That's a

00:02:40.280 --> 00:02:44.679
case where basically loop is always going to win because

00:02:44.680 --> 00:02:51.319
loop is optimized. This is true in both Emacs Lisp and in

00:02:51.320 --> 00:02:56.039
Common Lisp. For a case like this where you're not really

00:02:56.040 --> 00:03:02.399
doing two nested of chained calls, like you don't have many

00:03:02.400 --> 00:03:05.839
sort of what I was compositional steps. If you're just

00:03:05.840 --> 00:03:09.999
ripping through a collection of numbers, loop is always

00:03:10.000 --> 00:03:15.559
going to win. Transducers kind of shines when you have to do

00:03:15.560 --> 00:03:19.639
things that loop can't in terms of expressing yourself. So

00:03:19.640 --> 00:03:22.559
there are lots of different transducers that you can chain

00:03:22.560 --> 00:03:27.079
together. And in that case, you're kind of prioritizing

00:03:27.080 --> 00:03:33.039
developer time and developer happiness because you're

00:03:33.040 --> 00:03:36.399
able to yourself more clearly, whereas sometimes those

00:03:36.400 --> 00:03:40.679
kind of algorithms can get very hairy if you're just using

00:03:40.680 --> 00:03:45.399
loop. Now that sounds like I'm moving the goalposts, and

00:03:45.400 --> 00:03:48.639
there's really no excuse for these things not being as

00:03:48.640 --> 00:03:54.559
performant as possible. In this specific case, my guess is

00:03:54.560 --> 00:03:57.759
that the transducers is slower because it has to do a whole

00:03:57.760 --> 00:04:03.239
bunch of like inner function calls in order to actually do

00:04:03.240 --> 00:04:09.239
the adding and the collecting. So there's a lot of stuff that

00:04:09.240 --> 00:04:12.119
just the raw loop doesn't have to do, which transducers

00:04:12.120 --> 00:04:20.439
does. And so in this case, that's why it would be slower.

00:04:20.440 --> 00:04:29.079
All right, makes sense.

00:04:29.080 --> 00:04:36.239
Um... I cannot comment against Dash. And also a reminder

00:04:36.240 --> 00:04:40.159
that transducers both in CL and in Emacs Lisp here doesn't

00:04:40.160 --> 00:04:44.919
attempt to do any, you know, fun, you know, inner rewriting

00:04:44.920 --> 00:04:48.239
or, you know, what's called an Haskell fusion. Like if you

00:04:48.240 --> 00:04:51.359
have two different map steps, like in a row, it's not gonna

00:04:51.360 --> 00:04:55.159
see that and somehow fuse them internally. It's a fairly, in

00:04:55.160 --> 00:04:59.679
that sense, the implementation is just as is.

00:04:59.680 --> 00:05:04.159
to make it you know as raw fast as possible. The idea being

00:05:04.160 --> 00:05:12.839
that ergonomics is more important up front. Yeah, that's

00:05:12.840 --> 00:05:17.519
kind of a whole fascinating sub-panel, right? My theme this

00:05:17.520 --> 00:05:19.799
conference has been, oh, all these different things we

00:05:19.800 --> 00:05:24.039
should try to get sub-panels going for and use that. Maybe

00:05:24.040 --> 00:05:29.039
fill in the dev track or even have a third track or whatever.

00:05:29.040 --> 00:05:31.519
I'm not that concerned about the logistics of squeezing

00:05:31.520 --> 00:05:38.519
into the schedule so much. But anyway, interesting, I mean,

00:05:38.520 --> 00:05:40.839
to say.

NOTE Q: Do you know of any theoretical texts on transducers?

00:05:40.840 --> 00:05:47.799
Did we already speak to theoretical texts? No, right? No,

00:05:47.800 --> 00:05:53.399
let's continue. Okay, so another question from the group.

00:05:53.400 --> 00:05:58.879
Do you know of any theoretical texts on transducers? My

00:05:58.880 --> 00:06:01.959
readme, particularly of the Common Lisp implementation,

00:06:01.960 --> 00:06:06.159
is the theoretical text on transducers. Rich Hickey has

00:06:06.160 --> 00:06:10.439
some YouTube videos which also come close. I mean, he

00:06:10.440 --> 00:06:14.799
invented the things. But in terms of having a full

00:06:14.800 --> 00:06:21.559
explanation of everything, it's my readme and it's also

00:06:21.560 --> 00:06:23.319
the...

00:06:23.320 --> 00:06:28.559
The info manual of Guile Scheme, their documentation on

00:06:28.560 --> 00:06:34.199
Surfy 171 is what I used to learn transducers and to

00:06:34.200 --> 00:06:38.399
re-implement them in other LISPs. So if you just want like a

00:06:38.400 --> 00:06:41.639
document explaining them, MyReadMe is actually the

00:06:41.640 --> 00:06:46.959
clearest that I've found. Awesome. Okay, next question.

00:06:46.960 --> 00:06:50.119
And I'm sorry, you gave a name, you referred to somebody's

00:06:50.120 --> 00:06:55.439
videos. Rich Hickey, the inventor of Clojure. Rich Hickey,

00:06:55.440 --> 00:07:00.399
thank you. Hope I got the spelling right, and maybe somebody

00:07:00.400 --> 00:07:04.719
can catch that and fix it. If not, I'll reach on. Thank you.

NOTE Q: Did you think about [compiler features, macros] viz your cl, fennel, elisp, porting of your transducers?

00:07:04.720 --> 00:07:08.239
Reach on to the next question. Waters (Lazy Series in

00:07:08.240 --> 00:07:12.799
Lisp, late 70s) said this should have been done as an

00:07:12.800 --> 00:07:16.799
additional compiler feature in compilers, but if not, must

00:07:16.800 --> 00:07:21.439
be a macro package. Do you think about that vis your CL,

00:07:21.440 --> 00:07:27.519
Fennel, Elisp, porting of transducers? I think that

00:07:27.520 --> 00:07:28.519
there's definitely

00:07:28.520 --> 00:07:36.519
some Galaxy Brain Lisp author out there is probably smart

00:07:36.520 --> 00:07:40.599
enough to turn a bunch of this stuff into macros. I believe

00:07:40.600 --> 00:07:47.119
that's how the common Lisp library series works. It sees

00:07:47.120 --> 00:07:52.079
that you were calling map or whatever, and it actually knows

00:07:52.080 --> 00:07:56.639
that that's a special macro key. in order to be fast. I did not

00:07:56.640 --> 00:08:01.839
do that. The implementation as I have it is very simple and

00:08:01.840 --> 00:08:05.759
simplicity shouldn't be underestimated.

00:08:05.760 --> 00:08:13.559
I love it. What a nice succinct answer. Even I can manage to

00:08:13.560 --> 00:08:16.578
type that out as I scroll us to the next question.

NOTE Q: Does t-buffer-read provide a lazy stream that's linewise, or charwise, or do something else entirely?

00:08:16.579 --> 00:08:24.079
So, does t-buffer-read provide a lazy stream

00:08:24.080 --> 00:08:28.359
that's line-wise or character-wise or do something else

00:08:28.360 --> 00:08:29.018
entirely?

00:08:29.019 --> 00:08:31.587
Okay, there are two functions. I showed

00:08:31.588 --> 00:08:35.073
t-buffer-read. There's also one called t-file-read,

00:08:35.074 --> 00:08:38.682
which does that. You actually have the buffer open,

00:08:38.683 --> 00:08:40.239
it's much more clever.

00:08:40.240 --> 00:08:45.999
t-buffer-read, I believe, is simpler. As long as you have an

00:08:46.000 --> 00:08:52.079
Emacs list, what is called the current buffer active. I'm

00:08:52.080 --> 00:08:56.679
fairly sure you're able to just call next-line on it. I don't

00:08:56.680 --> 00:08:59.479
believe that I'm doing anything fancy there, looking for

00:08:59.480 --> 00:09:03.999
line ends. I believe I'm just grabbing the next line and then

00:09:04.000 --> 00:09:09.423
processing that line-wise. Very good.

NOTE Q: Can the Elisp library be combined with the stream.el API or seq in general?

00:09:09.424 --> 00:09:17.303
Can the Elisp library be combined with the stream.el API

00:09:17.304 --> 00:09:22.830
or seq in general? I would say that these libraries

00:09:22.831 --> 00:09:27.596
are completely orthogonal. You saw that everything

00:09:27.597 --> 00:09:29.279
was prefixed by t-.

00:09:29.280 --> 00:09:36.879
Basically, transducer is its own zone. However, one thing

00:09:36.880 --> 00:09:40.239
that I do in the common lisp, which is theoretically

00:09:40.240 --> 00:09:44.359
possible for the Emacs Lisp as well, is kind of like little

00:09:44.360 --> 00:09:48.919
shim libraries. So I provide, at least for Common Lisp, for a

00:09:48.920 --> 00:09:51.799
number of, you know, popular sort of third-party

00:09:51.800 --> 00:09:55.239
collection types, I provide an ability to use them as

00:09:55.240 --> 00:09:59.559
sources. Maybe that's what you mean. Like

00:09:59.560 --> 00:10:04.439
the built-in containers for Emacs Lisp are already

00:10:04.440 --> 00:10:06.519
supported. So, you know, a vector hash table and so on.

00:10:06.520 --> 00:10:13.719
make sense so i think what i heard there is yeah go ahead

00:10:13.720 --> 00:10:17.879
please sorry in terms of mixing like you know like for

00:10:17.880 --> 00:10:22.599
instance you know like seq-map used in transducers

00:10:22.600 --> 00:10:28.119
we'll put it that way

00:10:28.120 --> 00:10:31.879
i was just gonna say i think it um it it sounds like you're

00:10:31.880 --> 00:10:37.199
saying Yeah, probably they are actually. We don't know yet

00:10:37.200 --> 00:10:41.239
about any places where they don't play nicely together. So

00:10:41.240 --> 00:10:45.399
quite possibly so. We can use sequence and transducers

00:10:45.400 --> 00:10:49.959
together, for example. As a source potentially, yeah. It's

00:10:49.960 --> 00:10:54.159
very easy because that just uses defgeneric. As long as you

00:10:54.160 --> 00:10:57.719
have a new, like if you have a new collection type, as long as

00:10:57.720 --> 00:11:01.519
you implement a def method for it somewhere, it'll just

00:11:01.520 --> 00:11:12.159
magically work with this library. That's the magic of...

00:11:12.160 --> 00:11:18.439
Yeah, as an Emacs user enjoying, you know, sort of the

00:11:18.440 --> 00:11:21.959
renaissance of new features it's had, or sorry, Emacs ERC

00:11:21.960 --> 00:11:27.799
user for chat. I've seen a lot of awesome stuff get done in the

00:11:27.800 --> 00:11:32.119
last couple of years with generic set. JP never was working

00:11:32.120 --> 00:11:36.679
on that. And like, that's just making me my eyes pop and go,

00:11:36.680 --> 00:11:39.279
wow, that does make a whole lot of things simpler, doesn't

00:11:39.280 --> 00:11:44.279
it? I think we're a lot of us running into generics and how

00:11:44.280 --> 00:11:47.542
that solves problems in Emacs.

NOTE Q: How does one debug a t-comp expression? Can you single step and see intermediate results of the different statements you declare?

00:11:47.543 --> 00:11:50.279
How does one debug a t-comp

00:11:50.280 --> 00:11:55.119
expression? Can you talk in terms of single step,

00:11:55.120 --> 00:11:58.479
step-by-step, intermediate results of the different

00:11:58.480 --> 00:12:08.759
statements you declare? Yes. So in Common Lisp, this is

00:12:08.760 --> 00:12:12.919
and sly stickers and things like that. In Emacs Lisp, it's a

00:12:12.920 --> 00:12:19.559
little bit, shall we say, more difficult. For step

00:12:19.560 --> 00:12:20.479
debugging,

00:12:20.480 --> 00:12:25.679
so what comp does is comp internally, it should be a macro,

00:12:25.680 --> 00:12:28.839
but currently it's not, although there's work to improve

00:12:28.840 --> 00:12:33.559
that. It's doing an internal reduce and it's turning into

00:12:33.560 --> 00:12:37.479
one giant kind of composed lambda inside. So I don't know if

00:12:37.480 --> 00:12:42.999
step debugging would work there. However, we do have one

00:12:43.000 --> 00:12:47.439
function called log, which lets you inspect intermediate

00:12:47.440 --> 00:12:50.759
results. So you could technically use that to inject

00:12:50.760 --> 00:12:54.279
yourself somewhere into the transduction chain and, you

00:12:54.280 --> 00:12:57.239
know, halt or, you know, inspect the current value, et

00:12:57.240 --> 00:13:01.119
cetera. So you get a bunch of questions lined up. I think

00:13:01.120 --> 00:13:04.199
we're coming up, uh, within our last five minutes, uh,

00:13:04.200 --> 00:13:07.919
before some declared, uh, reset time that we have

00:13:07.920 --> 00:13:11.919
internally to just roll our closing credits, so to speak.

00:13:11.920 --> 00:13:14.839
Um, not that I would want to cut the question and answer

00:13:14.840 --> 00:13:18.399
short, but I might have to step away personally. But, um, as

00:13:18.400 --> 00:13:21.519
we discussed before, you can just kind of run the QA, however

00:13:21.520 --> 00:13:24.879
you want here. Um, or, or take questions offline if you'd

00:13:24.880 --> 00:13:27.999
like to answer them off the pad. And I just want to say one more

00:13:28.000 --> 00:13:30.959
time. Kitt said it managed later. Thanks again for your talk

00:13:30.960 --> 00:13:35.759
for dedicating the time to this live QA. And I think we can see

00:13:35.760 --> 00:13:40.279
by the many questions that are here. So I'll try to kind of

00:13:40.280 --> 00:13:42.959
flip us through as many of them as I can with our last couple of

00:13:42.960 --> 00:13:48.399
minutes, if that sounds good. Alternately, this might be a

00:13:48.400 --> 00:13:52.079
good time if you have kind of wrap it up, final thoughts, as

00:13:52.080 --> 00:13:58.399
Leo Sopanda saying. By all means, have at. Sure, thanks a

00:13:58.400 --> 00:14:01.639
lot. I'd say that if you are still curious, check out the

00:14:01.640 --> 00:14:05.159
read-me's because those have a lot of information,

00:14:05.160 --> 00:14:09.519
including a full description of the API and everything

00:14:09.520 --> 00:14:10.719
that's available.

00:14:10.720 --> 00:14:16.599
Otherwise, just give them a shot. Using these things is the

00:14:16.600 --> 00:14:21.639
best way to learn them, of course. I use them everywhere,

00:14:21.640 --> 00:14:24.719
basically, all across my Emacs list and all across my common

00:14:24.720 --> 00:14:29.839
list now. They get a lot of mileage. All right. You're

00:14:29.840 --> 00:14:33.639
speaking our language now. As Emacs users, all our ears poke

00:14:33.640 --> 00:14:36.039
up when you say, I'm getting a lot of mileage. I'm using it

00:14:36.040 --> 00:14:39.879
across everything. Every Emacs user has a story that

00:14:39.880 --> 00:14:42.494
harmonizes with that, I think.

NOTE Q: Is there a path for transducers to enable elisp processing of otherwise overly large datasets as if just normal Emacs \"buffers\" (i.e. just pulling one thing at a time so essentially stream-like under the hood but buffer-like in interface), with none of the usual perf issues with a traditional buffer structure?

00:14:42.495 --> 00:14:44.519
So our next question, is

00:14:44.520 --> 00:14:48.599
there a path for transducers to enable Elisp processing or

00:14:48.600 --> 00:14:53.999
otherwise overly large data sets as if just normal Emacs

00:14:54.000 --> 00:14:56.959
buffers, i.e. just pulling one thing at a time. So

00:14:56.960 --> 00:15:00.719
essentially stream like under the hood, but buffer like an

00:15:00.720 --> 00:15:03.519
interface. I think that makes sense to me. with none of the

00:15:03.520 --> 00:15:07.799
usual performance issues, like as if, you know, the history

00:15:07.800 --> 00:15:11.399
with long files is what that brings to mind, I guess. Yes, so

00:15:11.400 --> 00:15:15.799
as you saw before, the withBufferRead sort of stream

00:15:15.800 --> 00:15:19.879
function does have to have the actual buffer in memory, and

00:15:19.880 --> 00:15:22.679
then you can go really fast. But there's another one with

00:15:22.680 --> 00:15:26.839
file read. Now, again, I haven't tried to optimize that yet.

00:15:26.840 --> 00:15:30.119
But in theory, it is able to read right from the underlying

00:15:30.120 --> 00:15:32.839
file without having to open it as a buffer first.

00:15:32.840 --> 00:15:39.199
Awesome. Ari, the performance issues mentioned, and that

00:15:39.200 --> 00:15:43.479
popped up recently in the list and forums, to what extent

00:15:43.480 --> 00:15:46.959
does tail call optimization and other mechanisms like

00:15:46.960 --> 00:15:50.159
inlining, garbage collection friendliness, and so on,

00:15:50.160 --> 00:15:55.159
could these alleviate issues, enable their use at little to

00:15:55.160 --> 00:15:58.439
no extra costs? I feel like we're leading the witness here,

00:15:58.440 --> 00:16:01.279
but I'm sure you see where we're going. Yeah, no problem. So

00:16:01.280 --> 00:16:03.799
in terms of tail optimization, that's already happening

00:16:03.800 --> 00:16:09.199
because the internal loop mechanism is using CL labels. And

00:16:09.200 --> 00:16:12.199
in Emacs Lisp, CL labels is just a macro that is like

00:16:12.200 --> 00:16:16.079
extremely tail recursive. So that's very, very fast. It's

00:16:16.080 --> 00:16:19.039
not tail recursive, but it's using like goto. So it's

00:16:19.040 --> 00:16:22.519
extremely, extremely fast, like the raw looping of it. So,

00:16:22.520 --> 00:16:24.359
okay, well then where does the slowness come from? It's

00:16:24.360 --> 00:16:26.439
probably coming from those lambdas and it's probably

00:16:26.440 --> 00:16:32.399
coming from, uh, like extra consing, extra allocation

00:16:32.400 --> 00:16:35.999
somewhere, which is, um, sort of what you were, what you're

00:16:36.000 --> 00:16:38.519
referring to with the GC friendliness. So perhaps there's

00:16:38.520 --> 00:16:45.199
some, um, um, yeah, some, like some fusion that I can do to

00:16:45.200 --> 00:16:51.199
speed it up. Yeah, that just sounds fascinating endlessly.

NOTE Q: Is there an option to read a csv/json and produce an alist or plist instead of a hash table for an entry?

00:16:51.200 --> 00:16:55.559
Are there options to like read from a CSV, JSON, produce an

00:16:55.560 --> 00:17:01.679
alist or plist instead of hash table? Absolutely.

00:17:01.680 --> 00:17:06.239
Yes, I need to double check that, but we can read both CSV and

00:17:06.240 --> 00:17:10.359
JSON, and you should be able to just turn on the plist option.

00:17:10.360 --> 00:17:14.159
I will double check, but there's fairly free conversion

00:17:14.160 --> 00:17:18.039
between those three types because hash table is not always

00:17:18.040 --> 00:17:22.039
what you want. And actually, I suspect that slowness that we

00:17:22.040 --> 00:17:24.559
saw in the demo before was because it was allocating hash

00:17:24.560 --> 00:17:29.239
tables for every, like, all of the 50,000 lines. And had it

00:17:29.240 --> 00:17:32.599
been a plist, it would have been faster. Interesting, so

00:17:32.600 --> 00:17:35.399
maybe there's opportunities even if you end up with hash

00:17:35.400 --> 00:17:38.799
lists, but then they're shared strategically and you pay

00:17:38.800 --> 00:17:42.039
the cost of a little extra layer in there that buckets them

00:17:42.040 --> 00:17:46.439
together the way that we might group files by the first four

00:17:46.440 --> 00:17:50.519
characters in the file name once we've got a million files.

NOTE Q: Is the common lisp version ready for 'production' use? Is it complete enough and the API stable enough?

00:17:50.520 --> 00:17:54.479
Anyway, is the Common Lisp version ready for production

00:17:54.480 --> 00:17:59.959
use? Do you want to comment on API stability? I use it all the

00:17:59.960 --> 00:18:04.159
time. I'm writing a game in Common Lisp right now, and I'm

00:18:04.160 --> 00:18:08.559
using transducers everywhere in there, and it doesn't even

00:18:08.560 --> 00:18:11.119
make a dent in the frame rate, and I'm using them

00:18:11.120 --> 00:18:15.359
extensively. Okay, well, I'll just read from chat. Thanks

00:18:15.360 --> 00:18:17.476
so much for the answers.

NOTE Q: Do we need a pre-written \"t-\" version for every already existing reducing function like + or is there a function to construct them from already defined reducer 2-arg functions?

00:18:17.477 --> 00:18:20.439
Do we need a pre-written or t-minus

00:18:20.440 --> 00:18:24.959
version for every already existing reducing function,

00:18:24.960 --> 00:18:30.239
plus, as an example? Or is there a function that constructs,

00:18:30.240 --> 00:18:33.559
in my, I'm going to add the word, auto-visualifies them

00:18:33.560 --> 00:18:37.319
already, auto-defines or something, or just generically

00:18:37.320 --> 00:18:42.239
wraps function calls some way? already defined. This is

00:18:42.240 --> 00:18:49.399
basically fold. Some built-in functions like plus already

00:18:49.400 --> 00:18:52.599
function like reducers. It's a coincidence that they do

00:18:52.600 --> 00:18:56.799
that. But there's an example in the README. Max is one that

00:18:56.800 --> 00:19:00.559
does not act like that. For instance, maybe I could screen

00:19:00.560 --> 00:19:06.479
share later, but if you just type in plus one, If you call plus

00:19:06.480 --> 00:19:10.519
one in Emacs or Common Lisp, you get back one. It actually

00:19:10.520 --> 00:19:15.119
only needs one argument. If you only type plus, it actually

00:19:15.120 --> 00:19:20.839
gives you zero. Plus and multiple satisfy the API of

00:19:20.840 --> 00:19:24.759
reducers. But if you have one that doesn't, like the max

00:19:24.760 --> 00:19:28.759
function, and similarly, just type in plus as a function

00:19:28.760 --> 00:19:32.359
call, just plus with nothing else, and you'll see. No, as a

00:19:32.360 --> 00:19:37.199
function. zero will come out. This basically means it

00:19:37.200 --> 00:19:43.159
satisfies the reducer API. But a function like max does not.

00:19:43.160 --> 00:19:48.399
If you just type in max and then one, it won't work. Pardon me,

00:19:48.400 --> 00:19:54.239
it did. But if you type in max with nothing else, it wouldn't

00:19:54.240 --> 00:19:55.239
work.

00:19:55.240 --> 00:19:58.599
Hence, we have to wrap it in something like fold. I would say

00:19:58.600 --> 00:20:01.919
go look at the fold function. Right, which that I won't do.

00:20:01.920 --> 00:20:04.839
I'm not that well enough prepped. Darn it. Leo would have

00:20:04.840 --> 00:20:08.399
been here, but oh, well, you got me. Yeah, no problem. But

00:20:08.400 --> 00:20:16.879
fold is sort of the ultimate reducer function. Great. So is

00:20:16.880 --> 00:20:26.319
there, where was I? Here we go. We're way past this, right? So

NOTE Q: Is the compelling argument for transducers is that it's a better abstraction?

00:20:26.320 --> 00:20:34.279
is the compiling argument for transducers that it's a

00:20:34.280 --> 00:20:38.879
better abstraction? It seems like there are concerns,

00:20:38.880 --> 00:20:42.399
objections, while problematically valid focused on

00:20:42.400 --> 00:20:45.679
implementation. Can this abstraction allow for advances

00:20:45.680 --> 00:20:50.559
in implementation? Yes, what I've basically done is mostly

00:20:50.560 --> 00:20:55.999
followed the pattern of usage that exists in Clojure and in

00:20:56.000 --> 00:21:01.159
Scheme's SERP 171. In theory, the service level API is the

00:21:01.160 --> 00:21:04.999
same no matter where you're using this, and that's the idea.

00:21:05.000 --> 00:21:08.039
If you learn them in one list, you should be able to use them

00:21:08.040 --> 00:21:12.879
everywhere. Then what it's actually doing under the hood is

00:21:12.880 --> 00:21:18.359
free for us to change around. My implementations are mostly

00:21:18.360 --> 00:21:23.679
based on the scheme with a few alterations here and there.

00:21:23.680 --> 00:21:27.079
And in the Common Lisp case, like adding some Common Lisp

00:21:27.080 --> 00:21:27.959
isms

00:21:27.960 --> 00:21:34.759
to improve usage like UX a little bit. But overall, we are

00:21:34.760 --> 00:21:38.959
free to do whatever we want internally to speed up

00:21:38.960 --> 00:21:42.439
performance. I just haven't done that work. Awesome.

00:21:42.440 --> 00:21:47.239
Awesome. So here's where I have to, where we're getting the

00:21:47.240 --> 00:21:50.079
hook. We've just been pulled off the stream. The viewers

00:21:50.080 --> 00:21:54.079
just saw the crawl by as it sent us over to the other pad where I

00:21:54.080 --> 00:21:57.919
get to jump on and get involved with that now. But I can't

00:21:57.920 --> 00:22:00.359
thank you enough, Colin. Would you like me to stop the

00:22:00.360 --> 00:22:03.799
recording here? Any other comments you'd like to make? Uh,

00:22:03.800 --> 00:22:06.439
yeah, sure. Like, I mean, I'll stick around for any more live

00:22:06.440 --> 00:22:10.639
questions. I'm looking at both IRC and, and, um, uh, big blue

00:22:10.640 --> 00:22:13.239
button here. So if people have more questions, I'll hang

00:22:13.240 --> 00:22:15.959
around for a bit. I'm going to leave the channel open. I see

00:22:15.960 --> 00:22:17.839
you do have a few people in here, so I'm just going to go ahead

00:22:17.840 --> 00:22:20.839
and leave the recording. We can always trim it. Um, trim it

00:22:20.840 --> 00:22:24.279
up. If you, uh, let us know, Hey, the last 10 minutes weren't

00:22:24.280 --> 00:22:26.999
anything, you know, or whatever. No, no pressure, no

00:22:27.000 --> 00:22:29.839
worries, no mistakes. Thank you. Really appreciate you.

00:22:29.840 --> 00:22:31.959
Yep. Thanks a lot.

NOTE Q: Question about how the transducers video was made? Did you use Reveal.js? Do you have a pointer to the html hosted presentation? How did you generate the content for Reveal?

00:22:31.960 --> 00:22:48.399
OK, does anyone else have some questions? I see Mohsen in the

00:22:48.400 --> 00:22:52.839
BigBlueButton chat is asking how I made the video. So the

00:22:52.840 --> 00:22:59.079
presentation itself was done with RevealJS from Org Mode.

00:22:59.080 --> 00:23:03.639
So as you saw, I had a raw Org Mode buffer, which was

00:23:03.640 --> 00:23:09.319
which was the presentation itself, which I then just

00:23:09.320 --> 00:23:11.759
exported with a few certain settings, a few

00:23:11.760 --> 00:23:15.919
customizations. And then for screen recording, I used OBS,

00:23:15.920 --> 00:23:19.719
which worked flawlessly on Arch Linux. I used Sway,

00:23:19.720 --> 00:23:23.159
Wayland, and all of that. So all of that just worked, which

00:23:23.160 --> 00:23:27.999
was very impressive. Where do the HTML host the

00:23:28.000 --> 00:23:51.959
presentation? I don't have that presentation hosted

00:23:51.960 --> 00:23:52.599
anywhere.

00:23:52.600 --> 00:23:59.119
I'll look at the.

00:23:59.120 --> 00:24:00.079
I don't see that.

00:24:00.080 --> 00:24:08.159
Here it is. So we've got the file here as well.

00:24:08.160 --> 00:24:10.999
Looks like that's it for questions, basically.

00:24:11.000 --> 00:24:14.919
Yep, and it looks like everyone's moved on for now. Let's

00:24:14.920 --> 00:24:20.159
see. I mean, it would be so this is answering lounge 81 on IRC.

NOTE Q: From your investigations and tests so far, do you think there would be the necessity of transducers to eventually go down into the C level code for things like using them to solve "infinitely-big" buffer-like interfaces and such?

00:24:20.160 --> 00:24:24.599
Yeah, like, if we really wanted to go that hardcore, maybe

00:24:24.600 --> 00:24:29.439
there's some like C level stuff that we could

00:24:29.440 --> 00:24:36.119
you know, significant demand for such a thing. You know, so

00:24:36.120 --> 00:24:39.239
far there hasn't been such demand, but maybe there will be in

00:24:39.240 --> 00:24:42.519
the future. Yeah, perhaps there's some custom stuff we

00:24:42.520 --> 00:24:43.039
could do.

00:24:43.040 --> 00:24:48.599
And otherwise, magic one.

00:24:48.600 --> 00:25:00.599
Well, it looks like some people are quite happy with this.

00:25:00.600 --> 00:25:14.959
All right. That's about what I've seen. So why don't we end it

00:25:14.960 --> 00:25:19.839
here? I think I can control the recording from my end. If I

00:25:19.840 --> 00:25:23.800
pause it, will that work? All right. Thank you, everyone.