Evolution_of_Emacs_Lisp-PLDI.vtt

WEBVTT

1
00:00:12.340 --> 00:00:13.860
Hi Stefan! Good seeing you!

3
00:00:14.440 --> 00:00:00:16.430
Hi, Mike.  How're you doing?

6
00:00:16.440 --> 00:00:17.480
Pretty good.

7
00:00:17.490 --> 00:00:20.950
I guess we're here to talk about the evolution of Emacs Lisp.

8
00:00:21.440 --> 00:00:23.060
You want to introduce yourself briefly?

9
00:00:24.040 --> 00:00:24.390
Yes.

10
00:00:24.390 --> 00:00:25.720
So I'm Stefan Monnier.

11
00:00:25.720 --> 00:00:30.560
I do research and teaching in programming languages at University of Montreal.

12
00:00:31.140 --> 00:00:31.360
How about you?

15
00:00:32.340 --> 00:00:35.660
Yeah, I'm CEO of a software consultancy in southern Germany.

17
00:00:36.140 --> 00:00:39.920
So how do.. how did we get into this thing writing this paper?

18
00:00:39.920 --> 00:00:40.120
Right.

19
00:00:40.120 --> 00:00:43.860
I think a lot of people that are seeing a paper on the evolution of something..

20
00:00:43.860 --> 00:00:47.150
..something Emacs would expect Richard Stallman to be here.

21
00:00:49.040 --> 00:00:49.790
Right.

22
00:00:49.790 --> 00:00:52.100
Well, at least, you know,
I work in programming languages.

26
00:00:52.100 --> 00:00:56.860
So there is some relationship. I've been contributing to Emacs

27
00:00:56.860 --> 00:00:58.580
for many, many years,

29
00:00:58.580 --> 00:01:00.660
I've been maintainer of Emacs.

30
00:01:00.670 --> 00:01:02.380
So that's how I ended up here.

31
00:01:02.390 --> 00:01:03.460
Okay. I think,

33
00:01:03.460 --> 00:01:08.220
I think I was contacted by Guy Steele and by you to see there was some

34
00:01:08.220 --> 00:01:09.860
interest in working on this.

36
00:01:10.370 --> 00:01:11.070
How about you?

37
00:01:11.070 --> 00:01:12.030
So, you know,

39
00:01:12.040 --> 00:01:14.980
even though I work in the software consultancy today,

40
00:01:14.980 --> 00:01:18.090
I also used to be in research and programming languages many years ago.

42
00:01:18.880 --> 00:01:22.750
I remember when I started working there at the University of Tübingen about 30 years ago,

45
00:01:25.840 --> 00:01:30.830
we were looking at Emacs and we started using X windows and the version of Emacs that existed at the time

46
00:01:30.830 --> 00:01:33.160
would only run in a terminal or an X term.

47
00:01:33.640 --> 00:01:38.400
but there was a version of Emacs that would allow you to open

48
00:01:38.400 --> 00:01:40.660
multiple windows, called Lucid Emacs.

49
00:01:41.040 --> 00:01:46.160
So we started using that and then I think it didn't run on Linux.

51
00:01:46.160 --> 00:01:50.160
We started usually using at the time and I ported that and I started contributing code.

52
00:01:50.160 --> 00:01:55.140
And that kind of segued into me doing more and more development on first Lucid Emacs

53
00:01:55.140 --> 00:01:57.560
and Lucid Emacs was done by a company called Lucid.

54
00:01:57.570 --> 00:01:59.250
That company folded eventually,

55
00:01:59.540 --> 00:02:02.970
and the project moved to Sun Microsystems,
actually,

57
00:02:02.980 --> 00:02:06.840
where it was renamed to XEmacs by the marketing people there.

62
00:02:09.280 --> 00:02:13.600
So I started using Emacs at the time and then I was a programming Languages researcher,

63
00:02:13.600 --> 00:02:17.740
I think.
So,
I think we were like the two people among the recipients of Guy's

67
00:02:18.230 --> 00:02:23.440
email who,
write,
or who used to write papers for living.

70
00:02:23.450 --> 00:02:25.260
And we didn't say no.

71
00:02:26.140 --> 00:02:28.920
Yeah, so it was a lot of work.

76
00:02:31.420 --> 00:02:34.750
But we're here to talk about Emacs Lisp, right?

78
00:02:34.750 --> 00:02:36.190
Not primarily the editor,

79
00:02:36.190 --> 00:02:38.670
but the programming language of the editor.

80
00:02:38.680 --> 00:02:44.310
So how come, how come Lisp is like the language of Emacs?

82
00:02:44.310 --> 00:02:46.060
Or what does that have to do with the editor?

83
00:02:46.070 --> 00:02:46.660
The language?

84
00:02:48.040 --> 00:02:50.940
Yeah, actually, it it's interesting you ask it this way,

87
00:02:50.940 --> 00:02:54.950
because the first language of Emacs was not Lisp,
it was TECO.

90
00:02:56.010 --> 00:02:56.650
It was TECO, yeah. Ok.

92
00:02:58.340 --> 00:03:03.530
So I think Richard Stallman worked on TECO as well.

94
00:03:03.530 --> 00:03:05.880
Or on the TECO version of Emacs at the time.

95
00:03:05.890 --> 00:03:06.470
That's right.

96
00:03:06.480 --> 00:03:12.150
So the first version of Emacs was written by Richard and many others in TECO.

98
00:03:12.840 --> 00:03:16.120
And so I think you have an example ...

99
00:03:16.130 --> 00:03:17.230
I have an example.

100
00:03:17.230 --> 00:03:20.360
So here let's try this fancy switching feature here.

101
00:03:20.370 --> 00:03:25.150
So here's an example of TECO code and you can kind of see, well you get an inkling why

102
00:03:25.150 --> 00:03:29.230
it wasn't Richard Stallman favorite language to put into

103
00:03:29.240 --> 00:03:33.960
the version of Emacs that he then started developing later.

104
00:03:34.240 --> 00:03:40.080
So the code looks fairly cryptic and you can see every single line kind of
requires a comment to explain what it is.

106
00:03:40.440 --> 00:03:45.440
So you can kind of see that it maybe would not scale so well to both to larger code bases

107
00:03:45.440 --> 00:03:49.930
and also to lots of people were interested in doing something with Emacs,

109
00:03:51.040 --> 00:03:54.660
So that explains why it's not TECO, but why is it Emacs Lisp?

110
00:03:56.140 --> 00:04:01.310
Well, Richard was working at MIT

112
00:04:01.320 --> 00:04:05.260
where Lisp was very popular in the in the lab where he was working.

113
00:04:05.260 --> 00:04:07.490
So he was very familiar with Lisp.

114
00:04:07.500 --> 00:04:09.500
He was using Lisp all the time.

115
00:04:09.510 --> 00:04:12.940
He was probably editing Lisp with TECO Emacs.

117
00:04:12.950 --> 00:04:13.860
Okay.

118
00:04:14.540 --> 00:04:15.970
But I think that was you know,

119
00:04:15.970 --> 00:04:18.950
there was the main the main reason for using it.

120
00:04:19.540 --> 00:04:24.060
It was the obvious choice and I think it is to this day it is his favorite language.

121
00:04:24.640 --> 00:04:25.450
Okay.

122
00:04:25.460 --> 00:04:26.500
But I guess,

123
00:04:26.510 --> 00:04:29.580
I mean Richard Stallman also founded the GNU project, right?

125
00:04:29.580 --> 00:04:33.030
And Emacs is kind of the founding piece of software of that project.

128
00:04:33.970 --> 00:04:38.040
So we all know that it's a very political and idealistic project.

129
00:04:38.040 --> 00:04:42.760
So can we can we draw a line from Emacs Lisp to the ideals of the GNU project?

130
00:04:43.740 --> 00:04:44.530
Yeah, I think so.

132
00:04:44.540 --> 00:04:49.170
I think Emacs Lisp really

133
00:04:49.180 --> 00:04:53.690
embodies some of the ideas he has, the idea of empowering the

134
00:04:53.690 --> 00:05:00.450
user and this is a driving line in in the design of Emacs and Emacs Lisp

136
00:05:01.140 --> 00:05:06.060
and also in his promotion of Free Software.

137
00:05:06.640 --> 00:05:12.250
So empowering the user I guess means not just being able to use the software
to its full ability,

139
00:05:12.640 --> 00:05:16.540
but also to be able to customize it and modify it.

140
00:05:16.550 --> 00:05:16.960
Right.

141
00:05:17.740 --> 00:05:18.050
Right.

142
00:05:18.060 --> 00:05:18.290
Yeah.

143
00:05:18.300 --> 00:05:22.290
If you think of the the ideals of Free Software and you have this,

144
00:05:22.300 --> 00:05:27.700
you know,
being allowed to read the code or

146
00:05:27.700 --> 00:05:30.130
study the code and modify the code,

147
00:05:30.130 --> 00:05:31.360
redistribute the code.

148
00:05:31.370 --> 00:05:33.170
This is all all nice.

149
00:05:33.170 --> 00:05:36.360
But for Richard this is actually not sufficient

150
00:05:37.040 --> 00:05:43.550
because you also want it to be fairly easy to do
in practice.

152
00:05:43.560 --> 00:05:48.120
So you also have kind of pragmatic aspect to it.

154
00:05:48.130 --> 00:05:48.850
Okay.

155
00:05:48.860 --> 00:05:51.040
So I guess, today,

158
00:05:51.040 --> 00:05:53.020
when we look at a programming language like Emacs Lisp,

160
00:05:53.220 --> 00:05:55.830
we think of it mainly as a programmers' language.

161
00:05:55.840 --> 00:05:56.260
Right?

162
00:05:56.270 --> 00:06:03.590
I think it wasn't until, you pointed this out to me - let me switch

165
00:06:03.590 --> 00:06:05.860
here to the documentation here.

166
00:06:05.870 --> 00:06:08.080
So you pointed out to me that, well,

168
00:06:08.080 --> 00:06:13.050
here's the introduction of Emacs Lisp as it sits in the Emacs editor and ships with the

169
00:06:13.050 --> 00:06:18.550
editor and says this is an introduction to programming Emacs Lisp for people
who are not programmers.

171
00:06:19.040 --> 00:06:23.910
and I never saw this all these years that I was using

172
00:06:23.920 --> 00:06:28.460
Emacs and XEmacs and that there was actually a fair amount of effort being made

173
00:06:28.470 --> 00:06:32.750
to make it accessible to non-programmers as well.

174
00:06:32.760 --> 00:06:33.100
Right?

175
00:06:33.110 --> 00:06:36.020
I think that's kind of gone out of fashion since then.

176
00:06:36.020 --> 00:06:36.290
Right.

177
00:06:36.290 --> 00:06:39.050
That that ordinary users would program.

178
00:06:39.540 --> 00:06:45.090
It's definitely not in fashion in the world of of Android and Facebook,

180
00:06:45.100 --> 00:06:48.960
you know, empowering the user is definitely not the goal.

182
00:06:49.340 --> 00:06:53.590
But back then it was and also, you know,

183
00:06:53.600 --> 00:06:57.010
he mentioned experience with having, you know,

185
00:06:57.020 --> 00:07:01.950
secretaries using Emacs, and secretaries who had no experience with programming,

186
00:07:01.960 --> 00:07:05.120
to make it clear, and using Emacs and writing

187
00:07:05.120 --> 00:07:09.360
little chunks of ELisp code to customize their editor for their particular use.

188
00:07:09.740 --> 00:07:10.140
That's right.

189
00:07:10.150 --> 00:07:14.960
I think that's always been a very important aspect to Richard.

193
00:07:16.980 --> 00:07:19.050
You know, if you can't program in Emacs Lisp yourself,

196
00:07:19.050 --> 00:07:20.720
you might get somebody else to do it, right,

199
00:07:21.260 --> 00:07:26.140
which is something that you can't do with software that isn't customizable or doesn't have

200
00:07:26.140 --> 00:07:29.260
its own programming language or extension language that comes with it.

201
00:07:29.740 --> 00:07:30.420
That's right.

205
00:07:32.670 --> 00:07:37.330
I work in a lot of sort of digital transformation projects and there I talk to the managers a lot.

206
00:07:37.340 --> 00:07:42.010
This idea that the users would be able to modify or to a larger degree customize the

207
00:07:42.010 --> 00:07:44.820
software is very alien to them.

210
00:07:45.980 --> 00:07:49.600
I wish we would get back to the ideals of Emacs

211
00:07:49.600 --> 00:07:51.550
and Emacs Lisp at some point.

212
00:07:51.840 --> 00:07:54.060
So I guess that's what we're going to talk about today.

213
00:07:55.440 --> 00:07:55.880
Okay.

214
00:07:55.880 --> 00:07:59.860
So I guess we should give a brief overview of what Emacs Lisp is,

215
00:07:59.870 --> 00:08:02.890
at least for the younger people who don't know Lisp in the audience.

