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

[korvin]

Цитата D_KEY @ 29.11.11, 07:23

А вообще интересно, что ты противоречишь своим предыдущим сообщениям, где утверждал, что для реализации АТД "субтипирование" необходимо.

я этого не утверждал, я к этому склонялся

Цитата korvin @ 25.11.11, 22:51

хотя вообще интересный вопрос, является ли субтипирование необходимым.

и где я противоречу? напомню, что

Цитата korvin @ 25.11.11, 22:51

в общем случае в хаскелле вообще нет абстрактных типов

в Хаскелле нет поддержки АТД как языковой абстракции

[D_KEY]

Цитата korvin @ 29.11.11, 07:56

Цитата D_KEY @ 29.11.11, 07:23

А вообще интересно, что ты противоречишь своим предыдущим сообщениям, где утверждал, что для реализации АТД "субтипирование" необходимо.

я этого не утверждал, я к этому склонялся

Ок.

Цитата

в Хаскелле нет поддержки АТД как языковой абстракции

Объясни мне, зачем тебе формальное наличие АТД, если есть тайпклассы, которые позволяют делать все тоже самое(правда не в рантайме)?

[korvin]

Цитата D_KEY @ 29.11.11, 08:00

Объясни мне, зачем тебе формальное наличие АТД

мне оно не нужно.

Цитата D_KEY @ 29.11.11, 08:00

если есть тайпклассы, которые позволяют делать все тоже самое(правда не в рантайме)?

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

[D_KEY]

Цитата korvin @ 29.11.11, 08:24

Цитата D_KEY @ 29.11.11, 08:00

если есть тайпклассы, которые позволяют делать все тоже самое(правда не в рантайме)?

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

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

Сообщение отредактировано: D_KEY - 29.11.11, 08:40

[korvin]

Цитата D_KEY @ 29.11.11, 08:28

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

ты не понял... АТД описывает свойства данных, а тайпкласс описывает свойства типа данных. у них предмет описания разный.

[D_KEY]

Цитата korvin @ 29.11.11, 09:16

ты не понял... АТД описывает свойства данных, а тайпкласс описывает свойства типа данных. у них предмет описания разный.

Тип нужен исключительно для описания свойств данных. Описывая тип, ты описываешь свойства данных. В случае абстрактных типов это не отличимо.

Добавлено 29.11.11, 09:22
Т.е. в случае интерфейсов ты описываешь контракт объектов, в случае тайпкласса - описываешь требования к типу, которым описывается контракт объектов.

[korvin]

Цитата D_KEY @ 29.11.11, 09:17

Тип нужен исключительно для описания свойств данных. Описывая тип, ты описываешь свойства данных. В случае абстрактных типов это не отличимо.

Т.е. в случае интерфейсов ты описываешь контракт объектов, в случае тайпкласса - описываешь требования к типу, которым описывается контракт объектов.

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

[D_KEY]

Цитата korvin @ 29.11.11, 09:35

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

Как ни крути, ты делаешь именно это. Даже название механизма об этом же говорит.
Ты можешь сделать какой-нибудь Ord тайпклассом в одном языке или интерфейсом/абстрактным классом в другом - это ничего не изменит, программист хотел задать требования наличия соответствующих операций с соответствующей семантикой.

Добавлено 29.11.11, 11:59

Цитата haskell.org/haskellwiki/Abstract_data_type

In Haskell, it is also possible to describe an interface to a data type using the Type class concept. This provides a mechanism for making the implementation of operations for a data type abstract as well. For example, the above interface for the abstract Tree data type might be described as:

class Tree t where
    nil   :: t a
    node  :: t a -> a -> t a -> t a
    left  :: (MonadPlus m) => t a -> m (t a)
    right :: (MonadPlus m) => t a -> m (t a)
    value :: (MonadPlus m) => t a -> m a

Note that this description is even more abstract than the description of the Tree abstract data type above. This interface will also make the implementation of the tree abstract (not just the element type). This interface allows the user to change the implementation of the tree data type later easily.

http://www.haskell.org/haskellwiki/Abstract_data_type

Сообщение отредактировано: D_KEY - 29.11.11, 11:59

[korvin]

Цитата D_KEY @ 29.11.11, 11:19

Ты можешь сделать какой-нибудь Ord тайпклассом в одном языке или интерфейсом/абстрактным классом в другом - это ничего не изменит, программист хотел задать требования наличия соответствующих операций с соответствующей семантикой.

Да сколько можно-то.

Интерфейсы приводят к субтипированию (C++, Java, C#, Delphi, Go, Racket, etc.).
Тайпклассы -- нет.

К чему приводит эта разница я уже написал:

1) невозможность использования разных типов с одним тайпклассом в одном контексте

typeclass C
type A : C
type B : C
xs {a : C} : [a] = [A, B] -- ошибка типизации

2) потеря статической информации о типе при использовании интерфейсов

interface I
type A <: I
type B <: I
xs : [I] = [A, B] -- нет ошибки типизации
head xs -- имеет тип I

все, больше нечего обсуждать по этому вопросу.

Сообщение отредактировано: korvin - 29.11.11, 13:10

[D_KEY]

Цитата korvin @ 29.11.11, 13:06

Цитата D_KEY @ 29.11.11, 11:19

Ты можешь сделать какой-нибудь Ord тайпклассом в одном языке или интерфейсом/абстрактным классом в другом - это ничего не изменит, программист хотел задать требования наличия соответствующих операций с соответствующей семантикой.

Да сколько можно-то.

Интерфейсы приводят к субтипированию (C++, Java, C#, Delphi, Go, Racket, etc.).
Тайпклассы -- нет.

К чему приводит эта разница я уже написал:

1) невозможность использования разных типов с одним тайпклассом в одном контексте

typeclass C
type A : C
type B : C
xs : [C] = [A, B] -- ошибка типизации

2) потеря статической информации о типе при использовании интерфейсов

interface I
type A <: I
type B <: I
xs : [I] = [A, B] -- нет ошибки типизации
head xs -- имеет тип I

все, больше нечего обсуждать по этому вопросу.

Так с этим никто не спорит. Только это не противоречит тому, что пишу я.

[Ahilles]

есть структура

typedef struct mystruct {
DWORD f1;
WORD f2;
DWORD f3
}

в некоторых случаях её размер равен 10, а в некоторых 12, вся проблема в выравниваниях смещений полей. всё зависит от парметров компиляции.
в delphi я могу указать packed record и структура будет иметь размер тот который должен, а не тот который с выравниваниями. Т.е. я могу использовать одновременно выровненные структуры и невыровненные. Внимание вопрос: как тоже самое сделать в C++?

[D_KEY]

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

Сообщение отредактировано: D_KEY - 30.11.11, 07:45

[Ahilles]

да плевать мне на плаформу! я хочу чтобы вот одна структура была размерностью как положено (с выравниваниями), а другая структура без выравниваний и всё в одном проекте и в одном .cpp файле.

Сообщение отредактировано: Ahilles - 30.11.11, 07:56

[D_KEY]

Ahilles, так я же сказал pragma pack. Или гугл не работает у тебя?

[Ahilles]

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