OberonCore

то есть, в колбэках запрещено делать NEW?

Не верю, но разобраться некогда.

Там дело даже не в том. Если ф.обратного вызова выполняется, на стеке могут быть указатели, ссылающиеся на объекты на куче. Если не вести учёт выполнений всех функций, то будут висячие указатели. Т.е. даже не нужно делать NEW, достаточно открыть какой-нибудь глобальный мутабельный список (ссылка на него может быть в теле ф-ии обратного вызова) и походить по нему, получив в локальной переменной ссылку на объект на куче. Поэтому без учёта кадров стека таких функций, в т.ч. и времени их жизни, ничего работать не будет. Поэтому без обёрток я не представляю как тут выкрутиться. Т.е. либо Сергей что-то не знает, либо оно действительно не работает, либо есть какие-то ограничения на функции обратного вызова, о которых пока ничего не сказано. Например, должно быть запрещено не просто делать NEW, а вообще обращаться к куче. Ну либо оно сделано как-то ещё, т.е. мы слово "обёртка" как-то переименуем, чтобы не отступать от ранее сказанного.

Лисп силён синергией. В форте нет понятия консов а польская запись - для машин, а не для людей. И кучи вроде тоже нет. Т.е. он мелковат. Про смолтолк я не в курсе, но мне его идея ООП как-то не особо нравится. Так-то в целом смолтолк выглядит на сегодня гораздо живее лиспа. Насчёт непрактичности лиспов я в корне не согласен. Напротив. на лиспе легко делается то, что на других языках делается либо горкой костылей за время 10x, либо не делается вообще. У него есть кое-какие ограничения, но в очень широком классе задач я не знаю ему равных. Просто надо притерпеться к его синтаксису и да, в малом он более медленный, т.к. синтаксис там просто как назло сделан в некоторых местах.

с обращением к куче проблем нет, и быть не может: единственный вариант получить указатель на объект в куче — это добыть его или из глобальной переменной, или из поля объекта. обе эти штуки уже заякорены, так что ничего опасного нет. опасно только делать NEW с локальной переменной, если стек не сканируется: вот тогда объект не заякорится (даже если быстро локал присвоить глобалу — всё равно в промежутке может активироваться GC).

собственно, если запретить NEW с локалами, то всё будет хорошо. но. есть, так сказать, нюанс: тогда надо анализировать всё потенциально возможное дерево вызовов, потому что мы можем вызвать процедуру, которая сделает NEW с локалом.

ну, или как вариант: NEW знает, что его вызывают из колбэка, и якорит само. тогда надо для колбэка генерировать код «вошёл-вышел». причём со счётчиками, и с обработкой трапов.

короче, как ни крути, а получается сложный и хрупкий монстр. намного проще консервативно сканировать стек и не мучаться.

хотя в A2 консервативное сканирование более неприятно, чем в BBCB. в BBCB рано или поздно (скорее рано) процедура закончится, и мы вернёмся в главный цикл. где стек гарантировано чистый, без лишних якорей. а главный цикл периодически пинает GC (или другие процедуры пинают; всё равно вероятность что-то случайно заякорить навечно около нуля). в BBCB так надо делать, чтобы система продолжала оставаться отзывчивой.

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

Я специально написал "мутабельный". Например, процедура обратного вызова может извлечь что-то из глобальной очереди и тогда стек выполнения это процедуры станет единственной ссылкой на этот объект.

элементарно добавляется.

не, вот эта претензия со стороны лисперов очень смешная. у самих-то запись префиксная вместо постфиксной, тоже не для людей. ;-)

зависит от системы. надо — элементарно делается, в том числе и с GC. не надо (например, какая-нибудь маленькая эмбедовка) — не делается.

тащемта, библиотек для ANS Forth вполне себе дофига, от простых структур данных и до реализаций TCP/IP стека с нуля. (и даже несколько вариантов реализации CLOS есть.) если форт-система имеет режим совместимости с ANS — то проблем обычно не возникает. ну, может иногда пару констант в библиотеке руками настроить надо.

