Написание компилятора (не просто парсера) C# 3.0 на вашем любимом языке программирования — во сколько человеко-часов вы бы оценили такую работу?

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

N>Написание компилятора (не просто парсера) C# 3.0 на вашем любимом языке программирования — во сколько человеко-часов вы бы оценили такую работу?
нууу... человеко-год если с нуля и знаешь как это вообще правильно писать компиляторы. и есть реальный опыт.
если еще требуется и оптимизация кода,.. ну еще человеко-полгода, если знаешь что такое AST и всякие его преобразования.
а зачем собссно?
в одиночку правда писать такие вещи скушно, нужно три чела, можно два. если спецы — раскокают задачу как орех.
я правда С# знаю поверхностно, но он вроде довольно компактный, и вроде на первый взгляд проблем там особых нет.
если есть еще полгодика накинуть

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

N>Написание компилятора (не просто парсера) C# 3.0 на вашем любимом языке программирования — во сколько человеко-часов вы бы оценили такую работу?

2000 — 3000 ч/ч
от 500 руб 1 ч/ч

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

N>Написание компилятора (не просто парсера) C# 3.0 на вашем любимом языке программирования — во сколько человеко-часов вы бы оценили такую работу?

2-3 человекогода, если требуется production quality, 0.5-0.7 если достаточно работающего прототипа.

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

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

N>>Написание компилятора (не просто парсера) C# 3.0 на вашем любимом языке программирования — во сколько человеко-часов вы бы оценили такую работу?

AVK>2-3 человекогода, если требуется production quality, 0.5-0.7 если достаточно работающего прототипа.

а что такое — "работающий прототип компилятора"?

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

AVK>>2-3 человекогода, если требуется production quality, 0.5-0.7 если достаточно работающего прототипа.

M>а что такое — "работающий прототип компилятора"?

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

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

N>Написание компилятора (не просто парсера) C# 3.0

А во что он должен компилировать? Вдруг нужно в нативный код Z80 безо всяких MSIL и CLR.

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

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

AVK>>>2-3 человекогода, если требуется production quality, 0.5-0.7 если достаточно работающего прототипа.

M>>а что такое — "работающий прототип компилятора"?

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

я писал компиляторы. совершенно не понимаю — что такое нормальная диагностика ошибок?
если у вас есть правильный полный парсер(что уже должно быть на этапе прототипа), и у вас возможно еще не все конструкции генерируются в код, то диагностика ошибок уже нормальная. на этапе генерации кода ошибок практически не бывает, если только не разумные ограничения реализации.
тогда уж нужно делить на этапы
1. полный парсер
2. кодогенрация для конструкций таких-то.
3. таких-то
4. таких-то
5...

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

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

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

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

M>я писал компиляторы.

Я тоже.

M> совершенно не понимаю — что такое нормальная диагностика ошибок?

Это когда вместо "неверная лексема в (xx, yy)" что то вроде "неправильное применение конструкции abc. Возможно, вы неверно сделали d." Погляди на сообщения об ошибках компилятора C# — очень многие из них обеспечены специальным кодом, возможно даже с различными эмпириками, а не просто автоматический выхлоп генератора парсеров.

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

Увы, нет. Хорошая диагностика — отдельная большая работа. Даже если у нас LL парсер. А уж если парсер LR, что частенько бывает, все еще печальнее.

M>"примерная работа" — это как-то чересчур. работа и все!

Есть такое понятие, как качество кода. Оно совсем не мифическое и стоит очень дорого. Причем, чем сложнее парсер, тем больше отличается прототип от того, что в итоге пойдет в коробку.

M>вообще очень трудно выделить тут этап "прототипа".

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

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

DM>А во что он должен компилировать?

В сборки .NET

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

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

M>>я писал компиляторы.

AVK>Я тоже.

M>> совершенно не понимаю — что такое нормальная диагностика ошибок?

AVK>Это когда вместо "неверная лексема в (xx, yy)" что то вроде "неправильное применение конструкции abc. Возможно, вы неверно сделали d." Погляди на сообщения об ошибках компилятора C# — очень многие из них обеспечены специальным кодом, возможно даже с различными эмпириками, а не просто автоматический выхлоп генератора парсеров.

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

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

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

