Есть ли в CL и C алгебраические типы данных?

Что, прости? Каким образом это может быть не так? Мы о рантайме, напоминаю. Как то место, в котором программа отвалилась, может не быть тем местом, в котором программа отвалилась?

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

Чекер в отличии от рантайма вообще не может сказать ничего об ошибке.

Чекер выдает _полную_ информацию, почему не получилось вывести тип. В рантайме ты лишь получишь «начальник, не получилось».

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

Сюрприз, но что тебе еще надо знать, кроме _типов_, для отлавливания ошибок _типизации_? С другой стороны, у строгого статически типизированного языка есть полная картина всех веток исполнения программы, полная информация о том, что было до факапа и после. В рантайме динамического языка лишь информация о месте, где вдруг типы не совпали.

В случае вывода типов - местоположение факапа может быть вообще где угодно и не говорит ничего о местоположении ошибки.

Не совсем где угодно. Аннотация типов очень сильно ограничивает это дело.

Это если говорить об ошибках в общем, тут конечно ошибка в одном месте программы может отозваться в любом другом. Ошибка же типов (если речь идет о системах типах слабее, чем зависимых, например типизации на базе SystemF) ВСЕГДА находится там, где упало.

Тупой элементарный пример:

// Вот тут ошибка, присвоили значение не той переменной:
x = "Hello, I am an error!"
....
// миллион строчек кода
....
y = 1
z = x+y // упадет здесь, но ошибка была выше

Так нет, ошибка не в х. С х все в порядке. Вот именно тот момент где чекер тебе выдаст не то место ошибки (в х, вместо +).

Чекер выдает _полную_ информацию, почему не получилось вывести тип.

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

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

Именно. Рантайм выдает место ошибки, а чекер - место, где у него не получилось. Которое может быть сколь угодно далеко от места ошибки.

Сюрприз, но что тебе еще надо знать, кроме _типов_, для отлавливания ошибок _типизации_?

Если ты мономорфные, то ничего, конечно же (хотели строку, получили число). Но они ведь бывают и сложнее.

Так нет, ошибка не в х. С х все в порядке.

Нет, с 'x' как раз все хреново, и это именно та ошибка в коде, которую надо найти

чекер тебе выдаст не то место ошибки (в х, вместо +).

error: no match for ‘operator+’ (operand types are ‘std::__cxx11::string {aka std::__cxx11::basic_string<char>}’ and ‘int’)
     x + y;
     ~~^~~

Нет, с 'x' как раз все хреново, и это именно та ошибка в коде, которую надо найти

Так проблема не с х, проблема с +, которому всунули строку вместо числа. Мог бы быть код вида

x = "yoba"
y = "huy" + 2

error: no match for ‘

Так это мономорфный тип без инференса. То есть тот самый вариант, который работает нормально. Наверни туда шаблонов, посмотрим, какой он тебе cryptic error высрет.

Так проблема не с х, проблема с +, которому всунули строку вместо числа. Мог бы быть код вида

Хорошо, будь по твоему, ошибка в плюсе, но нам не это от компилятора/рантайма надо. Нам надо в конечном счете поправить x, а не +.

Нам надо в конечном счете поправить x, а не +.

x = "yoba";
y = "huy" + 2;

зачем поправлять х, еще раз? С ним все в порядке. Поправлять надо терм, который является аргументом +. Ошибка именно в нем. И, кстати, как выше показано, нормальные тайпчекеры (не убитые фулл инференсом) именно в том месте, где надо ее и показывают

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

И дальше либо чекер в нём запутался, либо программист, когда продумывал свой код с динамической типизацией. В случае наличия чекера нам это скорее всего обойдётся дешевле, потому что мы не запустим падучую программу. Но по сути проблемы итог одинаков: мы запутались.

То есть кажется, что чекер лучше: всё же он делает работу за меня. С философской точки зрения хорошо, когда кто-то делает работу за меня.

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

Если у вас есть информация о языках, где в типизации было осознанно принято и проведено в жизнь такое решение на уровне языка, то прошу имена в студию :)

зачем поправлять х, еще раз?

По условию задачи там опечатка. =)

С ним все в порядке.

Да, давайте исправлять там, где падает, а не так, чтобы работало правильно =)

По условию задачи там опечатка. =)

Тогда надо было указать для икса тип

Да, давайте исправлять там, где падает, а не так, чтобы работало правильно =)

Если ты исправишь там, где падает, то будет работать правильно.

Если ты исправишь там, где падает, то будет работать правильно.

Не будет. Правильно там складывать два числа x и y. Как мне исправить в том месте так, чтобы работало правильно?

Правильно там складывать два числа x и y.

Ставишь на место икса нужное тебе число.

Ставишь на место икса нужное тебе число.

Я тебя понял, шутник :D

Где тут шутка?

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

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

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

Теперь ты предлагаешь смотреть на неправильно работающую программу и убеждать себя и всех остальных, что она работает правильно =)

Т.е. они считают, что если компейлятор проверяет типы, то типы есть, а если не проверяет то типов нету(ну или есть только 1 тип). Это болезнь часто развивается у адептов строгой типизации и чистых функций.

Каждый адепт строгой типизации и чистых функций знает об алгоритме типизации Хиндли — Милнера, а «компейлятор проверяет типы» в любом языке со статической типизацией. Пожалуйста, не пиши больше такого бреда.

Пожалуйста, не пиши больше такого бреда.

Пока бредишь только ты.
P.S. И другие адепты.

Слив засчитан.

нет не предлагаю давай та за меня говорить не будешь?

Нет, предлагаешь.

в 2016 году еще кто-то верит в существование т.н. «тайпчекеров»? поразительно