забавно, что оберон (в плане системы, а не языка) на практике реализует именно её: расширение записи чтобы дополнить обработчик, и более-менее универсальный обработчик сообщений.

вот точно то же самое, точно теми же словами говорят фортеры про форт. и что характерно: оба лагеря правы. потому что форт и лисп — идеологически близкие родственники.

> а вот в A2 активности независимы, так что никто не мешает активности крутиться в процедуре со случайным якорем вечно.
Вот на этот случай там есть что-то. Я регулярно вижу сообщения "close unreferenced process". Не знаю, что это означает, но как-то там финализируются процессы. Если же активность полноценная, то она есть в списке всех активностей и можно её найти. Если она крутится бесконечно, значит, владелец системы за ней недосмотрел.

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

ну почему не досмотрел? да простой цикл поллинга каких-нибудь датчиков, который иногда дёргает/запускает другие активности. этот цикл будет вечно крутиться, например.

> не, вот эта претензия со стороны лисперов очень смешная

Польская запись описывает создание структуры, а лисповая всё же описывает саму структуру. Так что разница есть и большая. То, что в лиспе плохой синтаксис - это проблема не s-выражений. Они почти не избыточны по сравнению с алгебраической записью. Это проблема самих конструкций, таких, как let. Я это в своё время решал:

https://github.com/lisp-mirror/budden-t ... .lisp#L147

И стало намного лучше программировать на лиспе. Вторая проблема - это отсутствие нотации запись.точка. В hy её сделали, но это сложно воткнуть в уже сложившийся язык, не сломав его. У меня не получилось (сделал и пользовался, но было хрупко и наступал на грабли регулярно).

Если в Форте консы и кучу можно сделать библиотекой, то это не то же, что их наличие в самом языке - оно получается не органично и не увязано. Когда пытаются упростить язык , выкинув всё в библиотеки, то библиотеки могут плохо взаимодействовать между собой, т.к. никто не планирует их развитие как комплекса. В лиспе многое уже изначально в системе, и взаимоувязано.

Если речь про бОльшую опасность здесь консервативной сборки мусора, чем в ББЦБ, то да.

и чтобы разбавить адовый офтопик (не, я не против офтопа, если что: занимательная беседа получается): я, наконец, созрел и оторвал обработку шорткатов от меню. теперь менеджер шорткатов — отдельный модуль, и бэкэнд консультируется именно у него. а меню просто регистрирует свои шорткаты в глобальном списке.

соответственно, окна (документы, конечно) могут регистрировать свои шорткаты минуя меню. с одной стороны это плохо, потому что потенциально теряется обнаружимость шорткатов пользователем. а с другой стороны — иногда удобно. потом можно будет сделать отдельный менеджер шорткатов, где пользователь сможет их все посмотреть, активировать, деактивировать, сделать свои, и даже переопределить существующие (если автор прибил шорткат гвоздями, например).

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

абсолютно то же самое, потому что в форте нет никакой разницы между «языком» и «библиотеками». плюс там есть очень простые, но мощные и удобные namespaces — словари. иерархические, если хочется. в принципе, такая своеобразная, но вполне рабочая система модулей.

(косится на common lisp, который полностью не знает, кажется, вообще никто.)

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

Мне показалось, что это хорошо сделано в Tk. Но да, надо завязывать с офтопиками, и вообще работать надо.

В лиспе родной ввод-вывод почти весь уже построен на консах. Если в форте их в языке нет, значит там нельзя построить встроенный ввод-вывод на консах. Т.е. разница всё же есть.


По современным меркам Common Lisp достаточно компактный и простой язык. Документация там, конечно, не отличается особой понятностью и удобочитаемостью. Но на фоне какой-нибудь спецификации Котлина (которая, к тому же на момент прочтения мной существовала отдельно от языка и не была обязана чему-либо соответствовать) выглядит довольно скромно. И да, там довольно хорошо увязаны между собой многие части. Не все - CLOS сбоку торчит. Но я вообще сомневаюсь в нужности оного, хотя родовые функции использую. И не идеально. Но хорошо.


