и тут нужно делать рефы (как иорефы, так и просто хранить поинтеры/ключи на мапку с памятью)

то есть условно

x := 0
y := \() -> print x
x := 1
y () -- должно вывести 1

без явных боксов

Ну скоуп-то не меняется все равно. То есть в таком случае ридер + что-то мутабельное внутри

Дизайнить что-то такое, у чего скоуп меняется непредсказуемым образом, мне слава богу не приходилось

так, а чем это лучше, и можешь показать пример/дать ссылку что почитать

стейт выглядит проще и естественнее, а конты тут вообще не понятно как должны использоваться

do
 declare "a" 1
 set "a" 2
 local do
   declare "a" 0
   set "a" 1
 print =<< deref "a"

-- 2

вот такой язычек, как тут скоупы моделировать не стейтом?

тем что

1) local, предоставленный по дефолту, ведет себя ровно так как нужно. Точно не выстрелишь себе в ногу, случайно апдейтнув стейт и забыл отменить апдейт по выходу их скоупа (видел такое кучу раз). И коллега твой тоже не выстрелит, даже если не знает про всю эту специфику
2) при этом если ты таки хочешь иметь поведение стейта, то просто навешиваешь ContT поверх, и Reader превращается в State

таким образом у тебя по дефолту безопасное поведение, которое можно явно локально поменять, если это когда-то нужно

ща поищу ссылку про ContT/Codensity в этом контексте

According to the facts above, we should have that Codensity (s ->) (excuse the sectioning) is the same as state, and if we look, we see:

forall r. (a -> s -> r) -> s -> r

which is the continuation passing, or Church (or Boehm-Berarducci) encoding of the monad.

хм, я понял мысль, но я гарантировал невыстрел тем, что делал весь стек языка в ньютайпе, и крайне ограничивал работу со скоупом, то есть кроме withLocal ничего и не было

и таким образом если не править код языка, никак в ногу не выстрелить

спасибо

это решает проблему 1, но не проблему 2. С ридером + коденсити у тебя в типах видно, каким образом скоуп обрабатывается, и ты можешь менять это поведение посредством явного заворачивания/разворачивания в/из коденсити, так что в коде всегда понятно, где какое поведение используется

На MUMPS

Ну и откопал...

вот как это выглядит на практике: https://github.com/input-output-hk/plutus/blob/a6efba6ed03f31634886d88607efc4101d77f20b/language-plutus-core/plutus-ir/Language/PlutusIR/Transform/Rename.hs#L23-L58

все эти ContT выглядят страшно, но паттерн там простой, если к нему привыкнуть

понял идею, мы всегда работаем не с конкретной переменной, а с той, что нам выдали, и таким образом можем контроллировать то что выдавать в скоуп

Поразительно, вообще ни слова не понятно