Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

[korvin]

Цитата D_KEY @ 13.03.12, 08:08

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

Угу, в этом и есть ее смысл (как ты себе представляешь скалярное произведение векторов разной размерности?), нужно приводит вектора к единому типу.

[D_KEY]

Цитата korvin @ 13.03.12, 08:33

Цитата D_KEY @ 13.03.12, 08:08

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

Угу, в этом и есть ее смысл (как ты себе представляешь скалярное произведение векторов разной размерности?), нужно приводит вектора к единому типу.

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

[--Ins--]

Пожалуй, согласен с D_KEY насчет практической пользы - для списков полученных в разных местах, вне Test, номер не пройдет.

[korvin]

Цитата D_KEY @ 13.03.12, 08:08

А сам псевдокод понял?

Нет, я ничего не понял =/

Цитата D_KEY @ 13.03.12, 08:08

Будет сгенерирован код для f<Nil> и для f<Cons[a]>, соответственно. В f<Nil> будут созданы объекты Cons[Nil], затем будет вызвана foo<Cons[a]>, а информация о том, что a - это именно Nil - уже будет не нужна, там будут созданы объекты Cons[Cons[a]](на самом деле просто Cons[b]) и т.д.
Когда же дойдет дело до ScalarProduct, то будет осуществлено обращение к ScalarProduct<Cons[a]>(или к ScalarProduct<Nil>, если длина нулевая), что приведет к вызову нужной функции, которой не нужно знать является ли a Nil или Cons[b]. Сам ScalarProduct будет инстанцирован два раза: ScalarProduct<Nil> и ScalarProduct<Cons[a]>(ибо ему все-равно, что такое a и продолжение инстанцирования не требуется)

Мне из этого совершенно непонятно, каким образом в определении

instance ScalarProduct (Cons a) where
    scalarProduct (Cons h1 t1) (Cons h2 t2) = h1*h2 + scalarProduct t1 t2

внутренний вызов scalarProduct определяет какой тип у t1 и t2 (Cons или Nil), если это необходимо для выбора инстанса в рантайме, а типы, как ты говоришь, в рантайме не "строятся", хотя забываешь, что в тех же Delphi, Java и C# объекты имеют типы в рантайме.

[D_KEY]

Цитата korvin @ 13.03.12, 08:47

Мне из этого совершенно непонятно, каким образом в определении

instance ScalarProduct (Cons a) where
    scalarProduct (Cons h1 t1) (Cons h2 t2) = h1*h2 + scalarProduct t1 t2

внутренний вызов scalarProduct определяет какой тип у t1 и t2 (Cons или Nil)

Он знает тип на момент генерации кода для инстанса Ты там зря убрал кусок кода перед этим, откуда a берется. Т.е. в итоге компилятор из одного инстанса породит код, как будь-то для двух инстансов(для Cons<Nil> и для Cons<Cons<что-то>>).

Цитата

хотя забываешь, что в тех же Delphi, Java и C# объекты имеют типы в рантайме.

Дженерики забывают тип. Там фактически Object. Правда .NET'овский JIT-компилятор генерирует код для типов-значений, подобно плюсовому компилятору, но только во время выполнения.

[--Ins--]

Цитата D_KEY @ 13.03.12, 08:58

Дженерики забывают тип. Там фактически Object.

Что ты этим хотел сказать?

[D_KEY]

Цитата --Ins-- @ 13.03.12, 09:03

Цитата D_KEY @ 13.03.12, 08:58

Дженерики забывают тип. Там фактически Object.

Что ты этим хотел сказать?

А что не понятно?

[--Ins--]

Цитата D_KEY @ 13.03.12, 09:07

А что не понятно?

Ничего не понятно. В каком смысле "забывает" и "там фактически Object"?

[D_KEY]

Кстати, тут вспомнил про С++/CLI, там же есть generic'и. Надо бы проверить генерацию дженериков шаблонами

Добавлено 13.03.12, 09:20

Цитата --Ins-- @ 13.03.12, 09:10

Ничего не понятно. В каком смысле "забывает" и "там фактически Object"?

Благодаря этому и работает обсуждаемый пример, ибо компилятору достаточно проверить текущую итерацию рекурсии(и тут он проверяет параметры дженериков), а потом он переходит к следующей, "забыв" о параметре параметризованного типа предыдущей итерации.

[--Ins--]

Цитата D_KEY @ 13.03.12, 09:12

"забыв" о параметре параметризованного типа предыдущей итерации.

Типы параметров предыдущей итерации - это входные параметры текущей, а прототип метода гарантирует что они одинаковы. Но причем тут типы в рантайм? Как ты думаешь, TCons<TCons<TNil>> и TCons<TNil> - в рантайм, это один и тот же тип или разные?

Сообщение отредактировано: --Ins-- - 13.03.12, 09:31

[D_KEY]

Цитата --Ins-- @ 13.03.12, 09:28

Типы параметров предыдущей итерации - это входные параметры текущей

Не совсем. Когда функция будет вызвана для Cons<тип>, внутри функции тип будет уже неизвестен. Т.е. разницы между тем, будет ли тип=Cons<другой_тип> или тип=Nil для компилятора нет.

Цитата

а прототип метода гарантирует что они одинаковы

Да.

[--Ins--]