Хорошо построенный дом гораздо лучше, чем груда кирпичей. Во всяком случае, для жителя дома. Для строителя - может быть по-разному. И чтобы построить хороший дом, недостаточно иметь груду кирпичей - может получиться дом, а может и "шанхай". Но в целом пусть Форт тоже будет, я от него пришёл к лиспу, т.к. меня привлекла концепция "компилирующих слов". Не знаю, куда он уразвивался с того момента, когда я о нём читал советскую книгу в начале 90-х.

Комплексность - это хорошо. Части друг другу помогают и вместе получается больше, чем простая сумма компонентов. Это называется синергия. Просто N библиотек, написанных без единого плана, не будут обладать синергией, и работать с ними будет гораздо хуже.

Как пример - в Windows Ctlr-C Ctrl-V работает во всех графических приложениях, т.к. единый план. А в Linux может повезти, а может и не повезти. Или разные реализации строк в C++.

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

да интересная беседа же. я лично совмещаю: поработал — выпил кофе, почитал-пописал. ;-)

так в форте и встроеного ввода-вывода нет. ;-) ну, блоки — и даже они не обязательны. в большинстве форт-систем низкоуровневые i/o примитивы векторизуют, а поверх делай что хочешь.

вот поэтому я и не пользуюсь «современными языками». у нас с ними кардинально не совпадает понимание простоты и компактности.

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

опять таки: современное стремление иметь типовые жилые районы, в которых всё строительство заключается в том, что домики можно чуть-чуть подвигать, да иногда стены перекрасить — от меня очень далеко. мне, пожалуйста, кирпичи и цемент, остальное я уж сам.

да никуда особо: что там развивать-то? сделали ANS-стандарт (не самая лучшая идея, и стандарт не самый лучший, но и не ужас-ужас). периодически появляются разные прикольные идеи, которые остальные к себе утаскивают. типа забавного слова "…" (многоточие), к которому можно подцеплять цепочку вызовов. "scattered colon" называется:

с таким вот выхлопом:

такие своеобразные хуки.
и всякое подобное.

Если колбэк делает NEW, то он должен сохранять ссылки где-то внутри A2 - так как, по сути, выполняется в чужом сегменте. Тем не менее, барьеры записи маркируют блоки памяти при создании и присваивании указателей, независимо от того, помечена ли процедура как {WINAPI/C} или нет. Если вдруг запустится полная сборка мусора, то если мы сохранили единственную ссылку в локальных переменных колбэка, то есть шанс, что память будет освобождена до того, как колбэк закончит работу. Отдавать сущности A2 чужим процессам это, естественно, неправильно.
Если в колбэке есть необходимость выделения памяти, то либо пользоваться средствами нижележащей ОС, либо NEW внутри A2(в модуле или в коллекции).

Во что именно ты не веришь? Если в процедуру, помеченную {WINAPI}, например Windows.Display.WindowProc поставить HALT или ASSERT, то в трапе метаданные будут присутствовать, несмотря на то, что никаких тегов нет, так как соглашение о вызове WINAPI не подразумевает их наличия.

Собирать свой мусор в чужом процессе A2 не умеет, о чём я выше написал.
Тем не менее, при использовании NEW и присваивании барьеры записи помечают блок памяти как живой.
В документе несколько напутано с процедурами а2, помеченными как WINAPI и собственно процедурами winapi, при вызове которых вставляются вызовы Objects.LeaveA2/Objects.ReenterA2 для отслеживания фреймов стека

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

понятно, что это актуально только для A2, которая исполняется как процесс на чужой ОС (что, полагаю, просто никогда не являлось основным режимом работы).

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

p.s.: что отдавать блоки, выделеные через A2, чужим библиотекам неправильно — это понятно, тут никаких претензий нет и быть не может, конечно.