Развитие пользовательских типов данных в программировании

Указатели впервые появились не в С, а (из распространенных языков) в PL/1.

Гм, просмотрел я «PL/I: Language Specifications. 1965» — не нашёл там такого.
Появились впервые в ассемблере.
В Алголе-68 есть что-то, а Паскаль куда более близкий к современному понимаю указателей, он не до конца их добавил.
И уже Си их добавил в самодостаточном варианте.

Размышления о программировании

Безусловно, DSL — всего лишь способ не думать о мелочах.
Эллочке-людоедке хватило 30 слов, что бы общаться. Это и есть DSL
Но для того, что бы общаться нормально, всё равно придётся выучить язык поболе.

Размышления о программировании

Интересный взгляд на языки программирования.
Чем-то перекликается с моим Развитие пользовательских типов данных в программировании

Однако, выводы разнятся.
Я бы не сказал, что развитие DSL языков будет решением проблем. Имхо, это перекладывание проблем с одних плеч(базового языка программирования) на другие (DSL-языки). А их тоже надо как-то развивать. Сейчас ведь тоже многие DSL-языки находятся на уровне ассемблера — можно только пользоваться встроенными командами.

Развитие пользовательских типов данных в программировании

Условно говоря, можно посмотреть на многие объекты как на фреймворки. Их используют, а не правят. Если не походят — просто не используют.
Прежде всего это касается чужих и нетривиальных объектов.

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

Но нам нужны не Вектора (слишком банально для заказчика), а Вектор с Хризантемкой.
Тут уже полный тупик — в Механику уже никаких цветочков не вставишь.
И тут приходится выкручиваться: либо отказываться от цветочков, либо изменять Механику, либо добавлять всевозможные костыли.

Развитие пользовательских типов данных в программировании

То есть я правильно понимаю, что в хаскеле для одного типа не получится в части программы использовать одну реализацию тайпкласса, а в части — другую?

Можно, если эти реализации закрыты для экспорта/импорта друг к другу.

  module TestZero (Test(..)) where  -- TestZero.hs
     data Test = Test1 | Test2

  module TestOne(testf1)  where     -- TestOne.hs
    import TestZero
    instance Eq Test where
       _ == _ = True
    testf1:: Test -> Test -> Bool
    testf1 = (==)

  module TestTwo(testf2)  where     -- TestTwo.hs
    import TestZero
    instance Eq Test where
      Test1 == Test2 = True
      Test2 == Test1 = True
      _     == _     = False
   testf2:: Test -> Test -> Bool
   testf2 = (==)

  module TestThree  where          -- TestThree.hs
    import TestZero
    import TestOne
    import TestTwo
    test  =  (testf1 Test1 Test2) == (testf2 Test1 Test2)

Развитие пользовательских типов данных в программировании

Вижу, всё таки есть возможность разночтения. Поэтому внёс правку.

Я даже больше скажу — в Паскале перечисления были с самого начала.

И можно было даже интервалы делать:

operations := [etOne .. etThree];

Развитие пользовательских типов данных в программировании

Модули первого порядка и path-dependent types в скале — это одно и то же, на сколько я это понимаю.

Если это так, то это уже есть в статье: модули первого порядка (не знаю как в Скале, а в ОКамле они к тому же могут быть рекурсивными) — достойная функциональная замена объектам.
По мощности они соизмеримы с объектами.

To a.InnerClassName и b.InnerClassName — разные типы.

Верно, а вместе с

val c: a.type = a

a.InnerClassName и с.InnerClassName — одинаковы

Что означает «разрешение ввергнутся во внутреннее пространство объекта другому объекту, поскольку он имеет такой же тип»?

То, что в вышеприведённом примере `а` не отличит себя от `с`.

Развитие пользовательских типов данных в программировании

PS Чего только стоит "#haskellfail" ))

Развитие пользовательских типов данных в программировании

Собственно, что меняет этот пример, относительно простого объекта?

Мы можем добавить новые методы, использующие интерфейс, который вшит в класс.
Да, это более гибко, чем простой интерфейс, однако, ничего более возможностей вшитого интерфейса мы не получим от объекта.

Развитие пользовательских типов данных в программировании

В этом докладе рассказывается, какие они построили модули первого порядка, которых нет в Стандартном МЛ. Зато почему-то промолчали, что они есть в ОКамле.
И заодно рассказывают, почему классы типов — это так плохо на Хаскеле, зато так классно в Скале.

Что касается path-dependent types — в докладе об этом не сказано.
Тем не менее, path-dependent types — это разрешение ввергнутся во внутреннее пространство объекта другому объекту, поскольку он имеет такой же тип:

res: java.lang.Class[_ <: VariableName.InnerClassName] = class OuterClassName$InnerClassName

Развитие пользовательских типов данных в программировании

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

Развитие пользовательских типов данных в программировании

На счёт Скала — спасибо, попробую добавить. Эти «путе-зависимые» объекты добавляют межобъектное (одного класса) взаимодействие, но не межклассовое. Правильно?

Зависимые типы — отлично замечено. Я их не рассматривал, так как Agda и Coq используются для доказательств, а не программирования естественных задач.

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

Развитие пользовательских типов данных в программировании

Generic — метапрограммирование.
Он не предоставляет новые пользовательские данные.
Он «всего лишь» избавляет от рутины написания порождающих Generic классов

Развитие пользовательских типов данных в программировании

На счёт Паскаля — да, я об этом написал.
На счёт Делфи — похоже да, ошибся, исправлю, спасибо

Развитие пользовательских типов данных в программировании

экспоненциальных? ))

Экзистенциальные данные — со скрытыми параметрами.

data Counter a = forall self. NewCounter
    { _this    :: self
    , _inc     :: self -> self
    , _display :: self -> IO ()
    , tag      :: a
    }

Зависимые классы помогают выявить зависимость между передаваемыми параметрами класса и примерно выглядят так:

   class Collects e ce | ce -> e where
      empty  :: ce
      insert :: e -> ce -> ce
      member :: e -> ce -> Bool