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

Juan Vuletich juan at cuis.st
Thu Nov 3 08:03:33 PDT 2022


On 11/3/2022 11:46 AM, ken.dickey--- via Cuis-dev wrote:
> 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.

But assignments are not messages! Besides, the VM already supports 
read-only objects. I think we're not that far.

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

But I was only talking about block closures used like the arguments of 
collections. I think you're talking about a much broader area.

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

The people who really know about this kind of stuff is of course Martin, 
Andrés and other the Gemstone folks.

> Give the work involved, I would hope this to be driven by motivating 
> use cases and experiments.
>
> $0.02,
> -KenD

Thanks,

-- 
Juan Vuletich
cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
linkedin.com/in/juan-vuletich-75611b3
twitter.com/JuanVuletich



More information about the Cuis-dev mailing list