>На эстетов не угодишь.

А то! Мы люди нежные, нам всё нормальные языки подавай, где не рискуешь в 20 лет угодить в психушку из-за забытой точки с запятой. ;)

Пока за 10 лет выйдет новый стадарт ваш брат битонщик уже фаломорфирует от числа высеров своего гуру.

Вот братом битонщика меня ещё на лоре не обзывали.

У нас всё ок

Отстаёте в развитии лет на 30, а так --- всё нормально.

А в твоем ПТУ говорили, что она нормальная?

Попытайся обосновать обратное.

Ох уж эти сказки, ох уж эти сказочники.

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

не вижу проблемы в operator=( const std::string& )

и, соотвествтенно в operator std::string (void)

Ну, типа ура. Жду полную поддержку (особенно регулярных выражений) в GCC.

где их можно почитать?

Да многих нежных эстетов погубил C++. Но уж столько мне нервов похерил питон. Поколения битонщиков будут пахать для компенсации.

> Я не только читаю, но еще и цитирую вас :)

Копипаст и бот умеет.

Что рак легких, что смерть от оргаз.....

Сумма, главное сумма.

Для этого вашего 0.(0)9 надо этот GC обслужить, запустить, знать когда его вытошнит на поработать и прочие сопутствующие прелести. И всё впустую.

> Все мы за еду работаем. Кто-то за шаурму, кто-то за ведро икры, но сути-то это ведь не меняет, так?

гы-гы

отнюдь не все :-)

я работаю только тогда мне это интересно, и потому, что мне это интересно, а денег на шаурму у меня и без работы хватит на неограниченное время (но, правда, не на ведро икры)

это, впрочем, не означает, что усилия не нужны

вот кстати тут есть табличка с мотивацией программеров http://www.it4business.ru/lib/2052/

Давно было, не помню. То ли в дискуссиях о BitC, то ли в какой-то статье о применении параметризованных модулей Ocaml.

Но претензия была вполне очевидная - при модификации программ с тотальным Хиндли-Милнером ошибки могут вылезать в неожиданных (и далеких от точки модификации) местах, поэтому область применения вывода типов неплохо бы ограничивать, например, границами модуля.

что-то тебя не туда понесло, в C++ есть константа в виде NULL, добавят еще одну, которая будет иметь тоже значение, но тип pointer, а не int, причем тут рантайм, «при некоторых условиях становится специальной» и пр.?

Да всё туда. Null-pointer - это не то же самое, что и (void*)0. Это ты что-то прикопался на ровном месте.

> не вижу проблемы в operator=( const std::string& )

потому-что не видишь задачу целиком, где будет определен «operator=»? как и что он будет дергать? в результате все получится громоздко и медленно

> Но уж столько мне нервов похерил питон.

Нежные эстеты в треде!1

Поколения битонщиков будут пахать для компенсации.

Помечтай.

> Да всё туда. Null-pointer - это не то же самое, что и (void*)0

а true - это не то же самое, что и 1, но в том же С99 так заявлено, так и в C++ невалидный поинтер равен 0, не нравятся константы, значение которых определено стандартом?

Это ты что-то прикопался на ровном месте.

как скажешь

>> А в твоем ПТУ говорили, что она нормальная?

Попытайся обосновать обратное.

Приводились яркие примеры от самих же хаскеляторов здесь на ЛОРе, уже тыщу раз. То компилятор выдает ошибку за тридевять земель он фактического места возникновения и выплевывает тебе килограмм текста с клеветой «мол так и так, типы у тебя парниша не совпадают», а ты - ими вообще не заморачивался при написании и знать не знаешь, о чем он там щебечет. То системы типов внезапно не хватает, то изменяемых типов данных захотелось побольше, да с ООП!!! Только расчехлил ООП-дополнятор, не успел оглянуться - а ноги уже подгорают на костре...

----

