Чем у вас Empty отличается от None в Optional[T] или Void в Eiffel?

Он же используется в точности для тех же самых целей.

n-арный конструктор это конструктор (как в C++) с n аргументами.

Я забыл сказать о неиспользовании частичных функций. Что вместо — в нормальном языке паттерн-матчинг, в C++ есть static visitor.

Только вот аналог nullptr невозможно будет разыменовать.

Это уже другой вопрос.

Когда мы говорим о ссылках, у нас есть две ситуации:

1. Нам нужно указать, что ссылка пустая (невалидная, не ссылается ни на что). Эта возможность фундаментальна. Без нее нельзя сделать те же двухсвязные списки в императивных языках.

2. Нам нужно защититься от обращения по пустой ссылке.

Мой поинт в том, что для первой ситуации, будь то сырые указатели или AlgDT, аналог nullptr или Void из Eiffel в языке нужен.

Для второй ситуации без помощи со стороны языка программирования не обойтись. То, что сделали в Eiffel с void safety — это частный случай AlgDT для ссылок. Вполне себе удобный и не поломавший серьезно совместимость версий Eiffel-я.

Бесполезно спорить о том, что если бы язык изначально поддерживал AlgDT с паттерн-матчингом, то необходимости в ссылках со значением Void не было бы. Возможно и не было бы (а если бы и была, это было бы упрятано глубоко в недрах стандартной библиотеки и недоступно простому пользователю). Только все это разговоры из категории «если бы у бабушки...»

Только вот аналог nullptr невозможно будет разыменовать.

Это уже другой вопрос.

Это главный вопрос.

Нам нужно указать, что ссылка пустая (невалидная, не ссылается ни на что). Эта возможность фундаментальна

Нет. Это именно то, в чем раскаивался Хоар. Ссылка должна иметь _только валидные_ значения. То, что невалидно - это не ссылка.

Нам нужно защититься от обращения по пустой ссылке.

Невозможность обращения автоматически вытекает из предыдущего пункта.

Бесполезно спорить о том, что если бы язык изначально поддерживал AlgDT с паттерн-матчингом, то необходимости в ссылках со значением Void не было бы

Зато можно поговорить о причинах и последствиях сознательного исключения union types.

None : 1 -> Option[T]
Some : T -> Option[T]

Empty : 1 -> DList[T]
Node : T * DList[T] * DList[T] -> DList[T]

nullptr : 1 -> *T
& : &T -> *T

отличие в правилах композиции. Потом вопрос частичных функций, в третьем случае

* : *T -> &T (hardware exception on nullptr)

в Eiffel это, как я понял, решено. Но суть в том, чтобы определять правила конструирования (которые определяют правила деконструкции в паттерн-матчинге) ADT, а не кодировать его через другой тип и левые значения (* или глобальный null).

Нет. Это именно то, в чем раскаивался Хоар. Ссылка должна иметь _только валидные_ значения. То, что невалидно - это не ссылка.

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

В этом случае null для ссылки — это валидное значение. Как, например, 0 в математике для целого числа (хотя у римлян обозначения для нуля не было).

Причем void safety в Eiffel наглядно, на практике показал, что в языке могут быть именно что ссылки, и именно что со значением Void, и что наличие Void не будет приводить к обращению по пустой ссылке.

Хотя можно сделать вид, что придя к union, в котором либо есть ненулевая ссылка, либо нет ничего, мы избавляемся от нулевых ссылок.

Как по мне, то нифига не избавляемся. Просто начинаем работать с ними чуть иначе.

В этом случае null для ссылки — это валидное значение

Пока ты исходишь из этой посылки, ты ни Хоара не поймешь, ни квазимото.

В этом случае null для ссылки — это валидное значение. Как, например, 0 в математике для целого числа (хотя у римлян обозначения для нуля не было).

Деточка, разыменование NULL pointer вызовет злобного дядьку SIGSEGV, который даст тебе по морде. В случае с некоторыми микроконтроллерами — ребут. А вот если бы у тебя был тип данных, который означает ЯЧЕЙКА ПУСТА — вот тогда было бы всё в порядке.

Пока ты исходишь из этой посылки, ты ни Хоара не поймешь, ни квазимото.

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

Всего у тебя хватает. Просто ты слишком упрямый.

Деточка, разыменование NULL pointer вызовет злобного дядьку SIGSEGV, который даст тебе по морде.

