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

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

BZ>>от тебя больше 10 сооющений и все датированы 23:58. помогают навыки профессиональной машинистки?

я — само совершенство. можешь банить — как раз рабочая неделя начинается

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

AVK>Потому что LINQ прописан в стандарте и его будет обязан знать каждый, претендующий на звание C# developer. И когда я уйду из одной команды и приду в другую, там будет все тот же самый LINQ.

Ага. А в спецификации Nemerle описан list-comprehention выполненый в виде макроса и макрос foreach и что это меняет? Что помешало ввести макросы, реализовать LINQ на них, а потом ввести их в стандарт?

Текущее положение дел ведет к тому, что Шарп является объективно значительно более слабым языком и фич подобных LINQ-у нужно ждать от МС десятилетиями.

Наличие макросов не позволило бы упростить работу самих разработчиков Шарпа и тем самым ускорить появление тех самых LINQ-ов.

IT>>Индустрия банально не имеет макросов, поэтому извращается как может.

AVK>Спорно. Идее ситаксических макросов 200 лет в обед. Однако ж не прижились пока что.

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

К тому же, скажем идее фунционального типа еще болше лет (см. труды Чёрча по лямбдаисчислениям), но C# почему-то получил вместо него убогий делегат и только к версии 3.0 дорос до бледного подобия лябды и фуцкционального типа эмулируемого на обобщенных делегатах Fun<...>.

IT>> Проблемы pre-compile и run-time кодогенерации хорошо известны и, к сожалению, неразрешимы. Я, например, в своё время поимел много гемороя с pre-compile-time генерацей код. Народ по незнаю правил такой код вручную и когда это всплывало через несколько месяцев, то наступал полный паралич.

AVK>Это не проблема технических средств, это проблема организации процесса разработки.

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

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

IT>> Не потому ли, что это хоть что-то, что появилось в мейнстриме за последние 20 лет. А все те идеи о которых ты говоришь были всего лишь идеями и никогда к мейнстриму даже близко не относились?

AVK>Т.е. всемирный антимакросовый заговор? И Гейтс, поди, не последнюю роль в нем играет?
AVK>Должны же быть какие то причины отсуствия макросов в мейнстриме.

Вообще забвно. ИТ тебе говорит о том, что в С++ кривейший аналог макросов во всю исползуется программистами-практиками, а ты говришь, что отсуствуют.

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

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

M>Кодогенераторы тоже не являются языковыми средствами, но они тут активно обсуждаются, поскольку имеют много общего с макросами.
M>VM имеет непосредственное отношение к языковым средствам, так как для того и была создана — как промежуточный уровень абстракции между языком и железом.

Обясняю про ВМ... Есть работы преполагающие преобразование/модификацию/инструментирование и т.п. для байткода/MSIL-а. Например Феникс (похоже загнулся, правда). Работать на уровне МСИЛ-а выгодно с некоторой точки зрения и для некоторых задач. Но это делать тяжело. Уровень очень низкий, а убийственной технологии вроде квази-цитирования пока что на горизонте нет. Грубо говоря не придуманы решения как преобразовывать мсил просто.

Меж тем в мсил-е много информации уже потеряно, да и программист не особо может влиять на него. Он же пишет код на прикладном языке (например, на Васике).

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

Главное, что есть в макросах — это потрясаующе простая и удобная система их разработки. Квази-цитирование, паттерн-матчинг, атрибуты и некоторые другие решения позволяют писать макросы тем кто не толко ничего не понимает в мсил-е, но и мало что понимает в компиляторах.

M>IDE и VM были упомянуты не для перевода стрелок и отвлечения внимания. Они имеют непосредственное отношение к макросам, о чём я и написал достаточно подробно. Если вы этого не видите и не хотите видеть — так бы и сказали, мол обсуждать не хочу.