В подтверждение своих слов могу только процитировать Саймона Пейтона Джонса - одного из, если не основного разраба Haskell: «Вывод типов основывается на тщательно составленном наборе правил, которые удостоверяют, что вы находитесь в рамках того, что устройство вывода типов может понять. Если же программу преобразовывать из одного вида в другой на уровне исходного кода, то, возможно, вы выйдете за эти границы. Вывод типов не позволяет сделать это и потому не годится для оптимизации. Оптимизатор не должен беспокоиться о том, не вышли ли вы за границы вывода типов.

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

Пейтон-Джонс: Правильно. Такова природа систем со статической типизацией – и вот почему динамические языки по-прежнему важны и интересны. Можно написать программы, для которых не установить конкретную систему типизации, но которые не дают сбоев при выполнении. Это и есть золотой стандарт – нет аварийных сбоев, не добавляются целые числа к символам. Это будут отличные программы.»

----

"...Но в GHC, нашем компиляторе для Haskell, важно то, что в нем применен промежуточный язык с типизацией.

Сейбел: А в этом языке применена типизация исходного языка?

Пейтон-Джонс: Да, но в гораздо более явном виде. В оригинале широко применяется вывод типов – исходный язык подогнан под эту возможность. В промежуточном языке применена более общая система типизации, более явная и потому более выразительная: у каждого аргумента функции есть свой тип. Нет вывода типов, есть контроль типов."

> там, где надо было явно кастить NULL

Это где? Никогда не кастил, и даже ворнингов по этому поводу не встречал.

> Это где?

например два метода с одним именем - один получает индекс, второй указатель

Идею понял, спасибо.

> Для этого вашего 0.(0)9 надо этот GC обслужить, запустить, знать когда его вытошнит на поработать и прочие сопутствующие прелести. И всё впустую.

Тебя кто-то заставляет использовать GC там, где требуется высокая степень оптимизации производительности и гарантированный отклик? Хотя, на сколько я знаю, уже есть наработки в области RTGC

Вы бы c++0x нашли бы в педивикии и на дату посмотрели бы. Именно поэтому все плачут от облегчения, что вышло наконец-то!

Ну, значит, фигово работают, коли эти свойства появилась в D давным-давно. Значит, правильно Александреску свалил с C++.

GC намного старше всяких новомодных язычков вроде C и C++.

> Ну, значит, фигово работают, коли эти свойства появилась в D давным-давно

даже больше, в D уже успели сделать аж две версии языка

Что-то мне подсказывает, что ты тупой, а вызов функции может быть виртуальным.

Забавно, месяц назад, отслеживая новинки западной литературы по программированию и сопутствующим темам, удивлялся спаду интереса авторов к плюсам. А они выжидали, видать. Вот пожалуй только дятлы выдали недавно очередную толстенную книженцию и видеокурс, но им не привыкать строгать эдишены.

Complete type inference is known to be undecidable for higher-rank (impredicative) type systems,

Сам ты лишний, лошара. Без goto C не нужен.

названия езыка понравилось

типа пыщь пыщь C++11!!!один111!один

Сколько завистников в треде. Значит язык ещё годный.

типа пыщь пыщь C++11!!!один111!один

Неправильное название, кстати. Нужно C+=11.

Закопайте уже эти «грабли++»!

C#-капец?

Му-ха-ха-ха!!!! :))))) Это всё равно, что приклеить к запору спойлер и кричать: «Всё, мерсы разорятся?».

C# настолько очистился от синтаксического шлака «сипипей», концептуально выровнялся и развился, что костыли++ не просто позади, а тупо колыхающийся и воняющий труп страуса.
Писать на сипипях - это не просто «профессиональная деятельность», а целый дзен с погружением в метанирование идеями сипипей, не имеющими ничего общего вообще с концепцией ООП. Вопрос: зачем издеваться над трупом? Вам D нехватает??

С+100500 ?

>Вам D нехватает??

А он разве существует где-то кроме мокрых фантазий его создателей?

В стиле нового стандарта, скорее надо назвать C++<[]()<>>{&&}. И расписать каждую подконструкцию. Или не надо, всё же и так интуитивно ясно, а питон, конечно, изобрели придурки со своим бейсико-образным синтаксисом. Вот перл - это язык! вот к чему должен стремится настоящий C++<[]()<>>{&&}!