216
00:08:02.890 --> 00:08:03.230
Right?

217
00:08:03.240 --> 00:08:07.790
So Emacs Lisp is a Lisp and that means it's instantly

218
00:08:07.790 --> 00:08:10.500
recognizable to anyone.  By the syntax,

219
00:08:10.500 --> 00:08:10.700
right?

220
00:08:10.700 --> 00:08:13.840
The syntax works in that there's a lot of round parentheses,

221
00:08:13.840 --> 00:08:15.680
and also there's prefix notation.

222
00:08:15.690 --> 00:08:19.220
So if you want to add two numbers like 23 and 42,

223
00:08:19.220 --> 00:08:22.820
you write it like this .. open paren operator goes at the front,

224
00:08:22.820 --> 00:08:25.150
then the operations and then close paren.

225
00:08:25.540 --> 00:08:29.110
And you can see I'm typing that into the *scratch* buffer of XEmacs.

228
00:08:29.460 --> 00:08:33.780
And I can just push a button control-J and it will display the result of

229
00:08:33.789 --> 00:08:36.460
evaluating that expression.

230
00:08:36.940 --> 00:08:39.200
And you know, these parentheses,

232
00:08:39.200 --> 00:08:40.250
you can also nest them.

233
00:08:40.250 --> 00:08:41.990
So there's no precedence rules,

234
00:08:41.990 --> 00:08:44.280
like there are in a lot of other programming languages,

235
00:08:44.290 --> 00:08:49.090
and you have like the sum of 23 and the product of

236
00:08:49.090 --> 00:08:50.390
15 and 42.

237
00:08:50.390 --> 00:08:51.070
And again,

238
00:08:51.080 --> 00:08:56.040
I can press control-J and it will instantly display the result of evaluating that.

239
00:08:56.040 --> 00:09:00.460
A lot of people looking at this kind of get scared by all of these parentheses.

240
00:09:00.460 --> 00:09:03.700
But experienced Lisp programmers just look at the indentation.

241
00:09:03.700 --> 00:09:04.720
And in fact, you know,

243
00:09:04.720 --> 00:09:06.460
Emacs will automatically indent if I

244
00:09:06.460 --> 00:09:11.010
press a button, in a way that is pretty much standardized, and 

245
00:09:11.020 --> 00:09:14.560
everybody adheres to that standard when they indent their program.

246
00:09:15.440 --> 00:09:17.840
All right, we could also do like a variable.

248
00:09:17.850 --> 00:09:21.050
So here's a variable, I don't know.

251
00:09:23.640 --> 00:09:28.640
Something like this.  So here's pi.  Right?

255
00:09:28.640 --> 00:09:30.170
And then I can just evaluate Pie.

256
00:09:30.170 --> 00:09:33.710
And it will give me the value that comes with it.

257
00:09:33.720 --> 00:09:35.660
And I could also write a function,

258
00:09:35.670 --> 00:09:35.920
you know,

259
00:09:35.920 --> 00:09:40.590
let me write a function that computes the circumference of a circle with a given radius

260
00:09:40.600 --> 00:09:44.410
might look like this.  And again,

262
00:09:44.410 --> 00:09:47.570
I can evaluate that will define that function and then I can say,

263
00:09:47.570 --> 00:09:50.350
well, what's the circumference of a circle of radius 10?

265
00:09:50.540 --> 00:09:52.800
And it will display the result of that.

266
00:09:52.810 --> 00:09:56.570
So it's not just the fact that it's this programming language with parentheses,

267
00:09:56.570 --> 00:09:57.880
but also with Emacs,

268
00:09:57.880 --> 00:10:02.150
there's also instantly an interactive programming environment for it.

269
00:10:02.640 --> 00:10:07.510
Now you can also locally bind variables in

270
00:10:07.510 --> 00:10:10.730
Emacs Lisp with a construct called let.  So you can do this,

271
00:10:10.740 --> 00:10:16.160
you know? And so 10 and 20 bound to

273
00:10:16.540 --> 00:10:18.520
variables X and Y.

274
00:10:18.530 --> 00:10:21.510
You could evaluate this and get a result.

275
00:10:21.510 --> 00:10:23.260
So that gives me local variables.

276
00:10:23.740 --> 00:10:29.320
And now here's something that I guess nowadays is pretty unique to
Emacs Lisp.

278
00:10:29.330 --> 00:10:35.040
You know, I could write a function called F that takes a parameter called X.

281
00:10:35.050 --> 00:10:37.760
And I could add X to Y.

282
00:10:37.770 --> 00:10:41.110
And now there's no visible binding for Y.  Right?

284
00:10:41.120 --> 00:10:44.590
And of course if I kind of do F of 5.

286
00:10:44.590 --> 00:10:45.680
It will say, oh,

287
00:10:45.690 --> 00:10:46.870
symbol's variable is void,

289
00:10:46.880 --> 00:10:48.960
symbol's value as variable is void.

290
00:10:48.960 --> 00:10:50.560
Why?  Y is not bound.

292
00:10:50.570 --> 00:10:54.510
But I can bind it using let.  Right?

294
00:10:54.510 --> 00:10:56.060
So I can do this.

295
00:10:56.070 --> 00:11:00.870
I can bind Y to 7 and then I can call F of 5

296
00:11:00.880 --> 00:11:03.110
and it will give me the value 12.

297
00:11:03.110 --> 00:11:06.850
And this is a feature known as dynamic scoping.

298
00:11:07.340 --> 00:11:11.020
And you know every every piece of code that we've seen so far, actually,

300
00:11:11.030 --> 00:11:13.940
in Emacs Lisp could also be a MacLisp program.

301
00:11:13.940 --> 00:11:18.560
So MacLisp was one of the predecessors of Emacs Lisp, and was just a regular Lisp implementation that

302
00:11:18.560 --> 00:11:20.910
existed at the time.  Right?

304
00:11:20.990 --> 00:11:26.920
So, so there's a strange thing is that the binding that we do with let

306
00:11:26.930 --> 00:11:29.170
works more like an assignment.  Right?

308
00:11:29.180 --> 00:11:34.170
So, so when F refers to Y it doesn't refer to kind of lexically

310
00:11:34.180 --> 00:11:37.890
bound binding of of Y,

311
00:11:37.890 --> 00:11:41.050
but to the one that was done last at run time.

312
00:11:41.840 --> 00:11:46.150
So there's dynamic scoping and it seems just

313
00:11:46.160 --> 00:11:48.470
very unusual to do that.  Right?

315
00:11:48.470 --> 00:11:53.060
Why?  Why, Stefan, is there dynamic scoping in Emacs Lisp?

317
00:11:54.040 --> 00:11:55.860
Is that a feature or is it a bug?

319
00:11:57.240 --> 00:11:57.980
That is a feature.

320
00:11:58.080 --> 00:12:02.460
Okay, so can you show me something I can actually do with dynamic scoping?

323
00:12:03.680 --> 00:12:05.890
I can show you an example here.

324
00:12:05.900 --> 00:12:07.960
I'm switching to your Emacs.

325
00:12:08.640 --> 00:12:09.260
Yeah.

326
00:12:09.740 --> 00:12:12.080
See it's prettier than XEmacs.

328
00:12:15.140 --> 00:12:18.460
It's boringer than XEmacs, I can say that much.

330
00:12:19.040 --> 00:12:24.230
Okay, so here is an example of an Emacs Lisp package.

332
00:12:24.240 --> 00:12:25.390
Okay,

333
00:12:25.400 --> 00:12:30.230
it chose it somewhat randomly - I was just passing through the other day - and you can see

334
00:12:30.230 --> 00:12:34.560
it has a bunch of variable declarations and then a bunch of function declarations

335
00:12:35.140 --> 00:12:36.790
and I have it here folded

336
00:12:36.790 --> 00:12:38.970
so it doesn't overwhelm you with everything.

337
00:12:38.970 --> 00:12:40.970
But so here, for example,

339
00:12:40.970 --> 00:12:43.900
the isearch-mb--message function,

340
00:12:43.910 --> 00:12:44.890
it doesn't really matter

341
00:12:44.900 --> 00:12:49.770
what it's for, but you can see that the first thing you can see

342
00:12:49.770 --> 00:12:52.390
here is that it has a string at the beginning.

343
00:12:52.400 --> 00:12:53.260
Okay.

344
00:12:53.270 --> 00:12:55.970
And that's not what you were asking me.

345
00:12:55.970 --> 00:12:59.050
But since we see it, I just mentioned it.

347
00:12:59.440 --> 00:13:01.680
So that's a documentation string.

348
00:13:01.690 --> 00:13:03.220
That's a kind of, you know,

350
00:13:03.220 --> 00:13:06.460
ancestor to the JavaDoc style of programming.

351
00:13:06.940 --> 00:13:08.890
It was actually introduced by Richard Stallman,

352
00:13:08.890 --> 00:13:09.960
but not in Emacs Lisp.

353
00:13:10.640 --> 00:13:12.760
It was originally introduced in TECO.

354
00:13:13.440 --> 00:13:18.410
So he added it to TECO and then and then carried it to Emacs Lisp and from there

355
00:13:18.410 --> 00:13:20.180
it spread to other languages.

356
00:13:20.190 --> 00:13:23.490
Okay, so I guess that's another kind of facet of user empowerment.

358
00:13:23.490 --> 00:13:23.720
Right?

359
00:13:23.720 --> 00:13:27.960
That you can then easily look up that documentation and it kind of comes with the code.

360
00:13:28.540 --> 00:13:34.970
Exactly.  So that is something that he found, as you know,

363
00:13:34.980 --> 00:13:38.810
very, very useful for the users.

365
00:13:38.820 --> 00:13:40.860
And the one thing here you wanted,

366
00:13:40.870 --> 00:13:45.550
you asked about, was this message-log-max binding here.

367
00:13:45.560 --> 00:13:46.920
Not because it has this name,

368
00:13:46.920 --> 00:13:51.610
but if you look this variable is not used because .. it's using

369
00:13:51.620 --> 00:13:52.360
dynamic binding,

370
00:13:52.740 --> 00:13:54.060
dynamic scoping.  Sorry.

372
00:13:54.740 --> 00:13:59.470
So this variable is really fundamentally passed as a

373
00:13:59.480 --> 00:14:02.460
configuration argument through the message function here.

374
00:14:02.940 --> 00:14:05.330
The message function here is a kind of printf, you know,

376
00:14:05.330 --> 00:14:08.410
that just displays something in the minibuffer, in the little window

377
00:14:08.410 --> 00:14:13.380
you have at the very bottom here and

378
00:14:13.390 --> 00:14:17.020
as it does that also it kind of records the message in a log somewhere,

379
00:14:17.020 --> 00:14:19.160
So you can recover the messages you've seen in the past.

380
00:14:19.740 --> 00:14:22.010
And message-log-max is a variable

381
00:14:22.010 --> 00:14:25.470
you can use to tell message,

382
00:14:25.480 --> 00:14:30.260
you know how many messages to keep and more specifically in this case to just not log anything.

383
00:14:30.840 --> 00:14:32.590
Okay, so the implementation,

385
00:14:32.600 --> 00:14:36.450
so the implementation of the message function looks at the message-log-max variable.

386
00:14:36.940 --> 00:14:37.810
Exactly.

387
00:14:37.820 --> 00:14:39.820
This is actually in the C code,

388
00:14:39.830 --> 00:14:40.660
you know,

389
00:14:41.240 --> 00:14:43.550
we could show you but I don't think that's the point here.

390
00:14:44.040 --> 00:14:48.710
So so it's looked up in the C code as a normal

391
00:14:48.710 --> 00:14:53.610
variable and here it's bound to affect the behavior of message.

392
00:14:53.620 --> 00:14:55.720
And this is used very commonly,

393
00:14:55.720 --> 00:14:59.910
not specifically for this variable but all kinds of functions have this

394
00:14:59.920 --> 00:15:03.250
extra configuration passed in via dynamic scoping.

395
00:15:03.940 --> 00:15:07.510
Okay. So the alternative to that I guess would be to have, you know,

398
00:15:07.510 --> 00:15:09.960
all the functions have lots of parameters.  Right?

400
00:15:10.340 --> 00:15:15.760
Right.  Or some extra config parameter that's threaded through the code or passed through the code

402
00:15:15.760 --> 00:15:16.380
everywhere.

403
00:15:16.390 --> 00:15:20.710
So that that I guess makes dynamic scoping be a feature.  Right?

405
00:15:20.720 --> 00:15:23.350
Yes.  Very much so.

408
00:15:23.740 --> 00:15:24.250
Okay.

409
00:15:24.260 --> 00:15:26.490
It's used, you know,

411
00:15:26.490 --> 00:15:29.610
it's used in many places in the in the API,

414
00:15:29.920 --> 00:15:32.460
in the core API of Emacs Lisp.

415
00:15:33.040 --> 00:15:37.790
So Stefan, the other day I tried the dynamic scoping example that I had
earlier, that F function,