Как уже сказал IT в том же немерле принципиальных проблем с макросами нет. Интеграция с IDE использует основной компилятор (который реально реализован в виде DLL-и) запускаемый в специальном Intellisese-режиме. Объем специализированного кода крайне мал, так что подавляющее большинство изменений в компиляторе без единого вмешательства становятся сразу же доступны и в интеграции. Причем, прошу заметить, это положение дел сложилось при том, что при разработке компилятора и даже саомго языка автры вообще не думали о совместимости с IDE. Если же разрабатывать язык и (в особенности) компилятор с расчетом на работу в IDE, то можно избежать и те мелкие проблемы, что вылезли у нас.

IT>>Современные IDE фактически включают в себя компилятор. Как минимум какую-то его часть. Соостветственно, расширение компилятора может автоматически подхватываться IDE без особых проблем. Например, так сделано в том же Немерле.

M>Конечно это невозможно. Или мы о разных IDE.

Что "нонечно невозможно"? Ты внимательно прочел что тебе написали? Это работает. Это не просто теоретически возможно. Это работает на практике. Все новые макросы я разрабатываю под управлением VS 2005. И тестирую в ней же.

M>Скажем, у нас есть "расшитрение" для enum типов, и их использования в выражениях и switch/case. Для case value мы бы хотели в IDE иметь автодополнение, которое предлагало бы список перечислымых значений из декларации enum.

Расширения не безграничны. У них есть рамки. В этих рамках они подхватываются IDE. Есть понятие макроса. У макроса есть синтаксис. Синтаксис включает ключевые слова. Комплит считывает эти слова и рпедоставляет программисту-пользователю. Далее кода макрос написан код метода в котором использован макрос или типа скармливается компилятору который произвоидит его проверку и динамически подсвечивает строки с ошибками. Ну, и так далее. При это основной язык нельзя заменить на 100%. Его можно толко расширить.

M>Так вот, никаким образом этот тип автодополнения не появится автоматически из правил преобразования enum->class на уровне AST.

Ненадо фантазировать. Скачай последнюю версию интеграции и попробуй.

M>IDE уровня Eclipse или IntelliJ Idea понимает код, работает с ним на уровне семантики.

Ошибашся. Они работают даже на более низком уровне. Они работают на уровен типизированного АСТ. Именно на этом уровне с кодом работаем и мы. Просто язык расширяемый. Расширения загружаются и становятся доступны компилятору. Мы кормим компилятор расширеным кодам и читаем полученое АСТ. Далее остаетя только сопоставлять положение курсора и положения веток АСТ отфильтровывая нужные ветки.

M> Поэтому и является настолько удобным инструментом. А вы под IDE подразумеваете редактор+обработчик сообщений компилятора?

Иди скачай интеграцию: http://rsdn.ru/forum/group/prj.nemerle.aspx
И почитай статьи о языке: http://rsdn.ru/forum/group/prj.nemerle.aspx

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

M>Так я же написал — VM это рантайм плюс компилятор.

Что за компилятор? Джит?

M>Собственно говоря, после того как исходный код разобран (parsed & resolved), проверен на отсутствие ошибок — дальнейшая работа компилятора полностью автоматизирована (и представляет собой трансформацию дерева/графа), и может быть спокойно перемещена из source-to-bytecode компилятора в bytecode-to-native компилятор.

Я тебе скажу по сикрету. Все стадии компиляции — это набор процессов преобразования информации. Сначала из текста в список лексем. Потом из лексем в АСТ. Потом из АСТ в типизированное АСТ. Потом в МСИЛ. Потом (во время исполнения или инсталляции) в нэйтив код. Все это банальные преборазования. И каждая стадия преобразований чем-то уникальна. Информация которая есть на первых стадиях часто теряется на следующий. В мсиле уже нет и десятой доли информации из исходника. По этому макросы в Немерле это не один вариант, а несколько. Есть лексерные макросы. Есть макросы-атрибуты. Есть макросы-выражения. Есть макросы расширяющие синтаксис. Многие из них могут работать на раных стадиях компиляции. В общем, все довольно хитро, чтобы описать в двух слвах. И все делано не с бухты барахты.

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

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

