I believe you have the wrong end of the the stick promoting that the VM��

needs to be redeveloped using Pony to get the Reference Capabilities
at the Smalltalk level.�� After you Ahead-Of-Time compile the VM, the compiler

is left behind.�� The features of the compiler don't automatically flow through

to Smalltalk level.��

A third option could��be to extend to the existing "Immutability capability" of the VM.����

The six Reference Capabilities might be stored in the Spur Object Header��

using a re-purposed Immutability bit plus the two free "green" bits.

https://clementbera.wordpress.com/2014/01/16/spurs-new-object-format/����

"Reference Capabilities for Dynamic Languages" could be a strong PhD project.����

cheers -ben

On Fri, 10 Apr 2020 at 17:56, Shaping <shaping@uurda.org> wrote:
>
> Hi Ken.
>
> Not to discourage people, but I have not seen cases where a "strong
> type system would be able to scale for _real_ Smalltalk applications.
>
> You���re right.�� It doesn't.�� I'm not suggesting that.
>
> The type safety is not for app-level Smalltalk development.�� It's for building the VM only.
>
> The six ref-cap ideas for sharing data reliably between actors are not hard to grasp, but they take some getting used to, and involve some mental load.�� I don't want that much (concurrency-related or any other) implementation detail in the domain layer, much in the same vein as: ��I don���t use Forth because I don���t want to see stack acrobatics (ROTs and DUPs, etc.) amidst domain-level state-changes (FirePhotonTorpedo).�� It���s distracting.�� It dilutes focus on the domain work/layer, and tends to cause mistakes there.
>
> ��
>
> The programmer���s domain logic and the concurrency-integrity provided by the ref-caps are different layers of thought and structure.�� The ref-caps are, however, mixed freely with domain logic in current Pony code.�� I think that���s a mistake.�� But that���s how it is now.�� I think of this layer mixing as an intermediate design stage of Pony.�� I want to abstract-out some or all ref-caps as the VM is built.
>
> Pony language is not the remarkable thing here. I see it as a better C or better Rust.�� It���s very good (as Algol-60-ish-looking crap-syntaxes go), but that���s not what this is about.�� It���s about the actor programming, the concurrency model, and the guarantees given by use of the ref-caps.�� We would still obviously need to respect the Pony compiler���s determination of where ref-cap use is correct or not.�� Your Pony program won���t compile if you don���t use the ref-caps correctly, and you don���t get the guarantees or a running program without the compile.�� Much easier, therefore, might be to go the other way by changing Pony to support dynamic types without violating the invariants that allow the ref-caps (under the hood, abstracted out) to make the concurrency guarantees.�� Work Smalltalk dynamism into Pony, instead of building a Smalltalk VM with Pony.��