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

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

E>>Отсутствие final делает ситуацию с константностью несколько проще. Хотя транзитивность invariant и const -- это очень сомнительное решение, имхо.

FR>Не понял final для переменных совсем уберут?
FR>Сейчас в 2.008 без проблем проходит final x = 0;

Вот, что по этому поводу Вальтер говорил в digitalmars.D:

>> 1) no more final for variables
>
> Is the keyword in this context now a syntax error?

It's just ignored.

FR>Кстати тот же фобос все еще нужно много доводить, константность ладно, но много функций которые можно было бы сделать compile time, таковыми не являются (особенно раздражает модуль string)

Да было бы вообще здорово Tango и Phobos таки объеденить. Все равно щас оба на dsource.org хостятся.

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


FR>>Не понял final для переменных совсем уберут?
FR>>Сейчас в 2.008 без проблем проходит final x = 0;

E>Вот, что по этому поводу Вальтер говорил в digitalmars.D:

Разобрался, он игнорируется, то есть объявление final x = 0; эквивалентно auto x = 0;
В общем с константностью явно перемудрили, и вообще Андрей плохо влияет на Вальтера

FR>>Кстати тот же фобос все еще нужно много доводить, константность ладно, но много функций которые можно было бы сделать compile time, таковыми не являются (особенно раздражает модуль string)

E>Да было бы вообще здорово Tango и Phobos таки объеденить. Все равно щас оба на dsource.org хостятся.

Угу.

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

FR>В общем с константностью явно перемудрили, и вообще Андрей плохо влияет на Вальтера

С константностью перемудрили -- это точно. Осталось бы им еще от транзитивности константности отказаться.

На счет влияния Андрея -- не так все однозначно. Я так понимаю, что из-за подключения Александреску к разработке Phobos-а Phobos таки выполз на dsource.org.

А так же в подачи Александреску в D 2.008 добавлена такая штука, как typeof(return), которая должна облегчать написание обобщенных функций/методов.

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

E>Можно ли списочек разработанных тобой компиляторов универсальных языков программирования? Именно разработанных, с нуля.

Кто бы говорил. (с)

R#. Вот еще над Немерле работаю. Ранее не раз писал интерпретаторы и т.п. Но методом бутстрапинга были сделаны только R# и Nemerle.

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

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

FR>Я вот вообще не понимаю почему ты придаешь такое значение этому вопросу.

Я уже не раз говорил об этом. Это не очевидно только для тех кто не хочет напрячся и понять это. В прочем, возможно многие не способны оценить то, что сами не пробовали.
Повторяюсь еще раз. Приемущуства следующие:
1. Компилятор лучше разрабатывать на более мощьном языке. При этом он получается более компактным, более понятным и банально быстрее. Исходя из этого глупо не использовать приемущества создаваемого языка.
2. Компилятор сам по себе огромный продукт. Компилируя его новой версией компилятора разработчики вынужденно тестируют сам компилятор. Кроме того у разработчиков намного реже возникает желание внести ломающие изменения, так как это приведет к изменению кода компилятора, а из самого кода компилятора можно узнать о наличии таких изменений.
3. Работая над компилятором на создаваемом языке разработчики получают больше практики работы на этом язке и могут более адкеватно оценивать предложения по его изменению и вносить собственные предожения.

FR> В общем то практически для любого языка можно написать такой компилятор.

В общем, нет. Точнее создать то можно, но если язык исходно не был предназначен для компиляции, то результат по любому будет хреновенький. Эрланг и Питон тому доказательство.
Но тут даже вопрос не в этом. Тут вопрос на чем его создавать. Но об этом я уже сказал (в 101-ый раз).

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

VD>R#.

Это компилятор? Он же генерит исходники C#.
Компиляторы D генерят нативный код, да еще и с оптимизацией.

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

VD>Не ясно зачем мне работать над компиляторами с нуля, чтобы понять приемущества и недостатки бустрапинга.

Может быть почуствовал бы тогда что к чему.

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

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

FR>>Я вот вообще не понимаю почему ты придаешь такое значение этому вопросу.

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

Я думаю у тебя под влиянием функциональщины сильно ослабла способность адекватно оценивать собеседников
Думаю большинство твоих собеседников здесь все неплохо понимают. Но все таки отличают детали реализации от принципиальных вопросов.

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


E>Это компилятор? Он же генерит исходники C#.

