OberonCore

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

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

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

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

Так в разговоре две стороны - передающая и принимающая. И мне что-то кажется, что затраты энергии на понимание даже речи могут быть выше затрат на её издание. В печати-чтении - тем более. Якобы зрительный анализатор - это 40% энергозатрат мозга.


Это соглашение из тех времён, когда выкладки делали на доске или на бумаге. Поскольку выкладки большие, писать "energy" вместо E означало бы замедлить переписывание формулы в 6 раз. Сегодня можно про формулы говорить ровно то же, что и про алгоритмы, и кстати, вот формула из моего проекта:


В ней смесь принятых сокращений (P,T,V) и слов.

> сдизайнены или никак, или очень плохо.

Возможно. Я пытался сделать лучше, поэтому сразу сортирую все языки по тем недостаткам, которые в них есть. В меру своего понимания, которое на самом деле ограничено - я не осилил некоторые языки, например Haskell и Rust. Хотя у меня есть отговорки для обоих случаев, но не очень убедительные.

я имел в виду замену значков операций на длинные слова. DIV и MOD в принципе оправданы тем, что в ASCII нет общепринятых значков для целочисленного деления и остатка (и очень жаль). процент для остатка не предлагать. ;-)

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

именно поэтому мозг его адово оптимизирует. когда мы книги читаем на хорошо знакомом языке — мы же не читаем буквы: мы читаем слова, а иногда даже целые фразы. и тут, кстати, `PROCEDURE` лучше, чем `PROC` — потому что могзу вообще не надо детально анализировать образ, достаточно того, что «это длинная фигня». всё, на этом месте мозг останавливается и выдаёт результат: «это `PROCEDURE`».

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

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

В А2 нет такой проблемы. Так как для чужих соглашений о вызове теги не генерируются и сборщик кадр стека не обрабатывает.

Что-то выглядит слишком просто для правды. А разве нет функций обратного вызова, которые реализованы в A2 и которые бы ОС вызывала?

> `PROCEDURE` лучше, чем `PROC` — потому что могзу вообще не надо детально анализировать образ, достаточно того, что «это длинная фигня».

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

> сишечку, кстати, из-за отсутствия маркера процедур вообще читать очень сложно:

Да, там оптимизировали за счёт ухудшения других качеств. Но там и без этого всё плохо из-за неестественного порядка слов. Я её привёл не как пример того, как хорошо, а просто как крайнее значение в ряду.

> о функциональных языках я вообще мнения очень невысокого

У функциональщины есть свои плюсы. Как и во всём, проблемы начинаются, когда это доводят до фанатизма. Хаскель как раз является тому каноническим примером, но я верю, что в нём есть что-то хорошее, потому что мне об этом говорили более компетентные компьютерные полиглоты (знающие все ЯП, что и я, плюс ещё и другие, и на хорошем уровне). Ну и всё сильно зависит от того, какой смысл вкладывать в это понятие - оно такое же неоднозначное, как понятие об ООП.

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

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

ghc. он очень, очень большой — а значит очень хороший! ;-)

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

я, кстати, довольно активно использовал Схему, пока мне не надоело. до сих пор с пол-десятка разных реализаций Схем (собственноручно сделаных, в смысле) валяется. включая, кажется, даже компилятор в нативный x86.

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

ещё на Dylan смотрел: это такая прикольная Схема, только с синтаксисом для человеков. это даже можно использовать для простого скриптования. но особо смысла нет: компилятор оберона для скриптов написать, пожалуй, даже проще. ;-)

Такие функции тоже помечены соответствующим соглашением.

у каждой активности свой стек, у нее же и root для сборщика.

Иммутабельность (как один из принципов ФП) хороша для многих задач (не для всех), в т.ч. активно применяется в СУБД. А вот "всё есть список" мало имеет отношения к базовым идеям ФП, с какой стороны не посмотри. Схема же, на мой взгляд, непрактична среди лиспов, я долгие годы фанател от Common Lisp и до сих пор его утрату нечем возместить, несмотря на его болячки, которых там тоже вполне достаточно. Другой подобной технологии в природе всё же не существует, и Оберону до него далеко. Другое дело, там по-другому компромиссы нарезаны и с производительностью неустранимые проблемы.

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

я не очень понял. когда A2 работает в режиме приложения под другой ОС, и я вызываю системную библиотеку, передавая ей как колбэк обероновскую функцию, и системная библиотека изнутри себя вызывает обероновскую функцию — то что происходит? у нас больше нет стека, которым мы полностью владеем, поэтому безопасно по нему гулять больше нельзя. это как-то решается, или просто надеемся, что системные библиотеки формируют стековые кадры правильно?

p.s.: я не ёрничаю, если что, прошу прощения, если так выглядит. мне действительно интересно, а в компилятор/ядро лазить сложно.

прошу прощения, я довольно непрозрачно пишу иногда. тут я просто вспомнил Схему, а потом вспомнил принцип «всё есть список», а потом меня понесло.

я бы сказал, что лиспы в принципе… но это опять холивор будет. ;-) у Схемы есть (было, точнее, её разными RxRS окончательно добили) то преимущество, что она маленькая, простая, и просто же реализуется.

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

а, и self ещё, конечно.

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