Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.lisp > #61270 > unrolled thread

Malicious Computer Architecture (was: Re: Prioritize Performance over Correctness)

Back to article view | Back to comp.lang.lisp

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Malicious Computer Architecture (was: Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-03 19:23 +0800
    Re: Malicious Computer Architecture (was: Re: Prioritize Performance over Correctness) scott@slp53.sl.home (Scott Lurndal) - 2026-08-03 14:29 +0000
      Re: Malicious Computer Architecture Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-03 14:26 -0300
    Johnny Depp prevention [Windows 11 etc...] (Was: Malicious Computer Architecture) Mild Shock <janburse@fastmail.fm> - 2026-08-03 18:10 +0200
      But how can you deploy. when its ROM? (Was: Johnny Depp prevention [Windows 11 etc...]) Mild Shock <janburse@fastmail.fm> - 2026-08-03 18:15 +0200
        GPU Elasticity: Collective Communications Libraries (Was: But how can you deploy. when its ROM?) Mild Shock <janburse@fastmail.fm> - 2026-08-07 14:37 +0200
          What are Flits and Phits? [Network on a Chip] (Re: GPU Elasticity: Collective Communications Libraries) Mild Shock <janburse@fastmail.fm> - 2026-08-07 18:07 +0200
            Cristallina: Thank you for the Beam (Re: What are Flits and Phits? [Network on a Chip]) Mild Shock <janburse@fastmail.fm> - 2026-08-09 21:22 +0200
              Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Mild Shock <janburse@fastmail.fm> - 2026-08-18 16:26 +0200
                How to shoot yourself in the foot (Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Mild Shock <janburse@fastmail.fm> - 2026-08-18 16:50 +0200
                  Re: How to shoot yourself in the foot (Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-19 03:24 +0800
                Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-19 03:21 +0800
                  Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Aidan Kehoe <kehoea@parhasard.net> - 2026-08-18 21:13 +0100
                    Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-18 22:49 +0000
                      Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-19 08:32 +0800
                        Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Anthk GM <anthk@disroot.org> - 2026-09-15 17:10 +0000
                          Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] scott@slp53.sl.home (Scott Lurndal) - 2026-09-15 18:08 +0000
                            You hear some noises in the distance (Was: Loderunner Enemy AI better than SWI-Prolog?) Mild Shock <janburse@fastmail.fm> - 2026-09-15 20:21 +0200
                              Re: You hear some noises in the distance (Was: Loderunner Enemy AI better than SWI-Prolog?) scott@slp53.sl.home (Scott Lurndal) - 2026-09-15 20:05 +0000
                      Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] George Neuner <gneuner2@comcast.net> - 2026-08-21 02:08 -0400
                        Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-21 15:25 +0800
                          Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] George Neuner <gneuner2@comcast.net> - 2026-08-21 16:28 -0400
                    Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-19 08:27 +0800
                William A. Howard solved all his 99 problems (Re: Loderunner Enemy AI better than SWI-Prolog?) Mild Shock <janburse@fastmail.fm> - 2026-08-23 01:48 +0200
            The Mac Neo is a Budget Monster [GPU Channels] (Re: What are Flits and Phits? [Network on a Chip]) Mild Shock <janburse@fastmail.fm> - 2026-08-11 16:27 +0200
              The luminaries of duct-tape engineering [Sweeney and Torvald] (Was: The Mac Neo is a Budget Monster [GPU Channels]) Mild Shock <janburse@fastmail.fm> - 2026-08-11 16:51 +0200
    Re: Malicious Computer Architecture Aidan Kehoe <kehoea@parhasard.net> - 2026-08-03 19:51 +0100
      Re: Malicious Computer Architecture Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-05 00:22 +0800
        Re: Malicious Computer Architecture Richard Harnden <richard.nospam@gmail.invalid> - 2026-08-04 19:10 +0100
        Re: Malicious Computer Architecture Kaz Kylheku <046-301-5902@kylheku.com> - 2026-08-06 21:55 +0000
          Re: Malicious Computer Architecture Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-07 06:31 +0800
        Re: Malicious Computer Architecture Aidan Kehoe <kehoea@parhasard.net> - 2026-08-06 23:01 +0100
          Re: Malicious Computer Architecture Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-07 06:45 +0800
      Re: Malicious Computer Architecture Niocláisín Cóilín de Ghlostéir <thanks-to@Taf.com> - 2026-08-04 18:13 +0000
        Re: Malicious Computer Architecture Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-05 03:48 +0800
          Re: Malicious Computer Architecture Niocláisín Cóilín de Ghlostéir <thanks-to@Taf.com> - 2026-08-04 22:01 +0000
            Re: Malicious Computer Architecture Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-05 06:25 +0800
      GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-03 14:37 -0300
        Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) Madhu <enometh@meer.net> - 2026-09-04 08:36 +0530
          Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-15 12:19 -0300
            Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) Madhu <enometh@meer.net> - 2026-09-17 12:17 +0530
              Re: GNU Emacs native compiled functions Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-17 21:12 +0000
                Re: GNU Emacs native compiled functions Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-18 09:59 -0400
                  Re: GNU Emacs native compiled functions Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-18 22:00 +0000
              Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-18 10:12 -0400
                Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-18 22:01 +0000
                  Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) steve g <Sgonedes1977@gmail.com> - 2026-10-05 19:30 -0400
                    Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 23:50 +0000
                      Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) tfb <tfb@work.it.out> - 2026-10-06 05:11 +0000
                    Re: GNU Emacs native compiled functions Aidan Kehoe <kehoea@parhasard.net> - 2026-10-06 08:30 +0100
                Re: GNU Emacs native compiled functions Aidan Kehoe <kehoea@parhasard.net> - 2026-09-19 14:47 +0100
                  Re: GNU Emacs native compiled functions Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-19 21:58 +0000
                    Re: GNU Emacs native compiled functions Aidan Kehoe <kehoea@parhasard.net> - 2026-09-19 23:24 +0100
                      Re: GNU Emacs native compiled functions Paul Rubin <no.email@nospam.invalid> - 2026-09-19 17:23 -0700
                        Re: GNU Emacs native compiled functions Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-20 03:05 -0400
                          Re: GNU Emacs native compiled functions Kaz Kylheku <046-301-5902@kylheku.com> - 2026-09-22 18:20 +0000
                        Re: GNU Emacs native compiled functions Aidan Kehoe <kehoea@parhasard.net> - 2026-09-20 22:20 +0100
                          Re: GNU Emacs native compiled functions Paul Rubin <no.email@nospam.invalid> - 2026-09-20 16:18 -0700
                            Re: GNU Emacs native compiled functions Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-21 12:56 -0400
                              Re: GNU Emacs native compiled functions Madhu <enometh@meer.net> - 2026-09-22 12:22 +0530
                                Re: GNU Emacs native compiled functions Paul Rubin <no.email@nospam.invalid> - 2026-09-22 10:15 -0700
                                  Re: GNU Emacs native compiled functions Madhu <enometh@meer.net> - 2026-09-23 07:33 +0530
                                    Re: GNU Emacs native compiled functions Aidan Kehoe <kehoea@parhasard.net> - 2026-09-23 07:22 +0100
                                    Re: GNU Emacs native compiled functions Paul Rubin <no.email@nospam.invalid> - 2026-09-24 03:06 -0700
                                      Re: GNU Emacs native compiled functions Lars Brinkhoff <lars.spam@nocrew.org> - 2026-09-26 04:45 +0000
                                        Re: GNU Emacs native compiled functions Madhu <enometh@meer.net> - 2026-09-27 16:24 +0530
                                          Re: GNU Emacs native compiled functions Paul Rubin <no.email@nospam.invalid> - 2026-09-27 15:02 -0700
                                            Re: GNU Emacs native compiled functions Madhu <enometh@meer.net> - 2026-09-28 10:53 +0530
                                      Re: GNU Emacs native compiled functions steve g <Sgonedes1977@gmail.com> - 2026-10-05 19:47 -0400
                                    Re: GNU Emacs native compiled functions Anton Antimo <anton@safunu.org> - 2026-09-24 10:25 -0300
                                      Re: GNU Emacs native compiled functions steve g <Sgonedes1977@gmail.com> - 2026-10-05 19:49 -0400
                                  Re: GNU Emacs native compiled functions Lars Brinkhoff <lars.spam@nocrew.org> - 2026-09-23 13:59 +0000
                            Re: GNU Emacs native compiled functions Kaz Kylheku <046-301-5902@kylheku.com> - 2026-09-22 18:22 +0000
                              Re: GNU Emacs native compiled functions tfb <tfb@work.it.out> - 2026-09-24 20:01 +0000
                                Re: GNU Emacs native compiled functions Kaz Kylheku <046-301-5902@kylheku.com> - 2026-09-24 20:55 +0000
                            Re: GNU Emacs native compiled functions steve g <Sgonedes1977@gmail.com> - 2026-10-05 19:41 -0400
                          Re: GNU Emacs native compiled functions Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-21 00:18 +0000
                            Re: GNU Emacs native compiled functions antispam@fricas.org (Waldek Hebisch) - 2026-09-21 19:06 +0000
                              Re: GNU Emacs native compiled functions Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-22 00:42 +0000
                              Re: GNU Emacs native compiled functions Kaz Kylheku <046-301-5902@kylheku.com> - 2026-09-22 18:26 +0000
                                Re: GNU Emacs native compiled functions antispam@fricas.org (Waldek Hebisch) - 2026-09-25 21:54 +0000
                            Re: GNU Emacs native compiled functions steve g <Sgonedes1977@gmail.com> - 2026-10-05 20:13 -0400
                  Re: GNU Emacs native compiled functions Kaz Kylheku <046-301-5902@kylheku.com> - 2026-09-22 17:51 +0000
                Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) Kaz Kylheku <046-301-5902@kylheku.com> - 2026-09-22 18:02 +0000
    A Case for Impurity: The Applied Pi Calculus (Re: Malicious Computer Architecture) Mild Shock <janburse@fastmail.fm> - 2026-08-04 14:58 +0200
      The Sandcastle of Paul Taraus Interactors (Re: A Case for Impurity: The Applied Pi Calculus) Mild Shock <janburse@fastmail.fm> - 2026-08-04 15:10 +0200

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#61649 — Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture)