416
00:15:37.790 --> 00:15:42.630
in GNU Emacs, the Emacs that you're working on, and it it didn't work.

421
00:15:42.640 --> 00:15:44.950
What's the matter?  What's up with that?

423
00:15:45.640 --> 00:15:50.110
Could you type that into your Emacs just so you can ...

424
00:15:50.530 --> 00:15:51.580
defun F ...

425
00:15:51.590 --> 00:15:52.540
Yeah.

426
00:15:53.240 --> 00:15:54.670
Just X

427
00:15:54.670 --> 00:15:55.780
Right.

428
00:15:55.890 --> 00:16:00.740
y and then let Y to seven and call F

429
00:16:00.740 --> 00:16:01.460
with five.

430
00:16:03.040 --> 00:16:06.530
Right so and Okay.

431
00:16:06.540 --> 00:16:06.740
Right.

432
00:16:06.740 --> 00:16:07.070
Right.

433
00:16:07.080 --> 00:16:08.290
Yeah.

434
00:16:08.360 --> 00:16:13.270
Well it's because a few

435
00:16:13.270 --> 00:16:18.250
years back we actually changed the the default scoping to be to be lexical scoping

436
00:16:18.250 --> 00:16:21.060
instead of - or static scoping - instead of dynamic scoping.

437
00:16:21.640 --> 00:16:22.090
Okay.

438
00:16:22.090 --> 00:16:24.760
So of course now this doesn't work anymore.  That's right.

440
00:16:25.740 --> 00:16:29.500
So but I mean there are like

441
00:16:29.500 --> 00:16:32.180
a zillion lines of code written in Emacs Lisp.

442
00:16:32.190 --> 00:16:34.760
Did that all break when you made that change?

443
00:16:35.640 --> 00:16:39.120
It would have if we if we'd changed it just like that.

444
00:16:39.120 --> 00:16:39.700
Yes of course.

445
00:16:39.700 --> 00:16:42.380
But we just added a new dialect instead.

446
00:16:42.390 --> 00:16:45.290
Okay so there's now two dialects of Emacs Lisp.

447
00:16:45.300 --> 00:16:49.180
So there's statically scoped and then there's dynamically scoped Emacs Lisp.

449
00:16:50.530 --> 00:16:53.210
So I guess you found a way to kind of make,

450
00:16:53.220 --> 00:16:58.020
I mean, we said dynamic scoping is a feature and you need it to kind of configure things

451
00:16:58.140 --> 00:17:00.520
um, and add additional parameters,

452
00:17:00.520 --> 00:17:03.040
pass additional parameters into Emacs Lisp functions.

453
00:17:03.050 --> 00:17:06.060
So, um, so I guess you made that work.

454
00:17:06.069 --> 00:17:08.730
Why didn't Stallman do that originally?  Right?

456
00:17:08.730 --> 00:17:10.420
I mean he started working on,

457
00:17:10.430 --> 00:17:13.810
you know this version of Emacs in the 80s and at that time,

458
00:17:13.810 --> 00:17:14.950
you know, Scheme was available,

460
00:17:14.950 --> 00:17:18.089
Common Lisp was available, and every other language on the planet

461
00:17:18.089 --> 00:17:19.859
pretty much used static scoping,

462
00:17:20.339 --> 00:17:21.060
how come?

463
00:17:22.640 --> 00:17:27.339
Well, I think I think it was mostly because; first he had a lot of experience with dynamic scoping.

465
00:17:27.349 --> 00:17:31.970
The group where he was working was using MacLisp and Lisp Machine Lisp.

467
00:17:31.980 --> 00:17:34.550
All of these were using dynamic scoping.

468
00:17:35.140 --> 00:17:39.130
He also, you know, he also liked Multics Emacs,

472
00:17:40.000 --> 00:17:44.360
there were lots of lots of variants of Emacs back then when the new Emacs was started

473
00:17:44.940 --> 00:17:50.850
and I think Multics Emacs was definitely one of the most successful ones.

476
00:17:52.440 --> 00:17:57.200
And Multics Emacs used MacLisp and uses dynamic scoping and in the style of

477
00:17:57.200 --> 00:17:59.160
code, you write in Multics Emacs,

479
00:17:59.540 --> 00:18:02.920
dynamic scoping was also used very, very commonly.

481
00:18:02.930 --> 00:18:05.310
So he had a fair bit of experience.

482
00:18:05.310 --> 00:18:06.480
Also back then, you know,

484
00:18:06.480 --> 00:18:11.270
we should not forget that back then, in this particular context,

485
00:18:11.740 --> 00:18:14.050
dynamic scoping was considered as efficient,

486
00:18:14.740 --> 00:18:19.560
whereas lexical scoping was kind of the new guy on the block and it wasn't

487
00:18:20.040 --> 00:18:22.110
quite clear exactly what they would...

488
00:18:22.120 --> 00:18:26.370
you know, it seems kind of expensive to implement,

490
00:18:26.380 --> 00:18:29.230
there were ideas of how to make it work efficiently,

491
00:18:29.230 --> 00:18:31.520
but you know, it was not as obvious.

493
00:18:31.530 --> 00:18:34.980
Okay, so I guess the point is, with lexical scoping,

495
00:18:34.980 --> 00:18:38.700
you need to create closures when there's a lambda expression in your
program.  Right?

497
00:18:38.710 --> 00:18:45.400
And so you need to package up all the variables used in
the body of the lambda

500
00:18:45.400 --> 00:18:50.110
Right, and then you have to look for them in the different levels of the environment

501
00:18:50.110 --> 00:18:52.550
and depending on how you represent your environment,

502
00:18:52.560 --> 00:18:57.540
at least, it wasn't clear exactly how that should work.

503
00:18:57.550 --> 00:19:01.750
Okay, so, but how did people work for like 20 years,

506
00:19:01.750 --> 00:19:05.890
20, 30 years with just dynamic scoping available to them, right?

508
00:19:05.900 --> 00:19:10.490
If lambda doesn't bind local free variables, then, you know,

511
00:19:10.490 --> 00:19:11.860
that must be a major pain.  Right?

513
00:19:13.740 --> 00:19:21.360
Hmmm, no, you can live... dynamic scoping is perfectly sufficient.

518
00:19:27.040 --> 00:19:32.000
technically there's only two main issues with dynamic scoping,

519
00:19:32.000 --> 00:19:34.270
one of them is name conflict.

520
00:19:35.040 --> 00:19:35.410
Okay.

521
00:19:35.420 --> 00:19:39.060
You have to be more careful how you name your variables.

522
00:19:39.440 --> 00:19:43.960
If we go back to my example of isearch minibuffer,

523
00:19:43.970 --> 00:19:45.860
the isearch-mb package,

524
00:19:46.240 --> 00:19:48.750
you'll see that all the variables declared here,

525
00:19:48.920 --> 00:19:52.730
they all start with isearch-mb.

526
00:19:52.750 --> 00:19:55.540
And so this is basically - we use what we call,

527
00:19:55.540 --> 00:19:59.820
what we call a name space prefix that makes it clear that this variable

528
00:19:59.830 --> 00:20:04.370
belongs to this package and so it tries to avoid

529
00:20:04.370 --> 00:20:08.460
or it aims to avoid conflicts with other packages,

530
00:20:08.460 --> 00:20:11.360
using the same variable for other purposes.

532
00:20:11.370 --> 00:20:11.940
Okay.

533
00:20:11.950 --> 00:20:15.320
So you can still have conflicts within the package,

534
00:20:15.320 --> 00:20:18.170
but you know, presumably the author knows what he's doing

536
00:20:18.540 --> 00:20:19.860
so, it's easy to avoid,

537
00:20:20.440 --> 00:20:24.050
but if you look inside inside functions then you'll see,

538
00:20:24.050 --> 00:20:25.490
for example, here, you know,

541
00:20:25.490 --> 00:20:27.390
we just bind the count variable here,

542
00:20:27.390 --> 00:20:29.340
we bind the len variable.

543
00:20:29.350 --> 00:20:34.850
There's no need for name space prefix for the local variables.

545
00:20:34.860 --> 00:20:36.810
It's not as costly as you'd think.

546
00:20:36.820 --> 00:20:41.700
It makes it reasonably clear when you have a dynamically scoped variable,

547
00:20:41.700 --> 00:20:46.730
like we had here in the example of message-log-max, as opposed to a local variable

549
00:20:46.730 --> 00:20:51.570
that could use lexical scoping or doesn't really matter because it's just local.

550
00:20:51.580 --> 00:20:52.170
Yeah.

551
00:20:52.180 --> 00:20:52.600
Okay.

552
00:20:52.600 --> 00:20:55.360
Can you pull up the example that you just had with the count variable?

553
00:20:55.840 --> 00:20:57.330
Ahh.. right.

554
00:20:57.340 --> 00:21:00.210
So I guess here really, I guess, you know,

557
00:21:00.210 --> 00:21:04.210
the count variable is only used kind of within the lexical extent of the let.

558
00:21:04.220 --> 00:21:06.860
Right. So there,

560
00:21:06.870 --> 00:21:10.210
I mean at least as it pertains to that particular variable,

561
00:21:10.220 --> 00:21:13.940
there's no difference between dynamic and static scoping.  Right?

563
00:21:13.950 --> 00:21:14.260
That's right.

564
00:21:14.270 --> 00:21:19.240
I remember you know in the late 90s when I was

565
00:21:19.240 --> 00:21:20.780
still a research assistant at the university,

566
00:21:20.780 --> 00:21:24.080
we were thinking that in fact a lot of Emacs Lisp code, right,

568
00:21:24.080 --> 00:21:28.710
there's kind of the configuration variables that you have up there that are global,

569
00:21:28.710 --> 00:21:33.690
but kind of when you have purely local bindings are they're usually used in a way that would

570
00:21:33.690 --> 00:21:37.450
work just the same with status scoping and dynamic scoping.  Right?

572
00:21:37.460 --> 00:21:37.820
That's right.

573
00:21:37.830 --> 00:21:41.400
And so you know, we actually did this - shameless plug -

575
00:21:41.410 --> 00:21:46.310
so this is an ICFP paper that I think came out in 2001 

576
00:21:46.310 --> 00:21:51.280
where primarily my student at the time, Matthias Neubauer, implemented an analysis that

577
00:21:51.280 --> 00:21:54.890
would figure out whether kind of static and dynamic scoping would coincide.

578
00:21:54.890 --> 00:21:58.370
He found out that indeed they do coincide for most, you know,

580
00:21:58.370 --> 00:22:00.210
a large percentage, you know,

582
00:22:00.210 --> 00:22:03.540
99 something percent of all the variables.

583
00:22:03.540 --> 00:22:05.050
And so we thought,

584
00:22:05.140 --> 00:22:09.750
I think you did the smart thing by evolving Emacs Lisp into two different dialects

585
00:22:09.750 --> 00:22:14.630
and we just thought we were just going to transform all the code into a form that was

586
00:22:14.630 --> 00:22:19.540
agnostic to whether it was dynamically or statically scoped and then we would just change the

587
00:22:19.540 --> 00:22:24.410
language underneath and the code wouldn't notice.  Alas as it goes with many

588
00:22:24.410 --> 00:22:29.030
things that originate with research that unfortunately never materialized.

589
00:22:29.030 --> 00:22:31.020
Actually, yeah, I was wondering, you know,

592
00:22:31.020 --> 00:22:35.740
back then I thought it was a very promising path

593
00:22:35.750 --> 00:22:40.100
and I'm curious why you didn't go any further.

594
00:22:40.100 --> 00:22:44.200
Matthias graduated is probably the reason.

595
00:22:44.210 --> 00:22:48.340
As it goes, right, as we know how it goes.

596
00:22:48.350 --> 00:22:53.820
It does take many years of dedication to push through such a change.

598
00:22:53.870 --> 00:22:55.510
Yeah.  And to your credit,

600
00:22:55.520 --> 00:22:56.690
you've done that for many years.

601
00:22:56.690 --> 00:23:01.450
Yes, we have seen this on the Emacs side

603
00:23:01.460 --> 00:23:03.640
here you can see on ...

604
00:23:03.640 --> 00:23:05.360
you can go back to my to my example ...

607
00:23:08.620 --> 00:23:09.760
Okay, let me switch.

608
00:23:10.640 --> 00:23:14.680
... so you can see here at the top it says lexical binding colon t.

609
00:23:15.420 --> 00:23:15.810
Okay.

610
00:23:16.640 --> 00:23:19.250
Notice that we actually call it lexical binding and not scoping.

612
00:23:19.250 --> 00:23:22.740
I guess that was a mistake.

613
00:23:22.740 --> 00:23:24.420
And there's a typo.

614
00:23:24.420 --> 00:23:24.610
No,

615
00:23:24.610 --> 00:23:27.420
that's not a typo.

616
00:23:27.430 --> 00:23:32.180
So this is actually the little notes in the file that says

617
00:23:32.190 --> 00:23:36.620
this file is using the new dialect as opposed to the old dynamically scoped dialect.

