[Cuis-dev] Bag>>#sum:ifEmpty:

[ken.dickey at whidbey.com]

On 2022-11-03 06:28, Juan Vuletich via Cuis-dev wrote:

> A feature that would be nice to have is functional blocks. Some way to 
> be certain that some block will evaluate without modifying any existing 
> object at all. Then, Smalltalk would be better as a functional 
> language, and many operations taking a block would be more natural.

The base problem is with polymorphism.  A compiler can't tell what 
messages might be assignments.

The programming style has to change to be much nore "side effect" / 
assignment aware.

I am thinking of a Text Editor using Ropes.  Each mutation operation 
returns a new rope.  The editor than does the mutation to keep a stack 
of "undo" ropes.  Undo is trivial, just pop and redraw.  The ropes are 
immutable, so always thread safe, but the editor's state must be 
protected for single-threaded update behavior.

Being an old Scheme/Lisp/.. programmer, I find the functional style 
pleasing, but it is different.

Mumbling on..  with multicore SoCs, over time it would be good to adapt 
a microkernel approach to the Smalltalk runtime.  Be aware what state is 
local to a core, what is cached, what is proxied/shared.  Basically 
cheap to expensive in terms of management.

Perhaps an approach to this might be to define new "guarded/shielded" 
data structures (perhaps with a naming convention and a test predicate) 
which would be multicore safe but might be expected to do memory 
coherance and participate in multicore GC.

Give the work involved, I would hope this to be driven by motivating use 
cases and experiments.

$0.02,
-KenD