К твоему сведению. Компилятор — это утилита преобразующая один язык в другой. Так компилятор C# и Nemerle преобразуют свои языки в MSIL (точнее в вызовы его АПИ).
Компилятор R# преобразовывает R# в C#.
Здесь главное, что R# использовал себя для собственной генерации.

E>Компиляторы D генерят нативный код, да еще и с оптимизацией.

Вообще-то он это не делает. Он обращается к АПИ бэк-энда который уже что-там делает.
Но это не важно. Машинный код такой же язык как и другие. Суть компилятора от этого не исчезает.

E>Так что по R# ты судишь далеко не о всех проблемах, с которыми сталкиваются разработчики компиляторов (особенно тех, кто генерирует нативный код для нескольких платформ).

Перечисли, плиз, те проблемы о которых мне не известно.

VD>>Не ясно зачем мне работать над компиляторами с нуля, чтобы понять приемущества и недостатки бустрапинга.

E>Может быть почуствовал бы тогда что к чему.

А может быть и нет. Это разговор на уровене... эээ... на весьма странном уровне.

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

FR>Я думаю у тебя под влиянием функциональщины сильно ослабла способность адекватно оценивать собеседников

Все может быть.

FR>Думаю большинство твоих собеседников здесь все неплохо понимают. Но все таки отличают детали реализации от принципиальных вопросов.

Вот в этом далеко не уверен.

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

E>>Это компилятор? Он же генерит исходники C#.

VD>К твоему сведению. Компилятор — это утилита преобразующая один язык в другой. Так компилятор C# и Nemerle преобразуют свои языки в MSIL (точнее в вызовы его АПИ).
VD>Компилятор R# преобразовывает R# в C#.
VD>Здесь главное, что R# использовал себя для собственной генерации.

Ну если подходить к определению понятий, то:

The most common reason for wanting to translate source code is to create an executable program. The name "compiler" is primarily used for programs that translate source code from a high-level programming language to a lower level language (e.g., assembly language or machine language). A program that translates from a low level language to a higher level one is a decompiler. A program that translates between high-level languages is usually called a language translator, source to source translator, or language converter. A language rewriter is usually a program that translates the form of expressions without a change of language.

R# в большей степени language translator, чем compiler.
В отличии от того же DMD или GDC.

E>>Компиляторы D генерят нативный код, да еще и с оптимизацией.

VD>Вообще-то он это не делает. Он обращается к АПИ бэк-энда который уже что-там делает.

А удобство интеграции с back-end API -- это как, фигня?

VD>Но это не важно. Машинный код такой же язык как и другие. Суть компилятора от этого не исчезает.

Ну уж, а разные формы оптимизации для разных типов апаратных архитектур?

E>>Так что по R# ты судишь далеко не о всех проблемах, с которыми сталкиваются разработчики компиляторов (особенно тех, кто генерирует нативный код для нескольких платформ).

VD>Перечисли, плиз, те проблемы о которых мне не известно.

Оптимизация кода.
Генерация кода для отладочного режима с отладочной информацией и разные форматы объектных файлов в разных системах.

VD>>>Не ясно зачем мне работать над компиляторами с нуля, чтобы понять приемущества и недостатки бустрапинга.

E>>Может быть почуствовал бы тогда что к чему.

VD>А может быть и нет. Это разговор на уровене... эээ... на весьма странном уровне.

Тем не менее, ты позволяешь себе смеятся над словами человека, который проделывал в своем компиляторе гораздо больше работы, чем ты себе можешь вообразить.

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

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

FR>>Я думаю у тебя под влиянием функциональщины сильно ослабла способность адекватно оценивать собеседников

VD>Все может быть.

Я вот лечусь большими порциями корявого кода на C++

FR>>Думаю большинство твоих собеседников здесь все неплохо понимают. Но все таки отличают детали реализации от принципиальных вопросов.

VD>Вот в этом далеко не уверен.

Так большинство спорных вопросов сильно субъективны, так что все зависит от точки зрения.

Здравствуйте, VladD2, Вы писали:
VD>Еще интересно, что он отвечат на вопрос "Почему же все же Ди не написан на Ди?".
Насколько я понимаю, bootstrapping (в русскоязычной книге дракона – раскрутка) использовали в стародавние времена, когда просто выбора другого не было (например, из-за отсутствия Internet-а). Сейчас, по-моему, bootstrapping приносит мало пользы, зато добавляет лишние сложности. Например, я пишу компилятор и хочу использовать C++-библиотеку LLVM (low-level virtual machine) в качестве back-end-а, а там классы и STL. Если я пишу компилятор на C++, то нет проблем. А если bootstrapping, то что делать?
И ещё bootstrapping напоминает мне барона Мюнхгаузена, который сам себя за волосы вытащил из болота .

