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

[ken.dickey at whidbey.com]

On 2022-11-03 07:59, Juan Vuletich via Cuis-dev wrote:

> On 11/3/2022 11:21 AM, Luciano Notarfrancesco via Cuis-dev wrote: 
> 
>> Yes, the idea of functional blocks could be very interesting. But the most straight forward idea of blocks that don't modify state at all wouldn't work, it would be more complicated than that. 
>> For example, the block [:x | x / 2] is a function for integers and fractions in the sense I was using before, e.g. evaluating it multiple times at 3 returns always 3/2. But it modifies object memory and creates new instances of 3/2 each time (they are equal but not identical). 
>> So I think perhaps the notion of "functional blocks" should be used differently in Smalltalk, not strongly as in functional languages, but dynamically and in terms of behavior, similarly as how we deal with types (for example in methods that assume their arguments implement certain protocols, but without enforcing types explicitly like other languages).
> 
> Instead of "without modifying any existing object at all" I'd have said "without modifying any previously existing object at all". The idea is to disable modifying older objects, but to allow creating / modifying new objects, created during the execution of the block. That would be pretty close to what functional languages do, that is to allow modification only during creation.

This again would benefit from a copy-on-write/SquashFS like strategy for
use with multicore SoCs as the memory write protect vs local unprotected
allocation could have a natural management framework useful for this. 

Given that large amount of initial/base image which does not change, a
SquashFS like solution might lso yield faster startups, so trivial
scripting usage would be cheap.  In this context, functional code
updates might pay for themselves. 

$0.02, 

-KenD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20221103/5394c2b6/attachment.htm>