Здравствуйте, Ziaw, Вы писали: Z>Кстати, а какие основные проблемы ты тут видишь? C# же компилируют в js?
Основные проблемы — в том, что код не собирается работать в вакууме. Он будет исполняться в определённом окружении — browser, window, document.
Попытка построить строготипизированную модель для HTML и CSS по мне не выглядит многообещающей.
А умение компилировать базовую арифметику не очень интересно — оно имеет узкие практические применения.
Z>Я вижу основную проблему в том, что хорошо зная js, обязательно захочется делать трюки обычные для js, но невозможные для nemerle.
Z>Примерна та же проблема была у ранних ORM со своим языком запросов, который был богат, но не являлся заменой SQL тому, кто использовал нетривиальные запросы, не говоря уже об особенностях серверов.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: Веб и динамика? Веб и статика+метапрограммирование.
Здравствуйте, Sinclair, Вы писали:
S>Основные проблемы — в том, что код не собирается работать в вакууме. Он будет исполняться в определённом окружении — browser, window, document. S>Попытка построить строготипизированную модель для HTML и CSS по мне не выглядит многообещающей.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, gandjustas, Вы писали:
VD>>>Ты совсем с реальностью связь потерял. Шарпу лет 20 развиваться, чтобы первый немерл догнать. F# по менее, но тоже не мало. G>>Тем не менее на F# пишет больше народу, чем на Nemerle.
VD>Алё! Ты еще и с логикой не дружишь? Где связь между возможнсотями языка и тем сколько людей на нем пишут. Скажем на PHP пишет раз в 100 больше чем на F#. Можно из этого сделать вывод, что F# не дорос до PHP?
Нет, они из разных "экосистем". А вот nemerle и f# из одной — оба на .net, оба — функциональные языки и по возрасту примерно одинаковы.
VD>У F# есть только одно, весьма спорное, преимущество — глобальный вывод типов. Во всем остальном он <= Nemerle. Отсутствие макросистемы (при наличии, кстати, квази-цитирования необходимого для макросов) уже делает F# языком гораздо менее мощным. Функциональные возможности у языков почти идентичные. ООП в F# несравнимо хуже. Куча проблем вроде необходимости размещения файлов в проекте в определенном порядке и невозможность создать папку в которую поместить часть кода. При этом та же интеграция с IDE не в пример слабее. Все что сделано в F# или уже есть в немерле, или реализовано в виде макросов. Так как же F# может быть лучше?
Да-да-да, и тем не менее на f# пишут гораздо больше народу.
VD>Ну, а пишут на нем может и по более. Только заслуга тут исключительно в том ярлыке "Под покровительством Майкрософт". Ни одного реального достоинства у F# перед немерлом нет. И это факт, а не чьи-то домыслы.
Хороший язык, на котором никто не пишет и не хочет писать — плохой язык. Наоборот кстати тоже.
VD>>>Короче, не выставляй себя ламером. Разберись в предмете обсуждения. G>>От этого больше народу начнет пользоваться Nemerle?
VD>Ты вроде не в обсуждение диалогического исследования влез, а в техническое обсуждение. Так что же ты начинаешь увиливать? Ты на делал кучу безосновательных заявлений и теперь пытаешься подменить тему. Сливаешь?
Это же философия, технические вопросы в других форумах обсуждаются.
VD>Где, кстати, yield в F#?
seq {
yield x;
}
Re[7]: Веб и динамика? Веб и статика+метапрограммирование.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Ziaw, Вы писали: Z>>Кстати, а какие основные проблемы ты тут видишь? C# же компилируют в js? S>Основные проблемы — в том, что код не собирается работать в вакууме. Он будет исполняться в определённом окружении — browser, window, document. S>Попытка построить строготипизированную модель для HTML и CSS по мне не выглядит многообещающей. S>А умение компилировать базовую арифметику не очень интересно — оно имеет узкие практические применения.
А не строго? Это же наш язык, мы можем любые принципы применить.
Например сделать явное выделение динамических вызовов, которые компилятор не будет проверять. Да, полной проверки типов не будет, но значит ли это, что частичная бесполезна?
Гипотетический код:
var newWin = window.open("/test", "Test"); // статика, ибо сигнатуру метода мы указали в метаданных
newWin.focus(); // а вот сигнатуру focus, допустим, не указали, будет ошибка компиляции, можно ее описать и все заработает
dyn // а можно отключить проверку для конкретного блока, все, у нас внутри динамика, которую мы не контроллируем
{
newWin.focus()
}
При контроль типов не получится отдать компилятору, придется самостоятельно, через duck typing. Это будет не nemerle, но язык очень похожий на него с достаточно мощными механизмами статической типизации.
Re[32]: Веб и динамика? Веб и статика+метапрограммирование.
Здравствуйте, gandjustas, Вы писали:
G>Нет, они из разных "экосистем". А вот nemerle и f# из одной — оба на .net, оба — функциональные языки и по возрасту примерно одинаковы.
Ты ничего не путаешь? F# это порт на .net ocaml'а, которому 25 лет от роду и комьюнити огромное. Причем ocaml это всего лишь популярный диалект ML, который еще старше.
G>Хороший язык, на котором никто не пишет и не хочет писать — плохой язык. Наоборот кстати тоже.
Если никто — то конечно да. А плохой у немерле не язык, а PR, стабильность и доки.
Re[5]: Веб и динамика? Веб и статика+метапрограммирование.
Здравствуйте, Sinclair, Вы писали:
S>Есть разные способы разделения; не при всех выполняется значительное дублирование. S>Для некоторых частных случаев (например — валидация данных) метапрограммирование как раз позволяет построить компилятор с одного языка в несколько бэк-ендов: S>- в SQL, чтобы оптимизатор запросов мог пользоваться semantic query optimizaiton S>- в серверный код (например MSIL), чтобы нельзя было подсунуть некорректные данные в API S>- в JavaScript, чтобы можно было выполнять валидацию без похода на сервер.
Это я не очень понял, к чему ты.
S>В общем случае я не вижу способа сделать компиляцию Nemerle-кода в JS. По крайней мере, в эффективный JS.
Вон даже Хаскель вполне себе компилируют.
S>Не вижу никакого падения роли серверного языка. S>Даже "толстый" JS-клиент работает не в вакууме. Фактически, имеем клиент-серверное приложение. API сервера для него весьма и весьма важен, т.к. именно он определяет возможности клиента. На первый план выступает REST и прочее.
Хороший API можно написать даже на PHP. Но вот задача серверной части становится сильно сужена. Например, функциональный язык не даст мне никаких преимуществ — на сервере будет довольно грязный по большей части код. Интерфейсом этого кода станет HTTP, поэтому по сути уже не имеет значения какова там внутренняя архитектура — написан ли он в процедурном или в каком-то более другом стиле.
Серверная часть в первую очередь выполняет такие вещи как работа с данными, где скорость упирается в БД, поэтому статически-типизированный язык не даст каких-то значительных преимуществ, да и скорость этого языка практически по фигу — все в БД упрется так или иначе.
S>Статика тут позволяет опять же гарантировать ссылочную корректность (к примеру, что JavaScript код не пытается обращаться к несуществующим точкам входа) и много других полезных вещей.
Каким образом? Основной код-то на ДжаваСкрипт. Как ты его анализировать будешь?
Re[33]: Веб и динамика? Веб и статика+метапрограммирование.
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, gandjustas, Вы писали:
G>>Нет, они из разных "экосистем". А вот nemerle и f# из одной — оба на .net, оба — функциональные языки и по возрасту примерно одинаковы.
Z>Ты ничего не путаешь? F# это порт на .net ocaml'а, которому 25 лет от роду и комьюнити огромное.
Сейчас сходство в основном синтаксическое. Компилятор первой версии F# компилировался как компилятором ocaml, так и самим F#. После того как бустраппинг был пройдет начали резко отказываться от совместимости с ocaml.
Z>Причем ocaml это всего лишь популярный диалект ML, который еще старше.
Все языки так или иначе от чего-то берут свои корни, так можно сказать что любой язык с фигурными скобками — наследник C, который тоже немолодой. Но язык не работает в вакууме. Он работает в некоторой экосистеме с платформой (библиотеками) и средствами разработки.
G>>Хороший язык, на котором никто не пишет и не хочет писать — плохой язык. Наоборот кстати тоже. Z>Если никто — то конечно да. А плохой у немерле не язык, а PR, стабильность и доки.
Это фактически означает плохой язык.
Re[29]: Веб и динамика? Веб и статика+метапрограммирование.
VD>То как действует супер-компиляция плохо понимают даже такие люди как авторы хаскеля. На практике они практически не использовались. Только в Рефале — языке чисто эксперементаторском. А ты лезешь даже в такие непростое области.
ты сейчас говоришь об универсальной автоматической суперкомпиляции.
это задача действительно сложная и непонятная — и решается только тем же рефалом
на практике же речь обычно идет о специализированной автоматизированной суперкомпиляции.
специализированная означает — что решается лишь какой-то узкий сегмент суперкомпиляции.
автоматизированный означает — что способы суперкомпиляции и их применение определяются и фиксируются в том числе с помощью человека.
VD>Супер-компилятор не просто переписывает код по какому-то там алгоритму. Он создает мета-модель кода и производит частичные вычисления. При этом никаких новых результатов не получается. Получается всего лишь более шустрый код для той же самой программы.
те же грабли — в твоей неверной трактовке термина суперкомпиляция.
даже в вики второй строчкой написано, что это очень узкая трактовка суперкомпиляции.
еще раз повторю основную мысль суперкомпиляции:
по существующей версии кода(обычно обобщенного) — получить его специализированную версию.
специализация может идти по любому параметру — размер задачи, размер имеющейся памяти, заранее известное распределение исходных данных, вид исполнителя, имеющиеся языковые средства и т.д.
ничего кстати не напоминает?
а это кстати и есть, например, linq2sql — по версии на универсальном языке формируется специализированная sql-версия этого же кода.
Re[34]: Веб и динамика? Веб и статика+метапрограммирование.
Здравствуйте, gandjustas, Вы писали:
G>Сейчас сходство в основном синтаксическое. Компилятор первой версии F# компилировался как компилятором ocaml, так и самим F#. После того как бустраппинг был пройдет начали резко отказываться от совместимости с ocaml.
Я согласен с тем что F# и OCaml уже достаточно далеко разошлись, но совместимость при этом осталась, например далеко нетривиальная библиотека http://www.coherentpdf.com/ocaml-libraries.html компилируется и OCaml и F#.
Re[35]: Веб и динамика? Веб и статика+метапрограммирование.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, gandjustas, Вы писали:
G>>Сейчас сходство в основном синтаксическое. Компилятор первой версии F# компилировался как компилятором ocaml, так и самим F#. После того как бустраппинг был пройдет начали резко отказываться от совместимости с ocaml.
FR>Я согласен с тем что F# и OCaml уже достаточно далеко разошлись, но совместимость при этом осталась, например далеко нетривиальная библиотека http://www.coherentpdf.com/ocaml-libraries.html компилируется и OCaml и F#.
Ну это создатели библиотеки поставили цель сделать библиотеку компилируемой на обоих языках. Совершенно не означает что любой код будет компилироваться так. В общем случае как раз обратная картина будет.
Re[28]: Веб и динамика? Веб и статика+метапрограммирование.
DG>>кстати, макросы (раскрытие и свертку), исходя из теории программирования можно рассматривать, как подвид суперкомпиляции программы.
VD>Что за свертку макросов ты сейчас придумал?
если говорить, что foreach — это макрос, то:
это развернутый код
for(int i = 0; i < 10; ++i)
{
Console.WriteLine(i);
}
[code]
это свернутый с помощью макросов
[code]
foreach (var i in Enumerable.Range(0, 10))
Console.WriteLine(i);
VD>Что до суперкомпиляции, то еще раз повторяю тебе — это метод оптимизации. Она не меняет семантики кода. МП же своей целю имеет изменение семантики.
суперкомпиляция — это теоретическая формулировка решаемой задачи.
это ответ на вопросы:
1. какую теоретическую задачу решает введение макросов?
2. какая теоретическая задача решается при linq2sql, pl2js и т.д.?
VD>Ты лучше овтеть на прсотой вопрос. С какой целью ты суперкомпиляцию сюда приплел (если, кончено, отбросить предположение, что брякнул не подумав)?
цель — как у и любого приплетания теории: получить фундаментальный базис на который можно опереться при решении задачи.
DG>>при этом фиксированным доп. параметром суперкомпиляции — является исполнитель: с одной стороны — компилятор конкретного языка, с другой стороны — разработчик.
VD>О, блин, дожили. Разработчик стал у нас параметром программы!
конечно. пользователь программы всегда является одним из самых важных параметром программы.
программа делающая одну и ту же функцию — но для космонавта или бухгалтера — это две разные программы.
если мы говорим про МП, то пользователем такой программы — является разработчик.
и поэтому — да, для метапрограммы — разработчик является весомым параметром.
Re[36]: Веб и динамика? Веб и статика+метапрограммирование.
Здравствуйте, gandjustas, Вы писали:
G>Ну это создатели библиотеки поставили цель сделать библиотеку компилируемой на обоих языках. Совершенно не означает что любой код будет компилироваться так. В общем случае как раз обратная картина будет.
Нет первоначально все было написано на OCaml'е тут http://coherentpdf.com/blog/?p=12 автор дает отчет о первоначальном портировании.
Любой код конечно не будет компилироваться, но общее подмножество языков достаточно большое (гораздо больше чем у родственных
сиобразных например) чтобы писать кроссязыковые библиотеки.
Re[17]: Веб и динамика? Веб и статика+метапрограммирование.
S>Ну, это старый аргумент. Я наблюдаю этот спор тут чуть ли не со времён R#. Ответы на него мне тоже известны. S>Как оно окажется на практике — пока что непонятно. Пока что мы имеем не очень много макросных библиотек для немерле, так что трудно сказать, насколько твой страх оправдан.
вопрос еще более старый (ему лет 50) — спор идет со времен lisp, макро-ассемблера и т.д.
и видно, что в mainstream-е выбор всегда делался в пользу "жестких" инструментов.
на текущий момент, не видно почему этот выбор должен измениться.
Re[17]: Веб и динамика? Веб и статика+метапрограммирование.
Z>Вменяемый разработчик не станет делать "переопределение $, % и неровно дышит к наличию < > в коде", как сейчас не делают екстеншены с сигнатурой IEnumerable<T> First<T>(Func<T,bool> predicate). В первом случае это будет вести к конфликтам с семантикой кода, во втором со стандартной библиотекой.
но в том же .net-е (c#) — это является не просто соглашением "давайте писать хороший код", но и предоставляются способы по защите от плохого кода.
есть namespace, есть алиасы и т.д. — которые позволяют при необходимости один плохой код скрестить с другим плохим кодом, и все это использовать из хорошего кода.
Z>Давай на примере джейсона: Z>
Z> def test = json({
Z> a : arr;
Z> b : obj;
Z> c : null;
Z> d : true;
Z> e : { a : 1; "la la": null};
Z> "f" : [true];
Z> j : (43 + 55);
Z> });
Z>
Z>В теории он переопределяет значение оператора уточнения типа ":", на практике это никаких проблем в понимании кода не вызывает (по крайней мере у тех, кто знает что такое джейсон). Он не переопределяет ":" глобально, просто при разборе кода внутри себя интерпретирует его по своему.
опять исходная проблема подменяется обсуждением другой задачи.
в проблеме шла речь — про конфликт двух и более макросов, ты же говоришь — да нет никакой проблемы, вот смотрите когда макрос один, то все хорошо.
давай возьмем все-таки два сложных макроса с разным синтаксисом, например, json и макрос-шаблонизатор с синтаксисом:
[{ }] операторы шаблонизатора
[: :] — цитирование
< > — подстановка значение
и смешаем их
[{ j: 1..2
[:
def test<j> = json({
[{ i: 1..3
[: a<i> : arr; :]
}]
b : obj;
c : null;
d : [[{ i: 1..10 where i%2==0 [: <(j+i)>, :] }]];
e : { [{ i: 1..3 [: a<i> : <(j+i)*4>; :] }] "la la": null};
"f" : [true];
j : (43 + 55);
});
:]
}]
def test = test1 + test2;
ну как? еще читается? а здесь еще даже конфликты синтаксиса минимальны
Re[18]: Веб и динамика? Веб и статика+метапрограммирование.
Здравствуйте, DarkGray, Вы писали:
DG>опять исходная проблема подменяется обсуждением другой задачи. DG>в проблеме шла речь — про конфликт двух и более макросов, ты же говоришь — да нет никакой проблемы, вот смотрите когда макрос один, то все хорошо.
Там где в джейсон передаются значения могут быть использованы любые макросы любой вложенности возвращающие выражения. Никакого конфликта не будет. Тот же linq вполне пройдет, ничего для этого специально делать на надо.
В других местах, за синтаксис отвечает сам джейсон и требуется валидный синтаксис макроса джейсона, любое невалидное выражение вызовет ошибку при компиляции.
DG>давай возьмем все-таки два сложных макроса с разным синтаксисом, например, json и макрос-шаблонизатор с синтаксисом: DG>[{ }] операторы шаблонизатора DG>[: :] — цитирование DG>< > — подстановка значение DG>и смешаем их
С такими операторами и без смешивания мы не сможем работать. Подробнее расскажи о задаче, я тебе набросаю синтаксис. Если задача генерить код a la Т4 — ради бога, это все будет обычной строкой для твоего макроса и, когда превратится в код, у джейсона не будет никаких проблем с синтаксисом шаблонизатора.
Ты придумал макрос шаблонизатора, так расскажи семантику и смысл кода с ним.
DG>
DG>ну как? еще читается? а здесь еще даже конфликты синтаксиса минимальны
В чем суть примера? Доказать, что можно наколбасить нечитаемый код при использовании текстового шаблонизатора? Вон глянь любые исходники на T4. Там такая же каша, только синтаксис чуть чище твоего придумали.
Твой пример показывает, что ты видишь макросы как Т4 на стероидах, на самом деле они очень органично вписаны в язык. Это позволяет применять и комбинировать их без особых конфликтов. Все проблемы от твоего неверного видения.
Re[6]: Веб и динамика? Веб и статика+метапрограммирование.
Здравствуйте, Ziaw, Вы писали:
S>>В общем случае я не вижу способа сделать компиляцию Nemerle-кода в JS. По крайней мере, в эффективный JS. Z>Кстати, а какие основные проблемы ты тут видишь? C# же компилируют в js? Z>Я вижу основную проблему в том, что хорошо зная js, обязательно захочется делать трюки обычные для js, но невозможные для nemerle.
Не, мужик, по-моему наоборот. *Хорошо* зная JS, захочется НЕ делать трюки, обычные для JS.
Re[7]: Веб и динамика? Веб и статика+метапрограммирование.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Ziaw, Вы писали: Z>>Кстати, а какие основные проблемы ты тут видишь? C# же компилируют в js? S>Основные проблемы — в том, что код не собирается работать в вакууме. Он будет исполняться в определённом окружении — browser, window, document. S>Попытка построить строготипизированную модель для HTML и CSS по мне не выглядит многообещающей. S>А умение компилировать базовую арифметику не очень интересно — оно имеет узкие практические применения.
А не нужно ее делать... эээ... совсем строго-типизированной. Определенный уровень динамики там так или иначе останется, куда ж без него.
Тут, мне кажется, другая проблема — как транслировать код, активно использующий FCL? По-моему, вообще никак. Получается, что придется вводить очень жесткие ограничение на дотнетовское АПИ, которое разрешено в таких транслируемых в джаваскрипт функциях. А это уже не очень круто.
И самое забавное, что как раз одна из основных проблема джаваскрипта, которую в идеальном мире хотелось бы решить — это бедность доступных на нем библиотек.
Re[19]: Веб и динамика? Веб и статика+метапрограммирование.
Z>С такими операторами и без смешивания мы не сможем работать. Подробнее расскажи о задаче, я тебе набросаю синтаксис.
в максимально произвольном месте иметь возможность свернуть код вида:
A<i_1>B<i_1>C
A<i_2>B<i_2>C
A<i_3>B<i_3>C
где A, B, C(ит.д.) — фиксированные части, а i_n — изменяемая часть по определенным правилам
в код вида
генерация по i для шаблона A<i>B<i>C
под этот вид подходит следующий код
def test1 = json({
a1 : arr;
a2 : arr;
a3 : arr;
b : obj;
c : null;
d : [1, 3, 5, 7, 9, 11, 13, 15, 17, 19, 21, 23];
e : { a1:0, a2: 4, a3:8, "la la": null};
});
}]
def test2 = json({
a1 : arr;
a2 : arr;
a3 : arr;
b : obj;
c : null;
d : [2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24];
e : { a1:4, a2: 8, a3:12, "la la": null};
});
}]
def test = f(test1, test2);
в этом коде можно свернуть куски в один:
a) test1 и test2
b) последовательность a1, a2, a3
b) последовательность чисел в d
c) последовательность a1, a2, a3 внутри e
Re[20]: Веб и динамика? Веб и статика+метапрограммирование.
Здравствуйте, DarkGray, Вы писали:
Z>>С такими операторами и без смешивания мы не сможем работать. Подробнее расскажи о задаче, я тебе набросаю синтаксис.
DG>в максимально произвольном месте иметь возможность свернуть код вида: DG>
DG>где A, B, C(ит.д.) — фиксированные части, а i_n — изменяемая часть по определенным правилам DG>в код вида DG>
DG>генерация по i для шаблона A<i>B<i>C
DG>
Макросы работают не с текстом программы, а с AST. Они работают осмысленно, с валидными выражениями. Твой пример не может быть разобран в AST, ты хочешь собирать выражение из невалидных кусков. Это решается засовыванием всего в строку и собственным текстовым парсером. Любые конфликты со своим синтаксисом естественно будут на совести парсера.
Еще примеры конфликтов будут? Или сойдемся на том, что проблема конфликтов синтаксиса надумана?
Re[29]: Веб и динамика? Веб и статика+метапрограммирование.
VD>Ты не в состоянии отличить метода оптимизации от средства программирования. Вот в этом и вопрос.
средство программирования — это инструмент.
и как у всякого инструмента — у средства программирования есть цель и решаемая задача.
цель средства программирования — предоставить способ записи алгоритма оптимальным способом (оптимальность в широком смысле: в том числе рассматривается оптимальность по критериям: компактность, четкость, гарантии работоспособности, понятность, читабельность, скорость выполнения, разработки и т.д.)
решаемая задача: переписывание кода из одного вида в другой.
в частности — переписывание общего кода (например, C) в последовательность операций понятной данному процессору,
или переписывание из кода понятного макросу в код понятный платформе (.net, c#)
зы
и еще раз повторю, что данная решаемая задача: переписывание кода из одного вида в другой — это и есть суперкомпиляция чисто исходя из определения суперкомпиляции.