M>Между языком и VM тоже нет принципиальной разницы. Можешь рассматривать байткод как некий язык программирования со специфическим синтаксисом.

Подумай какую глупость ты только что сказал?
VM — это абстракное понятие. Язык есть язык. МСИЛ, скажем или байткод Явы — это конечно язык. Только это низкоуровневый язык — ассемблер для конкретной VM.

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

M>Этот процесс ничем не отличается от компиляции исходников OCaml в C. Они могут компилировать свои исходники в байткод для своей VM, а могут в исходный код на С.

Мгут. И менять С-код так же тяжело как менять мсил. В ОКамле есть паттерн-матчинг и алгеброические типы. В С это будет преобразовано в море низкоуровневого кода и структур. Понять что за код был в оригинале будет уже очень не просто. Это уже будет нехилый реверс-инжиниринг. А это само по себе задача не простая.

M>Когда я говорю о расширении VM, то имеется в виду что-то вроде расширяемого байткода.

Остется понять зачем это надо и что это даст?

M> Так же, как в Nemerle вы можете определять новые операторы, так и для такой расширяемой VM можно определять новые инструкции.

Но это не разумно! VM понимает один низкоуровневый и от того примитивный ЯП. VM это море кода единственная задача которого преобразовать этот универсальный ассемблер в реальный машинный код конкретной машины. Это абстракция от железа. Расширять инструкции мсила просто бессмысленно. Вель прийдется писать скажем их реобразователи в машинные кода разных процессоров. Плюс встает вопрос а на основании чего генерировать эти расширенные инструкции? Ведь компиляторы знают только тот их набор что стандартизован. В прочем при расширении мсила о стандартах можно будет сразу забыть.

В общем, это бредовешая идея.

Ну, а как было сказано преобразователи мсила есть. Тот же проект Феникс.


M> Самый простой пример — определение SIMD операций, ты их можешь определить в Nemerle для работы с 3D вычислениями.

Какие SIMD-инструкции? Это же VM? Ее код может быть скопилирован как на древних 486-ых, так и на экзотических процессорах у которых вообще может многого не быть.

Задача вырабатывания SIMD-инструкций — это задача опримизирующего JIT/PreJIT-компилятора. Вот в проекте Феникс предполагалось что можно будет делать плагины производящие те или иные оптимизации для конкретных процессоров.

В общем, не надо путать теплое с мягким. Макросы — это для человека. Инструции VM — это абстрация от железа. Оптимизаторы — это средство оптимальным образом скомпилировать абстрактный мсил в конкретные инструции конерктного процессора. И заниматься такой ахинеей прикладному программисту просто бессмысленно. Пусть этим занимаются исседовательские институты, специализированные коммерчиские фирым и владельцы ВМ. А мы будет писать код.

M> Если это расширение компилятора — то эти операции должны будут скомпилироваться либо в вызовы библиотечных методов, либо развернуться в последовательность скалярных операций. Если это расширение VM, то эти операции будут скомпилированы либо в вызовы библиотечных методов, либо развёрнуты в последовательность скалярных операций, либо могут использоваться непосредственно аппаратные SIMD инструкции CPU.

Вот это и есть работа JIT-а. Пусть он думает как и что там делать. И не на базе каких-то там самопальных инструкций. А на базе самых что ни на есть универсальных. Более того низкоуровенвый код проще вообще запихнуть в нэйтив-библиотеки. Скажем библиотеку векторной или 3D-графики. Это дешевле и проще.


IT>>Что такое "расширение" для enum типов? Это новый тип типов или новый enum?

M>Новый тип типов. Мне его удобно для примера пользовать, так как в Java изначально небыло enum-ов, и они реализуются сравнительно просто в виде "расширения", как трансформация AST (кодогенерация).