* Kragen Javier Sitaker <87wlsmo83m.fsf@debian> :
Wrote on Tue, 15 Sep 2026 12:19:25 -0300:
> Madhu <enometh@meer.net> writes:
>> * Kragen Javier Sitaker <87v78mz15a.fsf_-_@debian> :
>> Wrote on Thu, 03 Sep 2026 14:37:53 -0300:
>>> When I’ve disassembled these, they seem to indirect all their function
>>> calls through a jump table, so that you can rebind existing symbols to
>>> new functions and affect already-compiled code.
>>
>> isn't this just the behaviour of general compilation - unless the symbol
>> function is inlines at compile time or the macroexpanded at
>> macroexpansion time. [...]

> Oh hi enometh!
> It’s been a long time since UNM!  I live in Argentina
> now, and there’s a brand of jam here called Emeth, which always reminds
> me of your username when I see it.

Helu! haven't been in touch with NM folk since but I get to sample your
writings on canonical and in pdf form from time to time.

`Emeth' is hebrew for `truth'. [that (and "helu" and "guby") which
probably gets scraped from my emails gets classified incorrectly and has
got(ten) me into some orthodox advertising lists]

> It’s the usual behavior for Lisp compilation, but Emacs Lisp is
> sometimes a little unusual for a Lisp, and lots of other languages don’t
> do it this way.

