trait + impl vs class , навеяно Rust'ом

Цитата applegame @ 09.07.15, 09:24

Цитата D_KEY @ 09.07.15, 08:52

Из определения ПП следует отсутствие зависимости кода(исходного, а не бинарного) от параметров. В C++ эта зависимость существует

В исходном коде???

Возможно неверено выразился. Имел в виду, что C++ генерирует сущности языка. И речь именно о них, а не о машинном коде.

Цитата

Цитата D_KEY @ 09.07.15, 08:52

В том и дело, что для C++ это вопрос не реализации, а спецификации языка.

Реализация и спецификация не являются взаимоисключающими понятиями. Да, в спецификации C++ жестко указан способ реализации параметрического полиморфизма.

Нет. Там описаны шаблоны, а не реализация параметрического полиморфизма.

Цитата Qraizer @ 09.07.15, 08:12

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

С системой F мы как раз таки в состоянии сделать проверку типов, если их получается бесконечное количество как инстансов полиморфных типов. А C++, D, Rust - не в состоянии.

Добавлено 09.07.15, 09:47

Цитата applegame @ 09.07.15, 09:04

Эта дыра закрыта для ваших шаловливых ручонок. Ищите другие дыры

Она всё там же.
Мы так и будем играть, или вы таки поймёте, что если затирать типы до их проверки, то на эту проверку уже можно не полагаться?

Цитата MyNameIsIgor @ 09.07.15, 09:33

Она всё там же.
Мы так и будем играть, или вы таки поймёте, что если затирать типы до их проверки, то на эту проверку уже можно не полагаться?

Ну это уже совсем криминал. Может вынести всю фигню вам в отдельный модуль и заприватить конструкторы? ИМХО, это уже нарушение условий задачи. Думаете в жабовом и шарповом варианте не удасться аналогично похерить эти проверки?

Сообщение отредактировано: applegame - 09.07.15, 09:52

Цитата applegame @ 09.07.15, 09:50

это уже нарушение условий задачи.

В чем?

Цитата

Думаете в жабовом и шарповом варианте не удасться аналогично похерить эти проверки?

Аналогично? Покажи.

Цитата D_KEY @ 09.07.15, 09:53

В чем?

В том, что делается попытка использовать "скрытые" типы, которые совсем скрыть от юзверя невозможно в силу гибкости языка.
Даже если я запривачу все конструкторы наглухо, всегда можно влезть в сами cons'ы. А это совсем не то, что обсуждается в задаче.

Цитата applegame @ 09.07.15, 09:59

Цитата D_KEY @ 09.07.15, 09:53

В чем?

В том, что делается попытка использовать "скрытые" типы, которые совсем скрыть от юзверя невозможно в силу гибкости языка.
Даже если я запривачу все конструкторы наглухо, всегда можно влезть в сами cons'ы. А это совсем не то, что обсуждается в задаче.

Эм. Да ты хоть обзакрывайся
Кто помешает написать в main_ так:

List!1 as2 = cons(i, as);
return main_(n - 1, i + 1, cons(2*i + 1, as2), cons(i*i, bs));

?

Цитата D_KEY @ 09.07.15, 10:20

Эм. Да ты хоть обзакрывайся

Ага, то есть если тебе не удасться испортить код не влезая в cons'ы то ты признаешь решение задачи? Я ведь могу сами типы List!N и ListN!N скрыть, даже внутри main_.

Добавлено 09.07.15, 10:37

Цитата applegame @ 09.07.15, 10:31

Я ведь могу сами типы List!N и ListN!N скрыть, даже внутри main_.

Хотя это скорее всего не поможет. Но ты фактически искусственно испортил тип выражения cons(i, as), ты бы еще туда cast() вписал. Правильнее было бы

auto as2 = cons(i, as);

Иожет таки не будем упоминать List!N и ListN!N всуе? Для конструирования списка как и в хаскеле предусмотрена своя сущность - cons. Нахрена вручную портить тип списка?
А то как-то нехорошо получается. В Хаскеле даже переменную создать невозможно, а в D вы их создаете как вам вздумается. В Хаскеле типы выводятся из выражений, а в D вы почему-то решили, что указывать типы вручную - по правилам. Не, друзья, так дело не пойдет.

Сообщение отредактировано: applegame - 09.07.15, 10:48

Цитата applegame @ 09.07.15, 09:50

ИМХО, это уже нарушение условий задачи.

О какой задаче вы уже третий день спорите?

Цитата OpenGL @ 09.07.15, 10:41

О какой задаче вы уже третий день спорите?

О вот этой - https://www.linux.org.ru/forum/development/4300872

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

Цитата OpenGL @ 09.07.15, 10:50

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

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

Сообщение отредактировано: applegame - 09.07.15, 10:57

Цитата applegame @ 09.07.15, 09:50

Ну это уже совсем криминал. Может вынести всю фигню вам в отдельный модуль и заприватить конструкторы?

И каким образом вы мне гарантируете, что в этом вашем модуле нет ошибок с обработкой списков разной длины, например?

Цитата applegame @ 09.07.15, 10:31

а в D вы их создаете как вам вздумается

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

Цитата applegame @ 09.07.15, 10:31

Ага, то есть если тебе не удасться испортить код не влезая в cons'ы

Ни на чём не основанное условие.

Цитата applegame @ 09.07.15, 10:31

то ты признаешь решение задачи?

Вы хоть перед самим собой будьте честным.

Цитата OpenGL @ 09.07.15, 10:50

Как во время компиляции можно определить длину списка, которая известна только в рантайме?

Никак. Ее и не надо определять.

Цитата OpenGL @ 09.07.15, 10:50

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

Её не надо определять во время компиляции. Надо просто доказать, что мы обрабатываем два списка одинаковой длины.

Цитата OpenGL @ 09.07.15, 10:50

Имхо, задача поставлена некорректно.

Задача абсолютно корректна.

Цитата applegame @ 09.07.15, 10:31

Цитата applegame @ 09.07.15, 10:31

Я ведь могу сами типы List!N и ListN!N скрыть, даже внутри main_.

Хотя это скорее всего не поможет.

Ага.

Цитата

Но ты фактически искусственно испортил тип выражения cons(i, as), ты бы еще туда cast() вписал.

Я сделал все типобезопасно с точки зрения языка. Наследника можно воспринимать как предка. is-a и все такое.
Какие ко мне вопросы?

Цитата

Иожет таки не будем упоминать List!N и ListN!N всуе?

И как тогда написать main_?

Цитата

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

Хм. Что такого я сделал? Ты сам это делаешь при вызове main_