Создать асолютно новый тип в Nemerle нельзя. Да и не ясно зачем, так как в нем есть и энумы и даже алгеброические типы. Можно как-то пометить или изменить имеющиеся типы. Или сгенерировать экземляр некого типа. Например, можно создать новое перечисление и заполнить его чем-то на основании информации почерпнутой из других частей кода. Как толко он будет создан, то интелисенс сразу его увидит и обеспечит автодополнение. А создать, скажем, Ява-энум в Немерле просто нельзя. Но можно создать обычный класс и заполнить его чем нужно.

M>Теперь внимание — вопрос.
M>Каким образом из правил кодогенерации (трансформации AST) IDE сможет понять, что red, green, blue — это константы, что автодополнение кода в case value должно выдавать список из red,green,blue, каким образом IDE узнает, что существуют только 3 варианта значения Color и что switch может иметь максимум эти 3 case-а и так далее. Эти правила (что есть enum как понятие) — присутствуют в мозгах программиста. Трансформация AST — это применение этих правил, а не определение этих правил.

Описанное решение повторить на 100% на Немерле просто неудастся. Если говорить гипотетически, то в принципе можно обеспечивать обработку всех методов и трансформировать код как нравится. В том числе и подменять его.

В общем, макросы не предназначены для введения в язык новых классов типов данных. Они могут создават экзепляры типов, менять код, генерировать новый код. В отличии от Явы в Немерел и так много встроеных типов. Скажем его Variant-ы намного мощьнее перечислений Явы. И писать для них подержку свитчей не надо. В прочем в Немерле нет и свитчей. Вместо этого есть мощьнейший оператор match который заменяет все остальные операторы ветвления (if-ы есть, но они реализованы в виде макросов).

Так что читай описание языка и все поймешь сам.

M>Idea и Eclipse построены именно на понимании явовского кода, а не его формальном AST представлении.

Нет. Idea, Eclipse, VS и любая другая интеллектуальная IDE оперирует именно АСТ. Снабженным информацией о типах, но все же АСТ. А код это всего лишь текст. АСТ же и есть его программное представление.

M> Кроме самого AST туда ещё много чего напихано. Именно поэтом миграция на Java 1.5 (в которой эти enum-ы появились, а так-же generics, autoboxing и прочее) заняла пару лет для IDE, уже после того, как компилятор был выпущен.

Пара лет ушла на то, чтобы попросту добавить поддержку этих фич в их копию компилятора. В Немреле (и об этом тебе сказали уже 20 раз) для целей поддержки интелисенса используется сам компилятор. Так что все что в него добавляется (или в нем исправляется) сразу же (после перекомпиляции компилятора и модулей интеграции) становится доступным как в компиляторе, так и в IDE.

IT>>Пофантазировать можно конечно. MS research работает над проектом Феникс, возможно это из этой серии.

M>Приблизительно то-же говорят те, кто считает ненужным расширяемые компиляторы. Типа, "пофантазировать можно кончено". Вы их спрашиваете — как же они не видят полезности расширяемых компиляторов, а я так-же удивлён, почему ваша фантазия заканчивается на компиляторе.

Да, как раз, нет. Они говорят о своих страхах. А зачем это нужно им понятно без объяснений. Вот АВК, например, сам использует пепроцессор созданный на базе XSLT для генерации классов по модели описываемой на XML-е. А Гапертон сам рекламировал препроцессор для ОКамла.

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

M>Как я написал выше, результирующее AST нам даёт очень мало, для понимания сути написанного. А если IDE не понимает сути написанного, то она превращается просто в редактор.

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

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

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

M>Я не говорю о сегодняшнем дне, я говорю о завтрашнем.
M>Вы говорите о Nemerle, который работает только в рамках фиксированного набора AST узлов (и расширения компилятора строятся на композиции узлов) — это день сегодняшний.
M>А я говорю о расширяемом AST, где узел дополнительно описывает свою семантику, которая и служит как компилятору, так и IDE и VM, для работы с данным типом узлов — это день завтрашний.

О. Вот мы и добрались до сути.

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

Ты же живешь мечтами. Твоего будущего просто не будет.