Дяденька, расскажите это тем, кто программирует на Eiffel после добавления в него void safety. Там и ссылки остались, и значение void они могут принимать. А вот обращаться по ссылкам со значением void нельзя и это контролируется еще в compile-time.

Просто ты слишком упрямый.

Нет, просто я различаю следующие вещи:

T — объект некоторого типа, со своим набором разрешенных значений и состояний.

x — ссылку на объект типа T. У которой есть всего два разрешенных значения: актуальная ссылка на T и Void/null.

Во многих языках, где есть ссылочные типы, но нет отдельного понятия ссылки, разработчики отождествляют x и T. И рассматривают Void/null как одно из значений для T.

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

T — объект некоторого типа, со своим набором разрешенных значений и состояний.

Так вот ссылка (указатель) - это тоже объект, его разрешенные значения - это адреса существующих объектов. И только они, никаких NULL/nullptr/Void. Это другой подход - не такой, к которому ты привык, не подход Си/Си++/Эйффель. Но это не менее разумный подход, и из него тоже раскручиваются все нужные юзкейсы.

Но это не менее разумный подход, и из него тоже раскручиваются все нужные юзкейсы.

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

Т.е. проблема указания факта на то, что x в данный момент никуда не ссылается, такая же фундаментальная, как в математике работа со значением 0.

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

Ну, естественно, семантика двусвязного списка никуда не денется. А вот SIGSEGV от разыменования nullptr пропадут.

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

Я давно забыл математику, но nullptr - это не 0, а точка разрыва функции.

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

Дело не в этом. Мы, возможно, о разных вещах говорим.

Я о том, что в системе типов желательно иметь отдельно «ссылки» и отдельно optional, который можно использовать не только для указателей.

Просто ваш костыль будет это делать теперь не с голым указателем и nullptr, а со специальным значением optional<ref<T>>(). Которое нужно будет явным образом использовать при «обнулении» ссылки и явным образом проверять при обращении по ссылке.

Если у нас есть pattern matching, то так просто вы ничего не нарушите. Вам система типов не даст обратиться к null.

Что, при всем уважении к ФП/AlgDT/паттерн-матчингу есть те же яйца, только в профиль.

Другие это яйца. Вы на стадии компиляции гарантируете, что никогда в рантайме не сможете обратиться к null-ссылке.

Ну, естественно, семантика двусвязного списка никуда не денется. А вот SIGSEGV от разыменования nullptr пропадут.

В сухом остатке: есть объективная необходимость указывать, что какой-то ссылки не существует, а так же есть необходимость защититься от обращения к ссылке без значения.

Соответственно, решать это можно, как минимум, двумя способами:

1. Сделать void/null валидным значением для ссылок, но на уровне языка контролировать наличие проверок на void/null перед обращением по ссылке.

2. Считать ссылкой только валидную ссылку на объект. Для указания отсутствия валидной ссылки использовать какой-то другой объект (например, None в Optional[T]).

Собственно, я не понимаю, почему первый способ должен считаться костылем.

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

Если у нас есть pattern matching, то так просто вы ничего не нарушите.

Тема посвящена Eiffel-ю, в котором pattern matching-а не было. И не потребовалось, как показала практика.

В сухом остатке: есть объективная необходимость указывать, что какой-то ссылки не существует, а так же есть необходимость защититься от обращения к ссылке без значения.

Нет понятия «ссылки не существует».

Причем, в случае с C++, компилятор не даст вам по рукам

Это смотря как optional сделать. Можно вот как-то так:

...
struct optional {

...

template<typename Reader, typename NullHandler>
auto match(Reader r, NullHandler h) -> decltype(0 ? r(data()) : h())
{
    if (!is_null()) {
        return r(data());
    }
    else {
        return h();
    }
}

...

};

Использовать, правда, не очень удобно. Но чтож делать, раз нет сопоставления с образцом?..