I always thought it was essential for the "dynamic" nature lisp: change
the fdefinition and the next time the function symbol gets called from
any code (compiled or otherwise) it runs the new definition.

when emacs lisp had only dynamic binding you could exploit this further,
but with lexical binding the variables names get compiled out. that
takes out some of the fun -- "by design" of course.

Guby

[toc] | [prev] | [next] | [standalone]

#61650 — Re: GNU Emacs native compiled functions

On Thu, 17 Sep 2026 12:17:00 +0530, Madhu wrote:

> I always thought it was essential for the "dynamic" nature [of]
> lisp: change the fdefinition and the next time the function symbol
> gets called from any code (compiled or otherwise) it runs the new
> definition.

If the value of a symbol binding can get changed, then of course any
change to that value will be picked up by subsequent references to
that same binding. That would be true of whatever language with
whatever binding rules.

> when emacs lisp had only dynamic binding you could exploit this
> further, but with lexical binding the variables names get compiled
> out. that takes out some of the fun -- "by design" of course.

Dynamic binding seems more trouble than it’s worth. I remember
Stallman specifically justifying its use in Emacs to handle the case
of buffer-specific variable bindings. But there are (IMO) better ways
of achieving the same effect with lexical binding -- better because
they work with lexical binding, of course.

[toc] | [prev] | [next] | [standalone]

