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

Цитата D_KEY @ 09.07.15, 11:13

хотя вот в Rust могли бы решить иначе

Я попробовал сделать без генерации типов, на "трейт-обьектах" (интерфейсах), но снова не получилось, уже изз-а других особенностей языка.

Но вообще как это (в варианте с дженериками) сделать без потери эффективности?

Цитата applegame @ 09.07.15, 11:36

Цитата MyNameIsIgor @ 09.07.15, 11:35

Нет, просто потому, что это преобразование незаконно.

Да. А в D - законно. Может не будем тогда незаконно менять тип возвращаемый cons и незаконно конструировать списки неверного типа?

Если в D это операция законна, то значит все правильно написано, а значит мы все меняем законно. Ведь речь как раз идет о возможностях системы типов.

Добавлено 09.07.15, 12:32

Цитата DarkEld3r @ 09.07.15, 12:31

Но вообще как это (в варианте с дженериками) сделать без потери эффективности?

Сначала затайпчекать(тут не потребуется инстанцирования, т.к. в Rust нет специализаций и перегрузок), а потом генерировать специализации исключительно с целью оптимизаций.

Добавлено 09.07.15, 12:35
Это если вопрос о реализации в языке

Цитата D_KEY @ 09.07.15, 12:31

генерировать специализации исключительно с целью оптимизаций

Когда остановить то эту генерацию? Или во время исполнения?

Цитата D_KEY @ 09.07.15, 12:28

При вызове cons вызывается не первая перегрузка?

Она есть, но делается неявно компилятором.

Цитата D_KEY @ 09.07.15, 12:28

А разве при передачи в main_ ListN!1 не кастуется к List!1?

Это частный случай. Точнее будет сказать: ListN!N кастуется к List!N - это полиморфные типы. Ну или псевдополиморфные, с твоей точки зрения. А ListN!1 - это уже обычный тип.

Цитата MyNameIsIgor @ 09.07.15, 11:57

Компилятор же говорит, что надо сделать - http://ideone.com/iglyDq

Просто убрать public? Спасибо.

Цитата DarkEld3r @ 09.07.15, 12:31

Но вообще как это (в варианте с дженериками) сделать без потери эффективности?

Без потери эффективности по сравнению с чем? С учетом того, что просто генерация это сделать не позволяет и даже на C++/D приходится стирать типы.

Добавлено 09.07.15, 12:41

Цитата applegame @ 09.07.15, 12:39

Цитата D_KEY @ 09.07.15, 12:28

При вызове cons вызывается не первая перегрузка?

Она есть, но делается неявно компилятором.

И что?

Цитата

Цитата D_KEY @ 09.07.15, 12:28

А разве при передачи в main_ ListN!1 не кастуется к List!1?

Это частный случай. Точнее будет сказать: ListN!N кастуется к List!N - это полиморфные типы. Ну или псевдополиморфные, с твоей точки зрения. А ListN!1 - это уже обычный тип.

Так ты именно этот обычный тип и передаешь в main_. В первом же внутреннем вызове(и далее). В чем прикол-то?

Добавлено 09.07.15, 12:43

Цитата MyNameIsIgor @ 09.07.15, 12:37

Когда остановить то эту генерацию?

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

Цитата

Или во время исполнения?

Наверное это не лучший вариант.

Я не знаю, думаю, что такие вещи надо как следует обдумать

Цитата D_KEY @ 09.07.15, 12:40

Так ты именно этот обычный тип и передаешь в main_. В первом же внутреннем вызове(и далее). В чем прикол-то?

Скажем в том, что я вообще не манипулирую конкретными типами, только полиморфными вроде List!N. Обычные типы выводятся, кастуются и стираются сами. В первом варианте я стирал вручную. Во втором автоматически. Но автоматику все равно можно сломать если принудительно менять тип.

Ну вот, в жабе такая же байда. Ошибся и случайно скастовал к базовому классу (компилятор не возражает). И оно поломалось. Считается?
http://ideone.com/N8RiOn

Добавлено 09.07.15, 13:33

Цитата applegame @ 09.07.15, 13:06

Ошибся и случайно скастовал к базовому классу

А базовый ли это класс? Но компилятор все равно не возражает

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

