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 3 of 6 — ← Prev page 1 2 [3] 4 5 6  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]

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

On 2026-10-06, tfb <tfb@work.it.out> wrote:
> 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.

Maybe, Bash, sorta. It has dynamic scope. Though "local var=..." is
binding, additional occurrences of it in the same function are
assignment, which we may legitimately call out as conflation.

The documentation for local says that it creates a new variable,
but I can't think of a way in which thqt claim is testable.

Without lexical capture, we cannot tell the difference between
mutating an environment by replacing a binding, or replacing
the value part of an existing binding: both look like assignment.

If we could to this:

  local x=42
  local f=$(lambda echo $x)
  local x=$((x + 1))

and observe the 42 value by calling the lambda, then we would
have to admit that local is doing shadowing binding.

Without lambda (or at least something weaker, like being able to obtain
the value address of a variable), we can't distinguish shadowing binding
from clobbering.

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

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

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

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

Yeah, living with dynamic scoping in ELisp wasn't that bad.  The main
problem was with downward funargs where you needed to be careful to use
gross names for the local variables of the intervening (higher-order)
functions, in order not to hide the outer bindings that the first-class
functions wanted to access.

The move to lexical scoping eliminated that problem and brought the joy
of closures with it (the lack of closures was mostly not perceived as
a problem: the coding style just "naturally" avoided them, and for those
rare cases where they were really handy you could use hacks like
backquoted lambdas or `lexical-let`).


=== Stefan

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

#61710 — Re: GNU Emacs native compiled functions

On Tue, 06 Oct 2026 08:34:15 -0400, Stefan Monnier wrote:

> The move to lexical scoping eliminated that problem and brought the
> joy of closures with it (the lack of closures was mostly not
> perceived as a problem: the coding style just "naturally" avoided
> them, and for those rare cases where they were really handy you
> could use hacks like backquoted lambdas or `lexical-let`).

I can’t imagine how you could have functions as first-class objects
without closures. At the very least, you would end up writing a lot
more repetitive code, which I hate.