#61655 — Re: GNU Emacs native compiled functions

Lawrence D’Oliveiro [2026-09-17 21:12:29] wrote:
> On Thu, 17 Sep 2026 12:17:00 +0530, Madhu wrote:
>> I always thought it was essential for the "dynamic" nature [of]
>> lisp: change the fdefinition and the next time the function symbol
>> gets called from any code (compiled or otherwise) it runs the new
>> definition.
> If the value of a symbol binding can get changed, then of course any
> change to that value will be picked up by subsequent references to
> that same binding. That would be true of whatever language with
> whatever binding rules.

In ELisp, that's not true for functions defined with `defsubst`, nor is
it true for some of the core functions like `car`: the compiler
routinely inlines the function's definition and doesn't bother to make
sure it's "de-inlined" (or updated) if/when that symbol gets `fset`ed.


=== Stefan

[toc] | [prev] | [next] | [standalone]

#61656 — Re: GNU Emacs native compiled functions

On Fri, 18 Sep 2026 09:59:37 -0400, Stefan Monnier wrote:

> Lawrence D’Oliveiro [2026-09-17 21:12:29] wrote:
>
>> If the value of a symbol binding can get changed, then of course
>> any change to that value will be picked up by subsequent references
>> to that same binding. That would be true of whatever language with
>> whatever binding rules.
>
> In ELisp, that's not true for functions defined with `defsubst`, nor
> is it true for some of the core functions like `car`: the compiler
> routinely inlines the function's definition and doesn't bother to
> make sure it's "de-inlined" (or updated) if/when that symbol gets
> `fset`ed.

So which part of “subsequent references to that same binding” are you
disagreeing with, exactly?

[toc] | [prev] | [next] | [standalone]

#61654 — Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture)

Madhu [2026-09-17 12:17:00] wrote:
> when Emacs Lisp had only dynamic binding you could exploit this further,
> but with lexical binding the variables names get compiled out. that
> takes out some of the fun -- "by design" of course.

Yeah, dynamic scoping is more friendly to funky hacks, so in a sense
static scoping has a kind of "sad/boring/serious" side to it,
discouraging you from "walking on the wild side".

I've used dynamic scoping a few times in such "creative" ways
(i.e. reading a binding from a caller even thought that binding was
clearly intended to be a *local* variable), but I must say I don't miss
those fun days, because I find closures to be a source of a lot more
pleasure.  🙂


=== Stefan

[toc] | [prev] | [next] | [standalone]

#61657 — Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture)

On Fri, 18 Sep 2026 10:12:07 -0400, Stefan Monnier wrote:

> Yeah, dynamic scoping is more friendly to funky hacks, so in a sense
> static scoping has a kind of "sad/boring/serious" side to it,
> discouraging you from "walking on the wild side".

I find quite the opposite. Lexical binding allows you to create such
useful things as function factories and class factories.

In a dynamic language with lexical binding, who needs generics?

[toc] | [prev] | [next] | [standalone]

#61700 — Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture)

Lawrence D’Oliveiro <ldo@nz.invalid> writes:

> On Fri, 18 Sep 2026 10:12:07 -0400, Stefan Monnier wrote:
>
>> Yeah, dynamic scoping is more friendly to funky hacks, so in a sense
>> static scoping has a kind of "sad/boring/serious" side to it,
>> discouraging you from "walking on the wild side".
>
> I find quite the opposite. Lexical binding allows you to create such
> useful things as function factories and class factories.

The biggest problem with dynamic scoping is variable shadowing.

(defun this (char str idx)
  (eql (char str idx) char))