__>>А как же Tango?

E>А фиг его знает. Насколько я помню, после D Conference команда Tango обсуждала вопросы объединения Tango и Phobos для того, чтобы уйти от ситуации наличия двух "стандарных" библиотек. Но какого-то кардинального решения об отказе от какой из библиотек или об их слиянии достигнуто не было. Так что здесь вообще не понятно, что будет.

Существует экспериментальная ветка Tango, постепенно становящаяся совместимой с Phobos. А Runtime Phobos'а в D2 получает багфиксы из Tango.
Вполне возможно, что было достигнуто соглашение о слиянии библиотек, но никто об этом не знает.

Здравствуйте, Пётр Седов, Вы писали:

ПС>Насколько я понимаю, bootstrapping (в русскоязычной книге дракона – раскрутка) использовали в стародавние времена, когда просто выбора другого не было (например, из-за отсутствия Internet-а). Сейчас, по-моему, bootstrapping приносит мало пользы, зато добавляет лишние сложности.

Это чистой воды заблуждение.

ПС> Например, я пишу компилятор и хочу использовать C++-библиотеку LLVM (low-level virtual machine) в качестве back-end-а, а там классы и STL. Если я пишу компилятор на C++, то нет проблем. А если bootstrapping, то что делать?

Я не знаком с LLVM, но не думаю, что для нет возможностей взаимодействовать с этим делом из других языков. Там есть свой низкоуровневый язык, и как минимум, всегда можно написать АПИ для записи программ на этом языкп с последующей генерацией машинного кода.

ПС>И ещё bootstrapping напоминает мне барона Мюнхгаузена, который сам себя за волосы вытащил из болота .

Тебе конечно виднее. Вот только большинство серьезных языков таки бутсрапятся. В том числе С, С++, Ява, ОКамл, F#, Nemerle, Scala, Lisp. Delphi и C#, правда написаны на С++, но команда C#, насколько мне известно, очень хотела бы переписать компилятор на C#, однако менеджеры не дают пока.

Насколько я понимаю ты об этом судишь чисто теоритически. Или ты пробовал сам писать битстрап-компиляторы?

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

VD>Тебе конечно виднее. Вот только большинство серьезных языков таки бутсрапятся. В том числе С, С++, Ява, ОКамл, F#, Nemerle, Scala, Lisp. Delphi и C#, правда написаны на С++, но команда C#, насколько мне известно, очень хотела бы переписать компилятор на C#, однако менеджеры не дают пока.

Ты самый бустраписты язык упустил Forth

VD>Насколько я понимаю ты об этом судишь чисто теоритически. Или ты пробовал сам писать битстрап-компиляторы?

Я кстати писал, а ты?

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

VD>Я не знаком с LLVM, но не думаю, что для нет возможностей взаимодействовать с этим делом из других языков. Там есть свой низкоуровневый язык, и как минимум, всегда можно написать АПИ для записи программ на этом языкп с последующей генерацией машинного кода.
Да, можно обернуть LLVM в C-шный интерфейс и использовать LLVM через эту обёртку, но именно это я и называю «лишние сложности».
А если LLVM сгенерировал неправильный ассемблерный код и я хочу в отладчике пройтись по исходникам LLVM и посмотреть, что он там делает? С bootstrapping-ом так не получится, придётся усеивать код LLVM отладочными печатями (отладка в стиле printf), и это я тоже называю «лишние сложности».

VD>Вот только большинство серьезных языков таки бутсрапятся. В том числе С, С++,
С этими языками понятно: серьёзную программу имеет смысл писать на C/C++, в том числе если эта программа – компилятор C/C++.

VD>Ява, ОКамл, F#, Nemerle, Scala, Lisp.
А эти bootstrapping-овые компиляторы – оптимизирующие? Если компилятор оптимизирующий, то он сложный, а значит больше вероятность ошибиться. А искать ошибку, думаю, будет очень тяжело, учитывая несколько стадий bootstrapping-а (для получения оптимизирующего компилятора) и отсутствие среды разработки с интегрированным отладчиком.

VD>Delphi и C#, правда написаны на С++,
Насколько я знаю, компиляторы Delphi и C++ Builder имеют общий back-end (оптимизирующий). Думаю, это одна из причин того, что компилятор Delphi написан на C++.