619
00:23:38.110 --> 00:23:38.960
Okay.

620
00:23:39.940 --> 00:23:43.470
And this was introduced .. this took many years,

622
00:23:43.480 --> 00:23:45.240
this is not, you know,

624
00:23:45.250 --> 00:23:49.850
it's a very simple feature if you think about it and it took many years to introduce.

625
00:23:49.900 --> 00:23:53.050
And again details in the paper.

626
00:23:54.040 --> 00:23:56.980
So, Stefan looking at your code.

629
00:23:56.980 --> 00:23:57.280
Right?

630
00:23:57.280 --> 00:24:00.960
I see that well you're you're assembling a string there.  Right?

633
00:24:00.960 --> 00:24:02.670
With the concat function.  Right?

635
00:24:03.040 --> 00:24:06.580
But then you have this functions called propertize and face.

636
00:24:06.580 --> 00:24:08.350
Can you explain what that piece of code does?

637
00:24:09.240 --> 00:24:09.570
Right.

638
00:24:09.580 --> 00:24:14.270
So in in Emacs Lisp strings don't contain only characters,

639
00:24:14.280 --> 00:24:19.030
but every character can have extra additional properties.

640
00:24:19.040 --> 00:24:20.360
They're called text properties.

641
00:24:20.940 --> 00:24:25.770
And you can use those properties to add all kinds of information to your strings.

642
00:24:26.140 --> 00:24:30.630
One of the important information is this face property which is used to affect

643
00:24:30.630 --> 00:24:32.480
the way the text would be printed

644
00:24:32.480 --> 00:24:35.260
or displayed, if it is to be displayed.

645
00:24:35.840 --> 00:24:36.820
So here, for example,

647
00:24:36.820 --> 00:24:41.740
we place the minibuffer-prompt face onto that text

648
00:24:41.750 --> 00:24:43.050
so that when it's displayed,

649
00:24:43.050 --> 00:24:47.860
it uses a particular color that corresponds to the face

650
00:24:47.860 --> 00:24:49.030
called minibuffer-prompt.

651
00:24:49.040 --> 00:24:51.750
Okay, so I remember in Emacs 18, you know,

654
00:24:51.760 --> 00:24:53.520
early, early nineties, right,

657
00:24:53.530 --> 00:24:54.840
It didn't have properties yet.

658
00:24:54.840 --> 00:24:59.490
So I guess the language evolved to meet the requirements of displaying 

659
00:24:59.490 --> 00:25:02.250
multicolored and multi-font text like that.

660
00:25:02.250 --> 00:25:02.690
That's right.

661
00:25:02.700 --> 00:25:07.560
And so I think that's a good example where for a change of programming language

662
00:25:07.560 --> 00:25:12.090
actually evolves according to the requirements of the users as opposed to the

663
00:25:12.100 --> 00:25:16.070
requirements of the programming language researchers like ourselves.

664
00:25:16.080 --> 00:25:17.420
Yeah, that's right.  That's right.

667
00:25:17.430 --> 00:25:20.250
Okay.  So that's cool.

669
00:25:20.250 --> 00:25:24.860
So there's this fancy string data type but I want to get back to variables just briefly.

670
00:25:25.040 --> 00:25:27.610
So it's not just that we have dynamic scoping, right.

672
00:25:27.620 --> 00:25:32.100
There's another feature kind of baked into the core language called buffer-local variables.

673
00:25:32.100 --> 00:25:33.560
Could you illustrate what that is?

674
00:25:33.640 --> 00:25:37.170
Yeah, I think we have some example here actually.

676
00:25:38.040 --> 00:25:38.490
That's right.

677
00:25:38.490 --> 00:25:45.140
Here we have an example.  Here we see this tool-bar-map variable,

679
00:25:45.150 --> 00:25:49.540
which is assigned a particular value using setq-local.

680
00:25:49.540 --> 00:25:53.930
So setq-local is in this case a particular macro.

681
00:25:53.940 --> 00:25:57.950
But what it does really is actually it sets the variable but, you know,

682
00:25:57.960 --> 00:25:58.940
in a buffer-local way,

683
00:25:58.950 --> 00:26:02.360
which means that it only changes the value in this particular buffer.

684
00:26:03.040 --> 00:26:07.730
So you know, every piece of text is stored

686
00:26:07.740 --> 00:26:13.400
in a buffer and and you always have the current buffer,

688
00:26:13.410 --> 00:26:16.660
you know, whenever you're working in Emacs Lisp,

690
00:26:16.670 --> 00:26:22.050
there's always the current buffer, and the current position within this buffer is part of the normal state.

692
00:26:22.540 --> 00:26:27.140
And so when you look up a variable, a global variable such as this tool-bar-map,

693
00:26:27.150 --> 00:26:31.070
it will look it up in the current buffer.

694
00:26:31.070 --> 00:26:34.260
So every buffer can have a different value for this variable.

695
00:26:34.640 --> 00:26:39.610
Most variables are actually fully global so they have the same value in all buffers

696
00:26:39.610 --> 00:26:43.670
but you can set specific values in specific buffers.

697
00:26:44.040 --> 00:26:48.810
This is used here for this tool-bar-map which is,

699
00:26:49.050 --> 00:26:51.270
the "map" here refers to a key map,

701
00:26:52.150 --> 00:26:57.160
it's a data structure used to say what happens in response to a particular event.

703
00:26:57.840 --> 00:27:02.890
which command, which code should be executed

705
00:27:02.900 --> 00:27:04.860
in response to a particular user event.

707
00:27:05.340 --> 00:27:08.630
So in this case it's what should happen when you use the toolbar.

708
00:27:08.640 --> 00:27:13.020
Actually I think you can't see the toolbar right now 

709
00:27:13.020 --> 00:27:16.510
but Emacs has a toolbar which you can now see at the top.

710
00:27:16.520 --> 00:27:19.930
Okay.  So here you see various buttons.

712
00:27:19.940 --> 00:27:24.810
And so this toolbar is actually created by

713
00:27:24.820 --> 00:27:27.170
a particular Lisp data structure.

715
00:27:27.740 --> 00:27:30.850
And you can you can have.. every buffer can have

716
00:27:30.850 --> 00:27:35.370
a different toolbar to adapt it to the particular content in the buffer.

717
00:27:35.370 --> 00:27:39.640
So if it's a buffer that displays, you know, a normal piece of code,

720
00:27:39.650 --> 00:27:44.040
then you're going to have buttons which are specific to editing code.

721
00:27:44.050 --> 00:27:46.100
But then if your buffer contains,

722
00:27:46.100 --> 00:27:50.860
for example, the list of your your email then you will

723
00:27:50.870 --> 00:27:56.290
have other buttons so that you can create a new mail message or send mail, ...

725
00:27:56.440 --> 00:27:59.550
So that's that's what this setq-local does

726
00:27:59.550 --> 00:28:03.670
It lets you change the toolbar according to which buffer is current.

728
00:28:04.440 --> 00:28:05.640
Alright, so here, really,

730
00:28:05.640 --> 00:28:10.610
the core semantics of the programming language interact with the fact that it's running in an editor.

731
00:28:10.620 --> 00:28:10.920
Right?

732
00:28:10.920 --> 00:28:15.710
This is a feature that probably pretty much no other programming language has.

733
00:28:15.720 --> 00:28:19.370
You really need this concept of buffer and the current buffer and things like that.

734
00:28:19.380 --> 00:28:19.770
Right.

735
00:28:20.440 --> 00:28:20.760
Alright.

737
00:28:21.360 --> 00:28:24.160
Yeah, Emacs Lisp to a large extent is a normal Lisp

739
00:28:24.160 --> 00:28:26.970
but there are a few places where it was adapted to Emacs.

740
00:28:26.980 --> 00:28:29.620
Yeah, that's one of them.

742
00:28:29.630 --> 00:28:34.060
Well, I bet there's interesting interactions between dynamic scoping and
buffer local variables.  Right?

745
00:28:34.440 --> 00:28:35.730
Yes.  Yeah.

747
00:28:35.730 --> 00:28:38.680
There's been lots of bugs over the years.

748
00:28:38.680 --> 00:28:41.670
I think for the last few years it's been stable.

749
00:28:42.340 --> 00:28:43.360
Yes. Yeah.

751
00:28:43.370 --> 00:28:45.660
So and we talk about that in the paper, we should mention.

752
00:28:45.670 --> 00:28:46.500
Right,

753
00:28:46.510 --> 00:28:47.350
okay.

754
00:28:49.040 --> 00:28:50.600
So um apart,

755
00:28:50.610 --> 00:28:52.060
I mean lexical scoping,

756
00:28:52.060 --> 00:28:55.080
I mean you said it's not a big feature but it really is pretty big, right?

758
00:28:55.080 --> 00:28:57.540
It's one of the core parts of language that you changed,

759
00:28:57.550 --> 00:29:01.490
but apart from lexical scoping and you know, I think, you know,

762
00:29:01.490 --> 00:29:04.030
the string representation that we looked at earlier is kind of a detail.

763
00:29:04.040 --> 00:29:08.960
Was there a lot of fundamental evolution of the underlying core language in Emacs Lisp over the years?

764
00:29:10.740 --> 00:29:12.260
No, very little.

766
00:29:12.270 --> 00:29:16.040
Emacs Lisp has been very stable.

767
00:29:16.040 --> 00:29:18.860
If you think in terms of the actual language itself,

768
00:29:18.860 --> 00:29:21.270
the core language has not evolved very much.

769
00:29:21.270 --> 00:29:22.860
The style has changed,

770
00:29:23.340 --> 00:29:25.350
the implementation has changed to some extent,

771
00:29:25.840 --> 00:29:29.170
but the core language has stayed pretty much the same.

772
00:29:29.180 --> 00:29:30.240
So how do they do that?  Right?

774
00:29:30.240 --> 00:29:31.130
I mean, the Haskell people,

776
00:29:31.130 --> 00:29:33.960
they add a new features to the language every week. Right?

778
00:29:33.970 --> 00:29:34.580
pretty much.

779
00:29:34.590 --> 00:29:39.480
So how come with Emacs Lisp there doesn't seem to be a strong call

780
00:29:39.490 --> 00:29:41.460
for extending the core language every week there.

781
00:29:42.140 --> 00:29:43.470
But of course there's, first,

782
00:29:43.470 --> 00:29:46.610
the fact that Emacs Lisp actually is just a tool for Emacs,

783
00:29:46.610 --> 00:29:51.120
so there's no point in improving Emacs Lisp itself,

784
00:29:51.130 --> 00:29:52.210
you know, that's not the goal.

786
00:29:52.220 --> 00:29:55.590
The goal is to improve the editor and the experience

787
00:29:55.600 --> 00:29:56.480
for the end user.

788
00:29:56.490 --> 00:30:02.350
You know, as a language researcher, I like to add things to my language.

792
00:30:04.540 --> 00:30:05.170
But you know,

793
00:30:05.180 --> 00:30:09.660
Richard and Eli, one of the current maintainers, keep reminding us that,

794
00:30:09.670 --> 00:30:12.210
you know, well, this is all nice and good,

798
00:30:12.210 --> 00:30:13.290
but, you know,

800
00:30:13.300 --> 00:30:15.820
can we actually see features for the end user instead?

801
00:30:15.830 --> 00:30:20.010
So that's part of the reason for the stability.

802
00:30:20.020 --> 00:30:23.050
I think the other reason is is that it's not needed.

803
00:30:23.840 --> 00:30:24.180
Okay,

804
00:30:24.180 --> 00:30:25.980
In the sense that we can extend the language,

805
00:30:25.980 --> 00:30:29.060
without changing the core language, if we use macros.

806
00:30:29.070 --> 00:30:31.560
Okay, let me show something there.

809
00:30:32.540 --> 00:30:36.020
I'm just gonna do that in my favorite Emacs for a moment.  Right?

811
00:30:36.030 --> 00:30:39.780
I think the enabling feature that pretty much every Lisp has

813
00:30:39.780 --> 00:30:43.640
is that, you know, program code, program source code,

816
00:30:43.640 --> 00:30:46.340
there's a data structure that looks just the same. Right?

818
00:30:46.350 --> 00:30:49.660
And so if we, for example, have F of 5,

821
00:30:50.040 --> 00:30:53.180
we can add a quote, an apostrophe, to the beginning,

822
00:30:53.190 --> 00:30:57.570
and we have something that evaluates to a piece of data that prints out

823
00:30:57.580 --> 00:31:02.010
exactly like the function-call source code that you see above.  Right?

825
00:31:02.010 --> 00:31:07.560
And so, so program source code can be manipulated via Emacs Lisp code. Right?

828
00:31:07.840 --> 00:31:11.560
And so you could have fancier code and I have an example here.

829
00:31:11.740 --> 00:31:16.660
So here's a slightly fancier piece of code that doesn't just use a quote

830
00:31:16.660 --> 00:31:22.490
but uses a backquote, also one the fundamental features that all Lisps
pretty much have.