Цитата D_KEY @ 13.03.12, 09:35

Когда функция будет вызвана для Cons<тип>, внутри функции тип будет уже неизвестен.

Ровно на столько же, насколько внутри метода, скажем SaveToStream(Stream: TStream) неизвестно с каким именно стримом работает код - TFileStream, TMemoryStream и т.д.

Цитата D_KEY @ 13.03.12, 09:35

Т.е. разницы между тем, будет ли тип=Cons<другой_тип> или тип=Nil для компилятора нет.

Ну естественно, в этом же и суть параметрического полиморфизма

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

Цитата D_KEY @ 13.03.12, 09:35

Т.е. разницы между тем, будет ли тип=Cons<другой_тип> или тип=Nil для компилятора нет.

Для компилятора - нет, для выполняющегося кода - есть

[D_KEY]

Цитата --Ins-- @ 13.03.12, 09:43

Цитата D_KEY @ 13.03.12, 09:35

Т.е. разницы между тем, будет ли тип=Cons<другой_тип> или тип=Nil для компилятора нет.

Ну естественно, в этом же и суть параметрического полиморфизма

Ну вот это и есть "забывает"

Цитата

Для компилятора - нет, для выполняющегося кода - есть

Это уже рантайм

Сообщение отредактировано: D_KEY - 13.03.12, 10:20

[korvin]

Цитата D_KEY @ 13.03.12, 08:58

Он знает тип на момент генерации кода для инстанса Ты там зря убрал кусок кода перед этим, откуда a берется.

Он не знает тип. Т.к. конкретный тип (Cons или Nil) будет известен только когда список будет построен из n, т.е. в рантайме.

instance ScalarProduct a => ScalarProduct (Cons a) where ...

"ScalarProduct a" -- это не тип.

Цитата D_KEY @ 13.03.12, 08:58

Т.е. в итоге компилятор из одного инстанса породит код, как будь-то для двух инстансов(для Cons<Nil> и для Cons<Cons<что-то>>).

Зачем? Ему все равно придется в рантайме выбирать между этими вариантами. Не будет он этого делать. У нас уже есть две перегрузки scalarProduct, которых достаточно для работы примера.

Цитата D_KEY @ 13.03.12, 08:58

Дженерики забывают тип. Там фактически Object. Правда .NET'овский JIT-компилятор генерирует код для типов-значений, подобно плюсовому компилятору, но только во время выполнения.

а instanceof через libastral работает?

Добавлено 13.03.12, 10:23

Цитата D_KEY @ 13.03.12, 09:12

Благодаря этому и работает обсуждаемый пример, ибо компилятору достаточно проверить текущую итерацию рекурсии(и тут он проверяет параметры дженериков), а потом он переходит к следующей, "забыв" о параметре параметризованного типа предыдущей итерации.

Ты путаешь стадию проверки типов и стадию диспетчеризации функции. В Хаскелле это разные стадии.

Добавлено 13.03.12, 10:27

Цитата --Ins-- @ 13.03.12, 09:43

Цитата D_KEY @ 13.03.12, 09:35

Т.е. разницы между тем, будет ли тип=Cons<другой_тип> или тип=Nil для компилятора нет.

Ну естественно, в этом же и суть параметрического полиморфизма

Только параметрический полиморфизм тут практически не при чем.

[D_KEY]

Цитата korvin @ 13.03.12, 10:21

Цитата D_KEY @ 13.03.12, 08:58

Он знает тип на момент генерации кода для инстанса Ты там зря убрал кусок кода перед этим, откуда a берется.

Он не знает тип. Т.к. конкретный тип (Cons или Nil) будет известен только когда список будет построен из n, т.е. в рантайме.

Почему ты забываешь о генерации кода?

Цитата

instance ScalarProduct a => ScalarProduct (Cons a) where ...

"ScalarProduct a" -- это не тип.

a - тип.

Цитата

Цитата D_KEY @ 13.03.12, 08:58

Т.е. в итоге компилятор из одного инстанса породит код, как будь-то для двух инстансов(для Cons<Nil> и для Cons<Cons<что-то>>).

Зачем? Ему все равно придется в рантайме выбирать между этими вариантами.

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

Цитата

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

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

Цитата

Цитата D_KEY @ 13.03.12, 08:58

Дженерики забывают тип. Там фактически Object. Правда .NET'овский JIT-компилятор генерирует код для типов-значений, подобно плюсовому компилятору, но только во время выполнения.

а instanceof через libastral работает?

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

Цитата

Цитата D_KEY @ 13.03.12, 09:12

Благодаря этому и работает обсуждаемый пример, ибо компилятору достаточно проверить текущую итерацию рекурсии(и тут он проверяет параметры дженериков), а потом он переходит к следующей, "забыв" о параметре параметризованного типа предыдущей итерации.

Ты путаешь стадию проверки типов и стадию диспетчеризации функции. В Хаскелле это разные стадии.

Это было про дженерики, а не Haskell.

Добавлено 13.03.12, 10:48

Цитата korvin @ 13.03.12, 10:21

Он не знает тип. Т.к. конкретный тип (Cons или Nil) будет известен только когда список будет построен из n, т.е. в рантайме.

ИМХО, ты путаешь с шаблонами. При параметрическом полиморфизме не нужно точно знать тип-параметр.

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