Здравствуйте, nikov, Вы писали:
D>>Не было ли у кого такого рода начинаний?
N>Уж лучше написать компилятор из IL в JavaScript. А в этой области уже что-то делалось.
Думаю, что речь шла о идее единого языка для веб-разработок. В одном из проектов на F#-е (не уверен, что он жив до сих пор) использовали F# как для серверного кода, так и для клиентского. Причем для клиентского в итоге генерировали JavaScript аналогичный типизированному F#-ному коду.
Преимущества очевидны — интеллисенс, статическая типизация и другие проверки на стадии компиляции, единый язык для всего проекта.
В этом случае трансляция IL в JavaScript мало интересна, так как многие преимущества теряются (например, интеллисенс).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, nikov, Вы писали:
N>Здравствуйте, dotneter, Вы писали:
D>>Не было ли у кого такого рода начинаний?
N>Уж лучше написать компилятор из IL в JavaScript. А в этой области уже что-то делалось.
Оно то конечно лучше, но и сложнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, nikov, Вы писали:
D>>>Не было ли у кого такого рода начинаний?
N>>Уж лучше написать компилятор из IL в JavaScript. А в этой области уже что-то делалось.
VD>Думаю, что речь шла о идее единого языка для веб-разработок. В одном из проектов на F#-е (не уверен, что он жив до сих пор) использовали F# как для серверного кода, так и для клиентского. Причем для клиентского в итоге генерировали JavaScript аналогичный типизированному F#-ному коду.
VD>Преимущества очевидны — интеллисенс, статическая типизация и другие проверки на стадии компиляции, единый язык для всего проекта.
VD>В этом случае трансляция IL в JavaScript мало интересна, так как многие преимущества теряются (например, интеллисенс).
А куда он теряется? Код пишется на любом языка, а dll уже транслируется в js.
Здравствуйте, VladD2, Вы писали:
VD>Думаю, что речь шла о идее единого языка для веб-разработок. В одном из проектов на F#-е (не уверен, что он жив до сих пор) использовали F# как для серверного кода, так и для клиентского. Причем для клиентского в итоге генерировали JavaScript аналогичный типизированному F#-ному коду.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, VladD2, Вы писали:
VD>>Думаю, что речь шла о идее единого языка для веб-разработок. В одном из проектов на F#-е (не уверен, что он жив до сих пор) использовали F# как для серверного кода, так и для клиентского. Причем для клиентского в итоге генерировали JavaScript аналогичный типизированному F#-ному коду.
FR>WebSharper http://www.intellifactory.com/products/wsp/Home.aspx проект одного из соавторов книги Expert F#.
Спасибо за помощь. Я думаю, что Ников и так этот проект видел.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Теряется интерактивность. Чтобы что-то узнать о коде его придется предварительно скомпилировать.
Что ты понимаешь под интерактивностью? REPL? О коде можно будет узнать всё, что позволяет среда разработки — то есть, скорее всего, все типы, ошибки и т.д. Что ты ещё о нём хочешь знать. Чтобы запустить и посмотреть результат на джаваскриптовом движке (например, в браузере) — да, придется скомпилировать.
Здравствуйте, nikov, Вы писали:
N>Здравствуйте, VladD2, Вы писали:
VD>>Теряется интерактивность. Чтобы что-то узнать о коде его придется предварительно скомпилировать.
N>Что ты понимаешь под интерактивностью? REPL?
Под интерактивностью я понимаю поддержку IDE и (возможно) отладку.
N>О коде можно будет узнать всё, что позволяет среда разработки — то есть, скорее всего, все типы, ошибки и т.д.
В общем — да, но когда? После компиляции? Ты не забыл, что на выходе у нас должен быть скрипт. А у него есть свои ограничения. О том, что они нарушены мы узнаем только в момент трансляции исходного языка в скрипт.
К тому же это только увеличит объем работ, так как придется декомпилировать IL и синтезировать из него не только скрипт, но и представление на исходном языке.
Кроме того нужно учитывать, что IL дотнета вещь очень ограниченная. Про ООП он знает, а вот о ФП и,в частности, о вариантах + сопоставлении с образцом — нет. Меж тем было бы очень приятно если бы эти возможности были бы доступны в скриптах (путем эмуляции или использования возможностей скрипта).
Делая конвертер ЯП -> скрипт нам будет намного проще обеспечить эти возможность.
Еще один аргумент против работы с IL — это необходимость декомпиляции очень низкоуровневого формата. В схеме ЯП -> скрипт этого делать не придется. Мы исходно будет иметь АСТ высокоуровневого языка. Все что нужно — это написать макрос конвертирующий его в ЯваСктипт.
N> Что ты ещё о нём хочешь знать. Чтобы запустить и посмотреть результат на джаваскриптовом движке (например, в браузере) — да, придется скомпилировать.
Хочу иметь:
1. Комлит ворд.
2. Подсказки.
3. Навигацию.
4. Составление с образцом.
5. Варианты.
6. Отладку по исходникам (а не по генерированному скрипту). Но с этим все сложнее, так как отладка будет уже на клиенте.
И все это хочу иметь сразу при редактировании кода, а не когда-то после компиляции.
Еще не хочу возиться с дико низкоуровневым мсилом для реализации всего этого.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Хочу иметь: VD>1. Комлит ворд. VD>2. Подсказки. VD>3. Навигацию. VD>4. Составление с образцом. VD>5. Варианты. VD>6. Отладку по исходникам (а не по генерированному скрипту). Но с этим все сложнее, так как отладка будет уже на клиенте.
VD>И все это хочу иметь сразу при редактировании кода, а не когда-то после компиляции. VD>Еще не хочу возиться с дико низкоуровневым мсилом для реализации всего этого.
С отладкой могут быть сложности, а какие трудности с остальным — я не понимаю. Пишешь код на своем любимом языке (например, Nemerle) в своей любимой IDE, имея все эти удобства. Затем компилируешь, как обычно, в сборку с IL. На post-build step IL конвертируется в JavaScript (с дико низкоуровневым мсилом возится этот конвертер, а не ты) и выкладывается, куда нужно.
Здравствуйте, nikov, Вы писали:
N>С отладкой могут быть сложности, а какие трудности с остальным — я не понимаю. Пишешь код на своем любимом языке (например, Nemerle) в своей любимой IDE, имея все эти удобства. Затем компилируешь, как обычно, в сборку с IL. На post-build step IL конвертируется в JavaScript (с дико низкоуровневым мсилом возится этот конвертер, а не ты) и выкладывается, куда нужно.
Тогда пара вопросов к тебе, как к потенциальному дизайнеру этой возможности:
1. Как из IL я смогу обнаружить, что в исходном языке применялся сопоставление с образцом?
2. Насколько, по-твоему, будет сложнее генерировать скриптовый код по IL по сравнению с генерацией по АСТ Немерла или ФШарпа?
3. Полученный IL останется в сборке (причем не только написанный вручную, но и ссылки на типизированные заглушки библиотек для скриптов), ведь код смешан с серверным. Как его удалять? Или это не надо делать?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Мы сделали утилиту которая не только проверяет парсится ли исходник или нет, но и повзоляет проверить корректный ли АСТ при этом порожден. VD>Причем все на базе макросов и метапрограммирвоания. Короче, полнейшая круть .
Ты мне дай утилитку, которую я просил: чтобы по исходнику C# дампила AST в какой нибудь читаемой текстовой форме. Я накидаю интересных примеров.
Здравствуйте, nikov, Вы писали:
N>Ты мне дай утилитку, которую я просил: чтобы по исходнику C# дампила AST в какой нибудь читаемой текстовой форме. Я накидаю интересных примеров.
Здравствуйте, nikov, Вы писали:
N>Ты мне дай утилитку, которую я просил: чтобы по исходнику C# дампила AST в какой нибудь читаемой текстовой форме. Я накидаю интересных примеров.
Хардкейс с тобой связался?
И еще вопрос. Какой смысл "дампить AST"? Его же тогда руками приедтся проверять.
Наша утилита сразу позволяет задать паттерн который будет искаться в AST созданном при разборе исходника. Эдакий хайтек-юнит-тест.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
The key disadvantage is the lack of a runtime debugger. Debugging is currently done using a CLR debugger such as Visual Studio, but no in-browser debugger exists as yet.