Что же касается текста, то очень многие продукты использовавшие ранее бинарные форматы (МС Офис, Опен Офис) стримительно движутся к текстовым форматам (на базе стандартного ХМЛ-я). Правда есть над чем задуматься?

Есть огромная разница между внтренним представлением компилятора/IDE и форматом хренения на диске. Нет никакой нужны хранить бинарную хрень если можно хранить читабельный текст. Формат для хранения придуман много лет назад. Это — текст. Никто не мешает представлять его как в виде фиксированного АСТ, так и в виде изменяемого (если оно оправдано). ВМ тут правда не причем. Так как это редставление и язык ВМ совсем разные вещи (мсил и байтод недопустимо, для обработки человеком, низкоуровневы).

Я еже, кажется, говорил, что твои идеи не новы. Джетбрэйновцы озвучивали похожую идею. Лично мне она кажется просто непратичной. Идея же программирования в АСТ и хранения бинарного формата была опробована еще в GUPTA SQL Windows в 1993-ем (есл не ошибаюсь) году. В итоде они пришли к тому что тоже позволили генерировать текст. Ничего эта идея им не дала.

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

Его расширяемости за глаза хватит на 10 поколений. Язык более расширяемый был придуман более 50 лет назад. Его имя Лисп. Он и сейчас жалеет всех живых (с). Гичше уже ничего не будет. Но такая гибкость просто ненужна людям. Она черезмерна и (парадоксально но факт) приводит к другим ограничениям. И заметь, Лисп тоже имет основную форму в виде текста. Вопрос преобразовния текста лисп-программы в S-вражения в памти — это вопрос пары строк на том же лиспе. И тут просто нечго обсуждать. АСТ Лиспа (точнее S-вражения) самый расширяемый формат на свете. Гибче ХМЛ-я. Так что если тебе нужно именно это, то бери идею.

M> Его расширяемость даёт слишком небольшой результат, по сравнению с возникающими проблемами.

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

M> В целом он лучше (хотя в частностях может уступать), чем тот-же C#,

Опять же, с удоволствием послушаю про частности.

M> но эти преимущества не настолько велики, чтоб тратить огромные средства на переучивание массы народа, переписывания массы сопутствующих средств вроде IDE.

Слушай. Заканчивай ты эту пропаганду. Ейбогу. Я с удовольствием послушаю о недостатках, но не от тебя, а от тех кто хоть как-то знает язык.

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

M>Мне кажется — это попытка перепрыгнуть пропасть в два прыжка.

Не. Это не попытка. Мы пользуеся этим средством и видим его приемущества. Нам не надо куд-то прыгать, чтобы понять это. А вот ты пыташся сравнить свою мечту (которой не можешь даже дать качественного обоснования) с тем, что уже есть. Пусть оно еще недоработано, пусть глючит, но есть. Его можно потрогать, воспользоваться им... и (главное) получить реальную выгоду. Все кто серьезно программирвоал на этом языке в один голос говорят о его преимуществе по срвавнению с имеющимися языками. И только те кто хочет найти недостатки не изучая сам язык с успехом их находят.

Конечно гипотетическая мечта, темболее своя, завсегда будет красивее рельно сделанного другими дела. Но тут в пору вспомнить о синице в руках и журавле, сами знаете где.

M> Если уже прыгнули в сторону расширяемости через трансформацию AST — то прыгать надо до конца, до полного использования AST на всех стадиях разработки программы. Заменить текст деревом. Конечно, так прыгать прийдётся дальше — зато больше шансов перепрыгнуть, а не потратить усилия впустую.

Что ты так волнушся. Везде АСТ и исползуется. Причем зачастую еще и типизированное. Тот же дизайнер форм использует именно его для генерации кода при сохранении изменений. А при считывании файла тоже скармливает его компилятору и получает АСТ на базе которого строит CodeDom. Так что дизайнер форм в осноном — это код трансформации АСТ в CodeDom и обратно.