next.match(
    [](ref<node> n) {
        // node
    },
    []() {
        // null
    }

1. Сделать void/null валидным значением для ссылок, но на уровне языка контролировать наличие проверок на void/null перед обращением по ссылке.

2. Считать ссылкой только валидную ссылку на объект. Для указания отсутствия валидной ссылки использовать какой-то другой объект (например, None в Optional[T]).

Собственно, я не понимаю, почему первый способ должен считаться костылем.

Потому что в первом случае мы вводим механизм, узко заточенный под ссылки, а во втором - используем механизм pattern matching (или аналогичный оператор работы с tagged unions), полезный для решения гораздо более общих задач.

Потому что в первом случае мы вводим механизм, узко заточенный под ссылки

Не вижу в этом ничего плохого, т.к. при обычном программировании приходится считаться с объективной реальностью. Например, из-за которой в статически-типизированных языках есть разные типы для целых чисел и разные для вещественных. Почему-то то, что int — это одно, а float — другое, воспринимается нормально. А вот то, что есть указатели/ссылки — это уже плохо. Тем более, если рассмотреть указатели на указатели. Таки запись T** несколько удобнее, чем Optional[Optional[T]].

Хотя, если оперировать понятиями теории категорий и разрабатывать модели микропроцессоров на Haskell-е, то AlgDT рулят и бибикают, наверное :)

Собственно, я не понимаю, почему первый способ должен считаться костылем.

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

Таки запись T** несколько удобнее, чем Optional[Optional[T]].

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

let x :: **T in case x of
  **valOfT -> doSomethingWithVal valOfT
{- *optOfT -> doSomethingWithOpt optOfT -}
  _        -> {- got Nothing -}

Или посмотри, как в том же Хаскелле реализуются «цепочки» вызовов функций, принимающих значение типа, а возвращающих Maybe, например. Без всяких «специальных случаев» и вручную писать проверки не нужно.

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

Ну раз здесь все такие умные, то объясните, почему 30 лет назад языках, которые стали широкоиспользуемыми, ничего подобного не сделали?

Может тому были объективные причины?

И может взгляд ФП-шников на то, как нужно программировать, всего лишь один из возможных?

Потому что в первом случае мы вводим механизм, узко заточенный под ссылки

Не вижу в этом ничего плохого

Ну в костыле нет ничего плохого - он помогает ходить.

при обычном программировании приходится считаться с объективной реальностью

Программирование с ADT - вполне обычное программирование, оно считается с общей для всех нас объективной реальностью.

Хотя, если оперировать понятиями теории категорий и разрабатывать модели микропроцессоров на Haskell-е, то AlgDT рулят и бибикают, наверное :)

Mach7

как в том же Хаскелле реализуются «цепочки» вызовов функций

Через >>=?

Ну раз здесь все такие умные, то объясните, почему 30 лет назад языках, которые стали широкоиспользуемыми, ничего подобного не сделали?

Потому, что развитие шло от императивного подхода изначально. Потому, что проще сделать. Есть у нас адреса, зарезервируем значение, чтобы показывать «отсутствие ссылки» и все. Языки были довольно простыми. Сейчас растут объемы проектов, тяжело в голове держать код, появляются те или иные приемы. Начинают применяться те приемы, что раньше были невостребованны.

А си в асм транслируется все равно. Какая разница, во что это транслируется?

баян :-)

В чём профит от Eiffel... (комментарий)

Программирование с ADT - вполне обычное программирование, оно считается с общей для всех нас объективной реальностью.

У каждого, походу, своя реальность. Из языков, которые более-менее близко к мейнстриму, AlgDT и полноценный паттерн-матчинг есть в Scala, Haskell и OCaml.

Во всем остальном, включая C, C++, Java, C#, JavaScript, Python, Ruby, PHP, VisualBasic и т.д., кроме костылей ничего и нет.

Сейчас растут объемы проектов, тяжело в голове держать код, появляются те или иные приемы.

Объемы проектов привысили возможности отдельных разработчиков уже очень и очень давно. Как раз лет 30-40 назад, когда был очередной кризис разработки ПО, и создавались языки вроде C++, Ada и Eiffel. Продолжением которых стали появившиеся чуть позже Java, C# и Scala.

Кроме того, пришествие Web-а и мобильных платформ (смартфонов, планшетов, умных телевизоров и пр.) привело к востребованности таких языков, как PHP, Ruby, Python и JavaScript. И что-то мне подсказывает, что средние размеры проектов на этих языках будут поменьше, чем средние размеры проектов на C++, Ada или Eiffel. А так же Java и C#. Тогда как самих проектах на PHP/Ruby/Python/JavaScript, возможно, будет много больше.

Но это все лирика. Физика в том, что во времена зарождения Eiffel возможности вычислительной техники были совсем другие. Потому и решения, которые выглядели красиво в теории, на практике могли просто не взлететь из-за ограниченных мощностей тогдашних ЭВМ. Посему достаточно странно наблюдать, как принятые тогда решения оцениваются исходя из сегодняшних возможностей и популярных идей.

