Здравствуйте, nikov, Вы писали:
N>Взгляните, например, на это выражение (псевдокод, синтаксис Haskell/Ela): N>[haskell] N>let foo f = (f fst, f snd) N> bar g = g (id, []) N> in (foo bar, foo map)
Этот пример ничего не показывает кроме св-в конкретной системы типов. Ничего не мешает вывести типы абстрактно/неуточненно, если бы система типов некоего статически компиллируемого языка это позволяла.
В шаблонном коде "абстрактные" типы превращаются в реальные только в месте применения реальных же типов. По аналогии с С++, можно уточнять шаблоны конкретными типами, а можно так же шаблонными. Недобство в синтакцисе С++ тут в том, что каждый новый уровень шаблонов требует нового ключевого слова template. Если бы синтаксис позволял делать это автоматом и сколько угодно глубоко иерархически, то проблем с аналогами приведеного примера не было бы. Конкретные типы выводились бы в местах вызова с конкретными же типами. Чуть выше на макросах+шаблонах С++ показали абсолютно правильно.
Другое дело, что макросы и шаблоны — это же родственные технологии, т.к. у них родственная задача — обобщенная кодогенерация. В этом смысле, если сделать св-ва подстановки шаблонов "автоматом и сколько угодно глубоко иерархически" это будет то же самое, что добавление св-ва "нетипизированности" макросов в шаблоны... Но я всё еще не вижу здесь потери статической типизированности, ведь любая подстановка в итоге должна породить корректное, с т.з. системы типов, выражение. Я вижу потенциальную проблему только в диагностических сообщениях о подобных выражениях после серий подстановок. ))
Здравствуйте, VladD2, Вы писали:
VD>Можно производить частичную компиляцию. В бинарники можно АСТ или другое промежуточное представление засовывать, например.
Ты не хуже меня знаешь, что это фактически распространение в исходниках.
Декомпиляторов для .НЕТ тьма.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Ты не хуже меня знаешь, что это фактически распространение в исходниках. WH>Декомпиляторов для .НЕТ тьма.
Знаю точно, что это не исходники. Декомпиляторы тут не причем. Решается не задача обфускации, а задача бинарного распространения библиотек. Те же макры без намного удобнее подключать к проекту в виде длл-без нежели тащить с собой проекты.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Знаю точно, что это не исходники. Декомпиляторы тут не причем. Решается не задача обфускации, а задача бинарного распространения библиотек. Те же макры без намного удобнее подключать к проекту в виде длл-без нежели тащить с собой проекты.
Ну, так можно просто закатывать исходники в архив и всё.
И будет бинарное распространение.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Это если ты инфраструктуру сделаешь. А просто зип будет такой же неудобный и проблемый как исходники.
Ну, так и для сериализованного АСТ нужна инфраструктура.
VD>Тут целью является достижение модульности. В сборке с АСТ-ом могут разные метаданные валяться.
Больше чем в исходниках валяться не может. Единственное преимущество сериализованного АСТ перед архивом с исходниками это скорость работы.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Ну, так и для сериализованного АСТ нужна инфраструктура.
Нужна, но я не о том.
WH>Больше чем в исходниках валяться не может. Единственное преимущество сериализованного АСТ перед архивом с исходниками это скорость работы.
Может. Информация о проектах. В исходнике банально может не хватать зависимостей.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
RO>tnpo (Just x) = Just (Just (Just (tnpo x)))
RO>tnpo Nothing = Just Nothing
RO>collatz x = collatz3 x x x
RO>collatz3 x (Just y) (Just (Just z)) = collatz3 x y z
RO>collatz3 x y Nothing = collatz y
RO>collatz3 x y (Just Nothing) = collatz (tnpo x)
RO>
Ты это сам придумал?! Но чёртвозьмихолмс, как?
RO>И какой тип возвращаемого значения collatz (Just (Just (... (Just Nothing))...)? Я вот уверяю, что эта функция берет Maybe a и всегда возвращает Nothing. Докажи или опровергни :−)
Доказательство очень простое: единственная нерекурсивная ветка здесь — tnpo Nothing = Just Nothing.
Поэтому, если программа останавливается, то она останавливается на Just Nothing.
А проблема остановки решается очень просто: ставим хаскелл на Крэй-1 и ждём 6 секунд
RO>>tnpo (Just x) = Just (Just (Just (tnpo x)))
RO>>tnpo Nothing = Just Nothing
RO>>collatz x = collatz3 x x x
RO>>collatz3 x (Just y) (Just (Just z)) = collatz3 x y z
RO>>collatz3 x y Nothing = collatz y
RO>>collatz3 x y (Just Nothing) = collatz (tnpo x)
RO>>
К>Ты это сам придумал?!
Нет, конечно, пытался как-то сделать тип, соответствующий гипотезе «3n+1». Там еще не хватает collatz (Just Nothing) = Just Nothing, чем всё и должно завершаться. Теперь компилятор, чтобы вывести тип, должен доказать гипотезу или опровергнуть.
Здравствуйте, VladD2, Вы писали:
VD>Может. Информация о проектах. В исходнике банально может не хватать зависимостей.
А в сборку их святой дух записывает?
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
VD>>Может. Информация о проектах. В исходнике банально может не хватать зависимостей. WH>А в сборку их святой дух записывает?
Нет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>>>Может. Информация о проектах. В исходнике банально может не хватать зависимостей. WH>>А в сборку их святой дух записывает? VD>Нет.
Так откуда она берётся? Правильно. Из исходников.
Вот я и говорю что единственная разница между сборкой и исходниками это потребление ресурсов на машине пользователя.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
VD>>>>Может. Информация о проектах. В исходнике банально может не хватать зависимостей. WH>>>А в сборку их святой дух записывает? VD>>Нет. WH>Так откуда она берётся? Правильно. Из исходников.
Из файлов проектов, из метаинформации других сборок.
Исходники не несут всей информации. Не будет у тебя какого-то класса и как понять что это?
WH>Вот я и говорю что единственная разница между сборкой и исходниками это потребление ресурсов на машине пользователя.
Разница в полноценности. Имея сборку можно определить зависимости. С исходниками же все сложнее. Им нужны проекты, мекфайлы, правильное расположение на диске, внешние утилиты... В общем, все это сложно.
Плсю в сборку можно положить не только АСТ, но и код его обработки. А это уже совсем другой уровень, как ты понимаешь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Вот я и говорю что единственная разница между сборкой и исходниками это потребление ресурсов на машине пользователя.
Главная разница между исходниками и бинарниками в том, что в бинарнике все имена отресолвлены, типы выведены и весь синтаксический сахар развернут.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
WH>>Вот я и говорю что единственная разница между сборкой и исходниками это потребление ресурсов на машине пользователя.
AVK>Главная разница между исходниками и бинарниками в том, что в бинарнике все имена отресолвлены, типы выведены и весь синтаксический сахар развернут.
И что это даёт кроме того на что ты отвечаешь?
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
WH>>Так откуда она берётся? Правильно. Из исходников. VD>Из файлов проектов, из метаинформации других сборок.
Ну, так архивы с их исходниками лежат рядом.
VD>Исходники не несут всей информации. Не будет у тебя какого-то класса и как понять что это?
Ту таки святой дух работает?
VD>Разница в полноценности. Имея сборку можно определить зависимости. С исходниками же все сложнее. Им нужны проекты, мекфайлы, правильное расположение на диске, внешние утилиты... В общем, все это сложно.
Те нужна инфраструктура. Но она и сборкам нужна.
VD>Плсю в сборку можно положить не только АСТ, но и код его обработки. А это уже совсем другой уровень, как ты понимаешь.
Я даже не понял выделенное. Это о чём?
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>И что это даёт кроме того на что ты отвечаешь?
Гарантию отсутствия ошибок определенного рода. Я в свое время с питоном наелся подобного, когда скрипт где то внутри осыпается по непонятным причинам из-за того что где то что то неотресолвилось или отресолвилось неправильно.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Гарантию отсутствия ошибок определенного рода. Я в свое время с питоном наелся подобного, когда скрипт где то внутри осыпается по непонятным причинам из-за того что где то что то неотресолвилось или отресолвилось неправильно.
Мы же говорим про статическую типизацию? Так что питон тут вообще не причём.
А перед созданием архива исходники можно проверить.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, nikov, Вы писали:
N>Я всегда был убеждённым сторонником статической типизации. Но я регулярно сталкиваюсь с тем, что системы типов, хотя и помогают отлавливать многие ошибки, также отвергают вполне безопасный код (впрочем, это хорошо известный теоретический факт).
по моему опыту работы, если речь идёт о крупной программе, то основная система типизации должна быть статической. она позволит реализовать 99% потребностей и обнаруживать ошибки во время компиляции. а для оставшегося 1% нужна динамическая типизация, ну как минимум в виде типа Variant. ну и дальше уже — статическая типизация должна быть как можно более мощной (хаскел рулит) чтобы покрыть больше нужд, макропрограммирование может использоваться чтобы ещё больше расширить её возможности, а использование дин. типизации требует повышенного покрытия тестами
для небольших/исследовательских проектов (write-only) дин. типизация предпочтительней
что касается твоего конкретного примера, то в таком виде это лишь чуть больше писанины ради надёжности кода, а в каком-то более расширенном — кандидат на макросы. у меня например дин. типизация вылезает в основном при связи с dll-ками — поскольку они и основная программа могут развиваться независимо, набор поддерживаемых параметров, да и самих функций, могут немного отличаться. все остальные задачи в принципе решаемы кодогенерацией
Перекуём баги на фичи!
