<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>
<p>On 2022-11-03 07:59, Juan Vuletich via Cuis-dev wrote:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0"><!-- html ignored --> <!-- head ignored --><!-- meta ignored --> On 11/3/2022 11:21 AM, Luciano Notarfrancesco via Cuis-dev wrote:
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
<div dir="auto">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.</div>
<div dir="auto">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).</div>
<div dir="auto">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).</div>
</blockquote>
<br /> 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.</blockquote>
<p>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.</p>
<p>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.</p>
<p>$0.02,</p>
<p>-KenD</p>
<p><br /></p>
</body></html>