N>Здравствуйте, D. Mon, Вы писали:

DM>>А во что он должен компилировать?

N>В сборки .NET

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

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

M>ну вы это совсем ужжо... никто выхлопом генератора парсеров не пользуется.

Тем не менее для работающего прототипа этого достаточно.

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

Я не пойму тогда, о чем ты споришь.

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

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

M>>ну вы это совсем ужжо... никто выхлопом генератора парсеров не пользуется.
AVK>Тем не менее для работающего прототипа этого достаточно.
полгода для запуска генератора парсеров, прохождения кой каких тестов результатом, с соообщением что тут не та лексема??? ну это месяц-два, если вообще нет грамматики этого сишарпа. а она уж наверняка есть.
я вообще писал для LL1 ручками рекурсивным спуском, для языков по мощи сравнимых с шарпом.
у шарпа небось LR(N). оно конечно неприятно было бы.
но есть метОды.

M>>д.б. вполне вменяемые сообщения об ошибках, без воды и разных предположений, отчего и почему.
AVK>Я не пойму тогда, о чем ты споришь.
а просто так.

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

VK>>Тем не менее для работающего прототипа этого достаточно.
M>полгода для запуска генератора парсеров, прохождения кой каких тестов результатом, с соообщением что тут не та лексема??? ну это месяц-два, если вообще нет грамматики этого сишарпа. а она уж наверняка есть.

Про кодогенератор ты уже забыл? Во сколько, к примеру, ты оцениваешь кодогенерацию для yield?

M>я вообще писал для LL1 ручками рекурсивным спуском

С# 3 никак не LL(k) даже.

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

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

VK>>>Тем не менее для работающего прототипа этого достаточно.
M>>полгода для запуска генератора парсеров, прохождения кой каких тестов результатом, с соообщением что тут не та лексема??? ну это месяц-два, если вообще нет грамматики этого сишарпа. а она уж наверняка есть.

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

M>>я вообще писал для LL1 ручками рекурсивным спуском
AVK>С# 3 никак не LL(k) даже.
да и хрен с ним. в принципе это не так страшно.

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

M>если это переключение треда

Нет, это итераторы.

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

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

M>>если это переключение треда

AVK>Нет, это итераторы.

посмотрел. ну и что?
смотрел по диагонали. сильное впечатление что он просто например
1 генерит код для вычисления выражения если оно после него есть. потом пихает результат куда-то, куда — не проблема, и также пихает туда-же скрытый адрес конца выражения. поскольку судя по тому, что прочитал, следующий for_each, должен начать с этого адреса. адрес при вызове передается скрытым параметром в сам foreach. а может просто делается скрытый обьект с полями — текущий результат foreach, текущий адрес внутри for each. и именно через него происходит как передача значения, так и запоминание "контекста" внутри foreach.
ну что-то около того.
поскольку я только сейчас ознакомился поверхностно с этой приблудой.
поскольку семантика описана не очень ясно, предположения такие.

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

M>посмотрел. ну и что?

Вопрос тот же — во сколько ты оцениваешь время на написание этой части кодогенератора?

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

Все на самом деле совсем не так, как ты тут рассказываешь.

M>поскольку семантика описана не очень ясно, предположения такие.

Где не ясно? В стандарте C# семантика yield return/yield break описана детальнейшим образом. С работой реального компилятора можно ознакомиться при помощи рефлектора.

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

AVK>Вопрос тот же — во сколько ты оцениваешь время на написание этой части кодогенератора?
выяснить точную семантику плюс полчаса.

AVK>Все на самом деле совсем не так, как ты тут рассказываешь.
СОВСЕМ не как???
можно поразвернутей?
и уж точно не СОВСЕМ не так.
в добавление к ранее сказанному сохраняется просто контекст функции где был yield return.
остальное детали.
смысл приблуды делать итерационный шаг, возвращать результат, при следующем вызове возобновлять из того же контекста и делать шаг следующий.
это оператор сильно связанный с неким IEnumerable и явно чем-то из него пользуется.
какое отношение данная частность имеет к вопросу?
такие глубоко специальные фичи нужно делать на последнем этапе.
ну прям не обойдесси без него в других языках.