VD>но команда C#, насколько мне известно, очень хотела бы переписать компилятор на C#, однако менеджеры не дают пока.
Если компилятор C# напишут на C#, то кому и какая от этого будет польза? Будет ли новый компилятор быстрее старого?

VD>Насколько я понимаю ты об этом судишь чисто теоритически. Или ты пробовал сам писать битстрап-компиляторы?
Я не писал серьёзных компиляторов, тем более с помощью bootstrapping-а.

Ваши аргументы

Автор: VladD2
Дата: 29.11.07

за bootstrapping:

1. Компилятор лучше разрабатывать на более мощьном языке. При этом он получается более компактным, более понятным и банально быстрее. Исходя из этого глупо не использовать приемущества создаваемого языка.

Здесь почти согласен. Действительно, хочется писать на новом языке как можно скорее. Сомневаюсь только по поводу «быстрее». Что, компилятор, написанный на Java, будет быстрее чем компилятор, написанный на C++? И что, Java – более мощный язык, чем C++?

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

Тестировать компилятор, по-моему, лучше не самим собой, а тестами. А то, что bootstrapping ограничивает свободу авторов языка – скорее минус, чем плюс. Вряд ли можно заранее всё предусмотреть, поэтому в молодом языке скорее всего будет много ломающих изменений (у меня сложилось такое впечатление от книги Страуструпа «Дизайн и эволюция C++»). Да и в немолодом языке иногда есть смысл сделать ломающее изменение. В C++ это были:
* Область видимости for-переменной (раньше до конца охватывающего блока, теперь в рамках for-а).
* Время жизни временных объектов (раньше до конца блока, теперь «до точки с запятой»). Правда, ломает только плохой код, например:

string GetName()
{
  ...
}

void Load(...)
{
  const char* pName = GetName().c_str();
  ...
}

* Неудачный new (раньше возвращал NULL, теперь бросает исключение).

По-моему, ломающие изменения в языке – не такая уж страшная вещь. Особенно если доступна старая версия компилятора (никто же не заставляет ставить новую версию). Вот переход на другую платформу – это да, тут действительно много кода «ломается».
Boost FAQ про ломающие изменения:

How can the Boost libraries be used successfully for important projects? Many of the Boost libraries are actively maintained and improved, so backward compatibility with prior version isn't always possible. Deal with this by freezing the version of the Boost libraries used by your project. Only upgrade at points in your project's life cycle where a bit of change will not cause problems. Individual bug fixes can always be obtained from the CVS repository.

Boost – не компилятор, но разумное зерно в этих словах есть.

3. Работая над компилятором на создаваемом языке разработчики получают больше практики работы на этом язке и могут более адкеватно оценивать предложения по его изменению и вносить собственные предожения.

Чтобы получить серьёзный опыт программирования на новом языке необязательно использовать bootstrapping.

Здравствуйте, Пётр Седов, Вы писали:

ПС>И ещё bootstrapping напоминает мне барона Мюнхгаузена, который сам себя за волосы вытащил из болота .

Именно оттуда это название и пошло, если кто не в курсе.

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

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

E>Ну если подходить к определению понятий, то:
E>

E>The most common reason for wanting to translate source code is to create an executable program. The name "compiler" is primarily used for programs that translate source code from a high-level programming language to a lower level language (e.g., assembly language or machine language). A program that translates from a low level language to a higher level one is a decompiler. A program that translates between high-level languages is usually called a language translator, source to source translator, or language converter. A language rewriter is usually a program that translates the form of expressions without a change of language.

E>R# в большей степени language translator, чем compiler.
E>В отличии от того же DMD или GDC.

Ты как всегда выдрал фразу из контекста и интерпретировал ее как тебе было угодно. Прочти, плиз, начало этой статьи. А потом еще поинтересуйся значением "most common".

В любом случае ты как всегда докапался до терминалогии и как всегда же посторался уйти от сути проблемы.

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

Говорить с людьми ведущими дискуссию таки образом я не намерен. Научишся говорить по существу — подходи. А пока, пока.

ЗЫ

Сообщение я твое прочел. Твои слова четко подтверждают то, что ты не в зуб ногой в данной проблеме.
Что касается "позволяешь себе смеятся над словами человека, который проделывал", то я не смеялся над ним. Я просто говорил, что его отмазки смехотворны.

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

FR>Так большинство спорных вопросов сильно субъективны, так что все зависит от точки зрения.

Большинство вопросов объективны. Суждения субъективный, к сожалению...

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

FR>Я кстати писал, а ты?

И я, кстати.