Здравствуйте, mima, Вы писали:
M>Давайте попробуем как-то с понятием разобраться. data T = A ... | B ... У значений A ... и B ... — один тип или разный?
Один — Т.
M> У выражений if flag then A ... else B ... и if not flag then A ... else B ... — один тип или разный?
Здравствуйте, DarkGray, Вы писали:
M>>>Давайте попробуем как-то с понятием разобраться. data T = A ... | B ... У значений A ... и B ... — один тип или разный? DG>один обобщенный — T DG>разные конкретизированные: A, B
Кстати, если бы это был окамл и его полиморфные варианты, такое разделение было бы уместно. А в хаскеле это ересь, скорее всего.
VE>Странно, система типов одна, код один, а кол-во операций меняется.
Ты над ним выполнил IoC, и получил другой код. Одна и та же семантика не означает, что код один и тот же. А то так можно договориться, что хорошо спроектированный код и говнокод — это одно и то же, только потому, что работают одинаково.
VE>А динамическая типизация при этом убирается?
Вообще в ООП через IoC как раз борются с излишней динамической типизацией и прочими нарушениями LSP. Т.е. семантика сохраняется, а динамических проверок типов нет. Хотя, динамическое приведение типов есть, но оно теперь скрыто механикой рантайм-полиморфизма ООП. Чем это лучше ручной преврки и приведения типов? Да всем. В первую очередь тем, что в этом месте исключен человеческий фактор.
V>>В твоем примере преобразования изчезало промежуточное состояние Either, т.е. изчезали все накладные расходы,связанные с его обслуживанием.
VE>Spineless Tagless G-machine. VE>Только эти преобразования могут быть целиком на совести компилятора.
И что? Бета-редукция совмещенная с распространением констант до трети исходного кода способна нивелировать, если не больше, а суперкомпиляция до 3/4... И что это доказывает? НИЧЕГО. Потому что не влияет на исходный артефакт — программу, которую развивать и сопровождать и в которой еще надо будет делать ошибки и потом их искать.
===================
Знаешь что... У нас все время игра в одни ворота. Давай попробуем в другие для разминки. Возьмем пример, обратный твоим. Т.е. ты мне показывал технику из Хаскеля, реализованную на С, где у тебя система типов "там", превращалась в данные "здесь" и ты вопрошал: "а хде динамическая типизация, тут просто if?". Давай наоборот. Возьмём ООП-паттерн State (это совсем не то же самое, что монада State). В этом паттерне экземпляры внутреннего абстрактного объекта State неразличимы, если относятся к одному и тому же типу. Т.е. различимы только экземпляры разных типов. Это ключевое для паттерна. Теперь вспоминаем устройство динамического полиморфизма в мейнстримном ООП и спрашиваем себя — за счет чего различимы экземпляры только лишь различных типов в этом паттерне и при чем тут вообще система типов? Потом делаем этот паттерн в Хаскеле и получаем вместо иерархии типов-наследников абстрактного State обычный набор кортежей ф-ий, т.е. данные и код вместо типов. Вопрос на мильон $$, а куда делись типы в Хаскеле из исходного паттерна на С++?
Вот такого плана нелепыми вопросами ты меня заатаковал уже. Вроде ответил про кодирование состояний, про различные характеристики систем типов, про то, что любая информация о типах в рантайм — это ес-но данные и ничего кроме данных, и эти данные ес-но могут являться частью состояния, как это убедительно показано в ООП-паттерне State.
Здравствуйте, mima, Вы писали:
M>>>Т.е. тип значения A a1 a2 ... — Tuple(A1,A2,..), так что ли? DM>>Хаскельный алгебраик — это сумма (копроизведение) произведений. Так что формально T — это сумма Tuple(A1, A2, ...) и Tuple(B1, B2, ...). Каждый из них — отдельный тип, их сумма — третий тип, отличный от обоих.
M>Вопрос был вполне конкретный.
M>Ок, с другой стороны зайду. Понятие типа включает в себя операции над ним? Если да, то есть операции над типом Tuple(A1, A2...)? Есть. Можно ли их использовать для значений A a1 a2? Нет. И наоборот — операций над "типом" A не бывает.
А в ПМ у тебя что? Все операции, доступные над обычными туплами, доступны так же после распаковки АлгТД. Я не большой знаток Хаскеля, поправьте если не так, но есть ФП языки, где целый тупл может идти одним значением и даже быть поданным в виде такого одного значения в ф-ию соответствуюей размеру тупла арности. В общем, тот факт, что Хаскель не поддерживает в полной мере операции над туплами как в дргих языках не означает, что теперь туплы это не туплы...
M>Только над общим типом T.
Нет. Это ты как-то странно понимаешь термин "операция".
M>Даже A -> Tuple не может быть операции. Только T -> Maybe Tuple.
В условиях отсутствия структурных исключений любая условная проверка может возвратить только Maybe или любой его аналог, кодирующий тем или иным способом признак успешности проверки. А что это должно было доказать или опровергнуть?
M>Например, в Scala это не так, а в Haskell так: A — не тип. Мы можем использовать его как тапл только через разбор, например, катаморфизм.
Это от бедности ср-в над туплами конкретно Хаскеля. Но ведь в нем, если не ошибаюсь, можно назначить туплу алиас точно так же как любому другому типу, так? Т.е. Хаскель где-то "унутре" таки считает туплы неким типом, что даже может давать им алиасы наравне с другими типами.
M>В общем-то это и хотелось узнать: понятие типа для vdimas включает или нет операции над ним?
Ес-но включает. А разве при всей невнимательности Хаскеля к туплам над ними мало операций? А как же группировка, разбиение, возврат тупла как одного значения и т.д.?
M>Да. Обратите внимание, что по vdimas у A a1 a2 уточнённый тип (A1, A2)
Уточненный тип был Tuple(A1, A2) и больше ничего. Как вообще вызов ф-иий может являться типом? Какая-то каша.
M>Давайте попробуем как-то с понятием разобраться. data T = A ... | B ... У значений A ... и B ... — один тип или разный?
A и B в одном контексте представляют из себя вызов ф-ии, а в другом — дискриминаторы АлгТД. В этом втором случае тип значения дескриминатора одного и того же АлгТД ес-но один и тот же, согласно определению АлгТД. Но он тебе не доступен в Хаскель для пользовательских типов. Т.е. конструкция ПМ в Хаскеле такова, что информация о типе дискриминатора АлгТД нигде не участвует, следовательно нет надобности выносить её на уровень пользователя. Тем не менее, "числовое" или там "битовое" представление дискриминатора АлгТД тебе доступно для встроенных интегральных типов, которые являются АлгТД по спецификации.
M>У выражений if flag then A ... else B ... и if not flag then A ... else B ... — один тип или разный?
Это Хаскель или псевдоязык? А то ведь от контекста зависит, но ответ Да для обоих возможных контекстов.
Здравствуйте, D. Mon, Вы писали:
DG>>только надо быть честным и формулировать правильно: TMemoryMapping настолько изменчив, там настолько много информации, что я, D.Mon не знаю, как с этим можно работать.
DM>Нет, я о другом. Если включать TMemoryMapping в систему типов языка, то никакой вообще информации там не будет, т.к. значения его не будут известны. Ты не можешь заранее знать и включить в систему типов все подробности всех будущих реализаций компиляторов и других способов исполнения. Программу может вообще не компьютер исполнять, а группа бразильских студенток. Как у них в головах представлен int? Внесешь это в систему типов?
В С есть явное уточнение кол-ва бит для целочисленного типа. Если бит в исходном типе не хватает, то будет ошибка компиляции.
struct color {
int r:5, g:6, b:5;
};
size_t x:55; // x64 - ok, x86 - error C2034: type of bit field too small for number of bits.
Так что, при надобности легко обеспечить детерминированность целочисленной арифметики.
Ок, база индукции у тебя есть, теперь давай индуктивный переход, чтобы распространить на все другие языки. Мы же тут о языках и системах типов в целом говорим, а не об одном Си.
Здравствуйте, vdimas, Вы писали:
M>>Да. Обратите внимание, что по vdimas у A a1 a2 уточнённый тип (A1, A2) V>Уточненный тип был Tuple(A1, A2) и больше ничего. Как вообще вызов ф-иий может являться типом? Какая-то каша.
Что? Откуда вы взяли этот вызов функции?
M>>Давайте попробуем как-то с понятием разобраться. data T = A ... | B ... У значений A ... и B ... — один тип или разный? V>A и B в одном контексте представляют из себя вызов ф-ии, а в другом — дискриминаторы АлгТД.
A и B тут не при чём. Я спрашиваю про значения A ... и B ..., например, если A Int, а B String, то A 42 и B "hello" имеют один тип или разный?
V>В этом втором случае тип значения дескриминатора одного и того же АлгТД ес-но один и тот же, согласно определению АлгТД. Но он тебе не доступен в Хаскель для пользовательских типов. Т.е. конструкция ПМ в Хаскеле такова, что информация о типе дискриминатора АлгТД нигде не участвует, следовательно нет надобности выносить её на уровень пользователя. Тем не менее, "числовое" или там "битовое" представление дискриминатора АлгТД тебе доступно для встроенных интегральных типов, которые являются АлгТД по спецификации.
Я не понимаю. Вопросы:
Что такое значение дискриминатора? Например, A 42? Если да, то его тип мне доступен, почему нет?
При чём тут вообще ПМ?
Что такое тип дискриминатора? Вообще, если он нигде не участвует, может и не стоит о нём говорить, т.к. его нет? Например, я могу сказать, что в Haskell тип есть у where, но т.к. он нигде не участвует, то нет надобности выносить его на уровень пользователя, но это же бред. Тип бывает у значений. Дискриминатор (если под ним понимается A это или B) — не является значением.
Что такое встроенные интегральные типы?
M>>У выражений if flag then A ... else B ... и if not flag then A ... else B ... — один тип или разный? V>Это Хаскель или псевдоязык? А то ведь от контекста зависит, но ответ Да для обоих возможных контекстов.
Я не понимаю ответа "Да" на вопрос "это один тип или разный".
Здравствуйте, vdimas, Вы писали:
M>>Ок, с другой стороны зайду. Понятие типа включает в себя операции над ним? Если да, то есть операции над типом Tuple(A1, A2...)? Есть. Можно ли их использовать для значений A a1 a2? Нет. И наоборот — операций над "типом" A не бывает. V>А в ПМ у тебя что? Все операции, доступные над обычными туплами, доступны так же после распаковки АлгТД. Я не большой знаток Хаскеля, поправьте если не так, но есть ФП языки, где целый тупл может идти одним значением и даже быть поданным в виде такого одного значения в ф-ию соответствуюей размеру тупла арности. В общем, тот факт, что Хаскель не поддерживает в полной мере операции над туплами как в дргих языках не означает, что теперь туплы это не туплы...
Если есть языки, в которых A 42 13 воспримается не только как значение описанного типа T, но и как тупл (Int, Int), то в них, очевидно это так. В Haskell — да, это не тупл. И т.к. это не тупл, то "факт, что Хаскель не поддерживает в полной мере операции над туплами" с очевидностью ложен.
M>>Только над общим типом T. V>Нет. Это ты как-то странно понимаешь термин "операция".
Под операцией я понимаю функцию.
M>>Даже A -> Tuple не может быть операции. Только T -> Maybe Tuple. V>В условиях отсутствия структурных исключений любая условная проверка может возвратить только Maybe или любой его аналог, кодирующий тем или иным способом признак успешности проверки. А что это должно было доказать или опровергнуть?
Это должно опровергнуть ваше заявление о том, что у A 42 13 есть отдельный тип, отличный от B "hello" "world", скажем. Вы их ещё называете уточнёнными. Смысл в том, что раз нет различных операций над этими типами, то нет и различных типов.
M>>Например, в Scala это не так, а в Haskell так: A — не тип. Мы можем использовать его как тапл только через разбор, например, катаморфизм. V>Это от бедности ср-в над туплами конкретно Хаскеля. Но ведь в нем, если не ошибаюсь, можно назначить туплу алиас точно так же как любому другому типу, так? Т.е. Хаскель где-то "унутре" таки считает туплы неким типом, что даже может давать им алиасы наравне с другими типами.
Вы под туплом что понимаете? Тип или просто структуру? Если тип, то да, тупл — тип, но тогда A 42 13 — не тупл. Если структуру, то да A 42 13 — тупл, но тогда тупл A 42 13 и тупл 42:[] имеют разные типы (и им нельзя назначить алиас, например). Всё в контексе Haskell, разумеется.
M>>В общем-то это и хотелось узнать: понятие типа для vdimas включает или нет операции над ним? V>Ес-но включает. А разве при всей невнимательности Хаскеля к туплам над ними мало операций? А как же группировка, разбиение, возврат тупла как одного значения и т.д.?
Но тогда множества операций над типом T и над типом (Int, Int) — непересекающиеся. Следовательно, типы разные.
P.S. Давайте всё таки говорить о чём-то одном. Мой тезис: никаких уточнённых типов в Haskell нет. По той простой причине, что в коде мы их значения никак не можем отделить от других уточнений общего типа. Ваше замечание о ПМ, например, несостоятельно в том числе по этой причине.
Здравствуйте, vdimas, Вы писали:
VE>>Странно, система типов одна, код один, а кол-во операций меняется.
V>Ты над ним выполнил IoC, и получил другой код.
Здравствуйте, vdimas, Вы писали:
V>А то так можно договориться, что хорошо спроектированный код и говнокод — это одно и то же, только потому, что работают одинаково.
С т.з. того, есть там динамическая типизация или нет, да, одно и то же.
V>=================== V>Знаешь что... У нас все время игра в одни ворота. Давай попробуем в другие для разминки. Возьмем пример, обратный твоим. Т.е. ты мне показывал технику из Хаскеля, реализованную на С, где у тебя система типов "там", превращалась в данные "здесь" и ты вопрошал: "а хде динамическая типизация, тут просто if?". Давай наоборот. Возьмём ООП-паттерн State (это совсем не то же самое, что монада State). В этом паттерне экземпляры внутреннего абстрактного объекта State неразличимы, если относятся к одному и тому же типу. Т.е. различимы только экземпляры разных типов. Это ключевое для паттерна. Теперь вспоминаем устройство динамического полиморфизма в мейнстримном ООП и спрашиваем себя — за счет чего различимы экземпляры только лишь различных типов в этом паттерне и при чем тут вообще система типов? Потом делаем этот паттерн в Хаскеле и получаем вместо иерархии типов-наследников абстрактного State обычный набор кортежей ф-ий, т.е. данные и код вместо типов. Вопрос на мильон $$, а куда делись типы в Хаскеле из исходного паттерна на С++?
Какая разница. Это тебя волнует, куда что девается. Потому что в одном случае у тебя есть динамическая типизация, а в другом — нет.
Хотя семантика одна.
Здравствуйте, mima, Вы писали:
M>Тип бывает у значений. Дискриминатор (если под ним понимается A это или B) — не является значением.
Являются алиасами неких значений не хуже именованных констант. Конкретно в ограничениях Хаскеля ты можешь использовать эти значения только в конструкциях ПМ.
И да, сама по себе фраза "дискриминатор не является значением" — неслыханная ересь. Ес-но значение дескриминатора АлгТД является значением/индексом прямо по определению размеченного объединения.
M>Что такое встроенные интегральные типы?
Кто здесь?
M>>>У выражений if flag then A ... else B ... и if not flag then A ... else B ... — один тип или разный? V>>Это Хаскель или псевдоязык? А то ведь от контекста зависит, но ответ Да для обоих возможных контекстов. M>Я не понимаю ответа "Да" на вопрос "это один тип или разный".
if может вернуть лишь значение одного и того же типа из разных веток, так что в любом случае в компиллируемом примере будет один и тот же тип значения всего выражения. Рассматривай здесь A и B как ф-ии, конструирующие значение одного и того же неуточненного типа. Но если щатем уточнить содержимое такого неуточненного значения на ПМ, то получим, ес-но, разные уточненные типы-туплы.
M>>>Ок, с другой стороны зайду. Понятие типа включает в себя операции над ним? Если да, то есть операции над типом Tuple(A1, A2...)? Есть. Можно ли их использовать для значений A a1 a2? Нет. И наоборот — операций над "типом" A не бывает. V>>А в ПМ у тебя что? Все операции, доступные над обычными туплами, доступны так же после распаковки АлгТД. Я не большой знаток Хаскеля, поправьте если не так, но есть ФП языки, где целый тупл может идти одним значением и даже быть поданным в виде такого одного значения в ф-ию соответствуюей размеру тупла арности. В общем, тот факт, что Хаскель не поддерживает в полной мере операции над туплами как в дргих языках не означает, что теперь туплы это не туплы...
M>Если есть языки, в которых A 42 13 воспримается не только как значение описанного типа T, но и как тупл (Int, Int), то в них, очевидно это так.
Давненько такой густой каши не видел... ))
A 42 13 — это вызов банальной ф-ии, сигнатура которой описана так: Args->ReturnType, где
* ReturnType — T
* Args — Tuple(int, int).
M>В Haskell — да, это не тупл. И т.к. это не тупл, то "факт, что Хаскель не поддерживает в полной мере операции над туплами" с очевидностью ложен.
Что "это"???
Результат вызова ф-ии ес-но никакой не тупл, а значение типа Т. Но согласно семантики Хаскеля это неуточненное значение хранит в себе значение признака-дискриминатора, конкретно здесь A, а так же хранит значение типа Tuple(int, int), конкретно здесь (42, 13). См. моё замечание относительно дуальности идентификаторов конструкторов алгТД в Хаскеле.
V>>Нет. Это ты как-то странно понимаешь термин "операция". M>Под операцией я понимаю функцию.
Это слишком урезанное понятие. Ф-ии бывают не только пользовательские, но и встроенные, а операции бывают не только времени исполнения, но и времени компиляции. Популярные операции над туплами: обединение/рабиение — как раз пример таких операций.
M>>>Даже A -> Tuple не может быть операции. Только T -> Maybe Tuple. V>>В условиях отсутствия структурных исключений любая условная проверка может возвратить только Maybe или любой его аналог, кодирующий тем или иным способом признак успешности проверки. А что это должно было доказать или опровергнуть?
M>Это должно опровергнуть ваше заявление о том, что у A 42 13 есть отдельный тип, отличный от B "hello" "world", скажем.
Никак не должно, а сама фраза "у A 42 13 есть отдельный тип" какая-то нелепица. Что ты тимел ввиду? Тип возвращаемого значения или тип-сигнатуру ф-ии? Если первое — то оно одинаково с B "hello" "world", если второе — то разное.
M>Вы их ещё называете уточнёнными. Смысл в том, что раз нет различных операций над этими типами, то нет и различных типов.
Ес-но есть операции над уточненными типами — это распаковка завернутых туплов на ПМ. Собсно, в Хаскеле другого-то механизма в языке нет, кроме как ПМ, который достаёт уточненные типы из неуточненных АлгТД.
M>>>Например, в Scala это не так, а в Haskell так: A — не тип. Мы можем использовать его как тапл только через разбор, например, катаморфизм. V>>Это от бедности ср-в над туплами конкретно Хаскеля. Но ведь в нем, если не ошибаюсь, можно назначить туплу алиас точно так же как любому другому типу, так? Т.е. Хаскель где-то "унутре" таки считает туплы неким типом, что даже может давать им алиасы наравне с другими типами.
M>Вы под туплом что понимаете?
Некий составной тип, который представляет из себя кортеж неименованных полей.
M>Тип или просто структуру?
OMG
M>Если тип, то да, тупл — тип, но тогда A 42 13 — не тупл.
Ес-но, вызов ф-ии — это не тупл, это вызов ф-ии. Очень познавательно, спасибо.
M>Если структуру, то да A 42 13 — тупл, но тогда тупл A 42 13 и тупл 42:[] имеют разные типы (и им нельзя назначить алиас, например). Всё в контексе Haskell, разумеется.
Брр... разгрести эту кашу я не смог даже со 2-го раза...
M>>>В общем-то это и хотелось узнать: понятие типа для vdimas включает или нет операции над ним? V>>Ес-но включает. А разве при всей невнимательности Хаскеля к туплам над ними мало операций? А как же группировка, разбиение, возврат тупла как одного значения и т.д.? M>Но тогда множества операций над типом T и над типом (Int, Int) — непересекающиеся. Следовательно, типы разные.
Именно это я и показываю, что типы разные. Наверно Хаскель в плане туплов малость беден и не позволяет, скажем, в конструкции ПМ ссылаться на весь тупл через одну переменную (поправь, если я не прав), а затем эту переменную-тупл опять разобрать на составляющие во вложенном ПМ и т.д. Это особенность Хаскеля, что его пользовательские типы всегда алгТД, а набор операций над туплами крайне беден. Эдакий урезанный вариант функционального языка получился. Скорее всего, простоты ради.
M>P.S. Давайте всё таки говорить о чём-то одном. Мой тезис: никаких уточнённых типов в Haskell нет. По той простой причине, что в коде мы их значения никак не можем отделить от других уточнений общего типа.
Да без проблем можем отделить: переменные в шаблоне ПМ при разборе алгТД — это и есть "шаблон" кортежа результирующего тупла, полями которого ты можешь пользоваться в данной ветке ПМ. Видать, ограничения языка Хаскеля совершенно сбивают тебя с толку.
Re[4]: Мифический Haskell
От:
Аноним
Дата:
06.09.12 17:34
Оценка:
MM>По-моему, ты не писал реальных приложений вообще.
MM>Мне приходилось работать в геймдеве. Сейчас я занимаюсь антивирусами.
Геймдев и антивирусы это такие узкие-узкие нишевые области, в которых работают 0,1% программистов. Основная часть имхо ваяет внутрикорпоративное ПО либо сайты/порталы, и там и там GUI важная часть софта
Здравствуйте, VoidEx, Вы писали:
VE>Они уже оставили. Почти все нынешние языки впитали их гены и многие (в том числе Nemerle) являются потомками в том числе функциональных языков. А вот оставят ли потомство ваши, это ещё большой вопрос.
Это да. Но впитали они сами идеи ФП, а не синтаксис.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Мы же тут о языках и системах типов в целом говорим, а не об одном Си.
