chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Chicken-hackers] Would SRFI-157 (pre)support worth a consideration?


From: Jörg F . Wittenberger
Subject: [Chicken-hackers] Would SRFI-157 (pre)support worth a consideration?
Date: 23 Oct 2018 21:33:02 +0200

Hi all,

with Chicken 5 being about to be released I know there is no adding
features now.

That's why I hesitate to post at all.  At the other hand I'd guess it
might be easier to now add half the feature I'd desire than later deal
with a binary incompatible change.

The problem:

I've been looking into the idea today to port the "forcible" egg to
chicken 5.  Forcible was intented to do two things: a) fix force/delay
wrt. srfi-18 threads (make sure there is only one invocation of the
delayed expression) and b) implement "future"s (inherited from
rscheme) which is syntactically like delay, but the expression
evaluated in an asynchronous thread.  ((There is a actually one more,
but that's a programming experiment.))

Delayed, I had porting the egg since I knew it had an issue: "future"
and "delay" are not equivalent wrt. access to parameters.  Exactly
what SRFI-155 discusses in the Rationale.

The solution:

Or at least the hint to the solution I found in

https://srfi.schemers.org/srfi-157/srfi-157.html
section "Implementation hints" second paragraph

The idea:

Maybe it's worth to consider adding this one more "thread-local
mutable cell" in C5 threads now.  To make room for srfi-157 support in
C5.1 or so.

Best Regards

/Jörg





reply via email to

[Prev in Thread] Current Thread [Next in Thread]