Объемы проектов привысили возможности отдельных разработчиков уже очень и очень давно.

Крайне голословное утверждение.

Как раз лет 30-40 назад, когда был очередной кризис разработки ПО, и создавались языки вроде C++, Ada и Eiffel.

Ada была создана точно не из-за этого.

пришествие Web-а и мобильных платформ (смартфонов, планшетов, умных телевизоров и пр.) привело к востребованности таких языков, как PHP, Ruby, Python и JavaScript.

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

Физика в том, что во времена зарождения Eiffel возможности вычислительной техники были совсем другие.

Miranda ( http://en.wikipedia.org/wiki/Miranda_(programming_language) ) появилась на год раньше Eiffel, при этом в ней уже были ADT и Pattern Matching. ML же вообще в 1973 сделали.

Miranda ( http://en.wikipedia.org/wiki/Miranda_(programming_language) ) появилась на год раньше Eiffel, при этом в ней уже были ADT и Pattern Matching. ML же вообще в 1973 сделали.

Молодой человек, вы о чем-нибудь за пределами Haskell и Erlang наслышаны?

То у вас голословными являются утверждения, что размеры программ уже очень давно превысили возможности одного разработчика. То Python и Ruby у вас к Web-у отношения не имеют, а JS к мобильным устройствам...

Упомянутые вами Miranda и ML вряд ли были широко известны даже в узких кругах в те времена. А уж о более-менее заметном использовании и говорить не приходится.

Молодой человек, вы о чем-нибудь за пределами Haskell и Erlang наслышаны?

Конечно.

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

Каких программ? Всех программ?

Miranda и ML вряд ли были широко известны даже в узких кругах в те времена

Потому что ты о них не слышал?

У каждого, походу, своя реальность.

Каждому привычна его часть общей реальности.

Из языков, которые более-менее близко к мейнстриму, AlgDT и полноценный паттерн-матчинг есть в Scala, Haskell и OCaml.

Еще F#, Swift. В Erlang есть pattern matching, не знаю насчет ADT.

Во всем остальном, включая C, C++, Java, C#, JavaScript, Python, Ruby, PHP, VisualBasic и т.д., кроме костылей ничего и нет.

Похоже, вместо «обычное программирование» ты хотел сказать «программирование на привычных языках».

Конечно.

Крайне голословное утверждение.

Каких программ? Всех программ?

Очень и очень многих программ.

Потому что ты о них не слышал?

Скорее потому, что никогда живьем видеть их не приходилось. Только встречать упоминания в литературе. Например, о том, что Страуструп ссылается на ML говоря о языках, которые оказали влияние на C++. И о том, что Haskell бы мог не появится, если бы автор Miranda согласился бы сделать Miranda базой для развития нового, современного ФЯ.

Еще F#

Да, про F# забыл, каюсь...

Swift.

Он совсем недавно появился и время, когда он станет полноценным мейнстримом, еще впереди.

В Erlang есть pattern matching, не знаю насчет ADT.

Откуда в Erlang-е AlgDT, если там кроме списков и рекордов до недавнего времени вообще ничего не было. Совсем-совсем недавно в язык map-ы добавили.

Похоже, вместо «обычное программирование» ты хотел сказать «программирование на привычных языках».

Можно и так. А можно еще и так: «программирование на языках, для которых не сложно найти нормальную работу».

В Erlang есть pattern matching, не знаю насчет ADT

ADT там тоже есть, но из-за отсутствия статической типизации и наличия символов (как в лиспе) не так часто используются.

Он действительно не прав - в статике можно проверить любые контракты. Просто пишешь бекенд к своему любимому пруверу и все.

ЗЫ: имеются ввиду полноценные пруверы, а не всякие агды с петушками.

ADT там тоже есть

Нету их в Эрланге.

Через >>=?

Не помню, вроде <?> обычно. Ну, думаю, можно и в монаду обернуть.

Ну раз здесь все такие умные, то объясните, почему 30 лет назад языках, которые стали широкоиспользуемыми, ничего подобного не сделали?

Обратная совместимость? Лень? Упрямость? Глупость? Куча вариантов.

в статике можно проверить любые контракты

А не гонишь ли ты?

Получатся зависимые типы, кмк.

Нет, не гоню.

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

Хорошо, как в статике будет проверятся то что индекс не выходит за границы массива? При условии что индекс вводит юзер.