Здравствуйте, Пётр Седов, Вы писали:
ПС>Да, можно обернуть LLVM в C-шный интерфейс и использовать LLVM через эту обёртку, но именно это я и называю «лишние сложности».
Это нормальная практика. Как раз ненормальная практика предоставлять АПИ к универсальным библиотекам на С++.
ПС>А если LLVM сгенерировал неправильный ассемблерный код и я хочу в отладчике пройтись по исходникам LLVM и посмотреть, что он там делает? С bootstrapping-ом так не получится, придётся усеивать код LLVM отладочными печатями (отладка в стиле printf), и это я тоже называю «лишние сложности».
Все получится. Скомпилруешь ствой С++-код в дебаг и отладишь соответствующим отладчиком. А учитывая, что бэкэнд у Ди и С++ один, то отладичик должен быть одним и тем же.
VD>>Вот только большинство серьезных языков таки бутсрапятся. В том числе С, С++,
ПС>С этими языками понятно: серьёзную программу имеет смысл писать на C/C++, в том числе если эта программа – компилятор C/C++.
А, ну, если "серьзную", тогда конечно. Вот только, извини, но это несерьезный разговор. Ты просто плохо знаешь другие языки. Компиляторы уж точно удобнее писать на языках поддерживающих ФП, а это как раз почти весь список приведенный мной за исключением как раз таки С и С++, ну, и Ява, конечно.
VD>>Ява, ОКамл, F#, Nemerle, Scala, Lisp.
ПС>А эти bootstrapping-овые компиляторы – оптимизирующие?
ОКамла — да. Лисп — это вообще динамический язык с аля JIT-компиляцией. У Лиспа имются нехилые оптимизирующие компиляторы. Языкам вроде Ява, F#, Nemerle и Scala реализовывать оптимизации на уровне фронтэнда смысла особого не имеет, так как они генерируют промежуточный код (байткод Явы для Ява и Scala и MSIL для F# и Nemerle. Однако почти все эти языки делают рад оптимизаций требуемый для ФП. Так они обязательно заменяют концевую рекурсию на циклы. В С++ это не гаранируется, хотя без этого о поддержке ФП можно говорить только с натяжкой.
К сведению, фронтэнд компилятора Ди так же не делает много оптимизаций, да и те что делает, делает скорее потому, что бэкэнды их не делают.
ПС>Если компилятор оптимизирующий, то он сложный, а значит больше вероятность ошибиться.
Сложные оптимизации обычно делают на уровне промежуточного кода. А это уже прераготива бэкэнда. Тут же речь идет о фронтэнде. Читайте теорию компиляторостроения
.
ПС> А искать ошибку, думаю, будет очень тяжело, учитывая несколько стадий bootstrapping-а (для получения оптимизирующего компилятора) и отсутствие среды разработки с интегрированным отладчиком.
1. Отсутствие IDE никак не связана с тем бутстрапится компилятор или нет. Скажем, для Немерле и С++ среды есть, хотя языки бутстрапятся, а для Ди полноценной среды нет, хотя она и на С++ пишется.
2. Я лично не раз искал ошибки в бутсрамном компиляторе. Никаких проблем с этим нет. Есть проблема связанная с тем, что скомпилровавшийся компилятор может не собрать сам сбея из исходников. Но для ее предотвращения испоьзуется простой прием. Вводится несколько стадий компиляции и если они все не прошли, то компилятор не заливается в систему храения версий, а если кто-то залил по недомыслию, то откатывается (или правится, если это можно сделать).
VD>>Delphi и C#, правда написаны на С++,
ПС>Насколько я знаю, компиляторы Delphi и C++ Builder имеют общий back-end (оптимизирующий).
Это не имеет никакого отношения к делу. Бэкэнд может быть любой. Скажем, тот же Delphi в качестве бэкэнда использует в том числе и дотнет.
ПС> Думаю, это одна из причин того, что компилятор Delphi написан на C++.
Нет. Причина была озвучина — Delphi было просто неудобно писать на Delphi. Первая версия как раз была написана на Обжект Паскле.
VD>>но команда C#, насколько мне известно, очень хотела бы переписать компилятор на C#, однако менеджеры не дают пока.
ПС>Если компилятор C# напишут на C#, то кому и какая от этого будет польза?
1. Польза будет самим разработчикам компилятора, так как его попросту будет проще правит и развивать.
2. Поьза будет пользователям, так как в компилятор можно будет очень просто встроить систему событий (как в современном компиляторе Явы) которая позволит делать некоторые приятные вещи вроде инструментирования кода, дополнительных проверок и т.п. Сейчас для подобной фичи прийдется писать море оберточного кода.
ПС>Будет ли новый компилятор быстрее старого?
Может и не будет. Главное чтобы особо медленее не был. Но это больше зависит не от того на чем написан компилятор, а от того как он написан.
ПС>Здесь почти согласен. Действительно, хочется писать на новом языке как можно скорее. Сомневаюсь только по поводу «быстрее». Что, компилятор, написанный на Java, будет быстрее чем компилятор, написанный на C++? И что, Java – более мощный язык, чем C++?
"Быстрее" — не значит, что компилятор будет быстрее. "Быстрее" значит, что сам компилятор будет получен быстрее, т.е. его будет быстрее писать.
Пример: Компиляторы Немерле и Скалы пишутся меньшее время чем компилятор Ди, но при сравнивом объеме реализуют больше более сложных фич.
ПС>Тестировать компилятор, по-моему, лучше не самим собой, а тестами.
Тесты тестами. Но они а) всегда будут сентетическими (далекими от реальной жизни), б) никогда не покроют 100% случаев использования. Так что тесты тестами, но наличие больших проектов всегда положительный фактор. В начале жизни языка его компилятор всегда будет евляеться самым большим и всегда живым проектом.
ПС>А то, что bootstrapping ограничивает свободу авторов языка – скорее минус, чем плюс.
Он не ограничивает свободу. Он ограничивает желание делать ломающие изменения. По факту, Немерле и Скала очень сильно обходят по фунциональности Ди, но ломающих изменений в них куда меньше.
ПС> Вряд ли можно заранее всё предусмотреть, поэтому в молодом языке скорее всего будет много ломающих изменений (у меня сложилось такое впечатление от книги Страуструпа «Дизайн и эволюция C++»).
1. Все нужно проектировать. Чем тщательнее это сделать, тем логичнее будет язык. Так что знание того, что ты бутстрапишся подстегивает к более грамотному проектированию. Отсуствие качественной стратегии — это главный бич Ди.
2. Все конечно не придусморишь, но это не повод ломать то что есть. Большинство новшеств можно вносить не меняя сам язык, арасширяя его. Опять же хорошо видно на Скала и Немерле.
ПС> Да и в немолодом языке иногда есть смысл сделать ломающее изменение.
Ага. Вот в С++ никак не могут решиться, хотя ой как нужно...
ПС> В C++ это были:
ПС>* Область видимости for-переменной (раньше до конца охватывающего блока, теперь в рамках for-а).
Это не правда. Фор был определен стандартом еще в 98-ом. Это ты путаешь С++ и его реализацию в MC VC. Стандарт не изменялся.
ПС>* Время жизни временных объектов (раньше до конца блока, теперь «до точки с запятой»). Правда, ломает только плохой код, например:
ПС>ПС>string GetName()
ПС>{
ПС> ...
ПС>}
ПС>void Load(...)
ПС>{
ПС> const char* pName = GetName().c_str();
ПС> ...
ПС>}
ПС>
ПС>* Неудачный new (раньше возвращал NULL, теперь бросает исключение).
Тут я ничего сказать не могу, но подозреваю, что речь опять же не о стандарте языка, а о его реализации в некотором компиляторе.
У С++ есть только один стандарт, появившийся в 98-ом, но принятый только в 91-вом (есл не ошибаюсь). Так что ломающих изменений тут и быть не могло пока что. Ну, разве что если говорить о жизни языка до стандарта. Там их было не мало. Но тем не мнее Страуструп переписал компилятор сам не себе же и не пожалел об этом.
ПС>По-моему, ломающие изменения в языке – не такая уж страшная вещь.
Для самого компилятора — нет, так как каждая версия языка учитывает их. А вот для софта написанного на нем — это геморой. Помнится когда VC приводили в соответствие со стандартом, я убил пару месяцев на то чтобы изменить свои проекты. И это еще мне нужно было очень... А многие тупо забивают на новую версию и живут на старой. В итоге получается, что код который ты нашел в Интернете нельзя скомпилировать на современной версии компилятора.
ПС>Boost – не компилятор, но разумное зерно в этих словах есть.
Наверно есть. К теме только отношения не имеет.
ПС>ПС>3. Работая над компилятором на создаваемом языке разработчики получают больше практики работы на этом язке и могут более адкеватно оценивать предложения по его изменению и вносить собственные предожения.
ПС>Чтобы получить серьёзный опыт программирования на новом языке необязательно использовать bootstrapping.
Не обязательно. Но работа над языком требует много времени, и писать еще один проекто чтобы попробовать свое творение оказывается слишком затратно. А тут ты и компилятор развивашь, и пишешь на новом языке. По любому опыта получается больше. Иначе язык получается слишком надуманным. Он делается не для себя, а для галочки.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Здравствуйте, VladD2, Вы писали:
VD> Однако почти все эти языки делают рад оптимизаций требуемый для ФП. Так они обязательно заменяют концевую рекурсию на циклы. В С++ это не гаранируется, хотя без этого о поддержке ФП можно говорить только с натяжкой.
Практически все современные C++ компиляторы заменяют хвостовую рекурсию. D тоже.
VD>К сведению, фронтэнд компилятора Ди так же не делает много оптимизаций, да и те что делает, делает скорее потому, что бэкэнды их не делают.
Судя по скорости работы программок скомпилированных g++ против gdc, D делает их или чуть лучше или чуть больше
Здравствуйте, FR, Вы писали:
VD>> Однако почти все эти языки делают рад оптимизаций требуемый для ФП. Так они обязательно заменяют концевую рекурсию на циклы. В С++ это не гаранируется, хотя без этого о поддержке ФП можно говорить только с натяжкой.
FR>Практически все современные C++ компиляторы заменяют хвостовую рекурсию. D тоже.
Почти не считается.
VD>>К сведению, фронтэнд компилятора Ди так же не делает много оптимизаций, да и те что делает, делает скорее потому, что бэкэнды их не делают.
FR>Судя по скорости работы программок скомпилированных g++ против gdc, D делает их или чуть лучше или чуть больше
Оптимизации делаются в основном бэкэндами. Ди использует те же бэкэнды. Так что не придумывай.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Здравствуйте, Andrei F., Вы писали:
AF>Именно оттуда это название и пошло, если кто не в курсе.
Мюнхаузен вроде не при чём:
to pull oneself up by one's bootstraps — (idiomatic) To begin an enterprise or recover from a setback without any outside help; to succeed only on one's own effort or abilities.
... << RSDN@Home 1.2.0 alpha rev. 726>>
Здравствуйте, Delight, Вы писали:
D>Мюнхаузен вроде не при чём:
D>to pull oneself up by one's bootstraps — (idiomatic) To begin an enterprise or recover from a setback without any outside help; to succeed only on one's own effort or abilities.
Это в русском переводе он себя вытаскивает за волосы, а в оригинале — за ремешки на обуви (bootstraps). Оттуда выражение и пошло.
PS
кстати, еще одно выражение с забавным происхождением — это little/big endian, в смысле — порядок следования байтов в слове. Так вот это выражение происходит из "приключений Гулливера" Свифта, там где были люди которые спорили, с какой стороны надо правильно разбивать яйцо (в русском переводе — остроконечники и тупоконечники)
На
сайте Андрея Александреску появилась информация, что он собирается в октябре 2008 года выпустить книгу "The D Programming Language":
Of possible interest:
Andrei is working on "The D Programming Language" book, slated to hit the shelves in October 2008. His interest in the D programming language stems from Andrei's active participation in the design of D 2.0 as a close collaborator of D's creator, Walter Bright.
Брайт говорит, что в ней будет описываться D2.0.
Поэтому появляется надежда, что к этому времени D 2.0 будет стабилизирован и не начнется работа над D 3.0, разрушающем совместимость с D 2.0 (как это произошло с D1).
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, eao197, Вы писали:
E>>Вот, что мне ответил Брайт по этому поводу:
>>> Could we expect that D 2.0 will be stable enough at Oct 2008 and there won't be new compatibility-breaking changes in the language?
E>>Yes.
Кё>Это «Yes, you can expect» или «Yes, it will be stable?» 
Или даже "Yes, there won't be new changes"
Брайт уже оговорился, что на горизонте маячит D 3.0 с поддержкой элементов функционального программирования, чтобы хорошо встретить приближающуюся многоядерность процессоров:
It's far too early to make plans, but I expect 3.0 would be a push to support functional programming and other things for multicore programming.
Появилась информация об уже написанной книге о D.
"Learning to Tango with D" By Kris Bell, Lars Ivar Igesund, Sean Kelly, Michael Parker
В этой книге описывается основной синтаксис, обьектно-ориентированный подход к разработке на D и библиотека Tango.
Пост на блоге Michael Parker
А
здесь книгу можно купить за $13.59.