832
00:31:22.500 --> 00:31:27.480
And with backquote you can kind of splice little things in there

833
00:31:27.480 --> 00:31:30.230
by evaluating expression inside the quoted form,

834
00:31:30.230 --> 00:31:32.110
so for example, like array-size here,

836
00:31:32.120 --> 00:31:36.700
array-name and init-val.  And then you can see here that,

837
00:31:36.710 --> 00:31:38.920
there's a data type in Emacs Lisp, the symbol,

839
00:31:38.930 --> 00:31:40.080
which when printed out,

840
00:31:40.080 --> 00:31:42.960
looks just like a variable and has exactly the same syntax.

841
00:31:43.340 --> 00:31:44.090
So you can see here,

842
00:31:44.090 --> 00:31:47.130
we bind a bunch of variables and then these variables through the comma here,

843
00:31:47.130 --> 00:31:49.090
get inserted into the output.

844
00:31:49.100 --> 00:31:52.080
And so if I evaluate this, I see a form here.

846
00:31:52.090 --> 00:31:55.910
I mean, never mind that it's a special form called do,

849
00:31:55.910 --> 00:31:58.280
that Stefan you never use, but it's also the same in Scheme,

851
00:31:58.280 --> 00:32:00.050
so I've used it on occasion, [I don't like it!]

853
00:32:00.770 --> 00:32:03.270
and you don't like it.

854
00:32:03.280 --> 00:32:04.730
Yeah, well that's your loss.

856
00:32:04.730 --> 00:32:08.970
But you can see that it's spliced the array-size, for example, in here.

860
00:32:08.980 --> 00:32:09.960
11 here.

861
00:32:10.340 --> 00:32:14.630
And also, you know, init-val is this variable here.

864
00:32:14.640 --> 00:32:18.370
And so so you can assemble program code programmatically.

865
00:32:18.380 --> 00:32:22.090
And not only that; you can turn this into what's called a macro,

866
00:32:22.100 --> 00:32:23.500
as you mentioned.

867
00:32:23.510 --> 00:32:26.610
So a macro looks looks very similar to a function,

868
00:32:26.620 --> 00:32:28.990
but the difference is that, you know,

870
00:32:28.990 --> 00:32:31.020
kind of the function that gets defined here,

871
00:32:31.020 --> 00:32:35.750
gets called by the computer whenever it sees a parenthesized form

872
00:32:35.750 --> 00:32:37.840
that starts with fill-array.  Right?

874
00:32:37.850 --> 00:32:39.950
So if I do this I can then go ... 

875
00:32:39.960 --> 00:32:44.710
an array is kind of the sequence abstraction in Emacs

876
00:32:44.720 --> 00:32:46.850
so I can define a variable here.

877
00:32:46.850 --> 00:32:52.230
That's a string, which is also a kind of sequence.

879
00:32:52.230 --> 00:32:55.460
And I can use this fill-array form and it will

880
00:32:56.240 --> 00:33:00.920
just execute and we can see that it overwrites all the

881
00:33:00.920 --> 00:33:05.830
characters in the string by 65, essentially by expanding into

884
00:33:06.140 --> 00:33:09.560
this new form that we saw above and and compiling that, right?

886
00:33:09.840 --> 00:33:13.110
And we can also kind of see what it's doing,

888
00:33:13.110 --> 00:33:15.620
we can call a function called macroexpand,

889
00:33:15.620 --> 00:33:19.300
which will just say, see, you know, show us that, you know,

894
00:33:19.300 --> 00:33:23.250
the fill-array forum evaluates into core code here.

895
00:33:23.250 --> 00:33:25.600
And we can see that do was also a macro.

896
00:33:25.600 --> 00:33:29.600
It expands into that let-while combination that we see here.

897
00:33:29.610 --> 00:33:33.170
And so it's pretty easy with the facilities of the language.

898
00:33:34.040 --> 00:33:37.850
Yeah, talking about this actually, that reminds me have, you know,

902
00:33:38.240 --> 00:33:41.980
rather than manipulate code during macro expansion,

903
00:33:41.990 --> 00:33:44.500
we can manipulate code as data, you know,

905
00:33:44.510 --> 00:33:47.400
during run time and in Emacs Lisp with dynamic scoping

906
00:33:47.400 --> 00:33:49.560
we could do things like this.

907
00:33:50.240 --> 00:33:55.560
I really could say, let's say, you know,

911
00:33:55.940 --> 00:33:59.270
this is our function that adds 42.

913
00:34:00.280 --> 00:34:01.440
Have all my parentheses.

914
00:34:01.450 --> 00:34:05.130
So it's like a data structure that looks like a lambda expression, okay?

916
00:34:05.140 --> 00:34:08.230
Right. Exactly. That's what you manipulate typically at macro expansion time.

920
00:34:08.230 --> 00:34:08.460
Right?

921
00:34:08.840 --> 00:34:11.130
But you can actually use it at run time directly.

922
00:34:11.139 --> 00:34:15.920
I can funcall this function directly, which is actually not a function.

924
00:34:15.920 --> 00:34:20.469
It's a list, I can funcall the list and it does give me the 46 you would expect.

925
00:34:20.940 --> 00:34:23.300
Okay, that's bizarre.

927
00:34:23.310 --> 00:34:26.639
So, it has to be kind of whenever it calls a function,

929
00:34:26.639 --> 00:34:29.449
it has to check whether well, it's not actually a function,

931
00:34:29.449 --> 00:34:30.270
but it's a list.

932
00:34:30.270 --> 00:34:33.730
And maybe that list looks like the source code of a function.

934
00:34:34.480 --> 00:34:39.590
This is because originally this is exactly how functions were represented at run time.

936
00:34:39.600 --> 00:34:46.590
There was no difference between, you know, the S-exp that represents

939
00:34:46.590 --> 00:34:49.590
the number and the actual value.

940
00:34:49.600 --> 00:34:53.670
So the, the evaluation of a lambda that was just the lambda itself,

943
00:34:53.670 --> 00:34:54.960
the lambda list.

944
00:34:55.540 --> 00:34:59.700
So that's like the ultimate abstraction leak. Right?

947
00:34:59.710 --> 00:35:03.520
The representation of abstractions themselves leak.

948
00:35:03.530 --> 00:35:04.260
Exactly.

949
00:35:04.270 --> 00:35:05.290
Okay.

950
00:35:05.300 --> 00:35:06.390
So of course,

951
00:35:06.390 --> 00:35:08.010
when byte code was introduced,

952
00:35:08.020 --> 00:35:13.470
it was a notion of a real actual function object distinct from a list.

954
00:35:14.340 --> 00:35:15.470
But that stayed,

955
00:35:15.470 --> 00:35:17.260
because a lot of code existed,

956
00:35:17.300 --> 00:35:20.550
there's a lot of code that quotes lambdas with a quote.

957
00:35:21.140 --> 00:35:25.570
We don't actually need to quote lambdas because lambda itself is a macro that just adds

958
00:35:25.570 --> 00:35:27.660
a little "function" around it.

959
00:35:27.670 --> 00:35:29.060
And we can actually see it here.

960
00:35:29.540 --> 00:35:32.560
Let's see where is it, so lambda...

962
00:35:36.440 --> 00:35:37.460
So if I go see.

963
00:35:38.040 --> 00:35:39.640
Look at the definition of lambda.

964
00:35:39.880 --> 00:35:40.860
Oh, look at that.

967
00:35:43.240 --> 00:35:48.360
Okay. Here we are.  There's a lot of docstring.

972
00:35:49.440 --> 00:35:54.360
And then we see the definition just adds "function" in front of the lambda.

974
00:35:57.120 --> 00:35:59.660
The "function" means it's going to get compiled, right?

976
00:36:00.030 --> 00:36:00.570
Hopefully.

977
00:36:00.580 --> 00:36:06.430
Well, the "function" means that it quotes it as a function instead of quoting it as raw data.

981
00:36:07.910 --> 00:36:11.570
So the byte compiler is going to see that this is a function and can byte-compile it,

982
00:36:11.570 --> 00:36:11.980
exactly.

985
00:36:14.060 --> 00:36:19.120
But presumably because this was, you know,

987
00:36:19.130 --> 00:36:24.030
this didn't exist at the very beginning of Emacs.

990
00:36:25.230 --> 00:36:28.550
The habit of just using quote to quote lambdas stuck.

993
00:36:31.580 --> 00:36:35.010
So even even nowadays you can still see a lot of code,

994
00:36:35.020 --> 00:36:38.500
and if you if you look for it on the web even more, you know,

997
00:36:38.500 --> 00:36:43.240
there's lots of lots of code snippets that have the lambda quoted with a little quote.

998
00:36:43.630 --> 00:36:48.350
Okay, I bet that's a pain for your static scoping stuff, right?

1001
00:36:48.360 --> 00:36:49.380
Exactly, exactly!

1003
00:36:49.380 --> 00:36:52.950
For dynamic scoping, this doesn't really matter because,

1005
00:36:52.960 --> 00:36:56.490
you know, the code, it doesn't need to know anything.

1008
00:36:56.500 --> 00:36:57.600
You know, you don't need to compile it

1010
00:36:57.610 --> 00:37:00.750
specially in order to to preserve dynamic scoping.

1011
00:37:01.430 --> 00:37:04.550
But for static scoping you actually need your..

1013
00:37:04.560 --> 00:37:07.040
when you evaluate your lambda, you need to capture the environment, right?

1016
00:37:07.630 --> 00:37:09.600
Yeah.  Oh yeah!

1018
00:37:09.600 --> 00:37:12.340
You need to create a closure.  You can't do that when you just have the source code.

1019
00:37:12.830 --> 00:37:14.630
When you just have the quote,

1021
00:37:14.640 --> 00:37:18.280
the evaluation of the quote by definition just returns the list

1022
00:37:18.280 --> 00:37:21.050
and has no opportunity to capture the environment.

1024
00:37:22.260 --> 00:37:23.300
And of course, the same thing,

1025
00:37:23.300 --> 00:37:28.180
the compiler can't look inside and see that there's a reference to some of the variable which were

1026
00:37:28.180 --> 00:37:29.550
renamed and those kinds of things.

1027
00:37:29.930 --> 00:37:33.400
Okay.  So it's incompatible with lexical scoping and introduces,

1029
00:37:33.410 --> 00:37:38.520
you know,
a fair bit of pain when doing the conversion of going

1031
00:37:38.520 --> 00:37:40.910
from the old dialect to the new dialect.

1032
00:37:40.920 --> 00:37:44.040
Okay. So here's an evolution that still needs to happen, right,

1035
00:37:44.040 --> 00:37:46.230
the evolution of coding style in Emacs Lisp.

1036
00:37:46.240 --> 00:37:47.750
It's still ongoing, yes.

1040
00:37:48.980 --> 00:37:53.690
We've fixed those within the actual code base of Emacs by now

1041
00:37:53.700 --> 00:37:56.240
actually it's recently that we finished doing that,

1043
00:37:57.780 --> 00:38:00.650
but in the code out there, it's still,

1045
00:38:01.820 --> 00:38:04.700
it will be around us for another 20 years at least.

1046
00:38:04.710 --> 00:38:06.450
Okay,  Wow.

1048
00:38:08.320 --> 00:38:12.410
Okay.  So talking about Emacs Lisp within the context of Emacs is fine.

1050
00:38:12.410 --> 00:38:18.320
But also XEmacs for many years was the more featureful implementation with

1052
00:38:18.330 --> 00:38:23.070
graphical bells and whistles and what happened at the

1053
00:38:23.070 --> 00:38:28.240
language level in terms of maybe of implementation or of the language itself,

1055
00:38:29.020 --> 00:38:30.150
can you tell us something about it?

1056
00:38:31.020 --> 00:38:35.280
Well, I mean the focus in the development of Lucid Emacs

1058
00:38:35.280 --> 00:38:36.780
which is what it was called back then,

1059
00:38:36.780 --> 00:38:38.350
wasn't so much on the surface language,

1060
00:38:38.350 --> 00:38:41.710
but there were a few novel things that happened on the implementation side.

1061
00:38:41.720 --> 00:38:47.150
I think one of the first things that happened was that James Zawinski wrote
a new byte-code compiler,

1063
00:38:47.620 --> 00:38:52.240
that ended up in Lucid Emacs and I think later migrated back

1064
00:38:52.250 --> 00:38:53.770
into GNU Emacs.

1066
00:38:54.730 --> 00:39:01.020
I think one other notable difference has to do with when Emacs starts up.
Right?

1069
00:39:01.030 --> 00:39:02.960
So Emacs, when it starts up,

1071
00:39:02.970 --> 00:39:06.840
a whole bunch of Lisp code has to be present in order for it to work properly.

1072
00:39:07.020 --> 00:39:11.880
And we don't want to compile or evaluate or even load all that Lisp code each time

1073
00:39:11.880 --> 00:39:16.640
the editor starts up, or at least we didn't want to do that in the nineties