Цитата applegame @ 09.07.15, 13:06

Ошибся и случайно скастовал к базовому классу

Ни к какому базовому классу вы ничего не кастовали.

Цитата applegame @ 09.07.15, 13:06

В первом варианте я стирал вручную. Во втором автоматически.

Угу. Оно само конструирует именно ListN!1, а не от выведенного числа. Оно само передаёт указатели на наследников туда, где ожидается указатель на Base. И вообще оно само всё написалось.

Цитата applegame @ 09.07.15, 13:06

Считается?

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

Сообщение отредактировано: MyNameIsIgor - 09.07.15, 13:38

Цитата applegame @ 09.07.15, 13:06

Ошибся и случайно скастовал к базовому классу (компилятор не возражает). И оно поломалось.

Цитата

Exception in thread "main" java.lang.ClassCastException: Nil cannot be cast to Cons

Цитата D_KEY @ 09.07.15, 12:40

Без потери эффективности по сравнению с чем?

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

Цитата applegame @ 09.07.15, 13:06

Скажем в том, что я вообще не манипулирую конкретными типами

Явно, может и нет. А неявно происходит тоже самое, что сделал я. Не вижу разницы.

Цитата

Но автоматику все равно можно сломать если принудительно менять тип.

Я все делаю в рамках системы типов языка. Более того, я делают тоже самое, что неявно происходит в твоем коде.

Добавлено 09.07.15, 13:56

Цитата DarkEld3r @ 09.07.15, 13:50

Цитата D_KEY @ 09.07.15, 12:40

Без потери эффективности по сравнению с чем?

По сравнению с тупой генерацией.

Тупой генерацией такие задачи не решить.

Цитата

В джаве ведь, в итоге, в дженериках оказывался просто Object, так? Это уже менее эффективно, не говоря уже о том, что требует наличия общего родителя для всех типов.

После того, как уже были проверены типы, на этапе кодогенерации, в тех случаях, когда это выгодно(это где-то рядом с инлайнингом функций), можно генерировать специализации. В Rust их наличие/отсутствие в реализации ничему не мешает. Это если я правильно понимаю. Вполне возможно, что какие-то особенности языка таки заставляют его специализации строить.

Цитата MyNameIsIgor @ 09.07.15, 13:35

Ни к какому базовому классу вы ничего не кастовали.

Я уже все сам понял.

Цитата MyNameIsIgor @ 09.07.15, 13:35

Если не считается, то подумайте, что именно вы доказали на примере Java.

Честно говоря я жабу не знаю. И мне не ясно почему компилятор позволил кастовать к A. Например к Integer он не дает кастовать.

Добавлено 09.07.15, 13:58

Цитата D_KEY @ 09.07.15, 13:46

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

То ли лыжи не едут, то ли жабовский код какой-то неполный. Как сгенерить список длинее одного элемента? Вот это не компилируется:

_main(n-1, i+1, new Cons<A>(i, new Cons<A>(2*i+1,first)), new Cons<A>(i, new Cons<A>(i*i, second)));

http://ideone.com/RSGkSv
ЧЯДНТ?

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

Цитата applegame @ 09.07.15, 13:57

Честно говоря я жабу не знаю. И мне не ясно почему компилятор позволил кастовать к A. Например к Integer он не дает кастовать.

Через (Integer)(Object) даст. Но тогда уже _main не вызовется.

Цитата applegame @ 09.07.15, 13:57

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

Это просто говорит о том, что данный явный каст перенёс типизацию в run-time. Это примерно то же, что в плюсах запилить reinterpret_cast, а потом удивляться, что оно упало, но не там, где сам каст.

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

Цитата applegame @ 09.07.15, 14:05

ЧЯДНТ?

http://ideone.com/Huiqad. Естественно, ошибка несоответствия типов (длин списков).

Извиняюсь, слишком бегло посмотрел. Всё верно - http://ideone.com/RlfL3N

Сообщение отредактировано: MyNameIsIgor - 09.07.15, 14:12

В шарпе таже фигня http://ideone.com/LLsWQN

Цитата applegame @ 09.07.15, 14:15

В шарпе таже фигня

Нужно создавать Cons<Cons<A>>. Вы не забыли, что тип показывает длину списка?