It just drives me nuts thinking about it. Look at some old emacs code and
tell me that a defvar is bad thing :)

I usually use the same name for the same variables; str, len, pos, epos, idx,
rdx; horrifying.

[toc] | [prev] | [next] | [standalone]

#61704 — Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture)

On 2026-10-05, steve g <Sgonedes1977@gmail.com> wrote:
> Lawrence D’Oliveiro <ldo@nz.invalid> writes:
>
>> On Fri, 18 Sep 2026 10:12:07 -0400, Stefan Monnier wrote:
>>
>>> Yeah, dynamic scoping is more friendly to funky hacks, so in a sense
>>> static scoping has a kind of "sad/boring/serious" side to it,
>>> discouraging you from "walking on the wild side".
>>
>> I find quite the opposite. Lexical binding allows you to create such
>> useful things as function factories and class factories.
>
> The biggest problem with dynamic scoping is variable shadowing.

Not sure about "biggest".

Variable shadowing can be worked around with conventions, leaving only
accidents. Use *earmuffs* for variables intended to be context variables
(true specials). Omit them for locals.  Do not use SETQ on a variable
you did not bind with LET or other binding construct: this needs
discipine, verification/tooling, because people make typos:

(let ((foobar 3))
  (setq fubar 42)) ; clobbered caller's private fubar

The lack of closure over bindings is a big problem. That has workarounds
but they are not that nice and not just coding conventions/discipine.

> I usually use the same name for the same variables; str, len, pos, epos, idx,
> rdx; horrifying.

So if you make a typo somewhere, either in the binding or the
referencing, so that they are talking past each other, you are working
with the wrong frame's variable of the same name.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#61706 — Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture)

Kaz Kylheku <046-301-5902@kylheku.com> wrote:

> 
> (let ((foobar 3))
>   (setq fubar 42)) ; clobbered caller's private fubar
> 

Languages which conflate binding and assignment (I name no names) have a
variant of this problem, even with lexical scope.  I am sure there are
languages which do that *and* have dynamic scope.

-- 
tfeb.org/computer/

[toc] | [prev] | [next] | [standalone]

#61707 — Re: GNU Emacs native compiled functions

 Ar an cúigiú lá de mí Deireadh Fómhair, scríobh steve g.: 

 > Lawrence D’Oliveiro <ldo@nz.invalid> writes:
 > 
 > > On Fri, 18 Sep 2026 10:12:07 -0400, Stefan Monnier wrote:
 > >
 > >> Yeah, dynamic scoping is more friendly to funky hacks, so in a sense
 > >> static scoping has a kind of "sad/boring/serious" side to it,
 > >> discouraging you from "walking on the wild side".
 > >
 > > I find quite the opposite. Lexical binding allows you to create such
 > > useful things as function factories and class factories.
 > 
 > The biggest problem with dynamic scoping is variable shadowing.
 > 
 > (defun this (char str idx)
 >   (eql (char str idx) char))

This is orthogonal to dynamic scope. It’s a Lisp-1 vs Lisp-2 question. You’re
calling a function called #'char on local variables (in this case parameters)
called str, idx, and comparing them to the value of the local variable char.
This will work the same on Common Lisp and pre-lexical-scope Emacs Lisp.

 > It just drives me nuts thinking about it. Look at some old emacs code and
 > tell me that a defvar is bad thing :)
 > 
 > I usually use the same name for the same variables; str, len, pos, epos, idx,
 > rdx; horrifying.

Something I didn’t realise until several years in to Lisp development was that
part of the reason the example code on CLHS is not heavy on idiosyncratic
spellings, is that each distinct spelling has its own cost (the symbol has to
be interned and, pre-lexical-scope, has to stay interned.) It doesn’t matter
these days, there’s enough RAM, but the realisation did change my habits.

-- 
‘As I sat looking up at the Guinness ad, I could never figure out /
How your man stayed up on the surfboard after fourteen pints of stout’
(C. Moore)

[toc] | [prev] | [next] | [standalone]

