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 (was Re: Malicious Computer Architecture) Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-06 23:31 +0000
                      Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) Stefan Monnier <monnier@iro.umontreal.ca> - 2026-10-06 08:34 -0400
                        Re: GNU Emacs native compiled functions Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-06 20:51 +0000
                          Re: GNU Emacs native compiled functions Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-06 23:48 +0000
                          Re: GNU Emacs native compiled functions tfb <tfb@work.it.out> - 2026-10-07 07:56 +0000
                          Re: GNU Emacs native compiled functions steve g <Sgonedes1977@gmail.com> - 2026-10-10 19:14 -0400
                            Re: GNU Emacs native compiled functions Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-11 00:39 +0000
                              Re: GNU Emacs native compiled functions steve g <Sgonedes1977@gmail.com> - 2026-10-11 22:20 -0400
                                Re: GNU Emacs native compiled functions tfb <tfb@work.it.out> - 2026-10-12 05:37 +0000
                                Re: GNU Emacs native compiled functions Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-12 05:55 +0000
                                  Re: GNU Emacs native compiled functions steve g <Sgonedes1977@gmail.com> - 2026-10-12 17:06 -0400
                                    Re: GNU Emacs native compiled functions tfb <tfb@work.it.out> - 2026-10-13 08:14 +0000
                      Re: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) steve g <Sgonedes1977@gmail.com> - 2026-10-10 19:07 -0400
                    Re: GNU Emacs native compiled functions Aidan Kehoe <kehoea@parhasard.net> - 2026-10-06 08:30 +0100
                      Re: GNU Emacs native compiled functions tfb <tfb@work.it.out> - 2026-10-06 17:39 +0000
                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 Anton Antimo <anton@safunu.org> - 2026-10-06 15:14 -0300
                                Re: GNU Emacs native compiled functions steve g <Sgonedes1977@gmail.com> - 2026-10-10 19:17 -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 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

#61738 — Re: GNU Emacs native compiled functions

steve g <Sgonedes1977@gmail.com> wrote:

> 
> Yes, I read that. So you have a document with no tags; have you tried wc ?
> 

Seriously, msn, stop making a fool of yourself.  The original function
*stripped the markup and counted the words remaining*.  Your idiot
non-answer does the second part of that.  Can you see why that is entirely
failing to solve the problem?



-- 
tfeb.org/computer/

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

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

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

>> The biggest problem with dynamic scoping is variable shadowing.
>
> Not sure about "biggest".
>
> Variable shadowing can be worked around with conventions, leaving only
> accidents.

Umm, not the best programmer in the world, but isn't namespace an issue?

> Use *earmuffs* for variables intended to be context variables
> (true specials).

How do you define a context? I was thinking about sessions.

> Omit them for locals.

How do you mean? How do you implement local bindings? aside from
make-local-variable (emacs)? I usually use let.

> 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:

How can you determine bindings in the future or the past?

> (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.

No, I just stubborn.

[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]

#61709 — Re: GNU Emacs native compiled functions

Aidan Kehoe <kehoea@parhasard.net> wrote:

> 
> 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.
> 

I remember discussions about whether COMPILE-FILE had to intern symbols
used as local names, and then whether LOAD on the resulting file needed to.
 Not doing so is a theoretically-observable difference between interpreted
and compiled code.  I'm sure the practical answer is COMPILE-FILE should
while LOAD (of compiled code) needn't but is allowed to.

All this mattered so much more when symbols (let alone packages) were these
big expensive things.


-- 
tfeb.org/computer/

[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]

#61675 — Re: GNU Emacs native compiled functions

Madhu <enometh@meer.net> writes:
> 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.

Emacs Lisp (in the 1980s the contraction "Elisp" was frowned on) had
bytecode compilation from the beginning.  The recursive evaluator did
make debugging easier, so you might decide to skip compiling the thing
you wanted to debug.  If you left EVERYTHING uncompiled, Emacs probably
would have been unusable and maybe unrunnable on the hardware of those
days.

> With edebug, native-compilation, byte compilation and lexical
> binding...  I get impenetrable backtraces and opaque closures

Maybe there could be some better debugging support for compiled code,
like debugging symbols that let you immediately reach the source code
and run it under interpretation.  Earlier Lisps certainly relied on
native compilation since pre-1980s hardware (think PDP-10) was even more
limited than the Vaxes that GNU Emacs was developed on.

I never used the Lisp machine debugging environment but I know was
amazing even by today's standards.  I don't know what debugging in the
Maclisp era was like.

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

#61682 — Re: GNU Emacs native compiled functions

* Paul Rubin <87se31gqbw.fsf@nightsong.com> :
Wrote on Tue, 22 Sep 2026 10:15:31 -0700:

> I never used the Lisp machine debugging environment but I know was
> amazing even by today's standards.  I don't know what debugging in the
> Maclisp era was like.

you may have the chance to try it out now, if you can jump through the
hoops and apply for a personal license (bottom of
https://www.symbolics.biz/ , the invite only period seems to be over,
and can handle 75 dpi bitmap fonts on xlib under modern displays with)

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

#61683 — Re: GNU Emacs native compiled functions

 Ar an tríú lá is fiche de mí Méan Fómhair, scríobh Madhu: 

 > * Paul Rubin <87se31gqbw.fsf@nightsong.com> :
 > Wrote on Tue, 22 Sep 2026 10:15:31 -0700:
 > 
 > > I never used the Lisp machine debugging environment but I know was
 > > amazing even by today's standards.  I don't know what debugging in the
 > > Maclisp era was like.
 > 
 > you may have the chance to try it out now, if you can jump through the hoops
 > and apply for a personal license (bottom of https://www.symbolics.biz/ , the
 > invite only period seems to be over, and can handle 75 dpi bitmap fonts on
 > xlib under modern displays with)

Thanks for that, Madhu, I’ll apply for a personal licence.

-- 
‘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]

#61685 — Re: GNU Emacs native compiled functions

Madhu <enometh@meer.net> writes:
> https://www.symbolics.biz/ , the invite only period seems to be over,

Heh, I'm sure you have heard the RMS vs Symbolics saga.  I think I'll
pass that one up.  I don't know the current state of the CADR simulation
that people were working on a while back, but I hope I can give it a try
someday.

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

#61694 — Re: GNU Emacs native compiled functions

Paul Rubin wrote:
> I don't know the current state of the CADR simulation that people were
> working on a while back

Pretty good.

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

#61695 — Re: GNU Emacs native compiled functions

* Lars Brinkhoff <7wecegwrgy.fsf@junk.nocrew.org> :
Wrote on Sat, 26 Sep 2026 04:45:33 +0000:
> Paul Rubin wrote:
>> I don't know the current state of the CADR simulation that people were
>> working on a while back
> Pretty good.

I spotted this: https://tumbleweed.nu/lm-3/ from our ams (alfred m
szmidt) and (if i remember right) "tapes from moon's basement", though I
didn't have luck solving the fossil captchas on the mailing list.

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

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

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

csiph-web