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) Stefan Monnier <monnier@iro.umontreal.ca> - 2026-10-06 08:34 -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 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 5 of 5 — ← Prev page 1 2 3 4 [5]

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

#61693 — Re: GNU Emacs native compiled functions

Kaz Kylheku <046-301-5902@kylheku.com> wrote:
> 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.)

I meant that running system may create a variable and then use it.
In Lisp it normally happens when one loads Lisp source code (in text
form), but it may happen in other ways, for example program may
INTERN a string and then SET resulting symbol.  Also, one can
UNINTERN the symbol and effectively variable is gone for users
who want to access it by sting name.  The point is that
unlike classic (non-OO) static language where the program simply
assumes that all declared variables actually exist, in dynamic
language things happen at runtime and in particular part of a
program may be executing before variables used in other part are
created.  Some effects of this are observable and language
documentation gives some rules.

IIUC some other languages go further in this direction than
Lisp, unlike typical Common Lisp implementation where storage
for variable is provided by value slot of corresponding symbol
storage for variable may be allocated later.

Objects with constructors mean that even in static language
situation is not as simple as it was in the past.

-- 
                              Waldek Hebisch

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

#61705 — Re: GNU Emacs native compiled functions

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

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

It can be "shadowed", excuse my poor vocabulary. You are correct that a
global cannot/should not be overridden by a another declaration. I
forget the words...

This is an ugly one. I dislike the &aux binding but I do use it as well.


(defvar mode-keymap)

