Здравствуйте, FR, Вы писали:

FR>Угу, но не важно, рантайм и стандартная библиотека (фобос) практически полностью написаны на D и именно авторами языка, их объема более чем достаточно для заявленных тобой целей.

Смеешься что ли? Какой на фиг у Ди рантайм? И что там за библиотеки?

FR>Для этого не обязательно писать именно компилятор, рантайм и стандартная библиотека ничем ни хуже.

Нет. Компилятор — это большой и сложный код. Библиотеки на их фоне просто игрушка. Они же не воспроизвели явские или дотнетные либы?

Здравствуйте, FR, Вы писали:

FR>Да практически все что немерл унаследовал от ML семейства.

Да, ну? Стало быть все что есть в МЛ пригодно только для написания компиляторов?
В курсе, что его разрабатывали как для создания теорем-пруверов?

Здравствуйте, BulatZiganshin, Вы писали:

BZ>ghc вроде целиком на хаскеле написан. на C там RTS

Ага, в результате его не установить по-человечески, если в системе уже нету ghc.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, VladD2, Вы писали:

VD>Смеешься что ли? Какой на фиг у Ди рантайм? И что там за библиотеки?

Вполне приличный, язык-то нативный под три платформы, рантайм сишный практически полностью включает плюс gc плюс
реализация исключений и базового объекта, реализация встроенных примитивов (массивов и т. п.), примитивы для
мультитрединга, RTTI, по объему в последней версии (2.053) такой:

c/cpp: files = 7  lines = 749  size = 16 kb. (17326 bytes)
asm: files = 1  lines = 85  size = 2 kb. (2662 bytes)
d: files = 166  lines = 65909  size = 1757 kb. (1799949 bytes)

global: files = 174  lines = 66743  size = 1777 kb. (1819937 bytes)

Библиотеки такие (содержание в левой части страницы, на самой странице рантайм) http://www.digitalmars.com/d/2.0/phobos/phobos.html

FR>>Для этого не обязательно писать именно компилятор, рантайм и стандартная библиотека ничем ни хуже.

VD>Нет. Компилятор — это большой и сложный код. Библиотеки на их фоне просто игрушка. Они же не воспроизвели явские или дотнетные либы?

Нет библиотеки у D я не назвал бы простыми, очень много кода с шаблонами и практически включают в себя и стандартные библиотеки
небольшого функционального языка, да и по объему вполне уже прилично:

c/cpp: files = 30  lines = 14684  size = 525 kb. (538365 bytes)
d: files = 109  lines = 152783  size = 4937 kb. (5055714 bytes)

global: files = 139  lines = 167467  size = 5462 kb. (5594079 bytes)

(сишные файлы там zlib в исходниках)

Компилятор кстати:

c/cpp: files = 217  lines = 215303  size = 6194 kb. (6343482 bytes)

global: files = 217  lines = 215303  size = 6194 kb. (6343482 bytes)

из них унаследованный backend:

c/cpp: files = 80  lines = 94803  size = 2853 kb. (2922336 bytes)

global: files = 80  lines = 94803  size = 2853 kb. (2922336 bytes)

Вполне сопоставимо по объему.

Здравствуйте, VladD2, Вы писали:

FR>>Да практически все что немерл унаследовал от ML семейства.

VD>Да, ну? Стало быть все что есть в МЛ пригодно только для написания компиляторов?

Не только, но для этого очень удобен.

VD>В курсе, что его разрабатывали как для создания теорем-пруверов?

Угу, но потом на нем (исключая частично OCaml) в основном или писали компиляторы — трансляторы
или использовали для обучения.

Здравствуйте, FR, Вы писали:

VD>>Да, ну? Стало быть все что есть в МЛ пригодно только для написания компиляторов?

FR>Не только, но для этого очень удобен.

Не находишь, что есть определенная разница между "для этого очень удобен" и "специализированная фича пригодная только этого"?

VD>>В курсе, что его разрабатывали как для создания теорем-пруверов?

FR>Угу, но потом на нем (исключая частично OCaml) в основном или писали компиляторы — трансляторы
FR>или использовали для обучения.

Видимо именно по этому на вики упоминается, что "also used in bioinformatics, financial systems, and applications including a genealogical database, a peer-to-peer client/server program, etc.".

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, desperado_gmbh, Вы писали:

_>>Компиляторы всех паскалей и 16-битного дельфи — целиком ассемблер. На самом паскале был написан IDE, да и то не весь.

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

Естественно, я говорил только про борландовские

VD>За Борлоновские реализации я не так уверен, но мне кажется, что где-то читал, что и Турбо Паскаль тоже бутстрапился.
VD>Так что хотелось бы увидеть пруфлинк.

