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

WP>> Это не всегда нужно.

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

Нет, это тоже расширение компилятора, но на более низком уровне. Более гибкое.

WP>>Например, параметром макры таки может быть строка (допустим, регулярное выражение). А разворачивается макра в код распознавателя для этого регвыра.

VD>Может. Но тоже желательно проверить, что это строка или выражение которое может быть во время компиляции приведено к строке.

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

VD>Ну, вот мы и пришли тому с чего начли. Nemerle — это как раз тот самый один из клонов Лиспа с подержкой вывода типов а-ля Хиндли-Милнер, наличием синтаксиса (похожего на смесь C# и ML) и основанном на мошьном рантайме предоставляющем отличную среду выполнению и огромную тучу библиотек.

Только сам рантайм имеет ограниченную область применимости, и эта мощная семантика недостаточно адекватно подходит в качестве "ассемблера" для компиляции довольно широкого класса DSL-ей.

VD>Так зачем мне, спрашивается, старые реализации Лиспа в которых меня коробит уже только то, что я вынужден связываться с тучей скобок и писать код в виде АСТ записывая выражения в полькой натации?

Кю. Вот уж чего никогда не понимал — что все к этим скобкам прикопались?

Вы хотя бы прочитали Зибеля? Очень рекомендую. Полезно, независимо от того, будете Лисп использовать или нет.

WP>> Возможно всё. Из Лиспа сделать Nemerle тривиально. Из Nemerle сделать Лисп тривиально.

VD>Тривильно? Ну, так сделай. Если получится, я с удовольствием на нем по программирую. А делать Нэмерл из Лиспа лично я не хочу. Это огномный труд, а не тривильное занятие.

Да ничего огромного. Семантика Немерля довольно примитивная, все алгоритмы — простые и хорошо известные.

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

VD>К тому же код банально не здорово написан. В нем не произведена декомпозиция. Но на любом языке можно свалить все в кучу и получить птичий язык. Это не проблема зяыка.

Да чего все решили, что меня качество кода беспокоит? Качество кода в большистве случаев выявляется тестами и профайлером.
Я вот об этом говорю:

| <[ { .. $props } ]> =>
   props.Map(fun(_) { | <[ $(n : name) : $(t : name) ]> => (n, t) })

ты посчитай, сколько на идентификаторы приходится всяких скобочек, палочек и долларов. Если ты надеешься, что Nemerle сможет стать мейнстримом и потеснить C#, то представь, что на нем будут делать люди, которые даже в менстримовой Java умудряются выдавать такое: http://thedailywtf.com/forums/61026/ShowPost.aspx

Standard:
Initialize all variables at the point of declaration; null is prefered for reference types and strings while min- and max- values are preferred for value types, e.g. DateTime.MinValue.

Code:

string docOwnerUsername = "null";

E>>C++ шаблоны для меня так же не являются верхом изящества. Поэтому от трехэтажных шаблонов в C++ меня начинает отворачивать уже даже по эстетическим соображениям.

VD>На шаблонах С++ подобные задачи не решаемы. Так что оставим этот разговор.

Разговор бы не о том, решаема ли на C++ подобная задача или нет. И решаема ли она в других языках. Разговор был о том, насколько читабельны выглядят решения на шаблонах в C++ или реализации макросов в Nemerle.

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

VD>Если метасистема генерируется на самой себе, то ей нежен так называемый boot для саморскрутки. Так вот если сгенерировать код в котором будет ошибка, и этот код скомпилируется, то может получиться так, что метасистема не сможет самораскутиться. Если при этом изменился формат метасистемы, то можно попасть в очень неприятную ситуцию когда или прийдется откатываться до рабочего состояния жертвуя новшествами, или как-то патчить исполняемые файлы.

VD>Если же есть генерируемые исходники, то можно просто поправить их.

Чего-то у меня с логикой.
А почему нельзя откатиться к версии генератора boot-а, которая была правильной?

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

VK>>Отправлю-ка я баг-репорт.

VD>Поделись, плиз, как это делается (баг-репорты отправляются). А то я тоже тут уже на парочку багов наткнулся. Незначительных, но все же...

Тебе .сюды.

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

WP>> Если не в AST программировать, то многоуровневые макры становятся кошмаром.

VD>Казалось бы. Но Окамл и Нэмелр вроде как отлично опровергли это утрверждение. Решением оказалось тривиально и от того гениально.

Нет. Сплайс-синтаксис и quotations — не решение. Оно работает идеально для одноуровневых макр. А для многоуровневых, для таких, в которых промежуточный AST фундаментально (N.B.!!!!) отличается от AST базового языка, он работать никак не будет. Точнее, будет, но с синтаксическими преобразованиями посерёдке между макрами. Перед макрой весь нагенерённый AST — в строку, в макре — обратно из строки. Неэффективно.

Я такого добра нарадовался уже предостаточно и с CamlP4, и с Template Haskell. И меня бесят макры R5RS за свою однопроходность.

VD>Просто нужно ввести средство преобразующее куски кода в АСТ и обратно. Квази-цитирование из Схемы оказалось ключем к решению проблемы.

Всё так (только quasiquote есть и в CL, точно так же как в Схеме). Но проблема остаётся — AST недостаточно общий. Нет и не может быть ничего более общего чем двоичное дерево S-выражений. С AST заточенным под один язык с довольно сложным синтаксисом мы не сможем создавать произвольные промежуточные языки, на нас этот сложный синтаксис накладывает непростительно много ограничений.

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

Маленький совет — постарайтесь отвыкнуть от Сищного синтаксиса. Он избыточен. Он ограничивает. Он просто объективно неоптимален. Посмотрите на Haskell.

WP>> Затем что язык, где прикручено много всякого разного — нишевой, узкоспециализированный язык.

VD>Хм? Что нишевого в Нэмерле?

Скомпилируйте (так, чтоб макра-компилятор была простой и понятной) в нём DSL с семантикой близкой к Прологу. Изобразить тупенькую низкоуровневую машину Уоренна на высокоуровневой сложной семантике Nemerle — это будет героический подвиг. Вами будет гордиться вся страна!

WP>> А метаязык, к которому можно приделать всё, из которого можно сделать любой другой язык — это универсальный язык.

VD>Хм. Вся императивная часть Нэмерла написана на его макросах. Так что воде бы как с их помощью можно слелать очень многое. Их ограничение скорее обусловенно не проблемами реализации, а сдерживанием маняков.

Так низкий уровень всё равно недоступен. Правда, к сожалению, сама семантика CLI недостаточно низкоуровневая. Конечно она лучше чем JVM, но всё равно, тяжко с ней жить. Намучался я, компиляя всякие Прологи, Хаскелли да конечные автоматы с матричными языками в этот CLI. Хорошо хоть хвостовые вызовы есть.

VD>Если уж я прекрасно решаю 90% задач на C# в котором метапрограммирования нет (точнее доступно только по средствам рантайм-кодогенерации или создания отдельных кодогенераторов),

Вы уверены, что ваши решения заслуживают эпитета "прекрасно"?

VD> то в Нэмерле я вообще проблем знать не буду. На крайняк в нем есть возможность получить доступ к токенам и сделать все что хочешь. Но надеюсь прибегать к такому низкому уровню, кстати, в общем-то к Лисп-уровную, я лично очень не хочу. Мне банально жалго свое время.

Жалко, не жалко — а ведь придётся. Задачи — они разные бывают. Если пойти по этому великолепному и прекрасному пути Language Oriented Programming, то начнут рано или поздно встречаться DSL-и с очень экзотической семантикой.

Вот вы тут Лисп за низкоуровневость и примитивность ругаете. А мне иногда и он тяжеловат, тогда опускаюсь до уровня Форта.

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

E>>В C++ для подобных экспериментов изобрели Boost. В .NET-е, похоже, Nemerle с макросами.
E>>Впечатление почему-то от исходников того и другого одинаковое

VD>Шаблоны С++, а стло бытьи Буст по этому поводу нервно курит в сторонке.
VD>Если сможешь с помощью С++-шаблонов сгенерировать код конструктора и эксесор-методы для полей, то я сниму перед тобой шляпу.

Ну вот опять попытка понять мои слова буквально, не обращая внимания на смайлик.
Для тех кто в танке (смайлик!):

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

В Nemerle, имхо, сложится такая же ситуация -- будет группка продвинутых Nemerle-истов (естников), которые будут писать библиотеки макросов и получать от этого удовольствие. А оставшееся большинство будут использовать эти библиотеки даже не пытаясь понять, как же эти библиотеки устроены. И не горя желанием сотворить что-нибудь подобное.

Именно этим-то Boost community, имхо, будет похоже на Nemerle macros community. Хотя эти community будут писать на разных языках и решать разные задачи, движущая сила у них будет одна и та же.

VD>ЗЫ

VD>Эх. Как бы заставить обратить внимание МС на этот проект?! Ведь сейчас проекту нехватает гарммотного коммерческого подхода. Сейчас нужно было бы произвести ревизию фич, заморозить проект и довести, что назвается, его до релиза! Ведь щастье так близко, но все может погубить отсуствие коммерческой жилки у проекта.

Many programmers and researchers still dream of a general-purpose language that is
so expressive, elegant, and efficient that it can cover all application areas for
all kinds of users without significant inconveniences. Some vigorously insists
that their favorite language actually is such a language. However, no current
language in major use fits this ambitious profile, and we don’t see a research
language that could possibly grow into that position in the short-to-medium
term (e.g., within the next 15 years).

Интересная статья Страуструпа.

Автор: Шахтер
Дата: 13.02.06

Хотя да, я забыл

Автор: VladD2
Дата: 18.01.06

:

...Видимо Страуструп из тех, кто мало понимает в теории построения компиляторов... теоретик...

он же уже не котируется

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

VD>Откровенно говоря очень чешутся руки засунуть свои подлые рученки в их компилятор.

Ну это желание вполне понятно. Благо исходники то есть.

VD>Как они смотрят на впускание в проект новых людей? Если мы создадим брэнч в их проекте и покалдуем над ним, они не обидятся? В смысле права дадут?

Не знаю. Вроде не должны.

VD>Как варинт, скопировать их проект создать клон у нас. А когда будем находить и исправлять ошибки, или добавлять фичи будем рапортовать орлам, чтобы они тоже вставляли.

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

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

VD>[Record] съедается компилятором, но вот конструктора у класса не создается (смотрел Рефлектором).

Влад, вот этот макрос у меня работает на ура (билд 0.9.2): Re[28]: Новая версия макроса

Автор: Oyster
Дата: 22.02.06

. И конструктор создаётся. У тебя не работает?

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

VK>Наверное это потому, что Record работает только для публичных полей. В общем нужно писать свой вариант Record.

В той версии, что у меня, он для всех полей делает. Из core.n:

def instance_flags = BindingFlags.Instance %| BindingFlags.Public %| 
    BindingFlags.NonPublic %| BindingFlags.DeclaredOnly;

// ...

def flds = par.GetFields (instance_flags);

// дальше использование flds

Вообще непонятно, почему у меня этот код

Автор: Oyster
Дата: 22.02.06

работает, а у остальных конструктор не генерится. Странно...

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

O>Отлично. А о перфомансе ты не подумал?

Ну во-первых мы же говорим не о перфомансе, а о принципиальной возможности реализовать такую фишку. К тому же нормальный там перфоманс для ряда задач, в число которых вполне можно отнести и работу с бизнес объектами. Все равно оверхед на все эти финтифлюшки будет почти не заметен по сравнению со временем которое будет уходить на БД.
Собственно чего спорить. Создай ContextBoundObject и сравни. Да, обращения к нему будут порядке на два медленнее чем к обычному классу, но при этом все равно очень быстрыми.

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

ВВ>>И чем он неполноценный?
VD>Ну, попробуй, например, на нем создать хэш-табличку.

Т.е. SQL тоже неполноценный язык программирования? Если я пойду и скажу это нашим базовикам, ты мне припарки делать будешь?

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

O>"Написанную на макросах" != "язык под это дело". Кто мешает пользоваться обычными макросами, которые не расширяют синтаксис? Потом, пихать макросы где только ни попадя не имеет смысла.

Пользоваться обычными макросами никто не мешает. Точно так же как никто не мешает и необычными тоже пользоваться.

ВВ>>И таких библиотек на большом проекте могут быть десятки. Причем в 90 случаях из 100 эти макросы не будут предлагать ничего по сравнению с обычным АПИ кроме другой формы записи.
O>Это, конечно, всё вопросы культуры кода. Тут, кстати, кто-то высказывал интересную мысль, что булшитеры не смогут писать макросы из-за их относительной сложности, а те, кто смогут, не будут булшитерами и будут макросы применять аккуратно

Тут довольно интересный момент. Немерле в каком-то смысле предлагает беспрецендентные возможности, последствия которых оценить довольно сложно. Сами синтаксические макросы как и любая диковинная новинка по своему очень привлекательны; я вот не считаю себя булшитером, но написать некую библиотеку не в виде АПИ а в виде некоего диалекта было бы весьма интересно.
Понятно, что можно вводить всякого рода ограничения и гайдлайны для применения макросов, однако сама необходимость подобных гайдлайнов уже немного напрягает.

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

ВВ>>Вот представь себе библиотеку для работы, скажем, с серийным портом всю написанную на макросах. По суть вместо некого КОМ-порт АПИ у нас будет специальный язык под это дело, причем еще не факт что удачного спроектированный. И таких библиотек на большом проекте могут быть десятки. Причем в 90 случаях из 100 эти макросы не будут предлагать ничего по сравнению с обычным АПИ кроме другой формы записи.
S>Я правильно понимаю, что речь идет о плохо написанной хорошей библиотеке?

А что, на макросах нельзя хорошо написать библиотеку?
Да если даже и так — что в этом удивительного? Мало ты что ли видел важного/нужного АПИ, которое в то же время было плохо спроектировано? Кстати, тот же самый АПИ для работы с серийным портом из Win32 "жжот" не по-детски.

O>В той версии, что у меня, он для всех полей делает. Из core.n:

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

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

ВВ>Ну во-первых мы же говорим не о перфомансе, а о принципиальной возможности реализовать такую фишку. К тому же нормальный там перфоманс для ряда задач, в число которых вполне можно отнести и работу с бизнес объектами. Все равно оверхед на все эти финтифлюшки будет почти не заметен по сравнению со временем которое будет уходить на БД.
ВВ>Собственно чего спорить. Создай ContextBoundObject и сравни. Да, обращения к нему будут порядке на два медленнее чем к обычному классу, но при этом все равно очень быстрыми.

Ну... возможно всё Даже сейчас можно юзать runtime codegeneration на C# вместо макросов. Но это будет неудобнее и медленнее, чем в Nemerle. Так же и с контекстами.

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

G>При чем тут дворник?

Аналогия такая. Хорошая.

G>аналогия неверная. мы про инструмент говорим.

И про тех, кто им будет пользоваться.

G>аналогия должна быть примерно такая: если мне нужно убирать мусор, то что надо выбрать — метлу, которая производится легко и дешева в освоении и производстве или супер-пупер пылесос сложный в освоении, дорогой, и с неизвестно какой надежностью?

Нет. Вот это — неверная аналогия. Задача гораздо сложнее, чем убрать мусор — а вы пытаетесь её решать теми же средствами, которыми убирали мусор.

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

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

Подойдёт. Сформулируйте поточнее — объём базы, количество элементов ГУИ, вид обработки (какая часть данных вводится человеком, какие данные и в каком виде пользователи должны получать, какое время доступа к данным из GUI).

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

G>О! может для примера RSDN@Home взять? благо про его разработку известно довольно много.

Ок, сейчас почитаю. Хорошая идея — взять готовый проект и просчитать, как его сделать эффективнее.

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

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

WP>> Не понял — какой такой автокомплит для графического языка?

IT>Слабо?

Я не понимаю вообще как оно должно выглядеть. Если вы такое видели — приведите пример. Ну, допустим, автокомплит в каком либо UML-редакторе.

AVK>>Ты недооцениваешь возможности Nemerle. Они позволяют, к примеру, эмулировать синтаксис Питона.

VK>Не надо демонизировать Nemerle. Эмуляция синтаксиса Питона сделана не через макросы. Это неотъемлемая часть компилятора. Макросами это сделать абсолютно невозможно. А то c какой легкостью эта фича была добавлена в компилятор лишь демонстрирует расширяемость исходников компилятора, не более того.

Да, это сделано не через макросы. Но! Макросами это сделать возможно, да ещё и тривиально. Hint: ничто не мешает засунуть в макру парсер.

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

G>>О! может для примера RSDN@Home взять? благо про его разработку известно довольно много.
WP> Ок, сейчас почитаю. Хорошая идея — взять готовый проект и просчитать, как его сделать эффективнее.
ваш вариант на чем будет сделан?