M>Возможность добавлять новые типы узлов, работать с семантическим деревом, а не синтаксическим — позволяет и полную интеграцию расширений в IDE,

Опять же расслабься. Мы и так пользуемся всеми благами цевилизации. То что ты называешь "семантическое дерево" у нас называется типизированным АСТ. Оно не толко доступно нам, но и мы даже отображаем его ветки на ветка обычного АСТ. Это дает высокую точность позиционирования в коде.

Что до расширения самого АСТ, то это пербор. На то есть Лисп. Там АСТ гибок как список списков . Нам хватает того, что в АСТ есть ветки описывающие макросы и эти ветки могут иметь свой синтаксис (в довольно широких пределах).

И главное... нас не гнетет тот факт, что код хранится в текствых файлах. Зато их всегда можно отрыть через web и почитать даже без IDE.

M> и возможность генерировать разный код для разных target платформ,

А нам это без надобности. Это делают Моно и дотнет. Мы полностью абстрагированы от них интерфейсом Reflection.Emit и генерируемым им MSIL-ом.

M> и возможность использовать расширения в VM,

Нам они не нужны. Да и не дает хранение бинарной хрени никаких возможнсотей использовать какие-то там гипотетические возможности VM. VM вообще понятие виртуальное. Такой машины реально нет. Есть рантаймы которые читают и компилируют реальный и стандартизированный MSIL. Огромное приемущество использования MSIL-а заключается в том, что нас вообще не трогает как там работают эти рантаймы. Мы им даем стандартный MSIL они нам запускают программу. Моно по хуже, дотент по лучше, но в любом случае наша программа будет работать.

M> проводить компиляцию с минимальными потерями семантики (и за счёт этого максимально оптимизировать исполнение программы)

Это вообще глупость. Компилятор терят все что не важно для машинного кода. Чем более поздняя стадия тем больше он теряет. МСЛИ не содержит и 10% информации которая есть в исходника. Зато в процессе компиляции появляется информация о типах. Для одни задач она нужна. Для других нет. И мы можем ее использовать. А возиться с МСИЛ-мо — увольте.

M> и многое другое.

А зачем нам многое и другое?

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

Так что ты давай мечтай и вещай об этом миру. А мы потихоньку доведем свой примитивный инструмент до ума и начнем получать бенефиты.

На последок актуальный анекдот.

Послали директора колхоза делиться опытом западное фермерское хозяйство...
Приезжает он обратно и колхозники его спрашивают:
— Ну, что Семеныч... как там у них?
— Да... конечно у них на полях так чистенько. Кортошку они, конечно, собирают специальными машинами. Машины эти ни одной кортошины не повреждают и не пропускют. Собирают, сразу пакует в качественную тару и помещает в грузок. Дороги у них не как у нас — земляные, а все из бетона и асфальта. Чистенькие такие. Сами фермеры в чистой одежде...
— Ну, и?
— Но кода я им про наши планы рассказал, то они все на задницы сели!

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

BZ>я — само совершенство. можешь банить — как раз рабочая неделя начинается

Не поможет. Бан на чтение надо постараться чтобы заслужить

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

M>>Заменить текст деревом.

CU>Деревом-деревом!.. В виде списка... в текстовом файле

Уточню. Не прсто списка, а в виде S-выражения .

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


CU>>>Деревом-деревом!.. В виде списка... в текстовом файле

M>>Пробовали — херня получается , Lisp называется.

CU>1. "ниасилил"?

CU>2. Вы просто не умеете его готовить.

CU>P.S. Можно выбрать оба варианта

Ты это... окуратнее. А то тут и так проповедников лиспа выше крыши. И у всех психика хромает.

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

CU>>"Имя, сестра, имя!"

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

Наверно мне тоже не интересно. Так как я так и не смог его разглядеть. Идея отказаться от текстового представления мне разумной не кажется. Других идея (которых я бы не видел ранее) я так и не увидел.

Может ты в своей статье не о концепции расскажешь, а о том, как на твоем прототипе хотя бы гипотетически программку написать?

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

