нет)

и в хаскеле бывают циклические ссылки

ммм, я имел ввиду циклы большей длины. Например a = 1:b; b = 2:a

а зачем тебе IORefы в твоём языке?

ну какое-то подобие переменных впилить

локальные переменные можно на StateT, глобальные не нужны

как то так

Впрочем, без монад глобальные таки нужны :(

State есть, если функции в языке есть

любой State в интерпретаторе, который меняется при работе = память

т.е. почти всегда

не, юзай State внутри языка

а не в интерпретаторе

типа если ты туда что-то добавил, то оно там так и будет валяться, если сам не почистишь

гц за тебя это не сделает

проблема в том что в глобальном State внезапно не будет работать gc

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

статические переменные тоже не собираются обычно

в руби хорошо реализованно, там локальный стейт это объект первого класса

? началось

@azzaazaa если в языке есть функции, есть StateT, если есть StateT, то есть переменные

и не нужен экстра GC

внутри твоего трансформера что?

хочу переменную типа X, пишу код в State X

ок, пробграмма твоя перестала эту переменную использовать, что произошло?

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

если там есть переменные, то наверно он отличается от хаскеля, а если отличается то наверно сильнее чем наличием переменных

возможно там даже грязные функции есть

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

эх, ладно, проехали

переменные становятся просто абстракцией использующей s -> (s, a)

я вижу только три варианта: 1) юзать IORef и хаскельный GC, 2) юзать Map Int Data и писать свой GC, 3) не давать юзеру newIORef и заставлять использовать State внутри языка

можно ещё юзать IORef с reference counting и запретить создание циклических ссылок

ну и аналогично можно и без IORef тогда обойтись

использовать GC Haskell и делать ref counting /0

@nDanshin будет жить. Поприветствуем!

В обычной просто-типизированой лямбде циклические референсы не выразимы, конечно же

В раннем лиспе референс каунтеры внедрили именно потому что была доп-конструкция Cons

Поэтому в общем случае потребность GC выражается доп. конструкциями

Добавляю свой голос в число тех, кто полагает, что если будут циклические, то ничего лучше хост-GC всё равно не сделаешь

Но даже если добавить в язык какой-то fix, можно всё равно сделать референс-каунтинг, учитывающий эти добавленные ссылки

Смысл это всё имеет только если потеря переменной из скоупа должна иметь какую-то семантику в строящемся языке

так разговор не про циклы, а про грязь

так разговор не про циклы, а про грязь

Какую грязь?

ref

var

А что с ними?

блин, опять

как их реализовать не используя ref - ы самого хаскеля и при этом не менеджить самому эту память

Ну предложили же массив

это и есть память

своя

которую gc хаскеля заберёт только когда весь массив не нужен будет

Да. И, все и я указали, что в зависимости от языка, тебе нужен или не нужен гарбедж коллектор той или иной формы

Слово var само по себе ни о чём не говорит

Какова семантика?

если вары только локальные, то ГЦ не нужен

функции, логические значения, вары

вары типизируемые

ты опять сказал "вары'

пример напиши в своём языке

Могут ли вары ссылаться друг на друга

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

Есть ли уникальность

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

С помощью каких-то других определений

а?

промоутить?

Например в чистом call-by-name любой вар или что там у тебя - это ссылка на выражение, она будеи вычисляться каждый раз при необходимости. И тогда не нужно ни программного хипа, ни GC

Поэтому нужно очень много деталей операционной семантики для рассуждений о контроле за памятью

чувсвую сложность излишнюю в твоих речах )

то, что многое зависит от семантики - согласен

Мне, наоборот, кажется, что ты решил погрузиться в детали реализации, не имея хорошо сформулированного плана интерпретации

Звучит, будто решил сделать интерпретатор интуитивно, с наскока

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

var f = (lambda x:Bool. var z = 0 (lambda y:Bool. if x then z = z + 1 else z - 1)) f(true) вот в той реализации, которую я в голове пока могу сложить, во второй строке, выражение var z = 0 мутирует какую-то память интепретатора, StateT, Map, etc - не суть

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

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

Сначала сформулируй, как ты будешь это интерпретировать

А потом можно сказать, какой будет GC

f возвращает функцию, которая инкрементирует счётчик z при true параметре и наоборот

Потому что я могу вообразить как минимум пару форм, где GC не нужен

Например, овнершип. Внутренняя лямбда объявляется овнером x, x исчезает вместе с ней. При иниерпретации внутренняя лямбда превращает свой предыдущий завоненный стейт в следующий

Call-by-value всегда же будет в ситуации , когда gc не нужен

Ну и запрет на передачу ссылок

Например, овнершип. Внутренняя лямбда объявляется овнером x, x исчезает вместе с ней. При иниерпретации внутренняя лямбда превращает свой предыдущий завоненный стейт в следующий

предыдущий?

условно если я 1М таких функций навызывал, а потом перестал

этот предыдущий стейт где находится?

зачем вы разбиваете предложения на реплики? тяжело читать же

предыдущий?

Да. В семантике, где у тебя есть функции с овненным скрытым стейтом, ты имеешь каждый раз в скоупе функцию и последний актуальный стейт для неё.

зачем вы разбиваете предложения на реплики? тяжело читать же

implying кто-то намеревается их читать

f = \_ -> { var z = 1 (\_ -> { z += 1; z }, \_ -> { z -= 1; z }) } f = \_ -> { var z = \_ -> 1 (\_ -> { z 2 }, \f -> { z = f; () }) } (a, b) = f() b(a) если оба примера должны работать в этом гипотетическом языке, то без ГЦ не обойтись

если запретить var f : a -> b (и полиморфные varы, если есть полиморфизм), то можно обойтись reference counting

а интерпретаторы с reference counting вообще существуют? )

а почему нет

если там есть переменные, то наверно он отличается от хаскеля, а если отличается то наверно сильнее чем наличием переменных

будто бы в хаскеле переменных нету