1074
00:39:16.650 --> 00:39:18.730
when computers were still slower. Right?

1076
00:39:18.740 --> 00:39:20.720
You still don't want to do that.  Yeah.

1078
00:39:20.730 --> 00:39:23.430
So the idea is that you would fire up ...

1079
00:39:23.430 --> 00:39:24.710
so during the build process, right,

1080
00:39:24.710 --> 00:39:29.310
you would fire up Emacs or XEmacs and load all that Lisp code and then somehow

1081
00:39:29.310 --> 00:39:35.560
dump, you know dump Emacs so that you could then start up much faster.

1084
00:39:35.570 --> 00:39:40.090
And the way it was originally done was, there was a very operating-system specific facility

1085
00:39:40.090 --> 00:39:44.510
that dumped the operating system process

1086
00:39:44.520 --> 00:39:47.750
to disk and then be able to start that up again.

1087
00:39:47.760 --> 00:39:52.740
And I remember that being very fragile and I remember, you know

1088
00:39:52.750 --> 00:39:57.670
spending countless hours debugging AiX code because some field

1089
00:39:57.670 --> 00:40:01.250
in the binary format had shifted or something like that.

1090
00:40:01.260 --> 00:40:06.010
And there was a long-running effort in XEmacs to

1091
00:40:06.010 --> 00:40:10.810
improve on the internal data representation to make it possible to just dump

1092
00:40:10.820 --> 00:40:15.820
the heap of XEmacs and then be able to load that heap quickly into the running process later.

1093
00:40:15.830 --> 00:40:20.800
And the way that that happened was that you know

1094
00:40:20.800 --> 00:40:25.640
every object would get a run time description of the runtime

1095
00:40:25.640 --> 00:40:30.460
format that was written and that was then used to write out the heap representation

1096
00:40:30.460 --> 00:40:32.330
to be able to load it back in.

1097
00:40:32.810 --> 00:40:36.720
I remember we were doing that just by ourselves for XEmacs.

1100
00:40:36.960 --> 00:40:39.330
Did something similar happened with GNU Emacs?

1101
00:40:40.610 --> 00:40:42.790
Actually it happened just a few years ago,

1102
00:40:42.800 --> 00:40:47.560
so we suffered through the what was called the "unexec" process

1103
00:40:47.560 --> 00:40:52.280
of figuring out some way to dump the

1104
00:40:52.280 --> 00:40:56.550
state of the process into a form that can be started again.

1105
00:40:56.560 --> 00:40:56.990
Okay.

1106
00:40:56.990 --> 00:41:00.880
And only a couple of years ago that was changed in Emacs version 27

1107
00:41:00.890 --> 00:41:02.900
that came out fairly recently.

1108
00:41:02.910 --> 00:41:04.120
Wow. Okay.

1110
00:41:04.130 --> 00:41:05.850
I was curious what about those,

1111
00:41:05.860 --> 00:41:09.640
you know, those data structures you say that describe the data to help dump it.

1112
00:41:09.640 --> 00:41:11.940
Were they used for something else?

1113
00:41:12.410 --> 00:41:16.090
Yeah, well we also used them then to feed the garbage collector right?

1115
00:41:16.090 --> 00:41:20.890
To tell the garbage collector what the object layout was and that enabled us
to implement a new garbage collector.

1116
00:41:20.890 --> 00:41:23.830
Actually one of my students, Marcus Crestani,

1117
00:41:23.830 --> 00:41:26.720
developed an incremental garbage collector because one thing

1118
00:41:26.720 --> 00:41:31.530
that people really really hated in Emacs and XEmacs was when there was a message appearing

1119
00:41:31.530 --> 00:41:33.520
that said "garbage collecting", right?

1120
00:41:33.520 --> 00:41:36.430
And then you knew you were in for a little wait,

1121
00:41:36.440 --> 00:41:39.510
and even if it was just a one-second wait it was annoying.

1122
00:41:39.510 --> 00:41:40.940
So we fixed that in XEmacs.

1125
00:41:41.220 --> 00:41:45.080
By just having an incremental collector that got rid of the pauses, right?

1127
00:41:45.090 --> 00:41:48.230
I don't know about the "just" because that seems like a lot of work.

1128
00:41:48.240 --> 00:41:51.430
We fixed it in a simpler way.  We just removed the message.

1130
00:41:53.110 --> 00:41:58.050
Wow.  Well.  Okay.  So when I use GNU Emacs

1131
00:41:58.050 --> 00:42:02.090
I sometimes I wait but I don't know who to blame.

1132
00:42:02.100 --> 00:42:03.180
So now I know.

1134
00:42:04.560 --> 00:42:09.320
Maybe there's one notable difference really on the language side

1135
00:42:09.320 --> 00:42:13.290
that is significant between GNU Emacs and XEmacs, right?

1137
00:42:13.290 --> 00:42:15.620
When Lucid Emacs was originally developed,

1138
00:42:16.000 --> 00:42:20.150
a few of the things that were relevant for windowing got their own data structures.

1139
00:42:20.150 --> 00:42:23.500
So let me try to show that here.  So here's my XEmacs.

1144
00:42:24.600 --> 00:42:27.400
So one example is for example the mode map, right?

1146
00:42:27.410 --> 00:42:31.580
Emacs at the time just represented characters as numbers and 

1147
00:42:31.590 --> 00:42:37.950
so the idea was that you would have a mode map which was a keymap.

1149
00:42:37.960 --> 00:42:40.840
It would map key bindings to functions that were called.  Right?

1151
00:42:40.850 --> 00:42:43.990
And if you evaluate something like lisp-mode-map,

1152
00:42:43.990 --> 00:42:48.980
you can see that there's like a hash mark and then there's angle brackets and

1153
00:42:48.980 --> 00:42:53.810
they show you that there is an internal data structure that represents the keymap

1154
00:42:53.810 --> 00:42:58.810
and that was a departure from the way it was in GNU Emacs, right?

1156
00:42:58.810 --> 00:43:01.180
And I think it still is that way in GNU Emacs to this day?

1159
00:43:02.000 --> 00:43:05.020
Oh yes, very much so.  You can't see the mode map?

1162
00:43:05.970 --> 00:43:08.230
For us, you know, we actually see the map.

1165
00:43:08.800 --> 00:43:09.430
Okay.

1166
00:43:09.440 --> 00:43:11.230
Oh, it's a list.

1168
00:43:11.240 --> 00:43:15.310
So, of course, what else?  Another abstraction leak right there.

1169
00:43:15.320 --> 00:43:15.850
Right.

1170
00:43:15.860 --> 00:43:24.040
And you know, I think it goes to the core of the design of Emacs and Emacs Lisp.

1173
00:43:24.700 --> 00:43:25.100
Okay.

1174
00:43:25.110 --> 00:43:27.190
You know, we were talking about you know,

1176
00:43:27.200 --> 00:43:31.690
the idea of Free Software and how it influenced the design of Emacs.

1177
00:43:31.700 --> 00:43:33.230
I think there's you know,

1178
00:43:33.240 --> 00:43:37.980
there was a very clear and there still is a clear desire to try to

1179
00:43:37.990 --> 00:43:39.750
avoid abstraction boundaries.

1180
00:43:39.760 --> 00:43:40.440
Okay.

1181
00:43:40.450 --> 00:43:41.790
If you want to have, you know,

1183
00:43:41.800 --> 00:43:44.520
you want to have abstraction just by a convention.

1184
00:43:45.000 --> 00:43:49.700
So you want to have data structures which you can look inside

1185
00:43:49.700 --> 00:43:54.700
and dig in and you see all the messy details and change them as much as you want if you want to.

1186
00:43:54.700 --> 00:44:00.300
You still want to have some kind of abstraction on top of it,
so you don't have to do that.

1188
00:44:00.790 --> 00:44:04.210
But there's no effort to try to hide it to make it opaque.

1189
00:44:04.890 --> 00:44:05.200
Right.

1190
00:44:05.200 --> 00:44:10.110
But at the time there was a lot of code which was aware of the fact that keymaps

1191
00:44:10.110 --> 00:44:13.660
were lists and just manipulated them using the list functions. Right?

1193
00:44:13.660 --> 00:44:15.850
And we got rid of that for Lucid Emacs, right?

1195
00:44:15.860 --> 00:44:19.930
But it also means, I mean, you're talking as though that's, you know,

1198
00:44:19.930 --> 00:44:24.000
it's a win-only situation where users are empowered.

1200
00:44:24.290 --> 00:44:25.880
But the problem is of course,

1201
00:44:25.880 --> 00:44:30.430
you probably have a very hard time ever changing the format of these data structures,

1202
00:44:30.430 --> 00:44:30.860
right,

1203
00:44:30.870 --> 00:44:33.110
should that prove advantageous.

1204
00:44:33.690 --> 00:44:35.630
Yeah, that's true.  Actually,

1206
00:44:35.630 --> 00:44:41.310
we changed, we extended the format of the keymaps for Emacs 24, I think,

1209
00:44:41.690 --> 00:44:45.690
so that they could have several parents like in XEmacs.

1210
00:44:45.690 --> 00:44:46.380
You know, there's, you know,

1213
00:44:46.390 --> 00:44:50.540
keymaps have have a notion of a hierarchy where the keymap can have a parent keymap.

1214
00:44:50.550 --> 00:44:53.890
So until Emacs 24 for there was only one parent.

1215
00:44:53.890 --> 00:44:58.810
Then we tried to add more and that was pretty difficult to retrofit without
breaking existing code

1216
00:44:58.810 --> 00:45:00.310
because you had ... yeah.

1218
00:45:01.350 --> 00:45:04.820
And so that's a lot easier when you have abstraction boundaries.

1219
00:45:04.830 --> 00:45:09.300
But I guess this is about making life easier for the developer, not so much the users maybe.

1220
00:45:09.690 --> 00:45:11.810
So there's an interesting tradeoff there.

1222
00:45:13.190 --> 00:45:18.030
You mentioned the fact that you use conventions in order to

1223
00:45:18.040 --> 00:45:20.040
deal with abstraction boundaries, right?

1225
00:45:20.050 --> 00:45:21.340
And the obvious place

1226
00:45:21.350 --> 00:45:26.320
that we should talk about has to do with the module system, right?

1228
00:45:26.320 --> 00:45:30.120
Lots of people are developing packages for Emacs. You know,

1230
00:45:30.120 --> 00:45:34.700
there's surely more than a couple of million lines of code of external

1231
00:45:34.700 --> 00:45:37.510
packages for Emacs that people load all the time.

1232
00:45:37.890 --> 00:45:40.920
How do we deal with this these days?

1236
00:45:43.000 --> 00:45:43.990
That is a good question.

1238
00:45:44.500 --> 00:45:49.610
So we go back to this "isearch-mb" example.

1240
00:45:49.620 --> 00:45:55.420
You can see right right away what is the solution we settled on.

1242
00:45:55.890 --> 00:46:02.240
We just have a kind of poor man's namespace construct where every function,

1244
00:46:02.250 --> 00:46:05.400
every global function and global variable definition

1247
00:46:07.080 --> 00:46:09.750
has to start with a prefix, which we call a name prefix,

1249
00:46:10.040 --> 00:46:14.950
a namespace prefix.  There's nothing magical about it, you know,

1252
00:46:14.950 --> 00:46:19.860
we just use usually the file name and then a dash or something like this

1253
00:46:21.380 --> 00:46:25.910
and people have to follow that principle and not everybody follows it in this.

1254
00:46:25.920 --> 00:46:27.160
There's sometimes some surprises,

1255
00:46:27.160 --> 00:46:29.210
but over the years it has served us very well.

1256
00:46:29.580 --> 00:46:31.710
Okay, that's pretty amazing, right?

1259
00:46:31.710 --> 00:46:34.420
Because if you believe all the module systems people,

1261
00:46:34.420 --> 00:46:36.500
and all the ML researchers and so on,

1262
00:46:36.500 --> 00:46:41.070
its impossible to manage a couple of million lines of code using just social conventions and

1263
00:46:41.070 --> 00:46:45.210
without the abstraction boundaries of like a module system with strong interfaces.

1264
00:46:47.180 --> 00:46:47.760
Yeah, I'm not sure.

1266
00:46:47.760 --> 00:46:52.030
exactly why they think it's necessary.

1267
00:46:52.040 --> 00:46:53.560
Clearly, it's convenient,

1269
00:46:53.570 --> 00:46:56.040
it's convenient to be able to use whichever name,

1270
00:46:56.040 --> 00:46:57.710
and also to be able to use short names.

1271
00:46:58.180 --> 00:47:02.200
Part of it is probably has to do with just the syntax of Lisp

1272
00:47:02.780 --> 00:47:07.440
that doesn't make it too painful to have long function names where the

1273
00:47:07.450 --> 00:47:10.710
indentation and those kinds of things plays reasonably well,

1274
00:47:11.080 --> 00:47:15.050
because you can easily have the arguments below the function instead of on the side,

