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

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

#61697 — Re: GNU Emacs native compiled functions

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

Wow nice, it looks close to usable, though no idea what it takes to
actually run it.  I never used these machines to any extent in real
life, so I'm not very familiar with their operation.  It's ok, the
distro wasn't intended for people like me anyway.  But I might try to
play with it anyway.

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

#61698 — Re: GNU Emacs native compiled functions

* Paul Rubin <87zex2fj44.fsf@nightsong.com> :
Wrote on Sun, 27 Sep 2026 15:02:35 -0700:
> Madhu <enometh@meer.net> writes:
>> 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.
>
> Wow nice, it looks close to usable, though no idea what it takes to
> actually run it.  I never used these machines to any extent in real
> life, so I'm not very familiar with their operation.  It's ok, the
> distro wasn't intended for people like me anyway.  But I might try to
> play with it anyway.

The symbolics.biz is bound to be more polished as it is, for some value
of, "supported".  The question that led to this discussion was about the
debugger, and unfortunately i think there are goedel-theoretic limits on
a system to debug itself (the UI is 1986 zlib, i'd be interested to
hearing about your use of the debugger in LM-3)

also there seems to be a font of recently generated information here
https://github.com/htayj/lisp-machine-container-museum/

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

#61702 — Re: GNU Emacs native compiled functions

Paul Rubin <no.email@nospam.invalid> writes:

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

You could always come over my place and play with the Symbolics 1200xlt!
This one seems to work very well with women.

no, for real, I'm just bord...

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

#61686 — Re: GNU Emacs native compiled functions

Madhu <enometh@meer.net> writes:

> * 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)

This URL is currently unavailable:

--8<-------------------------------------------------------->8---
Service Unavailable

This server is currently operating at capacity and cannot accept your
request. Please try again later.  
CL-HTTP/169.0 (Symbolics Common Lisp)
--8<-------------------------------------------------------->8---

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

#61703 — Re: GNU Emacs native compiled functions

Anton Antimo <anton@safunu.org> writes:

> Madhu <enometh@meer.net> writes:
>
>> * 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)
>
> This URL is currently unavailable:
>
> --8<-------------------------------------------------------->8---
> Service Unavailable
>
> This server is currently operating at capacity and cannot accept your
> request. Please try again later.  
> CL-HTTP/169.0 (Symbolics Common Lisp)
> --8<-------------------------------------------------------->8---

I think reiner (spell) took his offline like a decade ago? Maybe he
still has some time to share a pizza.

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

#61684 — Re: GNU Emacs native compiled functions

Paul Rubin wrote:
> Emacs Lisp (in the 1980s the contraction "Elisp" was frowned on)

Because of this and also the Lisp dialect in CCA Emacs.

https://github.com/PDP-10/rutgers-elisp

Of course, only Emacs Lisp survives in active use today so maybe it's
time to accept "Elisp".  Maybe.

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

#61679 — Re: GNU Emacs native compiled functions

On 2026-09-20, Paul Rubin <no.email@nospam.invalid> wrote:
> 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.

I would go as far as: annoying to painful for it not to be available.

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

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

#61688 — Re: GNU Emacs native compiled functions

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

> I would go as far as: annoying to painful for it not to be available.
> 

I have, at least twice, had to implement dynamic variables in Python.  (in
memoryof Lisps I used before CL, I called these things variations on
'fluids').  Surprisingly Python does have enough to do this portably in a
thread-sane way.  So I agree: languages without a facility for this are
broken.

-- 
tfeb.org/computer/

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

#61690 — Re: GNU Emacs native compiled functions

On 2026-09-24, tfb <tfb@work.it.out> wrote:
> Kaz Kylheku <046-301-5902@kylheku.com> wrote:
>
>> I would go as far as: annoying to painful for it not to be available.
>> 
>
> I have, at least twice, had to implement dynamic variables in Python.  (in
> memoryof Lisps I used before CL, I called these things variations on
> 'fluids').  Surprisingly Python does have enough to do this portably in a
> thread-sane way.  So I agree: languages without a facility for this are
> broken.

