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

H>В общем случае это очень хреново реализуемо — ибо match. А вообще лучше плагин к ILSpy наваяать, который бы понимал немерловые лямбды и match.

А зачем ILSpy-ю их понимать? Он их в C# и так переведет. ILSpy нужно немного подправить, чтобы он не падал на некотором коде и все.

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

VD>Если такой результат устроит, то могу рассказать как это дело добавить в компилятор.

Пожалуй, такой результат не устроит.
Но за ответы спасиб.

Здравствуйте, Димчанский, Вы писали:

Д>Ну я только вчера поставил Nemrle, накидал по-быстрому рекурсивную функцию фибоначи с аккумуляторами, посмотрел в ILSpy как выглядит — вполне нормальный while цикл получился.

Это потому что случай простой. Ты декомпильни исходники компилятора и сам все увидишь. Особо прикольно выглядит функция Typer.DoType(). Там есть большой match по вариантам. Незабываемое зрелище .

Д>Вот когда алгебраические типи матчить или что еще посложнее, то конечно там должно получаться что-то страшное. А с другой стороны, если бы на C# кто-то бы пытался те же самые алгебраические типы данных изобразить и работать с ними, неужели бы у него код получился бы сильно красивее?

Вручную конечно же код будет красивее. Но главное, что на C# просто не стали бы так писать. Там стали бы использовать разные ООП-патетрны. Например, для обхода АСТ использовали бы паттерн "Посетитель". Вот переписать ПМ по вариантам в посетитель — это не реально.

Короче, сгенерить то C# можно. Но язык более высокого уровня по любому будет превращать язык более низкого уровня в аналог ассемблера. Так что такое кодогенераторы это очень формальное преодоление требований. К коду обычно предъявляется требование "читабельности". И этому требованию генерированный код не будет удовлетворять.

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


Z>Например так

Мне кажется ты его не правильно понял. Он имеет в виду генерация C#-а по проектам немерла средствами компилятора немерла. Ну, чтобы компилятор вместо конечной сборки генерировал бы C#, а тот уже скармливать компилятору от МС или Моно.

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

Z>Кстати, ктонибудь тестил ее в .Net4? Они ее оптимизировали вроде. Кто на ты с IL, потестите плиз.

Тестил. Нихера они не сделали. Разогнали немного. Теперь она тормоизт не в 10 раз больше, а в 5. Но толку с того никакого, так как один хрен это в разы медленнее простого перехода и даже вызова через стек. Учитывая, что в 99% случаев хвостовая рекурсия используется в рамках одной функции, самопальная оптимизация рулит неимоверно.

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

VD>Это потому что случай простой. Ты декомпильни исходники компилятора и сам все увидишь. Особо прикольно выглядит функция Typer.DoType(). Там есть большой match по вариантам. Незабываемое зрелище .

Обязательно посмотрю.

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

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

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

VD>Мне кажется ты его не правильно понял. Он имеет в виду генерация C#-а по проектам немерла средствами компилятора немерла. Ну, чтобы компилятор вместо конечной сборки генерировал бы C#, а тот уже скармливать компилятору от МС или Моно.

Да, именно это я имел ввиду.

Здравствуйте, Димчанский, Вы писали:

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

Вот, да. Супер-компилятор тут был бы очень кстати. Вот только их пока что создали только для игрушечных языков.

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

VD>Мне кажется ты его не правильно понял. Он имеет в виду генерация C#-а по проектам немерла средствами компилятора немерла. Ну, чтобы компилятор вместо конечной сборки генерировал бы C#, а тот уже скармливать компилятору от МС или Моно.

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

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

Z>Если так, то да. Осталось узнать смысл этого действа. С тем же успехом можно генерить код чем нибудь типа рефлектора.

Это было бы не плохо. Но Рефлектор падает на немерловом коде. И править Рефлектор никто не собирается. Более того его хотят убить, сделав его платным.

Чуть лучше дела обстоят с ILSpy и dotPeek. dotPeek так и вовсе не падает, но иногда декомпилирует не корректный или не эффективный код.

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

Z>Если так, то да. Осталось узнать смысл этого действа. С тем же успехом можно генерить код чем нибудь типа рефлектора.

Ну тут бабушка надвое сказала.. Когда AST конвертится в IL код — это одно, а когда его можно в текст на каком-то языке генерировать — это немного другое. По крайней мере мне интуитивно кажется, что из AST можно красивее сделать код на C#, нежели из конечного набора IL инструкций.

Здравствуйте, Димчанский, Вы писали:

Д>Ну тут бабушка надвое сказала.. Когда AST конвертится в IL код — это одно, а когда его можно в текст на каком-то языке генерировать — это немного другое. По крайней мере мне интуитивно кажется, что из AST можно красивее сделать код на C#, нежели из конечного набора IL инструкций.

Вот будут у нас сменные бэкэнды и сбацаешь бэкэнд "plain C#".

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

Z>>Кстати, ктонибудь тестил ее в .Net4? Они ее оптимизировали вроде. Кто на ты с IL, потестите плиз.
WH>Тестили. Тормозит.

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

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

Z>>Кстати, ктонибудь тестил ее в .Net4? Они ее оптимизировали вроде. Кто на ты с IL, потестите плиз.
VD>Тестил. Нихера они не сделали. Разогнали немного. Теперь она тормоизт не в 10 раз больше, а в 5.

А все потому что property tail call (оп код TailCall) и tail recursion — это не совсем одно и то же.

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

H>Вот будут у нас сменные бэкэнды и сбацаешь бэкэнд "plain C#".

А вот к слову, можно чуть поподробней про эту фичу?
Т.е. значит ли это, что код можно будет генерить, к примеру, для JVM?

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

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

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

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

Я не понимаю, почему нужно противопоставлять хвостовую рекурсию и proper tail call — и к тому же сравнивать их по производительности. TailCall логично генерировать в том случае, если у нас нет банальной хвостовой рекурсии. Он всяко должен быть быстрее, чем обычный Call.

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

WH>Хвостовая рекурсия частный случай хвостового вызова.

Собственно, чисто логически это так. Но с т.з. реализации не совсем. Хвостовая рекурсия вполне тривиально реализуется и без поддержки рантайма, собственно, тут и не нужно никакой поддержки. Хвостовой вызов же ты руками не сделаешь никак. Ну или по крайней мере это задачка на уровне full program optimization. Вы же зачем-то сравниваете заинлайненную вручную хвостовую рекурсию и стандартный TailCall, и мне непонятно — зачем? TailCall может рулить и в тех случаев, где вообще никакой рекурсии нет.

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

ВВ>Я не понимаю, почему нужно противопоставлять хвостовую рекурсию и proper tail call — и к тому же сравнивать их по производительности. TailCall логично генерировать в том случае, если у нас нет банальной хвостовой рекурсии. Он всяко должен быть быстрее, чем обычный Call.
В реализации мелкософт он значительно медленней, чем обычный вызов.
А ты опять развел флуд даже не попытавшись понять, о чем разговор.

Здравствуйте, Димчанский, Вы писали:

Д>Ну тут бабушка надвое сказала.. Когда AST конвертится в IL код — это одно, а когда его можно в текст на каком-то языке генерировать — это немного другое. По крайней мере мне интуитивно кажется, что из AST можно красивее сделать код на C#, нежели из конечного набора IL инструкций.

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