#61658 — Re: GNU Emacs native compiled functions

 Ar an t-ochtú lá déag de mí Méan Fómhair, scríobh Stefan Monnier: 

 > Madhu [2026-09-17 12:17:00] wrote:
 > > when Emacs Lisp had only dynamic binding you could exploit this further,
 > > but with lexical binding the variables names get compiled out. that
 > > takes out some of the fun -- "by design" of course.
 > 
 > Yeah, dynamic scoping is more friendly to funky hacks, so in a sense
 > static scoping has a kind of "sad/boring/serious" side to it,
 > discouraging you from "walking on the wild side".
 > 
 > I've used dynamic scoping a few times in such "creative" ways
 > (i.e. reading a binding from a caller even thought that binding was
 > clearly intended to be a *local* variable), but I must say I don't miss
 > those fun days, because I find closures to be a source of a lot more
 > pleasure.  🙂

This is in no way a strong argument for default dynamic scope in any flavour of
emacs, but one real advantage is you can put a hardware watchpoint (e.g. from
gdb or lldb) on the value field of a symbol, making it easier to track down
what Lisp code modified its value in an undesired way.

This comes up most with defvar'd symbols but would be necessary for the calling
package if you had decided in the above example to modify the binding in your
caller, rather than just read it. One of the strengths of lexical scope is you
can’t do that.

-- 
‘As I sat looking up at the Guinness ad, I could never figure out /
How your man stayed up on the surfboard after fourteen pints of stout’
(C. Moore)

[toc] | [prev] | [next] | [standalone]

#61659 — Re: GNU Emacs native compiled functions

On Sat, 19 Sep 2026 14:47:35 +0100, Aidan Kehoe wrote:

> This is in no way a strong argument for default dynamic scope in any
> flavour of emacs, but one real advantage is you can put a hardware
> watchpoint (e.g. from gdb or lldb) on the value field of a symbol,
> making it easier to track down what Lisp code modified its value in
> an undesired way.

Debuggers are allowed to hook into low-level runtimes in ways not
specified (or specifiable) in any language standard. They can walk
stacks and heaps and access objects regardless of what language
visiblity rules might say.

So whether a language does dynamic or static scoping is a design
decision that is all about the kinds of programs you write in it, not
how you implement a debugger.

[toc] | [prev] | [next] | [standalone]

#61660 — Re: GNU Emacs native compiled functions

 Ar an naoú lá déag de mí Méan Fómhair, scríobh Lawrence D’Oliveiro: 

 > On Sat, 19 Sep 2026 14:47:35 +0100, Aidan Kehoe wrote:
 > 
 > > This is in no way a strong argument for default dynamic scope in any
 > > flavour of emacs, but one real advantage is you can put a hardware
 > > watchpoint (e.g. from gdb or lldb) on the value field of a symbol, making
 > > it easier to track down what Lisp code modified its value in an undesired
 > > way.
 > 
 > Debuggers are allowed to hook into low-level runtimes in ways not specified
 > (or specifiable) in any language standard. They can walk stacks and heaps
 > and access objects regardless of what language visiblity rules might say.

I don’t disagree with that one bit. And in the world as it exists today, you
can do this with a dynamic scoped Emacs Lisp and, to my knowledge, it is not
possible with GNU Emacs’ lexically scoped Emacs Lisp. A simple workaround is to
disable lexical scoping for that file if you need to debug the situation I
described.

 > So whether a language does dynamic or static scoping is a design decision
 > that is all about the kinds of programs you write in it, not how you
 > implement a debugger.

Lexical scoping gives fewer bugs and faster execution, dynamic scope by default
was a bad decision.

-- 
‘As I sat looking up at the Guinness ad, I could never figure out /
How your man stayed up on the surfboard after fourteen pints of stout’
(C. Moore)

[toc] | [prev] | [next] | [standalone]

#61661 — Re: GNU Emacs native compiled functions

Aidan Kehoe <kehoea@parhasard.net> writes:
> Lexical scoping gives fewer bugs and faster execution, dynamic scope
> by default was a bad decision.