Some quarter century ago now, I had a dynamic_var<T> template in C++,
with a dynamic_let<T> for the binding.

  dynamic_var<int> dv_foo = 42;

  ...

  {
     dynamic_let<int> foo(dv_foo, 73);
     ...

     // both foo and dv_foo are now 73

  }

  // foo is gone, dv_foo back to 42.

or something like that.

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

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

#61701 — Re: GNU Emacs native compiled functions

Paul Rubin <no.email@nospam.invalid> writes:

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


The problem was most likely that the size of GNU Emacs exceeded his
initial estimation.

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

#61666 — Re: GNU Emacs native compiled functions

On Sun, 20 Sep 2026 22:20:38 +0100, Aidan Kehoe wrote:

> Common Lisp has dynamic binding for globals and lexical scope for
> locals.

How does “dynamic binding for globals” work, exactly? A global can
only be declared once, so how can the binding ever be overridden by
another declaration?

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

#61669 — Re: GNU Emacs native compiled functions

Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
> On Sun, 20 Sep 2026 22:20:38 +0100, Aidan Kehoe wrote:
> 
>> Common Lisp has dynamic binding for globals and lexical scope for
>> locals.
> 
> How does “dynamic binding for globals” work, exactly? A global can
> only be declared once, so how can the binding ever be overridden by
> another declaration?

In dynamic languages it is probably better to say that variables
are created, because this is runtime action.  Logically process
of getting variable value can be considerd as two stage process.
First is mapping from names to storage location, second step
is accessing storage location.  In Lisp variable name pretty
early (in Lisp reader) are replaced by Lisp symbols.  Lisp symbol
has several slots.  One is symbol name.  But there are other slots,
in particular symbol value slot.  So first stage is realised
by having symbol, second by accesing value slot.  So in a
sense there is exactly one storage location for each global
variable.  However, when you have function like:

(defun foo (x)
    (let ((*dlvar* x))
         (declare (special *dlvar*))
         (bar)))

then Lisp implementation ensures that value that '*dlvar*' had
at entry is stored, and new value (given by 'x') is assigned so
that 'bar' sees this new value.  When 'bar' exits, either
normally or due to an error previous value of '*dlvar*'
is restored regardless of what 'bar' could have done to
'*dlvar*'.

In a sense it is nothig more than saving old value and restoring
it.  But doing this correctly without proper language support may
be tricky or tedious.  For example you may be forced to wrap
"catch all" exception handler around call to 'bar'.  In effect
you get construct that could be synthetised from simpler
primitives, but is is conveniet (and more efficient) to have it
available as a specialised language construct

I am not sure what you consder as binding, but in Lisp literature
it us usual to say that 'let' constuct above (with variable
declared special) introduces dynamic binding.

-- 
                              Waldek Hebisch

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

#61670 — Re: GNU Emacs native compiled functions

On Mon, 21 Sep 2026 19:06:11 -0000 (UTC), Waldek Hebisch wrote:

> In a sense it is nothig more than saving old value and restoring it.
> But doing this correctly without proper language support may be
> tricky or tedious. For example you may be forced to wrap "catch all"
> exception handler around call to 'bar'.

Or just use try/finally.

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

#61680 — Re: GNU Emacs native compiled functions

On 2026-09-21, Waldek Hebisch <antispam@fricas.org> wrote:
> Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
>> On Sun, 20 Sep 2026 22:20:38 +0100, Aidan Kehoe wrote:
>> 
>>> Common Lisp has dynamic binding for globals and lexical scope for
>>> locals.
>> 
>> How does “dynamic binding for globals” work, exactly? A global can
>> only be declared once, so how can the binding ever be overridden by
>> another declaration?
>
> In dynamic languages it is probably better to say that variables
> are created, because this is runtime action.

Even if you don't declare a variable, in a purely dynamically
scoped lisp (with shallow binding), the variable is actually created at
read time when the form like (setq foo 42) is processed by the reader.
The reader notices the foo token which is converted to a symbol by
interning. The foo part of the internal form of the expression is then a
direct pointer to the symbol.

When the code is executing, nothing needs to be created at /that/ run
time. The foo pointer is basically just dereferenced to get to the value
cell of the symbol.

(Of course, if we regard the reader as being "run time", then it's all
run time; but there are different stages of run time.  The run time of
loading the file is different form the run time of executing something
in in millions of times in a loop.)

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

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

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

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

csiph-web