(defvar *keymap-modes* '(esc help cx super))
(setq my-modes (cdr *keymap-modes*))

(defun print-modes (lst)
  (dolist (mode lst)
    (let ((mode-keymap mode))
      (print mode-keymap))))

(defun print-my-modes (&aux (mode-keymap  *keymap-modes*))
  (dolist (mode mode-keymap)
    (print mode)))




=> CL-USER> (print-my-modes)

ESC 
HELP 
CX 
SUPER 
NIL


(print-modes my-modes)

HELP 
CX 
SUPER 
NIL

(let ((mode-keymap '(1 2 3 4)))
           (dolist (i mode-keymap)
             (print i)))

1 
2 
3 
4 



The basic idea is 'minor-mode' is a variable without a default binding
in the global (heap) position, so it can be bound with

(setq minor-mode 'fundamental-mode)

Now minor mode is default. When you switch buffers the open-buffer
command will rebind minor-mode to accomidate. Returning to your previous
buffer will do the same. It is like a list (LISP and list?) instead of
searching a list of available modes, it can be faster for the
open-buffer command to just set the value. Lexical binding is
unrealistic in this situation. I still like the &aux key but not too
many people use it. 


Unfortunately this mechanism can be very difficult to program with,
especially with something as large as Gnu Emacs.

This is close enough...

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

#61676 — Re: GNU Emacs native compiled functions

On 2026-09-19, Aidan Kehoe <kehoea@parhasard.net> wrote:
>
>  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.

OK, but with lexical scoping you know that nothing outside of the
lexical scope messed with the variable. And whatever it was, it was
in the same dynamic activation of that lexical scope as which
instantiated that binding. :)

Only a shallow-binding implementation of dynamic scope is susceptible to
a fixed address breakpoint. (Or a deep binding one too, if the variable
is left global.) Under deep binding implementations of dynamic scope,
there is actually a scope chain that is traversed to find dynamic
variables; when one or more dynamic bindings are introduced, they push
a new dynamic environment frame. The thread carries a pointer to the
current dynamic environment top as part of its context.

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

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

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

On 2026-09-18, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 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.  🙂

Dynamic scoping is an important tool; I loathe the environment without
support for them.

The situation of lexical binding by default with dynamic binding
being available is best.

I also like Common Lisp's idea of attributing a symbol for dynamic
binding. Combined with a naming convention like earmuffs, it works well.

Dynamic variables are great for carrying application-defined
implicit contexts, which would otherwise have to be carried
as numerous arguments (which is impractical when the call stacks
go through functions which are not supposed to know anything
about these contexts, like callback jigs and whatnot).

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

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

#61277 — A Case for Impurity: The Applied Pi Calculus (Re: Malicious Computer Architecture)

Hi,

How it started:

The Applied Pi Calculus: Mobile Values,
New Names, and Secure Communication
Martín Abadi et al. - Google Brain
https://arxiv.org/abs/1609.03003

How its going:

Dynamic Control Flow in
Large-Scale Machine Learning
Martín Abadi et al. - Google Brain
https://research.google/pubs/dynamic-control-flow-in-large-scale-machine-learning/

Have Fun!

Bye

Johann 'Myrkraverk' Oskarsson schrieb:
> On 03/08/2026 6:28 PM, David Brown wrote:
>> On 03/08/2026 11:41, Richard Harnden wrote:
>>> On 03/08/2026 09:16, David Brown wrote:
>>
>>>> On most targets, function pointers are the same size as void* 
>>>> pointers. But there are exceptions, with some small microcontrollers 
>>>> and DSPs having different kinds of pointers with different sizes, 
>>>> depending on the memory space involved.  I have yet to see a 
>>>> situation where there was any reason for storing a function address 
>>>> in a "void*" rather than a more appropriate typedef, such as :
>>>>
>>>>      typedef void (*FVoid)(void);
>>>
>>> dlsym requires that pointer-to-function is compatible with a void*
>>>
>>
>> As I say, I have yet to see a situation where using void* for function 
>> pointers was more appropriate than using a function pointer type.  If 
>> the OS system calls or standard OS libraries makes it a requirement 
>> that function pointers are converted to or from void* for some calls, 
>> then of course you need to follow those requirements - it's the people 
>> who designed the interfaces that made questionable design choices.
>>
> 
> Nope, you're wrong.  You're dead wrong.  The world isn't built on C,
> even though here in comp.lang.c we like to pretend it is.
> 
> Several language environments allow function generation on the fly,
> these functions need to be garbage collected.  Common Lisp is an
> example, therefore comp.lang.lisp is added to this discussion.
> 
> I've also added comp.theory so Mild Shock can comment.
> 
> You will have to go out of your way to make a computer architecture
> incompatible with garbage collected and heap allocated binary code,
> something I've been told SBCL does internally [1] to create an archi-
> tecture that has different
> 
> *  sizeof ( void * ), and
> *  sizeof ( void (*)( void ) ),
> 
> and when you do that, I'll just claim you're making a /malicious
> computer architecture/ and refuse to use it.
> 
> 
> [1] I've not looked at the code, but told the garbage collector can
> and will at least move the code around, if not collect it.

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

#61278 — The Sandcastle of Paul Taraus Interactors (Re: A Case for Impurity: The Applied Pi Calculus)

Hi,

While Paul Taraus Interactors were somewhere
between stackfull and stackless coroutines,
they were still a castle built on sand.

What was the comms? An interactor was a child
of a parent, and had only two comms, input "next"
and output "the". And there was not much

asynchronizity. But look at the new
library(misc/intercom) that provides ADA
Rendez Vous in Dogelog Player for Java:

:- ensure_loaded(library(misc/intercom)).

producer(C) :-
    between(1,10,X),
    Y is X*X,
    send(C,[Y]),
    fail.
producer(_).

consumer(C) :-
    between(1,10,_),
    recv(C,[Y]),
    write(Y), nl,
    fail.
consumer(_).

As the show case shows, it even works with
cooperating coroutines. I have looked at it
for 5 hours straight, its beautiful:

?- cpu_chan_new(C), create_task(producer(C)),
    create_task(consumer(C)), sleep(1000).
1
4
9
16
25
36
49
64
81
100
C = 0rReference.

Bye

Mild Shock schrieb:
> Hi,
> 
> How it started:
> 
> The Applied Pi Calculus: Mobile Values,
> New Names, and Secure Communication
> Martín Abadi et al. - Google Brain
> https://arxiv.org/abs/1609.03003
> 
> How its going:
> 
> Dynamic Control Flow in
> Large-Scale Machine Learning
> Martín Abadi et al. - Google Brain
> https://research.google/pubs/dynamic-control-flow-in-large-scale-machine-learning/ 
> 
> 
> Have Fun!
> 
> Bye
> 
> Johann 'Myrkraverk' Oskarsson schrieb:
>> On 03/08/2026 6:28 PM, David Brown wrote:
>>> On 03/08/2026 11:41, Richard Harnden wrote:
>>>> On 03/08/2026 09:16, David Brown wrote:
>>>
>>>>> On most targets, function pointers are the same size as void* 
>>>>> pointers. But there are exceptions, with some small 
>>>>> microcontrollers and DSPs having different kinds of pointers with 
>>>>> different sizes, depending on the memory space involved.  I have 
>>>>> yet to see a situation where there was any reason for storing a 
>>>>> function address in a "void*" rather than a more appropriate 
>>>>> typedef, such as :
>>>>>
>>>>>      typedef void (*FVoid)(void);
>>>>
>>>> dlsym requires that pointer-to-function is compatible with a void*
>>>>
>>>
>>> As I say, I have yet to see a situation where using void* for 
>>> function pointers was more appropriate than using a function pointer 
>>> type.  If the OS system calls or standard OS libraries makes it a 
>>> requirement that function pointers are converted to or from void* for 
>>> some calls, then of course you need to follow those requirements - 
>>> it's the people who designed the interfaces that made questionable 
>>> design choices.
>>>
>>
>> Nope, you're wrong.  You're dead wrong.  The world isn't built on C,
>> even though here in comp.lang.c we like to pretend it is.
>>
>> Several language environments allow function generation on the fly,
>> these functions need to be garbage collected.  Common Lisp is an
>> example, therefore comp.lang.lisp is added to this discussion.
>>
>> I've also added comp.theory so Mild Shock can comment.
>>
>> You will have to go out of your way to make a computer architecture
>> incompatible with garbage collected and heap allocated binary code,
>> something I've been told SBCL does internally [1] to create an archi-
>> tecture that has different
>>
>> *  sizeof ( void * ), and
>> *  sizeof ( void (*)( void ) ),
>>
>> and when you do that, I'll just claim you're making a /malicious
>> computer architecture/ and refuse to use it.
>>
>>
>> [1] I've not looked at the code, but told the garbage collector can
>> and will at least move the code around, if not collect it.
> 

[toc] | [prev] | [standalone]

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

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

csiph-web