Dynamic scope implemented with a shallow-binding cell is pretty fast so
I don't think speed is a serious concern in a relatively inefficient
interpreter like Emacs Lisp.  RMS used to think Emacs benefited from
dynamic scope since you could easily temporarily bind system variables,
such as (let ((case-fold-search nil)) ... ) where the temporary binding
would affect only the local scope.  IDK if he would still say that.  But
it was a philosophy that he applied to both ITS (TECO) Emacs and GNU
Emacs.

[toc] | [prev] | [next] | [standalone]

#61663 — Re: GNU Emacs native compiled functions

Paul Rubin [2026-09-19 17:23:00] wrote:
> Aidan Kehoe <kehoea@parhasard.net> writes:
>> Lexical scoping gives fewer bugs and faster execution, dynamic scope
>> by default was a bad decision.
> Dynamic scope implemented with a shallow-binding cell is pretty fast so
> I don't think speed is a serious concern in a relatively inefficient
> interpreter like Emacs Lisp.

When running code without byte-compiling it, the statically scoped
dialect of ELisp tends to be noticeably slower, indeed.


=== Stefan

[toc] | [prev] | [next] | [standalone]

#61678 — Re: GNU Emacs native compiled functions

On 2026-09-20, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> Paul Rubin [2026-09-19 17:23:00] wrote:
>> Aidan Kehoe <kehoea@parhasard.net> writes:
>>> Lexical scoping gives fewer bugs and faster execution, dynamic scope
>>> by default was a bad decision.
>> Dynamic scope implemented with a shallow-binding cell is pretty fast so
>> I don't think speed is a serious concern in a relatively inefficient
>> interpreter like Emacs Lisp.
>
> When running code without byte-compiling it, the statically scoped
> dialect of ELisp tends to be noticeably slower, indeed.

If deep binding is used for dynamic variables, it will be the same;
the top environment has to be searched for a variable, then if not
found there, the next one up and so on.

When we are byte compiling, we can speed up repeated accesses to the
same dynamic variable, by doing one lookup (on entry into a given scope)
to find the cell where the current value of the dynamic is held, then
caching that in a hidden lexical variable; uses of the variable are then
translated to direct references to the cell through this hidden
variable.

I'm aware of this issue but haven't put effort into it myself.
We can see it with an example, of a progn form that increments
a special variable three times:

