|
|
@@ -0,0 +1,18 @@
|
|
|
+---
|
|
|
+published: true
|
|
|
+layout: post
|
|
|
+---
|
|
|
+
|
|
|
+Так как прошлые язычки в основном про алгоритмы (декларативные/императивные), и только чуть-чуть про данные (в виде dom), то логично предположить, что надо расширить эксперименты на системы типов и прочее.
|
|
|
+
|
|
|
+Проблема в целом известная, любой пользовательский тип данных почти всегда лишён возможности описать для этого типа литерал в пользовательском формате, операции тоже зачастую неприменимы. Перегрузка операторов и прочее это конечно зло. Но что может быть концептуальным решением этой проблемы?
|
|
|
+
|
|
|
+В Оберонах выбран путь классического наследования. В КП добавлены абстрактные и полу-абстрактные типы, разделение доступа к методам при переопределении. В go вообще наследования нет, как такового. Множество вариантов.
|
|
|
+
|
|
|
+Отдельным пунктом можно отметить псевдонимы и/или расширение пользователем примитивных типов, базовых сложных типов.
|
|
|
+
|
|
|
+Так же встаёт вопрос о необходимости встроенных в язык сложных типов данных, типа `MAP` в `LEAF`.
|
|
|
+
|
|
|
+Если программы, это алгоритмы + структуры данных, и с алгоритмами мы уже разобрались, надо переходить к структурам данных.
|
|
|
+
|
|
|
+Решил начать издалека и как-то обобщить предыдущий опыт разработки компиляторов в виде [универсального сканнера/полупарсера](https://github.com/kpmy/tier) для будущего проекта.
|