CU>P.P.S. Можете банить — не считаю необходимым вести спор "в техническом русле" с оппонентами, шарахающимися тех. информации как чёрт ладана.

Да, на саомо деле, и не за что банить...

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

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

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

Вот чем хороши фразы выдержанные в строгом софистском духе, так тем, что от замены ключевых слов смысл не теряется. Например:

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

или

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

или

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

Звучит как првда, вот люди и покупаются.

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

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

BZ>текстовым представлением программы. помесь макросов С со средствами управления самого pl/1. вот пример, генерящий 10 строк кода:

BZ>%do i=1 to 10 do
BZ>a(i)=0
BZ>%end

Куль. Однозачно, моя слеза будетв в два раза больше, когда я принесу букетик на могилу PL/1.

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

BZ>>текстовым представлением программы. помесь макросов С со средствами управления самого pl/1. вот пример, генерящий 10 строк кода:
BZ>>%do i=1 to 10 do
BZ>>a(i)=0
BZ>>%end
IT>Куль. Однозачно, моя слеза будетв в два раза больше, когда я принесу букетик на могилу PL/1.
Причем, оно, AFAIR, еще и использовал для макросов арифметику неограниченой точности

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

IT>Это не флейм. Это принципиальный вопрос. Одно дело, если ты с ними поигрался да и бросил. Другое — если ты использовал Open C++ в серьёзном проекте и твои утверждения о вреде макросов основываются не на домыслах, а на реальном опыте их применения.

Кстати, я как раз Open C++ пытался использоать. Он с макросами имеет столько же общего как R#. Это не макрос-система. Это система глобальной замены по коду. Причем без малешего разумного зерна. Никаких средств дкомпозиции нет в помине. Средства композиции примитивны. Информация о типах недоступна. Парсер неполноценный.

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

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

Да, вот, например, Питон хороший язык. В нем "это" додумались не называть макросами. Побочные эффектыи не контролируемость даже больше, но на душе спокойно. Это же ведь не макросы!

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

К>Будет новый набор решений, но вот обязательны ли для них макросы?
К>Имхо, нужно ограничить их реализумость/применимость/видимость. Т.е. сделать что-то аля "только программист с чёрным поясом по N может писать макросы и он должен учитывать по возможности последствия их применения".

Ребяты. Да что вы так беспокоитесь то? Поймите, ламеры их просто неспособны писать. Так же как ламеры не могут воспользоваться рекурсивными шаблонами в С++ или выучить Хаскель.

Тут действует естественный отбор. Его код не то что будет содержать фатальные ошибки. Он банально не скомпилируется.

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

K>Нет, немного не то. То какой в результате текст генерится можно в студийной интеграции посмотреть простым наведением мышки на макрос. Я имел ввиду полноценную отладку, такую как если бы это был обычный код. Т.е. поставить в каком либо месте брейкпойнт, пройтись через F10-F11 по коду, смотреть какие значения переменных в данный момент, следить за калл стеком, условные брейкпойнты итд итп

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

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

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

J>Понятно. Да, если это встроено — это здорово.

J>В принципе, это можно сделать и в нормальной среде/отладчике, которая/ый допускает вменяемое программирование себя (т.е. скидывать сгенеренный текст во временный файл, автоматом проставить там все брейкпоинты и заинклудить его куда надо). В принципе, это же я делаю вручную, когда отлаживаю макросы — просто ставлю в нужном месте #include "generated.h", где generated.h — это результат работы препроцессора, и в нем уже расставляю брейкпоинты. Правда, я сомневаюсь, что в студии можно такую автоматику навернуть.

Не сомневайся. Можно. Но это требует некоторого объема работ, а значит усилий и времени.

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

FR>Мне правильно кажется что в немерле вообще очень затруднительно не пользоватся макросами?

Ну, почему же? Истенному профи ФП это не составит труда. Опертор match и вызов/описание фунции в нем встроенные. Остельное, правда, почти все макросы, но это же не повод отчаиваться?