DG>>в максимально произвольном месте иметь возможность свернуть код вида:

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

Z>Макросы работают не с текстом программы, а с AST. Они работают осмысленно, с валидными выражениями. Твой пример не может быть разобран в AST, ты хочешь собирать выражение из невалидных кусков. Это решается засовыванием всего в строку и собственным текстовым парсером. Любые конфликты со своим синтаксисом естественно будут на совести парсера.

давай побуквенно, что именно не будет астом и почему в следующей записи?
синтаксис немерле ботать не хочу, поэтому синтаксис ближе к c#

F1(Enumerable.Range(1..2), n=>
def test__n__ = json({ 
    F2(ann : arr;)
      b : obj; 
      c : null;
      d : [F2(Enumerable.Range(0, 20).where(nn=>nn%2==0), nn=>n+nn)];
      e : { F2(Enumerable.Range(0, 2), nn => a__nn__:nn*4),   "la la": null};
    }); 
def test = f(test1, test2);

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

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

DG>давай побуквенно, что именно не будет астом и почему в следующей записи?
DG>синтаксис немерле ботать не хочу, поэтому синтаксис ближе к c#

Это почти корректный аст, опечатки не буду рассматривать. Выделенное — валидный идентификатор, в предыдущем примере, ты вместо него ставил test<n>
Такой аст ты вполне можешь проверить на наличие идентификаторов содержащих __n__ и сгенерировать нужные по шаблону.

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

DG>

DG>F1(Enumerable.Range(1..2), n=>
DG>def test__n__ = json({ 
DG>    F2(ann : arr;)
DG>      b : obj; 
DG>      c : null;
// вот тут проблема, макрос должен возвращать одно выражение, в итоге при раскрытии твоего макроса джейсон получит код вроде [ [1, ..., 21] ]
DG>      d : [F2(Enumerable.Range(0, 20).where(nn=>nn%2==0), nn=>n+nn)]; 
// тут похожая  проблема, F2 должен вернуть одно выражение, джейсон получит код {{a0 : 0; ...; a4: 16} "la la": null}
DG>      e : { F2(Enumerable.Range(0, 2), nn => a__nn__:nn*4);   "la la": null};
DG>    }); 
DG>def test = f(test1, test2);
DG>

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

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

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

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

ВВ>Это я не очень понял, к чему ты.
К отсутствию дублирования в некоторых стратегиях разделения обязанностей.
ВВ>Вон даже Хаскель вполне себе компилируют.
Проблема не в коде, а в окружении. Я по соседству комментировал.

ВВ>Хороший API можно написать даже на PHP.
Вот только стоимость написания будет зависеть.

ВВ>Но вот задача серверной части становится сильно сужена.
С чего бы это вдруг?
ВВ>Например, функциональный язык не даст мне никаких преимуществ — на сервере будет довольно грязный по большей части код. Интерфейсом этого кода станет HTTP, поэтому по сути уже не имеет значения какова там внутренняя архитектура — написан ли он в процедурном или в каком-то более другом стиле.
Это очень смелое утверждение. Мне вот отчего-то кажется, что написать RESTful API при помощи ASP.NET MVC значительно проще, чем, к примеру, на процедурном C.

ВВ>Серверная часть в первую очередь выполняет такие вещи как работа с данными, где скорость упирается в БД, поэтому статически-типизированный язык не даст каких-то значительных преимуществ, да и скорость этого языка практически по фигу — все в БД упрется так или иначе.
Это ещё одно очень смелое утверждение. Я не то, чтобы его опровергаю, но безалаберное обращение с кодом сервера приложений вполне способно заметно испортить общую производительность. Это раз.
Два — для скорости в СУБД важно уметь строить эффективные запросы. Наличие средств эффективного построения гарантированно корректных запросов сильно помогает.
Хотя, конечно, строить код типа if (MinAge != null) { whereClause += " AND Age>@MinAge"; params.Add(new SqlParam("@MinAge", typeof(int)); params["@MinAge"].Value = MinAge} можно и на PHP — вопросов нет.

ВВ>Каким образом? Основной код-то на ДжаваСкрипт. Как ты его анализировать будешь?
Стандартным образом: вызовы к серверу в JS будут генерироваться при помощи всё того же механизма. Тебя же не удивляет то, что чисто текстовые URL-и в тегах <A> и <IMG> можно сделать гарантированно корректными?

Z>Для решения этих проблем тебе придется засунуть весь код опять же в макрос который перепишет выражения. Только сама задача подобного генератора менее бредовой не становится.

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

Z> это ты пытаешься забивать гвозди микроскопом и генерировать код в стиле текстовых шаблонов. задача абсолютно не нужная в nemerle.

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

Z>// вот тут проблема, макрос должен возвращать одно выражение,

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

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

но часть AST-а — является лишь списком, а не деревом:
последовательность параметров функции,
последовательность декларации параметров функции,
последовательность операндов через точку (хз, как их правильно назвать),
последовательность инициализации массива,структуры и т.п.
и т.д.

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

ВВ>>Это я не очень понял, к чему ты.
S>К отсутствию дублирования в некоторых стратегиях разделения обязанностей.

Тогда не очень понял, что это за стратегии. Примерчик можно?

ВВ>>Вон даже Хаскель вполне себе компилируют.
S>Проблема не в коде, а в окружении. Я по соседству комментировал.

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

ВВ>>Хороший API можно написать даже на PHP.
S>Вот только стоимость написания будет зависеть.

Какие-то вещи на PHP можно сделать даже быстрее. И не в ущерб качеству. Библиотек — так, чтобы все работало "из коробки" — там тоже до хрена. Просто сам язык убогий. Но тут-то мы и подходим к интересному — каких-то особенных языковых возможностей тут, собственно-то, и не требуется.

ВВ>>Например, функциональный язык не даст мне никаких преимуществ — на сервере будет довольно грязный по большей части код. Интерфейсом этого кода станет HTTP, поэтому по сути уже не имеет значения какова там внутренняя архитектура — написан ли он в процедурном или в каком-то более другом стиле.
S>Это очень смелое утверждение. Мне вот отчего-то кажется, что написать RESTful API при помощи ASP.NET MVC значительно проще, чем, к примеру, на процедурном C.

Ну а причем тут С? Часто на С веб-приложения пишут? На PHP вполне сравнимо, мне кажется. На Nemerle или С# тоже будет практически одинаково.

Заметь, кстати, ты сравнил Си и ASP.NET MVC, т.е. корову и яйца. А не Си и C#. Т.е. что тебе упрощает твой РЕСТ-то на самом деле? Не язык, нет. Библиотека.

ВВ>>Серверная часть в первую очередь выполняет такие вещи как работа с данными, где скорость упирается в БД, поэтому статически-типизированный язык не даст каких-то значительных преимуществ, да и скорость этого языка практически по фигу — все в БД упрется так или иначе.
S>Это ещё одно очень смелое утверждение. Я не то, чтобы его опровергаю, но безалаберное обращение с кодом сервера приложений вполне способно заметно испортить общую производительность. Это раз.

Безалаберное обращение — это одно. А выжимать биты из тонкого клиентского кода, стоимость выполнения которого на порядки ниже стоимости запросов к БД — это уже совсем другое.

S>Два — для скорости в СУБД важно уметь строить эффективные запросы. Наличие средств эффективного построения гарантированно корректных запросов сильно помогает.

Я таких средств не знаю. Linq к ним не относится, к примеру.
Кстати, такие средства даже на уровне, скажем, C# кода вносят такой оверхед, что мало не покажется. Представляешь же как linq2sql работает? Не будешь же ты предлагать отказаться от него только потому что он пессимизирует скорость C# кода?

ВВ>>Каким образом? Основной код-то на ДжаваСкрипт. Как ты его анализировать будешь?
S>Стандартным образом: вызовы к серверу в JS будут генерироваться при помощи всё того же механизма. Тебя же не удивляет то, что чисто текстовые URL-и в тегах <A> и <IMG> можно сделать гарантированно корректными?

Мне, честно говоря, не особо знакома эта проблема. И совсем не знакомо рекламируемое тобой решение. Если ссылки генерятся с помощью какого-то механизма, то наверное нам уже все равно, на каком языке там код на сервере? На худой конец — парсер JS + валидатор ссылок, которые можно тупо натравить на исходники и получить результат, должны решить эту проблему чуть более чем полностью и без всякой статической типизации.

ВВ>валидатор ссылок

вот это что такое? и как он доказывает, что не будет сгенерена невалидная ссылка?

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

ВВ>>валидатор ссылок
DG>вот это что такое? и как он доказывает, что не будет сгенерена невалидная ссылка?

Запрос делает?

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

ВВ>Берешь и пишешь парсер своего языка, а также парсер ХТМЛ-я. На основе полученного АСТ можно генерировать код на целевом языке, который генерирует ХТМЛ.
ВВ>По сравнению с макросом задача усложняется тем, что нужен еще и парсер своего языка. Но его можно создать один раз и реюзать для дальнейших ДСЛ-ей.
Ты сам то понял что только что предложил сделать макросы?

ВВ>Есть и другие VM. Например, LLVM.
А там уже есть в поставке точный ГЦ
А как вставить свой без "теневого стека"?
Короче LLVM это то еще УГ.

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

WH>>Другие .NET языки не нужны.
G>Чувствую влияние темной стороны в твоих словах я...
Ну так объясни смысл других языков.

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

Z>>// вот тут проблема, макрос должен возвращать одно выражение,

DG>по опыту скажу, что вот это очень неприятное ограничение. очень ограничивает встраиваемость макросов.

Еще раз говорю, весь твой опыт тут работает против тебя, усиливая и без того не слабые заблуждения. У тебя просто нет опыта использования нормального метапрограммирования. Ты наверняка встречал людей незнакомых с функциональным программированием. Им довольно сложно объяснить профит от первоклассных функций. Тут все то же самое.

Давай я напишу правдоподобно выглядящие аргументы, почему делегаты в сишарпе лишние, а ты попробуй опровергнуть:

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

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

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

ВВ>>Берешь и пишешь парсер своего языка, а также парсер ХТМЛ-я. На основе полученного АСТ можно генерировать код на целевом языке, который генерирует ХТМЛ.
ВВ>>По сравнению с макросом задача усложняется тем, что нужен еще и парсер своего языка. Но его можно создать один раз и реюзать для дальнейших ДСЛ-ей.
WH>Ты сам то понял что только что предложил сделать макросы?

Я предложил внешний ДСЛ.
Макросы позволяют сделать внутренний ДСЛ.
А кардинальной разницы нет, да.

ASPX вот — тоже такой внешний ДСЛ. Просто очень убогий. И вместо парсера там регексы. Почему — я не знаю. Но мне слабо верится в то, что он убогий, потому что в C# нет макросов, и у МС не хватило денег и времени на разработку чего-то более вменяемого. Скорее были приоритеты другие на момент его создания + совместимость с ASP Classic.

Интереснее тут другое. Я в общем не очень понимаю, почему на вопрос "а насколько этим удобно пользоваться?" я получаю ответ "но зато это написано на макросах". И целый поток словоблудия, которое пытается меня убедить в том, что у меня просто нет прав не интересоваться, как тяжело жилось бы разработчику на макросах и как легко и просто задача была решена с ними. Проще говоря — почему любой разговор о Немерле должен сводиться к макросам? Я вообще не хотел их обсуждать. Преимущества макросов перед внешними ДСЛ-ями *для разработчика* очевидны. Но также очевидно и то, что внешние ДСЛ-и в принципе покрывают основные возможности макросов. И не имея поддержки макросов в языке я все же могу ДСЛ-и создавать. А вот поддержку циклических типов я в C# сам не добавлю, хоть об стенку убьюсь.

ВВ>>Есть и другие VM. Например, LLVM.
WH>А там уже есть в поставке точный ГЦ
WH>А как вставить свой без "теневого стека"?

Э, там вроде как раз идея в том, что каждый может реализовать свой ГЦ, именно тот, который нужен, для чего и предоставляются базовое API. Но надо делать, да. Впрочем, я не в курсе деталей.

WH>Короче LLVM это то еще УГ.

Да, да, я понял. Все написанные VM — это УГ. А все VM, которые не УГ, не написаны.

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

ВВ>Ты правда питон от других динамических языков не отличаешь? Я тебе писал выше — для питона это, может, и задача на грани фолла. По причинам дизайна языка. Но есть и другие языки.
Ну давай сделай IDE уровня немерла для своего любимого pure.
А я посмотрю...

ВВ>А для разработчиков, которые не пахают на большого и сильного вендора? Давай возьмем разработчиков OCaml, Haskell, Pure и пр.
IDE в современном мире является необходимым условием.
Соответственно люди который не заботятся о IDE при разработке языка дураки.
А те кто вместо того что бы грамотно сделать компилятор и использовать один и тот же код для компиляции и IDE делает работу дважды еще большие дураки.

ВВ>В реальности у вас получается не апология статики вообще, а пиар вполне конкретного языка. Только вот сравнивается он не с каким-то конкретным динамически-типизированным языком, а со всеми сразу — вернее с теми, которые наиболее удобны вам для сравнения.
Сделай IDE для pure.

ВВ>Зачем мне Agda2? Мы о Немерле или не о Немерле?
За тем что всегда можно найти фичу в которой нет в системе типов некоторого языка.

ВВ>Можно замутить что-то в стиле метаклассов питона. И таки да, типизатор отдохнет в таком случае. Доволен?
А в немерле сволочь такая не смотря на макросы не дохнет.
Теперь то тебе очевидно что твое утверждение

Если брать с чистого листа, то создание ИДЕ для динамически-типизированного языка и "языка вроде Немерле" — по сложности где-то близкие задачи. И там, и там будет хардкорный вывод типов

Бред.

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

ВВ>Мутабельные локальные переменные могут мешать выводу типов. Собственно, в общем случае их тип не выводится вообще. С ref гораздо проще. И в контексте разговора они сильно лучше мутабельных локальных переменных. При этом, что, собственно, ясно из названия, они обеспечивают ref семантику. Для мутабельных переменных пришлось бы вводить дополнительный механизм. А в плане опасности ref ничуть не опаснее хэш-таблиц, частным случаем которых и являются.
Бред!
Изменяемость переменной выводу типов не мешает.

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

ВВ>>>Берешь и пишешь парсер своего языка, а также парсер ХТМЛ-я. На основе полученного АСТ можно генерировать код на целевом языке, который генерирует ХТМЛ.
ВВ>>>По сравнению с макросом задача усложняется тем, что нужен еще и парсер своего языка. Но его можно создать один раз и реюзать для дальнейших ДСЛ-ей.
WH>>Ты сам то понял что только что предложил сделать макросы?
ВВ>Я предложил внешний ДСЛ.
ВВ>Макросы позволяют сделать внутренний ДСЛ.
ВВ>А кардинальной разницы нет, да.
А зачем ты написал выделенное?
Это же явное предложение сделать возможность внутри своего языка вставлять другой.
Те превратить нешний ДСЛ во внутренний но сделать это через задний проход.

ВВ>ASPX вот — тоже такой внешний ДСЛ. Просто очень убогий. И вместо парсера там регексы. Почему — я не знаю. Но мне слабо верится в то, что он убогий, потому что в C# нет макросов, и у МС не хватило денег и времени на разработку чего-то более вменяемого.
Именно так.
Они там все на С++ пишут...
А этот язык требует просто нереальное колличество ресурсов для разработки.

ВВ>Скорее были приоритеты другие на момент его создания + совместимость с ASP Classic.


ВВ>Интереснее тут другое. Я в общем не очень понимаю, почему на вопрос "а насколько этим удобно пользоваться?" я получаю ответ "но зато это написано на макросах".
Это твои фантазии.
Я тебе показал два примера которые в качестве внешних ДСЛ неюзабельны вообще но ты их проигнорировал.

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

DG>и еще раз повторю, что данная решаемая задача: переписывание кода из одного вида в другой — это и есть суперкомпиляция чисто исходя из определения суперкомпиляции.

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

Повторяю последний раз. Супер-компиляция — это метод оптимизации. Она не изменяет семантики кода. Главной же целью мета-программирования является изменение семантики кода.

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

DG>и еще раз повторю, что данная решаемая задача: переписывание кода из одного вида в другой — это и есть суперкомпиляция чисто исходя из определения суперкомпиляции.
Это компиляция.
Суперкомпиляция это выкидывание лишних вычислений без изменения семантики кода. Те просто очень крутая оптимизация.
Метпрограммирование это изменение семантики кода.

DG>>по опыту скажу, что вот это очень неприятное ограничение. очень ограничивает встраиваемость макросов.

Z> У тебя просто нет опыта использования нормального метапрограммирования.
Z> Ты наверняка встречал людей незнакомых с функциональным программированием. Им довольно сложно объяснить профит от первоклассных функций. Тут все то же самое.

имхо, ты что-то не понимаешь..

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

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

и всё это мне позволяет более-менее уверенно утверждать, что такое хорошее МП, а что такое плохое МП.

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

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

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

DG>на практике же речь обычно идет о специализированной автоматизированной суперкомпиляции.

Примеры этой "практики" в студию.

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

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

Ой, блин, поймал на лжи. Ну, да. Если быть точным, то авторы говорят о свойствах программы. Так что можно достигать меньшего или большего по объему кода или другого потребления памяти. Но суть от этого не меняется. Главное, что у программы не меняется семантика. Главным же свойством программы (если исключить семнтику) является скорость. Потому я о ней и говорю.

DG>еще раз повторю основную мысль суперкомпиляции:

Не надо мне рассказывать то, что я понимаю как минимум не хуже тебя. Ты лучше расскажи зачем ты ее сюда вообще прилел. Ну, причем тут мета-программирование?

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

DG>ничего кстати не напоминает?

Ничего. Оптимизация есть оптимизация. Семантика не изменяется.

DG>а это кстати и есть, например, linq2sql — по версии на универсальном языке формируется специализированная sql-версия этого же кода.

Ты правда настолько не понимаешь о чем говоришь, или это продолжение защитной позиции?

Кочай нести бред. Linq2sql не имеет никакого отношения к суперкопмпиляции. Это провайдер преобразующий статические вызовы в SQL и обратно. Сам же LINQ (в той его части что работает с деревьями выражений и поддержкой синтаксиса) — это встроенный в компилятор или реализованные средствами МП конвертер кода в типизированное АСТ и синтаксическая поддержка в языке. Все это опять же никакого отношения к суперкомпиляции не имеет, так как меняется семантика кода, а не его характеристики.

В общем, продолжай. Это довольно забавно.

WH>Суперкомпиляция это выкидывание лишних вычислений без изменения семантики кода. Те просто очень крутая оптимизация.
WH>Метпрограммирование это изменение семантики кода.

вторая строчка из вики

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

и там же правильное определение

Суперкомпилятор принимает исходный код алгоритма плюс некоторые данные о входных параметрах и возвращает новый исходный код, который является лучше исходного алгоритма по каким-то показателям

если не нравится слово "суперкомпиляция", то пусть будут "смешанные вычисления" по Ершову.

WH>Метпрограммирование это изменение семантики кода.

изменение какой именно семантики: аксиоматической, операционной или может денотационной семантики?

в виде определения, пожалуйста.

какую из этих семантик меняет введение foreach, using, peg-грамматики в язык?
какую семантику меняет linq2sql?

почему ту же самую семантику не меняет суперкомпиляция?

доказательство, пожалуйста.