1275
00:47:15.050 --> 00:47:19.410
I guess something like this, but to a large extent is just,

1277
00:47:19.420 --> 00:47:21.670
you know, you see extra, you know, you have

1280
00:47:21.680 --> 00:47:26.580
your function and global variables with longer name than what you would

1281
00:47:26.590 --> 00:47:32.300
ideally have, but we live with this very successfully.

1283
00:47:32.470 --> 00:47:36.680
There's constantly pressure to try to introduce

1284
00:47:36.690 --> 00:47:40.500
some new mechanism for having an actual namespace,

1285
00:47:41.280 --> 00:47:42.800
but it still hasn't happened yet.

1286
00:47:43.580 --> 00:47:47.690
Okay. So yeah,

1288
00:47:48.380 --> 00:47:51.250
I think the next 20 years are gonna be interesting, right?

1290
00:47:51.250 --> 00:47:52.490
There's pressure to make changes.

1291
00:47:52.490 --> 00:47:54.710
On the other hand, the language has stayed very stable.

1294
00:47:55.860 --> 00:47:59.890
Actually there's a good argument for keeping the long names.

1296
00:47:59.900 --> 00:48:03.550
One of the strongest argument is that, you know,

1298
00:48:03.560 --> 00:48:05.860
on the side of the tooling.

1299
00:48:05.870 --> 00:48:10.850
It makes the tooling much easier because you don't need to pay attention to the context

1300
00:48:10.850 --> 00:48:13.590
in order to know what is the meaning of each identifier.

1301
00:48:13.670 --> 00:48:15.500
So when you look for a function,

1304
00:48:15.720 --> 00:48:18.390
if you look at the function "isearch-mb--after-change"

1305
00:48:19.170 --> 00:48:20.030
that's the function.

1306
00:48:20.030 --> 00:48:21.290
You know, you don't have to say

1308
00:48:21.290 --> 00:48:26.270
in which namespace am I.  Should I look for other uses that

1309
00:48:26.270 --> 00:48:28.080
correspond to this particular namespace,

1310
00:48:28.670 --> 00:48:33.320
which also means that you can do searches with tools that know nothing about your language.

1311
00:48:33.330 --> 00:48:34.200
Yeah,

1312
00:48:34.210 --> 00:48:39.000
like I can go on DuckDuckGo and search for "isearch-mb--after-change".

1313
00:48:39.970 --> 00:48:43.390
They can give me actual results, actual matches.

1315
00:48:43.870 --> 00:48:46.570
Yeah, I agree.  That's an advantage.

1318
00:48:46.580 --> 00:48:49.980
So, Stefan, I think we're pretty much out of time,

1321
00:48:49.990 --> 00:48:53.240
so we should wrap this up.  Right?

1323
00:48:53.250 --> 00:48:56.750
So Emacs Lisp has seen a great deal of evolution,

1324
00:48:56.750 --> 00:48:58.920
is staying remarkably stable.

1325
00:48:58.930 --> 00:49:03.520
I'm looking forward to another 20 years of Emacs on my

1326
00:49:03.520 --> 00:49:06.590
desktop and programming Emacs Lisp in 20 years.

1327
00:49:08.070 --> 00:49:08.870
Yes, same thing.

1329
00:49:08.870 --> 00:49:13.320
I think evolution has been very limited at the core level,

1330
00:49:13.320 --> 00:49:16.560
but in terms of the actual language being used,

1331
00:49:16.560 --> 00:49:18.590
there's been a lot of changes because of macros.

1332
00:49:19.070 --> 00:49:23.090
So I'm looking forward to what it's going to look like in

1333
00:49:23.670 --> 00:49:26.050
in 20 or so years.  HOPL 7 maybe?

1336
00:49:27.870 --> 00:49:30.100
Yeah, that'd be nice.

1338
00:49:30.100 --> 00:49:34.010
I'm not sure I'm up for spending that much time on writing a paper though.

1340
00:49:34.020 --> 00:49:36.130
I think I'll have longer hair again.

1341
00:49:36.140 --> 00:49:41.710
Yeah, but I guess it's time to give the audience an opportunity to ask some questions and engage in some interactions,

1343
00:49:41.710 --> 00:49:44.280
See you around and hope you'll have a great conference.

1347
00:49:47.534 --> 00:49:51.184
Thank you both for an excellent and enjoyable talk.

1348
00:49:51.574 --> 00:49:56.344
This is a an area that's a little different from some of the

1350
00:49:56.734 --> 00:50:02.194
shall I say more conventional language presentations and I thought both the
content and the style was great.

1352
00:50:02.574 --> 00:50:08.834
I have a couple questions in Slack, reminding other people if you have other
questions for the authors,

1354
00:50:08.834 --> 00:50:11.784
please add that to Slack.  The first one,

1355
00:50:11.794 --> 00:50:16.534
by the way, there are a lot of comments in Slack that all said "not a question".

1357
00:50:16.534 --> 00:50:17.594
So after you're done,

1358
00:50:17.594 --> 00:50:22.554
please read through those.   A lot of arguments about origins of different kind of Lisp

1359
00:50:22.554 --> 00:50:25.664
and corrections on your TECO expertise.

1360
00:50:25.664 --> 00:50:31.854
But back to the questions.  From Will Christian in Stanford.

1362
00:50:31.864 --> 00:50:36.774
"One trend I've noticed in recent systems adopting

1363
00:50:36.784 --> 00:50:41.284
dynamically scoped features is to promote extensibility.

1364
00:50:41.574 --> 00:50:44.554
For example, context objects in React UX.

1366
00:50:44.774 --> 00:50:49.774
What do you think are the main lessons from Emacs Lisp that these systems should use

1367
00:50:49.774 --> 00:50:52.484
in designing the next generation of dynamic scoping?"

1369
00:50:55.674 --> 00:50:58.494
Should I take that one Stefan?

1370
00:50:58.974 --> 00:50:59.334
Yeah.

1371
00:50:59.344 --> 00:51:03.934
So so we actually talked about this right just a couple of weeks ago.

1373
00:51:04.434 --> 00:51:08.104
So these days I work a lot in software architecture and

1374
00:51:08.114 --> 00:51:10.454
software architecture education, right?

1376
00:51:10.454 --> 00:51:15.304
And there's this issue of modularity and I remember talking to the author of Pico Lisp,

1377
00:51:15.304 --> 00:51:19.804
which is a dynamically scoped Lisp, many years ago about modularity.

1378
00:51:19.804 --> 00:51:25.164
And we were fighting and I was working on Scheme 48, which is statically scoped, at the time.

1380
00:51:25.174 --> 00:51:26.224
And he said, well,

1382
00:51:26.224 --> 00:51:31.134
"modularity is the ability to take an existing system and reach into its
guts so you can make

1383
00:51:31.134 --> 00:51:34.294
it do what you want done, right?"

1385
00:51:34.304 --> 00:51:37.564
Which is an unconventional view of modularity,

1386
00:51:37.574 --> 00:51:41.054
but I can't really say it's completely wrong, right?

1388
00:51:41.064 --> 00:51:45.864
I mean we want modular software to be reusable and in

1389
00:51:45.864 --> 00:51:50.764
many ways the dynamic scoping in Emacs Lisp or some of the other dynamic features that you can

1390
00:51:50.764 --> 00:51:53.274
just sort of set a function to be a different one,

1391
00:51:53.284 --> 00:51:55.324
replace it by something else and so on,

1392
00:51:55.334 --> 00:52:00.024
are what makes it possible for users to modify and to make Emacs,

1393
00:52:00.034 --> 00:52:01.784
you know, do what you want done.

1395
00:52:01.794 --> 00:52:06.784
So I think that's one side of it that it's

1396
00:52:06.784 --> 00:52:08.934
important to have these kinds of capabilities.

1397
00:52:08.944 --> 00:52:15.104
On the other hand, it's really easy to kind of lose an overview and

1399
00:52:15.104 --> 00:52:17.784
to lose a good understanding of what's going on in your system right?

1400
00:52:17.784 --> 00:52:21.344
With Emacs Lisp you can usually get it to do what you want done,

1401
00:52:21.354 --> 00:52:25.194
but you often get unexpected interactions between parts of the system.

1402
00:52:25.194 --> 00:52:29.974
And the paper talks a little bit about this when it comes to a mechanism known as advice, right?

1403
00:52:29.974 --> 00:52:33.084
Which is also a kind of a dynamic extension mechanism in the language.

1404
00:52:33.474 --> 00:52:35.644
And so I think, you know,

1406
00:52:35.644 --> 00:52:38.814
kind of the trend at the conferences that I've gone to in recent years,

1407
00:52:38.814 --> 00:52:43.714
ICFP and so on, has been to create unbreakable abstractions and

1409
00:52:43.724 --> 00:52:48.084
but also the systems that result from that or that result from tighter abstractions,

1410
00:52:48.094 --> 00:52:52.934
particularly the editors, are just not as flexible at runtime

1411
00:52:52.944 --> 00:52:56.534
in making it possible to change their behavior as Emacs is.

1412
00:52:56.534 --> 00:52:59.464
So I think - I don't have an answer to that question -

1413
00:52:59.464 --> 00:53:01.634
I think that's an avenue for research.

1414
00:53:01.644 --> 00:53:04.674
And in particular the context mechanism in React,

1415
00:53:04.674 --> 00:53:10.514
I happen to be familiar with that, also underwent a substantial redesign.

1417
00:53:10.514 --> 00:53:13.684
It's just difficult to get this kind of stuff to get the right balance between,

1418
00:53:13.874 --> 00:53:14.174
you know,

1419
00:53:14.174 --> 00:53:18.914
changeability and adaptability of the system and at the same time you know,

1420
00:53:18.914 --> 00:53:22.694
keeping the system comprehensible, if that makes any sense.

1421
00:53:23.974 --> 00:53:26.904
Yeah, if I can add something to that.

1423
00:53:26.914 --> 00:53:31.404
I think the experience we've had with Emacs Lisp and and the dynamic

1424
00:53:31.414 --> 00:53:32.494
facilities in there,

1425
00:53:33.074 --> 00:53:37.934
all that, you can have a lot of dynamic features like dynamic scoping,

1426
00:53:37.944 --> 00:53:38.474
you know,

1427
00:53:38.484 --> 00:53:43.174
in kind of unchecked ways despite all my own notions

1428
00:53:43.174 --> 00:53:47.964
of how it should work, as you know I'm a static-typing kind of

1429
00:53:47.974 --> 00:53:48.794
researcher.

1430
00:53:49.274 --> 00:53:53.994
But I think one element that is important is that 

1431
00:53:54.004 --> 00:53:58.004
you need to develop a set of conventions along with it.

1432
00:53:58.014 --> 00:54:00.584
And that probably takes a lot more time.

1433
00:54:05.174 --> 00:54:06.193
Okay,

1434
00:54:06.874 --> 00:54:07.494
All right.

1435
00:54:07.494 --> 00:54:11.604
So the next question is from Troels Henriksen,

1437
00:54:11.604 --> 00:54:16.574
the University of Copenhagen. Lisp isn't particularly known for its text-processing

1438
00:54:16.574 --> 00:54:20.964
capabilities and many other highly dynamic languages now exist.

1439
00:54:20.974 --> 00:54:25.084
Is Lisp still the best language for creating Emacs-style editors?

1441
00:54:28.674 --> 00:54:30.194
Absolutely, right?

1442
00:54:30.204 --> 00:54:35.084
I'm not sure it's as much a language question as a question of

1443
00:54:35.094 --> 00:54:38.264
if it offers the right data types for processing text.

1444
00:54:38.264 --> 00:54:38.614
Right.

1445
00:54:38.624 --> 00:54:42.674
I remember reading an article about the editor buffer representation

1446
00:54:42.674 --> 00:54:46.584
they use in Visual Studio Code, and they needed to go to horrendous lengths,

1447
00:54:46.974 --> 00:54:50.084
you know, to make it work efficiently.

1449
00:54:50.094 --> 00:54:54.264
That is all done in C, but it's available at the Emacs Lisp language level.

1450
00:54:54.274 --> 00:55:00.904
Arguably, you know, arguably there's some facilities in other languages.

1452
00:55:00.904 --> 00:55:02.864
I recall SNOBOL, for example,

1454
00:55:02.864 --> 00:55:06.724
which has advanced text processing.  But, given the flexibility of Lisp,

1455
00:55:06.734 --> 00:55:11.164
there is no reason why you can't have any text processing capability that you want in Emacs Lisp.

1456
00:55:11.164 --> 00:55:12.784
So, absolutely, it's the best language.

1459
00:55:16.074 --> 00:55:20.754
Okay, let's see, the next one is from Marc Law.

1462
00:55:20.764 --> 00:55:25.764
It's been pointed out the dynamic scoping is really not a historical artifact, but

1463
00:55:25.764 --> 00:55:30.524
a means for allowing some parameterization without having to explicitly plumb state