1> (defvar *foo*)
*foo*
2> (disassemble (compile-toplevel '(progn (inc *foo*) (inc *foo*) (inc *foo*))))
data:
    0: *foo*
syms:
    0: succ
code:
    0: 68400004 getv t4 d0
    1: 20010003 gcall t3 0 t4
    2: 00040000
    3: 80400003 setv t3 d0
    4: 68400004 getv t4 d0
    5: 20010003 gcall t3 0 t4
    6: 00040000
    7: 80400003 setv t3 d0
    8: 68400004 getv t4 d0
    9: 20010002 gcall t2 0 t4
   10: 00040000
   11: 80400002 setv t2 d0
   12: 10000002 end t2
instruction count:
   10
#<sys:vm-desc: a82b250>

Notice that "getv t4 d0" appears three times. The t4 register is not
modified by anything else.  Because there are no intervening "bindv"
instructions we we could optimize this in the bytecode back end
entirely.

d0 referes to the data vector for the compiled form (see "data:" above,
data [0] is the symbol *foo*).

"getv t4 d0" means to get the current dynamic value cell of *foo*,
and capture it in register t4.

In any basic block of code, if a register "Tx" is set by a "getv"
instruction for a certain symbolic datum "Dy", if that register
is not subsequently clobbered and is again the target of a "getv"
from the same "Dy", that second instruction can be eliminated.

Doing it at the basic block level would be imperfect since any top-of-loop
would have to fetch the variable, but would improve things in situations like
the above. Also, in more complex code, a different register may be
chosen for the redundant getv. If we see "getv t4 d0" and later
"getv t6 d0" such that we are sure t6 is obtaining the same value that
t4 already has, the we can replace the latter instrution by "mov t6 t4".
Then, another optimization round will likely get rid of t6; there
is already a strategy for eliminating useless register duplications
which will replace uses of t6 in subsequent code with t4 and drop the mov.

(Of course, the real optimization we want is to collapse three
incs into (inc ... 3)) but that is neither here nor there.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#61664 — Re: GNU Emacs native compiled functions

 Ar an naoú lá déag de mí Méan Fómhair, scríobh Paul Rubin: 

 > Aidan Kehoe <kehoea@parhasard.net> writes:
 > > Lexical scoping gives fewer bugs and faster execution, dynamic scope
 > > by default was a bad decision.
 > 
 > Dynamic scope implemented with a shallow-binding cell is pretty fast so
 > I don't think speed is a serious concern in a relatively inefficient
 > interpreter like Emacs Lisp.  RMS used to think Emacs benefited from
 > dynamic scope since you could easily temporarily bind system variables,
 > such as (let ((case-fold-search nil)) ... ) where the temporary binding
 > would affect only the local scope.

My understanding was that he felt it was faster, but I don’t care to argue.

Common Lisp has dynamic binding for globals and lexical scope for locals.
(let ((case-fold-search nil) ...) works fine with this design. Current GNU
Emacs has made the same decision.

 > IDK if he would still say that. But it was a philosophy that he applied to
 > both ITS (TECO) Emacs and GNU Emacs.

Philosophies can be wrong.

-- 
‘As I sat looking up at the Guinness ad, I could never figure out /
How your man stayed up on the surfboard after fourteen pints of stout’
(C. Moore)

[toc] | [prev] | [next] | [standalone]

#61665 — Re: GNU Emacs native compiled functions

Aidan Kehoe <kehoea@parhasard.net> writes:
> My understanding was that he felt it [dynamic scope] was faster, but I
> don’t care to argue.

See here: https://www.gnu.org/software/emacs/emacs-paper.html#SEC18

Even with byte compilation, I'd have to see benchmarks to believe that
the speed difference between dynamic and lexical binding in Emacs is
significant, especially with a small amount of coding attention, such as
using LET outside rather than inside a tight loop if you can.

> Philosophies can be wrong.

RMS is a pretty sharp Lisper and while anyone can be wrong about things,
I tend to want a pretty good reason to think I'm not the one who's
wrong.  In the previous section of that paper (SEC17) though, he does
say,

   It is not necessary for dynamic scope to be the only scope rule
   provided, just useful for it to be available.

That roughly fits the situation in CL, Scheme, and modern-day Emacs
Lisp.

[toc] | [prev] | [next] | [standalone]

#61671 — Re: GNU Emacs native compiled functions

> Even with byte compilation, I'd have to see benchmarks to believe that
> the speed difference between dynamic and lexical binding in Emacs is
> significant, especially with a small amount of coding attention, such as
> using LET outside rather than inside a tight loop if you can.

IME, as currently implemented in Emacs, speed of byte-compiled ELisp
code is indeed pretty much the same with lexical-scoping as with
dynamic scoping.


=== Stefan

[toc] | [prev] | [next] | [standalone]

#61672 — Re: GNU Emacs native compiled functions

* Stefan Monnier <jwv4ifipmsc.fsf-monnier+comp.lang.lisp@gnu.org> :
Wrote on Mon, 21 Sep 2026 12:56:33 -0400:

>> Even with byte compilation, I'd have to see benchmarks to believe that
>> the speed difference between dynamic and lexical binding in Emacs is
>> significant, especially with a small amount of coding attention, such as
>> using LET outside rather than inside a tight loop if you can.
>
> IME, as currently implemented in Emacs, speed of byte-compiled ELisp
> code is indeed pretty much the same with lexical-scoping as with
> dynamic scoping.

and without byte compilation?

The 80s Elisp appeal for adoption was full control of the system, in the
case of an error you could see where you stood, see what variable had
which value, there were no secrets held by the author from the user by
the system.

With edebug, native-compilation, byte compilation and lexical binding
Todayon Tishri 11, 5787 when trying to send mail via smtpmail.el or
using mew with gnutls I get impenetrable backtraces and opaque closures
so solving the same problems that I was dealing with these 30 years ago
is even more challenging. and the techniques I could use then to solve
the problem are now impossible to use.

Of course these "compiler advances" are the gift of gold to the new
developer ecosystem that emacs now supports.

[toc] | [prev] | [next] | [standalone]

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | comp.lang.lisp

csiph-web