К сожалению, дизассемблированные мной исходники шестого турбопаскаля накрылись вместе с диском несколько лет назад. Они время от времени всплывают на разных сайтах, но в принципе достаточно посмотреть на tpc.exe через дизассемблер. Нормальный рукописный код, ничего общего не имеющий ни с выдачей tpc, ни с выдачей tcc.

Здравствуйте, x-code, Вы писали:

XC>Потому что Си (а также С++, D, ObjC, Java, C#, Delphi и т.п.) — нормальные языки, понятные и удобные для реального, практического, старого доброго программирования.

Перефразирую: нормальные языки, понятные и удобные для старых добрых программистов для которых эти языки стали привычкой и реально, практически применяются по инерции

XC>А хаскели и прочее — это абстрактная околоматематическая сущность. Вроде матлаба или чего-то типа того. ИМХО, в большинстве случаев это даже не "языки программирования", а скорее средства компьютерного моделирования какой-то математической парадигмы или теории. По крайней мере, их разработчики точно не ставят целью создание языка, на котором можно писать к примеру ядра операционных систем или навороченные GUI приложения.

House — операционная система написанная на Хаскель

Здравствуйте, LaptevVV, Вы писали:

LVV>ВСЕ тексты доступны в среде — можно модифицировать, если сильно нужно.
Никогда не видел сырцов компилятора. VCL — да, конечно. Но даже сырцов системных юнитов (не говоря уже про компиль) никогда не видал. С какой версии у них такой сахар тростниковый пошёл?

Здравствуйте, Mr.Delphist, Вы писали:

MD>Здравствуйте, LaptevVV, Вы писали:

LVV>>ВСЕ тексты доступны в среде — можно модифицировать, если сильно нужно.
MD>Никогда не видел сырцов компилятора. VCL — да, конечно. Но даже сырцов системных юнитов (не говоря уже про компиль) никогда не видал. С какой версии у них такой сахар тростниковый пошёл?
Не знаю. Я пользуюсь BB1.5 — там все есть, не только компилятор. Тексты самой среды и всего-всего, что в среде сделано и работает.
Предрелиз сейчас 1.6. А исходники открыли наверное тогда, когда сделали BlackBox свободным — это я и не знаю с какой версии...
На форуме oberoncore.ru могут подробно ответить

Здравствуйте, Mr.Delphist, Вы писали:

LVV>>ВСЕ тексты доступны в среде — можно модифицировать, если сильно нужно.
MD>Никогда не видел сырцов компилятора. VCL — да, конечно. Но даже сырцов системных юнитов (не говоря уже про компиль) никогда не видал. С какой версии у них такой сахар тростниковый пошёл?

Ты похоже про Дельфи а твой оппонент про BlackBox
А в Делфи системные юниты и RTL сейчас доступны в исходниках компилятор нет.

Здравствуйте, anokata, Вы писали:

A>Меня всегда удивляет почему многие компиляторы/интерпретаторы языков программирования (и среды для них и софт) написаны на С, С++ , а не на них самих. Почем так редко применяют раскрутку компилятора? или я неправо? К тому же там где применяют не редко остаётся ядро на С.

Очень много проверенных временем тулов (свободных, коммерческих, внутренних и т.д) для создания компиляторов, которые написаны на С/C++ и генерят код на C/C++. Потому удобней взять готовые инструменты а не писать свои.

Здравствуйте, _Obelisk_, Вы писали:

_O_>Очень много проверенных временем тулов (свободных, коммерческих, внутренних и т.д) для создания компиляторов, которые написаны на С/C++ и генерят код на C/C++. Потому удобней взять готовые инструменты а не писать свои.
Они все настолько убоги, что на них даже смотреть противно.
Не то, что пользоваться.

Здравствуйте, WolfHound, Вы писали:

_O_>>Очень много проверенных временем тулов (свободных, коммерческих, внутренних и т.д) для создания компиляторов, которые написаны на С/C++ и генерят код на C/C++. Потому удобней взять готовые инструменты а не писать свои.
WH>Они все настолько убоги, что на них даже смотреть противно.
WH>Не то, что пользоваться.

Правильно. Как только начинаешь писать такое на С++, говнокод подавить при всем желании не получится и нужно приседать вокруг крутого языка С/C++.

VD>Компилятор — это такая же программа как и все другие. Если ее удобно писать, то будет удобно писать и многие другие программы.

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

а большинство программ работают по другому:
они стартуют,
получают в произвольном порядке события,
в произвольном порядке меняют свое внутреннее состояние,
в произвольном порядке выдают события наружу,
и часто могут вообще никогда не завершаться (по крайней мере логически).
и если компилятор — это функция, то такая программа — скорее агент (или в упрощенном виде — объект).

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

Здравствуйте, DarkGray, Вы писали:

VD>>Компилятор — это такая же программа как и все другие. Если ее удобно писать, то будет удобно писать и многие другие программы.

DG>сам по себе компилятор — это очень узкий класс задач.

Этот класс задач можно назвать так — "трансформация данных". И узок он примерно так же как талия бегемота.

DG>по сути компилятор — это одна большая функция, которая получает один пакет на вход, потом долго жужжит и выдает один пакет на выход, завершаясь.

По сути любая программа это одна большая (или не очень) функция. И что из того?

DG>а большинство программ работают по другому:
DG>они стартуют, получают в произвольном порядке события, в произвольном порядке меняют свое внутреннее состояние, в произвольном порядке выдают события наружу, и часто могут вообще никогда не завершаться (по крайней мере логически).

Ну, то есть они состоят из ряда маленьких функций которая получает один пакет на вход, потом жужжит и выдает один пакет на выход? Огромные различия с точки зрения используемых возможностей ЯП.

Потом твои знания о современных компиляторах сильно устарели. На сегодня компиляторы стали на много сложнее. Их код используется в IDE, средствах тестирования и т.п. Да и сами они умеют компилировать инкременально, параллельно и т.п.

DG>и если компилятор — это функция, то такая программа — скорее агент (или в упрощенном виде — объект).

Сегодня трудно представить программу которую можно представить в виде одной функции. Любая программа — это куча разнородного кода. Мне смешно объяснять взрослому человеку, что компилятор тут ничем не отличается. В современном компиляторе нет разве что GUI. Хотя в GUI их код так же используется.

Вот Вольвхаунд предлагает использовать в следующей версии немерла реактивный подход. Его в GUI на сегодня мало кто применяет, а ты говоришь "одна функция".

DG>и соответственно если язык обкатывался на описании компилятора, то легко могут быть упущены такие направления как:
DG>обработка и генерация событий,

Это какая-то редкостная ересь. Сообщением является любой вызов функции. Что тут обкатывать? То что в языки проектировавшиеся императивщиками вроде Хельсберга гвоздями прибили события и делегаты еще не значит, что это так и надо. В языках ML-ного ряда исходно были функции высшего порядка. Они решают те же проблемы играючи и применяются в куче мест. Одна беда их событиями не называют. Но в чем разрица между списком функций и событиями дотнета? Три грамма никому не нужного синтаксического сахара — вот и вся разница.

Надеюсь, ты не будешь спорить по поводу того, что в любом ФЯ работа с ФВП продумана и оттестирована до блеска?

Потом современный компилятор — это тебе не компилятор Паскаля времен Вирта. Это в нем теперь используются и события и все остальное, что есть в арсенале ЯП. В прочем, я уже повтояюсь.

DG>описание изменчивого внутреннего состояния,
DG>недетерминированный характер работы программы
DG>и т.п.

Любая программа имеет свое состояние которое изменяется во времени. Вопрос только в том как оно хранится. Компиляторы тут ничем не отличаются.

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

VD>Ну, то есть они состоят из ряда маленьких функций которая получает один пакет на вход, потом жужжит и выдает один пакет на выход? Огромные различия с точки зрения используемых возможностей ЯП.

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

Здравствуйте, DarkGray, Вы писали:

VD>>Ну, то есть они состоят из ряда маленьких функций которая получает один пакет на вход, потом жужжит и выдает один пакет на выход? Огромные различия с точки зрения используемых возможностей ЯП.

DG>если программа — это одна функция из миллиона операций, то, в первую очередь, нужен инструмент который упрощает работу с операциями, но если программа миллион функций по одной операции, то, в первую очередь, нужен инструмент который упрощает работу с набором функций и мало критичен инструмент для работы с операциями.

Не бывает работающих программ состоящих из одной функции. Любая "большая функция" состоит из множества вызовов функций по меньше. И совершенно по барабану кто и как вызывает эти функции. Сложность в их количестве, точнее в интеллектуальной сложности задачи.

Инструменты для борьбы с миллионом операций и с миллионом функций одни и те же — это средства инкапсуляции. Чем они мощнее, тем более сложные задачи можно решать с помощью языка.

Здравствуйте, VladD2, Вы писали:

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

Например, val/var.

Здравствуйте, DarkGray, Вы писали:

DG>а большинство программ работают по другому:
DG>они стартуют,
DG>получают в произвольном порядке события,
DG>в произвольном порядке меняют свое внутреннее состояние,
DG>в произвольном порядке выдают события наружу,
DG>и часто могут вообще никогда не завершаться (по крайней мере логически).

Недавно кто-то кидал ссылку на подборочку видео с конференции Scala Exchange 2011. На одном из них Одерски рассказывал про новый Eclipse plugin и какие изменения в логике компилятора были сделаны для его поддержки. Так вот, ты не поверишь...