Programming Language Design

12 November 2025 17:44

Почему скорее упрощение, чем желание? Я, к примеру, не хочу, чтобы в расчётной задаче в семантику входило время выполнение операции + :: Int -> Int -> Int. И, кмк, мало кто хочет. Более того, несомненный успех ЯВУ означает, что нас в среднем интересует «более высокое».

Programming Language Design

12 November 2025 17:39

Кажется, чтобы дать формальное опредение аспектам, Вам необходимо также уточнить определение семантики исходной программы — отрезать те части, которые кажутся незначительными. Точно также, как это делается при определении "оптимизации"

Programming Language Design

12 November 2025 10:35

А есть ли пример для иллюстрации того, как один обработчик мешает другому? (кажется, такое возможно только при нарушении некоторого контракта)

Programming Language Design

12 November 2025 10:27

Вот как раз когда назначение — сделать побочный эффект, тогда и не композятся. Композиционность обработчиков — это НЕ композиция функций. Это тогда, когда два корректных по отдельности обработчика (производящих нужные побочные эффекты), повешенные на одно и то же событие (а хоть бы и два разных) НЕ МЕШАЮТ друг другу, т.е. комбинация остаётся корректной.

Очевидно, для произвольных обработчиков событий это не выполняется даже в однопоточном JS.

Programming Language Design

12 November 2025 10:19

Я бы сказал — зависит от. В некоторых случаях можно определить обработчик в виде композиции других обработчиков (например, если у них тип unit -> unit ).

С другой стороны, если назначение обработчиков — сделать побочный эффект (у каждого свой), а не трансформировать событие, то зачем их композить?

Programming Language Design

12 November 2025 09:58

Ну, как бы, Reactive Streams в Java и FRP - это разное. И Rx тоже немного не то. Там нет общей концепции.

Programming Language Design

12 November 2025 09:54

Я имею в виду общую концепцию. https://en.wikipedia.org/wiki/ReactiveX в ту же степь, и остальные "псевдо FRP" библиотеки.

Programming Language Design

12 November 2025 09:52

Какая разница, Java или нет? Не на то сообщение ответ?

Programming Language Design

12 November 2025 09:44

Ну и мы уже отлично знаем, что обработчики событий не композятся, надёжнее использовать reactive streams... 😁

Programming Language Design

12 November 2025 09:18

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

Programming Language Design

12 November 2025 09:10

При чём, даже, в принципе, достаточно эффективно. Потому что можно сначала накомпозить себе какую-нибудь процедуру таким образом, а потом скомпилировать её.

Programming Language Design

12 November 2025 09:06

Наверное, под cross-cutting concern в контексте AOP следует понимать функционал, который добавляется к модулю, но от которого модуль не зависит. Потому как, если модуль зависит от этого функционала, то он явно его подключает и использует — и техники AOP не нужны.

Programming Language Design

12 November 2025 07:13

Вы смешиваете 2 независимые ветки беседы.

Programming Language Design

12 November 2025 07:08

Проблема cross-cutting, решение не. Трассировку ведь тоже не по всей программе включают

Programming Language Design

12 November 2025 07:06

В принципе, мы можем искусственно аннотировать точки соединения (чтобы что-то не упустить).

Например, мы можем определить функцию со специальным именем, которая ничего не делает (identity function), и использовать ее в тех местах, где нужно подсоединять соответствующие аспекты.

Все еще AOP, но некоторый срез намеренно задается "внутри" модулей.

#aop #crosscutting

Programming Language Design

12 November 2025 17:41

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

Поэтому подобный аргумент плохой.

Programming Language Design

12 November 2025 17:34

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

Programming Language Design

12 November 2025 10:28

Модель reactive streams/Rx тоже масштабируется — для простых случаев в одном потоке её можно реализовать очень "дёшево".

Programming Language Design

12 November 2025 10:22

Это совсем другой масштаб по сравнению с простыми обработчиками. Далеко не всегда привлечение такой махины оправдано 🙃

Programming Language Design

12 November 2025 10:03

Оставляя "RFP a la Conal Elliot" за скобками, общая концепция, как отметил @ruv256 выше, как минимум в использовании асинхронных очередей сообщений/данных и трансформации этих очередей (как целого, при помощи комбинаторов). Это обеспечивает композиционность, в отличие от "голых" обработчиков сообщений.

Programming Language Design

12 November 2025 09:56

Не знаю как конкретно в Java Reactive Streams, а .NET Rx включают ещё и скедулер для всего этого дела, и ещё пару скедулеров и обвязок для отладки, и прочее по мелочи. Дельный набор.

Programming Language Design

12 November 2025 09:53

да, я про reactive streams.

Programming Language Design

12 November 2025 09:52

Которые reactive streams? Типа, асинхронная очередь?

В JavaScript — reactive-streams / reactive-streams-js

Programming Language Design

12 November 2025 09:43

Это до тех пор, пока практика ограничена одной программой/библиотекой/командой разработки — как только 3 разные библиотеки начнут мутировать одно и то же каждая под свои нужды... станет очень весело разбираться и отлаживать. 😏

Programming Language Design

12 November 2025 09:11

Ok. Я не к тому, что именно так надо делать. А к тому, что смотрите, как оно бывает на экзотических островах.

Programming Language Design

12 November 2025 09:09

Есть такая книженция Software Design for Flexibility, там в первой главе обсуждаются различные игры с функциями в стиле. Вот есть у нас (define f (lambda (x) ...)), а потом мы берём, пишем какой-нибудь композитор для функций, и используем его, чтобы вокруг f накручивать функциональность. Например (set! f (after f (lambda (x) (display x)))). Можно и покрасивше оформить, но суть в том, чтобы просто иметь некую мутабельную переменную, вокруг которой наверчивается функциональность.

Оно, конечно, typefree и мутабельно... 🤷‍♂️ Но работает неплохо на практике.

Programming Language Design

12 November 2025 07:17

Одна была про AOP, а вторая про что? 😊

Programming Language Design

12 November 2025 07:12

Как раз таки нет, это локализованная проблема, потому что в логах ищется не "любая фигня", а какая-то конкретная фигня/сообщение, которое производится конкретным куском программы.

Снова не нужно путать идею (в данном случае, "сигнализировать о проблеме неизвестной стороне") и её реализацию. Можно сигнализировать не через логи, а через MQ, например.

Programming Language Design

12 November 2025 07:07

Тогда это НЕ аспект, а кусок функциональной корректности.

Programming Language Design

12 November 2025 07:01

Какое же это "cross-cutting", если оно за пределы одной функции не выходит?! 😂