>C++ не нужен

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

Ну теперь с такими нововведениями C# не нужен?

Ну и где тебе нужен этот higher-rank? Даже rank-2 (который decidable) практически нигде не применяется, а уж придумать осмысленный rank-3 тип - это уже вообще нетривиальная задача.

В стиле нового стандарта, скорее надо назвать C++<[]()<>>{&&}. И расписать каждую подконструкцию. Или не надо, всё же и так интуитивно ясно, а питон, конечно, изобрели придурки со своим бейсико-образным синтаксисом. Вот перл - это язык! вот к чему должен стремится настоящий C++<[]()<>>{&&}!

Сегдня я узнал, что играю на стороне придурков. спасибо вам, дорогой посетитель ЛОРа! ;))

Winston. P. and Horn. B. 1989. Lisp. Third Edition. Reading, MA: Addison-Wesley, p.510. : «Алгоритмы, используемые в языке CLOS, сложны, и даже кудесники программирования стараются не вникать в их детали»

Похоже ЦПП решил переплюнуть ЦЛОС таки переплюнуть. Оно и верно, давно пора... ;)

Анекдот: Что произойдет с рыбой после ночи с китом? Ответ: приплюснутая камбала. :p

И не включается никогда. Зачем поганить годный инструмент когда сейчас этих языков с GC и так как говна за баней.

> Что произойдет с рыбой после ночи с китом?

часть уже есть в c++ - unicode, alignof, анонимные структуры, static asserts, часть будет на уровне libstdc, т.е. автоматом «приплюсуется», конечно не все так гладко, но C1X еще в разработке, так что гадать рано

Ну и где тебе нужен этот higher-rank? Даже rank-2 (который decidable) практически нигде не применяется, а уж придумать осмысленный rank-3 тип - это уже вообще нетривиальная задача.

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

в Practical type inference for arbitrary-rank types дается пример rank-3

type MapT = forall a b. (a->b) -> Term a -> Term b
fixMT :: (MapT -> MapT) -> MapT
fixMT f = f (fixMT f)
mapT :: MapT
mapT = fixMT (\mt -> \f t ->
              case t of
                Var x     -> Var (f x)
                App t1 t2 -> App (mt f t1) (mt f t2)
                Lam t     -> Lam (mt (mapI f) t))

но вопрос понятно глубже

Алгоритм Хиндли-Милнера не заменяет мозг и всяким инструментом нужно уметь пользоваться. Сюрприз?

более глубокий слой:

одна из важный особенностей хорошего языка — это универсальная применимость базовых средств

как минимум, надо избавить прогера от мучительных раздумий «это компилятор не справляется с выводом типов или я чего неправильно написал», причем такого рода раздумья особенно недопустимы в том, в необходимости чего программисты не убеждены — т.е. в борьбе против системы типов и компилятора

хотя возможен и вариант 2

>Сколько завистников в треде.

В плюсах есть что-то, что может вызвать зависть? o_O

вариант 2 — это не ошибка вида «я тут попытался вывести типы, но не смог» (охренеть как информативно), а ошибка вида «тут *действительно* не вывести типы, и *вот здесь* нужна аннотация»

правда, программист не особо будет верить тому, что «*действительно*», и придется реализововывать в компиляторе поиск этого «*вот здесь*», что, по-моему, сложнее для разработчика компилятора, чем универсальный алгоритм, работающий всегда

Ну да, пример интересный. Однако, я очень-очень сомневаюсь, что подобное может понадобиться писать на практике. А если и понадобится - то предельно редко. То есть неразрешимость тайпинференса для rank-n - всяко не аргумент в пользу того, что Хиндли-Милнер не нужен. Он, конечно, не нужен, но по другим причинам (которые уже были упомянуты выше).

Да, точно. Правда, никто не мешает мне и в старом стандарте сделать #define nullPtr (void*)0