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.
| Date | Sujet | # | Auteur | |
| 4 Aug 26 |  A Case for Impurity: The Applied Pi Calculus (Re: Malicious Computer Architecture) | 2 | Mild Shock | |
| 4 Aug 26 |   The Sandcastle of Paul Taraus Interactors (Re: A Case for Impurity: The Applied Pi Calculus) | 1 | Mild Shock |
Les messages affichés proviennent d'usenet.