For example, how would you deal with this, for counting words in an
HTML page after stripping all the markup (from
<https://gitlab.com/ldo/emacs-prefs>):

    (let
        (
            ...
            (delete-between
                (lambda (find-opener find-closer)
                    ; deletes regions between successive pairs of points
                    ; identified by find-opener and find-closer callbacks
                    (goto-char (point-min))
                    (while (funcall find-opener)
                        (let*
                            (
                                (end-tag (point))
                                (start-tag
                                    (progn
                                        (search-backward "<" nil nil)
                                        (point)
                                    ) ; progn
                                )
                            )
                            (goto-char end-tag)
                            (funcall find-closer)
                            (delete-region start-tag (point))
                        ) ; let*
                    ) ; while
                ) ; lambda
            ) ; delete-between
            ...
        )
        ...
        (dolist (tag '("head" "style" "script"))
            ; Gobble entire content for these tags, up to and including closing tags
            ; (luckily they don’t nest).
            (funcall delete-between
                (lambda () (re-search-forward (concat "<" tag "\\b[^>]*>") nil t))
                (lambda () (re-search-forward (concat "</" tag "\\b[^>]*>") nil nil))
            )
        ) ; dolist
        ...
    ) ; let

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

#61713 — Re: GNU Emacs native compiled functions

On Tue, 6 Oct 2026 20:51:02 -0000 (UTC), I wrote:

>                 (lambda () (re-search-forward (concat "<" tag "\\b[^>]*>") nil t))
>                 (lambda () (re-search-forward (concat "</" tag "\\b[^>]*>") nil nil))

Actually, I think that one is simple enough to work with dynamic
binding.

I do have a more complex example, which I can offer if required ...

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

#61714 — Re: GNU Emacs native compiled functions

Lawrence D´Oliveiro <ldo@nz.invalid> wrote:
> I can’t imagine how you could have functions as first-class objects
> without closures.

You can do it very easily, as your example shows.

-- 
tfeb.org/computer/

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

#61723 — Re: GNU Emacs native compiled functions

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


> On Tue, 06 Oct 2026 08:34:15 -0400, Stefan Monnier wrote:

> I can’t imagine how you could have functions as first-class objects
> without closures. At the very least, you would end up writing a lot
> more repetitive code, which I hate.

> For example, how would you deal with this, for counting words in an
> HTML page after stripping all the markup (from
> <https://gitlab.com/ldo/emacs-prefs>):

M-x count-words

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

#61725 — Re: GNU Emacs native compiled functions

On Sat, 10 Oct 2026 19:14:48 -0400, steve g wrote:

> Lawrence D’Oliveiro <ldo@nz.invalid> writes:
>
>> For example, how would you deal with this, for counting words in an
>> HTML page after stripping all the markup (from
>> <https://gitlab.com/ldo/emacs-prefs>):
>
> M-x count-words

Tried it on a test HTML file I had handy.

M-x count words reports a count of 10370.
My code reports a count of 9564.

Solving the wrong problem, much?

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

#61732 — Re: GNU Emacs native compiled functions

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

> On Sat, 10 Oct 2026 19:14:48 -0400, steve g wrote:
>
>> Lawrence D’Oliveiro <ldo@nz.invalid> writes:
>>
>>> For example, how would you deal with this, for counting words in an
>>> HTML page after stripping all the markup (from
>>> <https://gitlab.com/ldo/emacs-prefs>):
>>
>> M-x count-words
>
> Tried it on a test HTML file I had handy.
>
> M-x count words reports a count of 10370.
> My code reports a count of 9564.

Not to be an asshole, but I can be; what do you mean by words? Usually
counting spaces does not qualify.

> Solving the wrong problem, much?

always!

have you tried wc -w ? I get the same result from wc -l and count-lines.
and the same result from wc -w from count-words. Most people do not
consider a words less than 3 letters or sum such.

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

#61733 — Re: GNU Emacs native compiled functions

steve g <Sgonedes1977@gmail.com> wrote:
> 
> 
> have you tried wc -w ? I get the same result from wc -l and count-lines.
> and the same result from wc -w from count-words. Most people do not
> consider a words less than 3 letters or sum such.

It helps to read the problem specification: 'for counting words in an HTML
page after stripping all the markup'.

-- 
tfeb.org/computer/

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

#61734 — Re: GNU Emacs native compiled functions

On Sun, 11 Oct 2026 22:20:04 -0400, steve g wrote:

> Lawrence D’Oliveiro <ldo@nz.invalid> writes:
>
>> On Sat, 10 Oct 2026 19:14:48 -0400, steve g wrote:
>>
>>> Lawrence D’Oliveiro <ldo@nz.invalid> writes:
>>>
>>>> For example, how would you deal with this, for counting words in
>>>> an HTML page after stripping all the markup (from
>>>> <https://gitlab.com/ldo/emacs-prefs>):
>>>
>>> M-x count-words
>>
>> Tried it on a test HTML file I had handy.
>>
>> M-x count words reports a count of 10370.
>> My code reports a count of 9564.
>
> Not to be an asshole, but I can be; what do you mean by words?
> Usually counting spaces does not qualify.

Why, did you think I was?

Clue: I mentioned “stripping all the markup”.

>> Solving the wrong problem, much?
>
> always!
>
> have you tried wc -w ?

Yes, that is even worse than your idea. Which is saying something.

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

#61735 — Re: GNU Emacs native compiled functions

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

> On Sun, 11 Oct 2026 22:20:04 -0400, steve g wrote:


> Clue: I mentioned “stripping all the markup”.


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

>>
>> have you tried wc -w ?
>
> Yes, that is even worse than your idea. Which is saying something.

Dunno. wc (1)

DESCRIPTION
       Print  newline, word, and byte counts for each FILE, and a total line if
       more than one FILE is specified.  A word is a nonempty sequence  of  non
       white  space  delimited  by white space characters or by start or end of
       input.

       With no FILE, or when FILE is -, read standard input.

       The options below may be used to select which counts are printed, always
       in the following order: newline, word,  character,  byte,  maximum  line
       length.



wc (1) seems to do the job very well. I just tried wc and count-words
again on a text file and got the same exact results.

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

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

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

csiph-web