семантика возможных миров это классический способ формализации любых модальных логик

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

+++ (разве что я постарался привести пример другими словами)

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

ОК, это ещё один аргумент в пользу рассмотрения вопроса о типе Possible World. Может ли он входить в систему типов языка программирования? ))) Или его нужно моделировать каким-то способом?

Например, как воткнуть possible worlds в систему типов языка Julia? Макрос модели как задания eDSL там есть — https://julialang.org/blog/2017/08/dsl. Может, сделать макрос возможного мира или дописать это в макрос модели?

При этом Джулевский "макрос для создания eDSL" вполне можно считать тем самым GPL-для-моделирования, на котором потом пишутся eDSL, а сам он написан на хост-языке программирования (то бишь на Julia и всем её математическим внутри).

Общий же вопрос "как делать GPL" для меня решён, я делаю ставку на мейнстримно-выглядящий язык с включение FOL для прямого использования логического вывода, подобно тому как дифференциальные уравнения включены в Modelica, а LINQ в C#. Здесь очень сильна неопределённость, нет такого чтобы "вот теория категорий крутая, значит с ней можно сделать крутой язык программирования". Нельзя сравнивать то, чего нет. Можно лишь делать ставки.

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

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

пример с оператором amb, разделявшим ветки эволюции мира/варианты расчета, если я не ошибаюсь, был в том же SICP'85 (соотв-но, на Scheme)

GraphQL это просто очередной мэппер к БД, со своей мифологией. Мне приходилось работать с проектом, где он был ранее выбран для связи фронт-бэк, и впечатления самые неблагоприятные, необходимость одновременно учитывать "как это в базе" и "как это в GraphQL" лишь умножает когнитивные затраты.

уточню - GPL = general purpose language?

БД тут во множественном или в единственном числе?

соглашусь что он ни разу не магический; не соглашусь что он "очередной". graphql дает способ единообразно выразить больше, чем sql, но он не гарантирует, что выраженное будет удобным (собственно, на SQL DDL тоже можно трэш написать, и будет "как в базе" и "как там откуда база наполняется", например если не хватает констрейнтов)

Ну вот дифференциальные уравнения оказались включены в Julia по факту не хуже, чем они включены в Modelica (и автор Modelica перешёл из-за этого на Julia). Насчёт FOL, так разных опытов по логике в той же Julia полно. Например, вот "типизированный пролог" (с вопросом "помогает ли типизирование хоть чему нибудь") — https://github.com/hessammehr/Logic.jl или стопятьсотый клон раннего Kanren — https://github.com/habemus-papadum/LilKanren.jl

При необходимости можно просто сделать то, что очень хочется — таким, как хочется.

Не думаю, что отсутствие FOL "из коробки" в расширяемом языке было бы проблемой. В любом случае, это не бОльшая проблема, чем отсутствие солвера для дифуров.

тут два уровня библиотек: хост-язык, библиотека "моделирования мира", библиотеки eDSL этого моделирования.

да

Как угодно. Можно в виде GraphQL представлять одну базу, можно несколько, а можно представлять какие-то внутренние API, даже не делающие запросов к persistent storage.

Ну "как угодно" -- это отверткой гвозди забивать.

@val_krylov Чем двойственность "в базе" / "в GraphQL" отличается от тройственности "в базе" / "в REST API v1" / "в REST API v2"?

Вот, кстати, смолтоковцы с этим работали — http://www.vpri.org/pdf/m2013002_experiments.pdf