1464
00:55:30.524 --> 00:55:32.204
context through every function.

1465
00:55:32.214 --> 00:55:34.784
Do you have any remarks on the implications

1466
00:55:34.784 --> 00:55:39.584
this has for the possibility of even being able to make Emacs multithreaded.

1467
00:55:40.074 --> 00:55:45.194
For example, using TLS to simulate dynamic scope while being thread-friendly.

1469
00:55:47.574 --> 00:55:49.394
That's one for you with Stefan, I think.

1472
00:55:55.874 --> 00:55:58.464
Yeah, I think that is a hard one.

1474
00:55:58.474 --> 00:56:04.194
Multithreading is is clearly a hard problem for Emacs Lisp,

1476
00:56:05.274 --> 00:56:12.984
mostly because of all this state, and this heavy reliance on dynamic scoping.

1479
00:56:18.144 --> 00:56:20.254
I'm not sure exactly what I can say about this,

1481
00:56:21.884 --> 00:56:24.484
but it can be an opportunity,

1482
00:56:24.484 --> 00:56:29.694
but I think at least in the context of Emacs it's more of a problem than a solution.

1484
00:56:31.174 --> 00:56:33.314
Well, maybe I can contribute something.

1488
00:56:34.094 --> 00:56:35.984
I mean there's a section on multithreading in the paper,

1489
00:56:35.984 --> 00:56:38.884
first of all, and about how that relates to dynamic scoping.

1491
00:56:39.374 --> 00:56:44.274
Getting the interaction between threading and dynamic scoping tends to be difficult, and

1492
00:56:44.274 --> 00:56:46.994
also difficult to reconcile with modularity.

1496
00:56:51.404 --> 00:56:54.994
I think in the case of of Emacs, you know,

1499
00:56:56.124 --> 00:57:00.694
making dynamic scoping work was multithreading ...

1501
00:57:01.774 --> 00:57:04.344
I think Stefan blanked out on that one.

1503
00:57:04.354 --> 00:57:06.244
Internet blip.

1504
00:57:06.244 --> 00:57:07.744
That's fine.  We'll go on to the next one.

1506
00:57:07.764 --> 00:57:10.904
Okay, the next one is a multi-part.

1508
00:57:10.904 --> 00:57:15.874
I'm just going to ask the first part of it. From Yoshiki Takashima, CMU:

1509
00:57:15.884 --> 00:57:20.744
"Do you think the number of ELisp programmers is hindering its development?"

1510
00:57:20.754 --> 00:57:23.424
So is it worth considering thinking of ELisp

1511
00:57:23.424 --> 00:57:25.884
as a compiler target for other languages.

1514
00:57:30.874 --> 00:57:31.964
Isn't it?

1515
00:57:31.964 --> 00:57:34.084
Isn't an Emacs Lisp backend for Idris?

1516
00:57:38.174 --> 00:57:42.754
Well, I always considered ELisp to be implemented in a fairly inefficient way.

1518
00:57:42.764 --> 00:57:45.134
And so to be fundamentally fairly slow.

1519
00:57:45.144 --> 00:57:49.574
I've since had the opportunity to learn that it's actually not that slow,

1523
00:57:50.354 --> 00:57:54.674
it's a fairly average performance, let's say.

1525
00:57:54.684 --> 00:57:59.314
But I wouldn't, you know, I wouldn't promote it as a target for a compiler.

1531
00:57:59.934 --> 00:58:01.894
I don't think it's very adapted to that.

1532
00:58:04.874 --> 00:58:05.624
Okay.

1533
00:58:05.634 --> 00:58:07.484
One could imagine targeting the byte code.

1534
00:58:07.494 --> 00:58:07.874
Right,

1535
00:58:07.874 --> 00:58:08.304
Stefan?

1538
00:58:09.684 --> 00:58:14.444
You can imagine talking to the byte code for a slightly different frontend,

1539
00:58:14.454 --> 00:58:21.374
but then you might as well just use, you know, another approach as well.

1542
00:58:21.374 --> 00:58:24.814
So, you  why would you want to use another source language basically?

1545
00:58:24.814 --> 00:58:26.854
So if you want to run within Emacs,

1546
00:58:26.854 --> 00:58:31.744
it's probably easier to just write Emacs Lisp code directly so that the set of

1547
00:58:31.744 --> 00:58:32.884
features matches.

1548
00:58:34.174 --> 00:58:36.764
Yeah.  Okay, from Guy Steele:

1551
00:58:36.764 --> 00:58:39.634
"What changes, if any,

1553
00:58:39.644 --> 00:58:43.564
have been made to Emacs Lisp primarily for the sake of improved performance

1554
00:58:43.564 --> 00:58:46.094
rather than for a new functionality?"

1555
00:58:48.974 --> 00:58:57.254
Very little.  Performance has rarely been an issue when it comes to the language.

1557
00:58:57.254 --> 00:59:00.504
That is, the language has a fairly simple implementation.

1559
00:59:00.524 --> 00:59:04.084
It's reasonably slow in this respect,

1560
00:59:04.674 --> 00:59:09.184
but most of the elements that take time are actually implemented in C anyway.

1561
00:59:09.184 --> 00:59:12.294
They're part of the library basically.

1562
00:59:12.774 --> 00:59:16.254
And so the language itself has not really been changed

1563
00:59:16.254 --> 00:59:17.184
to accommodate speed.

1564
00:59:18.874 --> 00:59:21.014
Yeah, if we're talking about the source language, right?

1567
00:59:21.024 --> 00:59:23.884
Of course, the implementation has seen quite a few improvements.

1569
00:59:24.474 --> 00:59:24.864
Yes.

1570
00:59:24.874 --> 00:59:28.364
Okay,

1571
00:59:28.374 --> 00:59:30.544
it's time for one or two more I think.

1572
00:59:30.554 --> 00:59:35.554
Andrew Black from Portland State says: "The first version of Emacs Lisp that I used

1573
00:59:35.554 --> 00:59:37.784
was in Gosling's Emacs for Unix.

1574
00:59:38.174 --> 00:59:41.694
The early versions did not have function parameters, as I recall.

1576
00:59:42.004 --> 00:59:46.314
The convention was to use dynamically bound variables to get information into functions.

1577
00:59:46.544 --> 00:59:50.024
Was this just a limitation of the Gosling implementation?

1578
00:59:50.104 --> 00:59:53.384
Was it also a feature of the early TECO-based versions?"

1579
00:59:56.174 --> 01:00:00.164
I have no idea.

1580
01:00:00.174 --> 01:00:04.994
So my impression was ... I never got to the point where I fully learned

1581
01:00:05.004 --> 01:00:05.684
the TECO language.

1582
01:00:05.684 --> 01:00:08.174
My impression was that it did not have named parameters.

1583
01:00:08.204 --> 01:00:11.774
So TECO's extension language is completely un-Lisp-like, we should note.

1584
01:00:11.784 --> 01:00:12.164
Right.

1585
01:00:12.174 --> 01:00:16.774
And I think we had an example of that in the talk and I don't think named ...

1586
01:00:17.204 --> 01:00:19.004
Gosling Emacs also had a completely different Lisp.

1589
01:00:19.904 --> 01:00:20.324
That's right.

1591
01:00:20.634 --> 01:00:22.724
I mean the characterization of Gosling Emacs is correct.

1593
01:00:22.904 --> 01:00:27.284
It did not have named function parameters and that's in the paper as well, but

1594
01:00:27.294 --> 01:00:30.314
I don't think TECO had that notion either.

1595
01:00:30.324 --> 01:00:33.594
Like a programming language with regular named parameters.

1597
01:00:35.674 --> 01:00:37.184
I think it had registers,

1598
01:00:37.194 --> 01:00:39.694
it's just basically global variables.

1599
01:00:40.274 --> 01:00:44.954
That sounds familiar going back a lot of years. 

1600
01:00:44.954 --> 01:00:50.684
From Paul: When and how do external packages get bundled into Emacs's core?

1602
01:00:54.374 --> 01:00:58.294
Oh ... it just happens

1603
01:00:58.294 --> 01:01:03.954
and it happens in ways that nobody notices because there is no

1604
01:01:03.964 --> 01:01:06.374
technical definition of what is the core.

1605
01:01:06.384 --> 01:01:09.924
It's more what people consider as being part of the core.

1606
01:01:09.934 --> 01:01:12.084
So there are packages ... To be part of the core,

1607
01:01:12.084 --> 01:01:13.764
you have to be distributed with Emacs,

1608
01:01:13.774 --> 01:01:18.994
but just being distributed with Emacs is not sufficient for people to consider it as core.

1610
01:01:19.174 --> 01:01:21.174
And I think if you asked different people,

1611
01:01:21.174 --> 01:01:25.394
different people would consider different parts as being part of core or not.

1612
01:01:25.394 --> 01:01:28.894
So it's a fuzzy, fuzzy notion.

1614
01:01:30.274 --> 01:01:34.794
It's more a question of a habit and what is commonly used within the code.

1617
01:01:39.074 --> 01:01:39.494
All right.

1618
01:01:39.494 --> 01:01:43.964
So I think this will be the last question, from Kiran Gopinathan of NUS.

1619
01:01:43.974 --> 01:01:48.904
"I love the extensibility of the ELisp when it provides an editing experience unlike any

1620
01:01:48.904 --> 01:01:49.994
other editor out there.

1621
01:01:50.474 --> 01:01:51.974
But out of curiosity,

1622
01:01:51.984 --> 01:01:56.934
are there lessons that ELisp may be able to learn from the scripting languages

1623
01:01:56.944 --> 01:01:58.794
of other modern editors,

1624
01:01:58.794 --> 01:02:02.484
such as JS for VS Code or Neovim?

1626
01:02:05.874 --> 01:02:06.384
Mike?

1627
01:02:07.574 --> 01:02:08.984
I think the answer is no.

1631
01:02:11.594 --> 01:02:14.004
I mean, as I said, right,

1635
01:02:14.004 --> 01:02:15.714
I mean the great advantage is, in Emacs Lisp,

1636
01:02:15.714 --> 01:02:17.014
you can really do things at runtime.

1637
01:02:17.014 --> 01:02:20.234
Whereas these modern editors, Neovim

1639
01:02:20.234 --> 01:02:21.074
I don't know much about,

1641
01:02:21.694 --> 01:02:26.544
but I think you customize it in Lua these days.

1643
01:02:26.554 --> 01:02:29.294
The main question isn't so much about the language,

1644
01:02:29.294 --> 01:02:33.964
but if the language enables being able to do things at runtime. Right?

1646
01:02:33.964 --> 01:02:35.874
And a lot of ... like Visual Studio Code,

1647
01:02:35.874 --> 01:02:37.274
you modify any of its plugins,

1648
01:02:37.274 --> 01:02:40.144
you have to restart the editor, as an example. Right?

1650
01:02:40.154 --> 01:02:44.864
And so that's something that we don't need to do in Emacs.

1651
01:02:44.864 --> 01:02:49.494
And so I'm not sure there's a great lesson for either system organization or

1652
01:02:49.874 --> 01:02:51.274
language design there.

1653
01:02:51.284 --> 01:02:56.794
I don't think I would change Emacs Lisp to accommodate their way of doing things.

1656
01:02:58.684 --> 01:03:04.164
I think in terms of the language I don't think there is much to be gained from there,

1658
01:03:04.174 --> 01:03:09.684
there are some very interesting aspects that we do want to integrate from those editors,

1660
01:03:09.694 --> 01:03:11.384
but they're not really part of the language there.

1661
01:03:11.384 --> 01:03:14.904
More part of the design, of how you structure, you know,

1663
01:03:14.904 --> 01:03:19.804
the the description of the language that you want to parse so as you do highlighting for example and

1664
01:03:19.804 --> 01:03:22.294
those kinds of things.  And redisplay for example,

1665
01:03:23.224 --> 01:03:25.894
might be my favorite thing to borrow from these.

1669
01:03:29.164 --> 01:03:31.014
I'm going to cut off the questions there,

1670
01:03:31.014 --> 01:03:34.154
but I want to thank you both for like I said,

1671
01:03:34.164 --> 01:03:36.544
an excellent paper, wonderful presentation.

1673
01:03:36.554 --> 01:03:39.724
And for what I can see from the non-question discussions,

1674
01:03:39.734 --> 01:03:44.254
we're bringing back a lot of arguments and discussions from the history of

1675
01:03:44.264 --> 01:03:48.054
editors and Lisp that I haven't seen in decades.

1676
01:03:48.054 --> 01:03:50.334
So thank you both very, very much.

1678
01:03:50.344 --> 01:03:52.304
And thanks Brent for your hard work. Right?

1680
01:03:52.304 --> 01:03:56.594
If the paper is any good, it's at least as much your fault as it is ours.

1681
01:03:56.974 --> 01:03:57.454
Yeah.

1682
01:03:57.464 --> 01:03:58.494
That's kind of you to say it,

1683
01:03:58.494 --> 01:03:59.884
but thank you.