Здравствуйте, -VaS-, Вы писали:
VS>Мне эту ссылку принес вчера твиттер И вот что сказал автор по поводу странного использования немерла:
В подобном использовании немерла нет ничего странного. Это идеальный код для новичка преходящего с шарпа.
VS>Автор: just migrated http://code.google.com/p/cs2project/ to #nemerle. cool language VS>Я: Why do you not use any of the Nemerle unique features but just port the code almost line-by-line? VS>Автор: Simple reason, I first migrated the code as-is, and now I'm starting to learn the language. And liking it so far! VS>И согодня добавил: Have a look at the current state of the repo,any suggestions are highly appreciated,even if it's my first approach to Nemerle
VS>Так что я бы не судил его строго
Его никто и не судит строго. Более того ему сейчас нужна помощь. Нужно советовать как написать код крассивее, какие подходы можно использовать для его улучшения... Если кому-то не в лом, то помогите парню.
Я же говорил о том, что объем применения макросов зависит от разных факторов. И не в последнюю очередь от опыта и их понимания.
Проблема в том, что спроектировать задачу в виде ДСЛ-ей не так то просто. Без тренировки ты будешь мыслить теми категориями что были в твоем прошлом языке. Даже применение неизменяемых структур данных, ФВП, АлгТД и ПМ требует изменения способа мышления. А уж мышление моделями и языками — это уже совсем другой подход — отдельный скил. Сам грешен. Зачастую скатываюсь на C#-пное мышление.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
I>>Ты точно так же как и они агитируешь, отвечаешь вопросами на вопрос и уклоняешься от сложных вопросов. Пример I>>http://rsdn.ru/forum/nemerle/4812833.1.aspx
— а это евангелизм который уже лет пять назад набил оскомину I>>Так что не вижу разницы между тобой и другими евангелистами, ну разве что в качестве результата
VD>Ну, да. Ребята на пути понимания макросов. Ты на этот пут только пытаешься ступить. Понять их тебе проще.
Если бы ты меньше додумывал и фантазировал, то давно бы понял о чем я говорю.
>Мы же с тобой разговариваем на разных языках. Лично для меня аргумент — возможность изменить генерацию кода для своего ДЛС-я вообще не меняя прикладной логики. И возможность описания задачи на максимально высокоуровневом языке — это железные аргументы которые невозможно не понять.
Ты зациклился на плюсах непосредственно языка и ничего кроме них не видишь и не хочешь видеть. Вероятно, это по причине того, что кроме как в компиляторе ты лично никгде всерьез не применял немерле. У тебя есть серьезный продукт не направленый на разработку и писаный на немерле ? Нет. Ты перевел разработку в крупной фирму на немерле ? Нет.
Объясни, что ты мне можешь объяснить, если у тебя вообще нет опыта в том, что меня интересует больше всего ?
>Для тебя это, похоже, пока что, пустые слова. Зато мелкая автоматизация вроде генерация диспозов тебе понятна. Вот тебе и кажется, что тебе что-то там внушают.
Твои слова для меня ничего не значат. Ты кроме компилера не в состоянии ничего увидеть.
Здравствуйте, WolfHound, Вы писали:
VE>>Прекращай телепатировать, меня WolfHound спросил, я ответил. Ответ вас не устроил и вы теперь убеждаете меня, что я не разобрался, так ещё и ищу основание для того, чтобы не разбираться. У вас уже совсем евангелизм способность читать поел. WH>И твой ответ содержал 0 аргументов.
Понимаешь ли, ты спросил моё мнение, я написал. А далее ты решил зачем-то начать меня убеждать, что я не прав и почему ты лично считаешь иначе, а не спрашивать о том, почему я так считаю.
WH>И все твои последующие сообщения тоже не содержат ни одного аргумента.
А ты их и не спрашивал, тебя интересует только спор и попытка навязать своё мнение. Тебе процитировать?
— А что лучше макросов?
— Грубо говоря всё, я считаю, что развивать остальную часть языка, чем всё на макросах
— Нет, ты не прав, лучше делать макросы! Они круты и великолепны
Однако если всё же интересно, могу добавить, что вообще говоря в макросах как таковых нет ничего плохого, просто на данный момент макросы во всех языках — убожество. Они, конечно, уже далеко не те тупые сишные #define, работающие с текстом, но оперируют сильно другими сущностями, из-за чего метапрограммирование получается каким-то языком в языке. Ну, лучше, чем на шаблонах C++, но тоже хрень.
Вот на той же Агде гетерогенный список (тупл по простому) задаётся так:
data tuple {l} : (list {suc l} (Set l)) → Set (suc l) where
null : tuple []
cons : ∀ {a : Set l} {ts : list {suc l} (Set l)} → a → tuple ts → tuple (a ∷ ts)
Т.е. tuple параметризуется списком типов, и null — конструктор tuple [], а cons по значению типа a и туплу с типами ts (список его типов) создаст новый тупл с типами (a :: ts).
И всякие MapTuple, SelectFromTuple, конкатенация туплов — это не макросы, а просто функции.
Можно на макросах такое реализовать? Чтобы можно было объявить такой тупл и чтобы SelectFromTuple был бы простой функцией?
Здравствуйте, VoidEx, Вы писали:
VE>Можно на макросах такое реализовать? Чтобы можно было объявить такой тупл и чтобы SelectFromTuple был бы простой функцией?
Можно. На макросах можно сделать все, что умеет любой из компиляторов.
Но то, что ты это хочешь, говорит о том, что так и не понял, зачем нужны макросы. Тут
хорошо написано куда отправляются фичи общего назначения когда проект захватывают макросы. И то что ты хочешь фича общего назначения.
Которая нахрен ни кому не нужна.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, VoidEx, Вы писали:
VE>>Можно на макросах такое реализовать? Чтобы можно было объявить такой тупл и чтобы SelectFromTuple был бы простой функцией? WH>Можно. На макросах можно сделать все, что умеет любой из компиляторов.
Ну ты бы ещё Тьюринг-полноту вспомнил. А можно просто компилятор написать, да?
WH>Но то, что ты это хочешь, говорит о том, что так и не понял, зачем нужны макросы.
хорошо написано куда отправляются фичи общего назначения когда проект захватывают макросы. И то что ты хочешь фича общего назначения. WH>Которая нахрен ни кому не нужна.
Давай поподробнее. Ты утверждаешь, что любая фича общего назначения не нужна?
Здравствуйте, VoidEx, Вы писали:
VE>Давай поподробнее. Ты утверждаешь, что любая фича общего назначения не нужна?
Я утверждаю, что для решения задачи нужны фичи позволяющие решать задачу в терминах задачи.
При этом фичи общего назначения чуть менее чем всегда не имеют ничего общего с терминами задачи.
Максимум на что они годятся это кривая и тормозная эмуляция фичей заточенных на задачу. А как правило и с этим справится не могут.
Чем ты в своём примере с туплом и занимался. Причем что характерно ты опять делал фичу общего назначения.
Но тебе же всё равно, что я напишу. Ты же любыми средствами пытаешься доказать что макросы зло.
При этом ни одного аргумента подтверждающего твою точку зрения ты до сих пор не привел.
Ну что? Покажешь класс? Изобразишь на агде https://github.com/rampelstinskin/ParserGenerator ?
Да так чтобы по скорости на несколько порядков не сливал. И синтаксис описания грамматики был не хуже.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
VE>Т.е. tuple параметризуется списком типов, и null — конструктор tuple [], а cons по значению типа a и туплу с типами ts (список его типов) создаст новый тупл с типами (a :: ts). VE>И всякие MapTuple, SelectFromTuple, конкатенация туплов — это не макросы, а просто функции. VE>Можно на макросах такое реализовать? Чтобы можно было объявить такой тупл и чтобы SelectFromTuple был бы простой функцией?
Ну анонимные типы из C# в Nemerle вроде как раз макросом и реализованы. Так там с синтаксисом, и вроде даже с возможностью передачи между сборками. А просто объявить тип и функции работы с ним вообще без проблем.
. То что это сходу на макросах не получилось и выплыло на форум вопросом — лишь потому что в N1 реализация макросистемы не такая гибкая как могла быть. Да и это исправимо, где-то неделю работы надо вложить, просто у меня на прототип совсем мало времени было. Но в итоге даже не это нужно, а полноценные "макротипы". Например макротип Number может иметь все свойства и операции для чисел, но в процессе "рендеринга" в целевую программу, может подставлять вместо себя int, double, decimal или complex.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, VoidEx, Вы писали:
VE>>Давай поподробнее. Ты утверждаешь, что любая фича общего назначения не нужна? WH>Я утверждаю, что для решения задачи нужны фичи позволяющие решать задачу в терминах задачи. WH>При этом фичи общего назначения чуть менее чем всегда не имеют ничего общего с терминами задачи.
Как и сами макросы. А вот то, что написано на макросах — уже имеет. Ну или то, что написано на других общих средствах.
WH>Но тебе же всё равно, что я напишу. Ты же любыми средствами пытаешься доказать что макросы зло. WH>При этом ни одного аргумента подтверждающего твою точку зрения ты до сих пор не привел.
Зато ты привел аж чуть более, чем ноль.
Любая библиотека оперирует терминами задачи. Другое дело, что в слабом языке этот термин будет выглядеть object = SomeFactory.createObject(arg1, arg2, arg), что совсем неприглядно, но это не означает автоматически, что ситуацию способны исправить только макросы.
WH>Ну что? Покажешь класс? Изобразишь на агде https://github.com/rampelstinskin/ParserGenerator ? WH>Да так чтобы по скорости на несколько порядков не сливал. И синтаксис описания грамматики был не хуже.
Это наверное какой-то особый склад ума надо иметь, аргументировать повсеместную крутость метапрограмминга невозможностью написать нормальное решение одной конкретной чисто метапрограммерской задачи без метапрограмминга.
Здравствуйте, hi_octane, Вы писали:
_>Ну анонимные типы из C# в Nemerle вроде как раз макросом и реализованы. Так там с синтаксисом, и вроде даже с возможностью передачи между сборками. А просто объявить тип и функции работы с ним вообще без проблем.
Я про другое, про то, что SelectFromTuple — макрос. Кстати макросы высшего порядка есть?
_>Больше года назад я лепил прототип одного проекта. Вот посмотри чего хотел Именованные туплы и более типизированные массивы
. То что это сходу на макросах не получилось и выплыло на форум вопросом — лишь потому что в N1 реализация макросистемы не такая гибкая как могла быть. Да и это исправимо, где-то неделю работы надо вложить, просто у меня на прототип совсем мало времени было. Но в итоге даже не это нужно, а полноценные "макротипы". Например макротип Number может иметь все свойства и операции для чисел, но в процессе "рендеринга" в целевую программу, может подставлять вместо себя int, double, decimal или complex.
Мне кажется, что такие вещи должны решаться в несколько строк на нормальных макросах. В общем-то, в N2 мб так и будет.
Здравствуйте, VoidEx, Вы писали:
VE>Как и сами макросы. А вот то, что написано на макросах — уже имеет. Ну или то, что написано на других общих средствах.
Ох. Другие общие средства не позволяют достичь того уровня что позволяют макросы.
Ибо при использовании обычных средств всё равно получается куча говнокода.
VE>Зато ты привел аж чуть более, чем ноль. VE>Любая библиотека оперирует терминами задачи. Другое дело, что в слабом языке этот термин будет выглядеть object = SomeFactory.createObject(arg1, arg2, arg), что совсем неприглядно, но это не означает автоматически, что ситуацию способны исправить только макросы.
Ну попробуй добавить в свой тупл именованные поля.
Что? Не можешь?
Я такое знаю только в одном языке. Ur. Но там туплы в язык захардкожены.
А реактивное программирование на агде изобразить? А как на счет даталога?
Я вычислительные модели, которые ты делать запаришься, могу очень долго перечислять.
Ну и нельзя забывать про то, что есть еще куча прикладных вычислительных моделей. Которые появляются во время анализа конкретной задачи.
VE>Это наверное какой-то особый склад ума надо иметь, аргументировать повсеместную крутость метапрограмминга невозможностью написать нормальное решение одной конкретной чисто метапрограммерской задачи без метапрограмминга.
Давай ты покажешь не метапрограммерскую задачу.
Только чтобы её вычислительная модель 1 в 1 не отображалась на существующий язык общего назначения. Ибо на практике такое не происходит почти никогда.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Ну попробуй добавить в свой тупл именованные поля. WH>Что? Не можешь? WH>Я такое знаю только в одном языке. Ur. Но там туплы в язык захардкожены.
...вообще-то, туплы с именоваными полями есть в тонне языков...
Здравствуйте, Cyberax, Вы писали:
WH>>Ну попробуй добавить в свой тупл именованные поля. WH>>Что? Не можешь? WH>>Я такое знаю только в одном языке. Ur. Но там туплы в язык захардкожены. C>...вообще-то, туплы с именоваными полями есть в тонне языков...
На ur посмотри. Потом говори про тонну.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, VoidEx, Вы писали:
WH>Ну попробуй добавить в свой тупл именованные поля. WH>Что? Не можешь?
Весёлый ты парень, "поменяй-ка грамматику языка без метапрограмминга, что не можешь?"
Однако исходники Агда-компилятора открыты, если что. Так что могу. Правда почему-то менять компилятор напрямую некомильфо, а писать под него плагины — мегакрутая суперпупер технология.
А ты ленивость реализуй, не куцую Lazy, а полноценную. А потом тотальность. На макросах. А потом сравни с той, что сделана напрямую.
VE>>Это наверное какой-то особый склад ума надо иметь, аргументировать повсеместную крутость метапрограмминга невозможностью написать нормальное решение одной конкретной чисто метапрограммерской задачи без метапрограмминга. WH>Давай ты покажешь не метапрограммерскую задачу.
Забабахать систему, для которой идеально подходит Erlang.
Это только в мире эльфов на языке программирования пишут код, который нужен только для языка программирования.
Здравствуйте, VoidEx, Вы писали:
VE>Однако исходники Агда-компилятора открыты, если что. Так что могу. Правда почему-то менять компилятор напрямую некомильфо, а писать под него плагины — мегакрутая суперпупер технология.
Это твои фантазии.
С моей точки зрения это строго одно и то же.
Но если сделать ДСЛ для того чтобы описывать языки это будет намного проще чем пилить код на ЯОН.
VE>А ты ленивость реализуй, не куцую Lazy, а полноценную. А потом тотальность. На макросах. А потом сравни с той, что сделана напрямую.
На Н2 без проблем.
Но ты опять показываешь то что ты не понимаешь о чем вообще разговор.
А он о том, что для решения практических задач ни ленивость, ни тотальность, ни зависимые типы, ни множественное наследование,... не нужны.
Просто по тому, что задачи, которые решаются в их терминах в природе практически не встречаются.
Ты еще раз перечитай, что hi_octane пишет
.
WH>>Давай ты покажешь не метапрограммерскую задачу. VE>Забабахать систему, для которой идеально подходит Erlang.
Ты специально следующую строчку стёр да?
Ну, так я ее восстановлю.
Только чтобы её вычислительная модель 1 в 1 не отображалась на существующий язык общего назначения. Ибо на практике такое не происходит почти никогда.
Ну и забабахить это на Н2 будет ни разу не проблема.
VE>Это только в мире эльфов на языке программирования пишут код, который нужен только для языка программирования.
Это только в мире эльфов языки общего назначения идеально подходят под задачу.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>>>Я такое знаю только в одном языке. Ur. Но там туплы в язык захардкожены. C>>...вообще-то, туплы с именоваными полями есть в тонне языков... WH>На ur посмотри. Потом говори про тонну.
Я смотрел (уже достаточно давно). Что там такого особого конкретно в туплах?
Здравствуйте, VoidEx, Вы писали:
VD>>Ты палишся. Тебе никто не говорил "ты боишься".
VE>Тебе процитировать, кто и когда мне это сказал пару сообщений назад?
Давай. А то я в упор не вижу.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VoidEx, Вы писали:
VE>Прекращай телепатировать, меня WolfHound спросил, я ответил. Ответ вас не устроил и вы теперь убеждаете меня, что я не разобрался, так ещё и ищу основание для того, чтобы не разбираться. У вас уже совсем евангелизм способность читать поел.
Ага кругом враги.
Верь в это.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VoidEx, Вы писали:
VD>>Не уверен. Уловил, что скорее всего речь идет о трасформации кода. До ≡ идет паттерн распознающий некое выражение, а после ≡ идет паттерн формирующий переписанное выражение. При этом f и g это аналоги сплайсов в квази-цитатах, т.е. на их месте может быть произвольный код (или произвольная функция, что несколько более примитивно).
VE>Нет.
Ну, так объясни.
VE>Просто тип данных. Можешь сам таких написать с десяток.
Если это просто тип данных, то мне это просто не интересно. Зачем ты тогда этот пример приводил?
VD>>Короче на лицо описание трансформации кода.
VE>На лицо твоё непонимание.
Возможно. Так кому нужен язык который нельзя понять без проедания плеши в мозгу? В прочем, это уже другая тем. Ты что хотел своим примером то сказать? Раз это не описание трансформации кода, то к чему пример то?
VE>Ты смешон. Обвиняешь всех огульно в нежелании разбираться, а сам везде видишь паттерны и макросы "вид сбоку".
Ты что-то перепутал. Я не заходил в форум по Агде и не пытался доказать, что Агда не нужна, а посетители форума дурью маются. Это ты это пытаешься делать по отношению к макросам. Причем вообще не разбираясь в предмете. По сему я не обязан разбираться в Агде и читать примеры кода на ней. Не понял я твой пример, ну так объясни что в нем есть и как это надо понимать, если это важно для дискуссии.
Еще одно выступление про то что кто-то смешон или другие переходы на личности и ты пойдешь общаться с мамой на кухню. Хочешь говорить по делу, говори. А разводить здесь флэйм и флуд с переходом на личности не надо.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
_C_>+1. Метасвязки от Анонима — это, несомненно, будущее программирования. _C_>Если бы он мог объяснить, то сказал примерно следующее: _C_>компонентное программирование имеет очевидный недостаток — для скрепления компонентов нужно много рукописного, специфического кода. _C_>если представить, что компоненты будут свойствами "автосвязи" и "авторасширения" с компонентами, которые находятся рядом, то мы можем _C_>выйти на уровень роботов из жидкого металла, компоненты которых "знают" свое место и "знают" как реагировать со связными компонентами.
Я случайно пропустил слово, что исказило смысл высказывания:
компоненты будут свойствами "автосвязи" и "авторасширения" => компоненты будут обладать свойствами "автосвязи" и "авторасширения"
Здравствуйте, Cyberax, Вы писали:
C>...вообще-то, туплы с именоваными полями есть в тонне языков...
Они в них ахандкожены. Покажи язык в которых их нет, но можно их сделать средствами языка. При этом чтобы не страдала производительность и работа в IDE.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
И вот что сказал автор по поводу странного использования немерла:
