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)

Started byJohann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid>
First post2026-08-03 19:23 +0800
Last post2026-08-04 15:10 +0200
Articles 6 on this page of 106 — 19 participants

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 steve g <Sgonedes1977@gmail.com> - 2026-10-15 15:27 -0400
                                        Re: GNU Emacs native compiled functions tfb <tfb@work.it.out> - 2026-10-15 19:58 +0000
                                    Re: GNU Emacs native compiled functions Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-15 21:19 +0000
                          Re: GNU Emacs native compiled functions Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-15 21:33 +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 6 of 6 — ← Prev page 1 2 3 4 5 [6]

#61711 — Re: GNU Emacs native compiled functions

FromAnton Antimo <anton@safunu.org>
Date2026-10-06 15:14 -0300
SubjectRe: GNU Emacs native compiled functions
Message-ID<877bju66ho.fsf@safunu.org>
In reply to#61705
steve g <Sgonedes1977@gmail.com> writes:

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

What's wrong with the vocabulary?  It's pretty standard to say
"shadowed", at least in programming English.

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

#61724 — Re: GNU Emacs native compiled functions

Fromsteve g <Sgonedes1977@gmail.com>
Date2026-10-10 19:17 -0400
SubjectRe: GNU Emacs native compiled functions
Message-ID<8733ud16yk.fsf@gmail.com>
In reply to#61711
Anton Antimo <anton@safunu.org> writes:

> steve g <Sgonedes1977@gmail.com> writes:
>


>> It can be "shadowed", excuse my poor vocabulary.
>
> What's wrong with the vocabulary?  It's pretty standard to say
> "shadowed", at least in programming English.

Why thank you.

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

#61676 — Re: GNU Emacs native compiled functions

FromKaz Kylheku <046-301-5902@kylheku.com>
Date2026-09-22 17:51 +0000
SubjectRe: GNU Emacs native compiled functions
Message-ID<20260922104542.572@kylheku.com>
In reply to#61658
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)

FromKaz Kylheku <046-301-5902@kylheku.com>
Date2026-09-22 18:02 +0000
SubjectRe: GNU Emacs native compiled functions (was Re: Malicious Computer Architecture)
Message-ID<20260922105111.31@kylheku.com>
In reply to#61654
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)

FromMild Shock <janburse@fastmail.fm>
Date2026-08-04 14:58 +0200
SubjectA Case for Impurity: The Applied Pi Calculus (Re: Malicious Computer Architecture)
Message-ID<114snlo$uj7n$2@solani.org>
In reply to#61270
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)

FromMild Shock <janburse@fastmail.fm>
Date2026-08-04 15:10 +0200
SubjectThe Sandcastle of Paul Taraus Interactors (Re: A Case for Impurity: The Applied Pi Calculus)
Message-ID<114sod0$ujln$3@solani.org>
In reply to#61277
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 6 of 6 — ← Prev page 1 2 3 4 5 [6]

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

csiph-web