Z>>Влад не то, что бы присваивает идеи, просто он регулярно делает компиляцию всего, что ему кажется разумным на текущий момент не расписывая где чья идея. То, что твои идеи туда попали говорит лишь о том, что Влад убедился в их разумности. WH>Проблема в том, что Влад начинает мне доказывать, что это его идеи.
Проблема в том, что ты достал подчеркиванием свой значимости. Ziwa совершенно прав. Мы в целом, и я в частности высоко ценим твое мнение и с интересом рассматриваем твои предложения, когда они четко сформулированы и не имеется веских аргументов против.
WH>И что я бы до этого никогда не додумался.
Это уже какие-то совершенно не понятные домыслы. Мне по барабану додумается кто-то до чего-то или нет. Если идея здравая, я ее рассматриваю и пытаюсь адаптировать к проекту в целом. Если нет — высказываю критику.
Если бы ты был конструктивен, то вместо того чтобы постоянно якать (Это придумал я! Тебя надо тыкать носом! Ты будешь говорить что это твои идеи!...) лучше бы реагировал на критику своих идей.
Я тебе уже раз 20 просил описать как ты собираешься реализовать linq с предварительной типизацией. Просил не случайно, так как на этот вопрос ты не сможешь дать корректного ответа не изменив свой первоначальный план. Ты упорно уходишь от ответа и продолжаешь повторять свое.
Вот такие идеи нам не нужны. Твое поведение не конструктивно. Идеи нужно не только генерировать, но отстаивать и развивать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Аноним, Вы писали:
А>Я, как представитель коллектива разработчиков корпоративного софта, планирующий использование в будущем Nemerle для разработки софта, подумываю — а нужен ли мне Nemerle, если внутри коллектива творится такая грызня ? А>Представляю, что не выносится на публику
На самом деле не на публике разговоры обычно спокойнее. Просто товарищ решил использовать форум для логирования обсуждения, так как боится что кто-то забудет об авторстве его идеи типизации до раскрытия макросов (которая до него была озвучена в ряде работ, например xoc).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Я бы описал ситуацию с точностью до наборот. Вот как-то (месяца три назад) я тебе подсунул идею использования Pratt-а, а через месяц ты меня задолбал объяснением того, что ты это все придумал.
Я придумал то, как скрестить ПЕГ с Праттом.
А ты очень долго мне объяснял, что это не возможно и нахрен никому не нужно. Ибо все могут ручками по распарсенному пробежаться и все что нужно получить.
А потом заявил что я бы без тебя не смог парсер оптимизировать
VD>Сейчас вот я тебе уже неделю пытаюсь доходчиво и спокойно объяснить, что полная предварительная типизация — это плохая идея, так как она зачастую просто избыточна, а иногда невозможна, так как семантика изначально задумывалась в терминах переписывания кода (является чистым синтаксическим сахаром). Но ты по прежнему упирашся рогом, не признаешь очевидного и постоянно терроризируешь меня своим "тыканьем носом" (попросту говоря — хамством).
Про соединения ПЕГа с праттом ты мне тоже самое говорил.
А до этого пытался убедить в том, что 2-3 деревья фигня и нужно обязательно делать RB дерево. При этом еще предлагал использовать кортежи, которые тормозят.
История повторяется в очередной раз.
VD>Я тебя понял. Идея типизации по SST придумана сильно раньше чем ты до нее дошел.
Я до нее дошел, когда начал вопросом интересоваться.
Просто раньше я не знал, как это сделать. А теперь знаю.
VD>Я ее видел и долго обдумывал возможность ее применения. В результате я пришел к выводу, что в чистом виде она не работает.
Поправка: Ты не смог придумать алгоритм, который будет работать.
VD>Ты пока что не занимался глубоким анализом, от того и думаешь, что все будет шоколадно. Если бы ты просто потрудился рассмотреть все аспекты, то наверняка согласился бы со мной.
В том то и дело что занимался.
У меня остался всего один пробел.
Формализация поиска имен.
Но интуитивно понятно, что это вопрос техники и ничего принципиально невозможного тут нет.
Когда я с ней закончу я тебе нарисую все твои "невозможные" примеры на раз-два.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>На самом деле не на публике разговоры обычно спокойнее. Просто товарищ решил использовать форум для логирования обсуждения, так как боится что кто-то забудет об авторстве его идеи типизации до раскрытия макросов (которая до него была озвучена в ряде работ, например xoc).
Ты опять передергиваешь.
Эта идея столь очевидна что на ней можно ставить "(С)КО".
Я логирую это обсуждение для того чтобы ты потом не заявил мне что ты всегда говорил что типизация АСТ хорошая идея.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
WH>>И что я бы до этого никогда не додумался. VD>Это уже какие-то совершенно не понятные домыслы.
Кто там мне втирал, что я никогда бы не додумался использовать в ПЕГ парсере один инт для всего?
Особенно учитывая то, что я это и придумал.
VD>Вот такие идеи нам не нужны. Твое поведение не конструктивно. Идеи нужно не только генерировать, но отстаивать и развивать.
Неконструктивно твое поведение.
Ты постоянно говоришь мне, чтобы я не изобретал алгоритмы.
Потом говоришь: ВАУ! Какой классный алгоритм!
А потом я всегда говорил что так и надо, а ты тут вообще не причем.
ДОСТАЛ!
Я теперь ВСЕ логировать буду.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
VD>>Очень часто данных у тебя не будет. Я уже устал повторять христоматийные примеры: linq, foreach, ... В них конкретные типы зависят от того во что макрос раскрывается. Это прямо в спецификацию C# записано. WH>А уже устал повторять, что вся информация есть.
Это треп. Пустой и бесполезный. Тебе еще раз привести цитату из спецификации linq?
Как говорится — show me code!
VD>>Сколтько можно игнорировать факты и упираться рогом в стену? WH>Вот. Вот. WH>Перестань упираться рогом в стену и прекрати нести пургу. WH>Самому же потом стыдно будет, когда это все заработает.
Да где же я упираюсь то? Я всего лишь прошу тебя описать то как ты будешь реализовывать спецификацию C# 3.0.
WH>И что характерно ты точно также упирался рогом, когда я алгоритм парсинга изобретал.
Я! Я! Я! Тебе не стыдно?
Я тебе напомню как дело было. Ты пришел с идеей использовать PEG и Пакрат как алгорит его разбора. Оценив Пакрат я тебе сразу сказал, что это не приемлемо по производительности. Ты поупирался, но в итоге выкинул его и начал оптимизировать обычный алгоритм рекурсивного спуска. Точно так же ты долго упирался с применением ДКА, в итоге таки реализовал его.
Если бы ты еще не отбросил идею создания списка возможных начальных символов для правила и проверку их до входа в правило, то глядишь мы еще процентов 10-20 отиграли.
Потом ты мне долго пилил мозг идей реализации идиотского алгоритма устранения левой рекурсии. Я опять же тебе почти сразу сказал, что он идиотский и на фиг не нужный. В итоге ты пришел к тому же мнению когда узнал о Пратт/TDOP.
О таких мелочах, как предложение использовать один int вместо двух переменных из оригинального Пакрата, ты уже целиком и полоностью забы. О том что скорость C#-пного парсера в значительной степени является заслугой Хардкейса ты даже и не думал.
Но, зато, от тебя постоянно слышно "Я! Я! Я!". Слово мы тебе похоже не знакомо.
Кстати, код порождаемый PegGrqammar-ом очень далек от совершенства. Там еще очень много можно (и нужно) оптимизировать. Достаточно взглянуть на результат декомпилятором, чтобы это стало очевидно.
ЗЫ
Мне по фигу кто какие иди предложил. Меня интересует результат. Я за свои идеи не держусь. Идеи — это не самоцель. Это всего лишь средство к достижению цели. А цель у меня одна — создать удобный, легко расширяемый, переносимый на другие платформы и мощный язык программирования. Язык который можно было бы расширять без приседаний и геморроя.
По сему я рассматриваю все идеи критически. Мне интересны не сами идеи, а идеи в разрезе конечной цели. Так что если ты что-то предлагаешь, то будь готов защищать свои идеи, и изменять их, если они не вписываются в общие задачи.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
WH>>У нас на входе макроса есть все данные, чтобы вывести тип.
VD>Очень часто данных у тебя не будет. Я уже устал повторять христоматийные примеры: linq, foreach, ... В них конкретные типы зависят от того во что макрос раскрывается. Это прямо в спецификацию C# записано.
VD>Сколтько можно игнорировать факты и упираться рогом в стену?
Ты можешь хоть обставиться минусами, если у тебя нет чего сказать — это ничего не изменит.
Тебе предъявили факты которые ломают твою стройную систему. Тебе придется или менять свою систему, или отказываться от нее. Третьего не дано.
И вот когда ты будешь менять свою систему (адаптировать ее к реалиям мира), ты вспомни свои наезды в мой адрес.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Это треп. Пустой и бесполезный. Тебе еще раз привести цитату из спецификации linq?
Да хоть заприводись.
У нас есть ссылка на объект.
По ней мы можем получить тип этого объекта.
У типа этого объекта мы можем получить методы с соответствующим именем.
Далее мы можем разрешить перегрузку.
Типизация линка ничем. ПОВТОРЯЮ АБСОЛЮТНО НИЧЕМ не отличается от типизации точки.
Но ты продолжаешь махать линком и даже не замечаешь что в спецификации типизация линка фактически сводится к типизации точки.
Разница лишь в том что в линке имена методов захардкожены.
Короче повторяю в пятисотый раз: У меня нет проблем с линком. У меня проблемы с поиском имен. Причем даже не проблемы, а просто слишком много вариантов того как это можно реализовать.
Я сейчас думаю над формализаций областей видимости и организации поиска имен.
VD>Я тебе напомню как дело было.
Я теперь все логировать буду
VD>По сему я рассматриваю все идеи критически. Мне интересны не сами идеи, а идеи в разрезе конечной цели. Так что если ты что-то предлагаешь, то будь готов защищать свои идеи, и изменять их, если они не вписываются в общие задачи.
А критики не было.
Есть упертая вера в то, что это сделать нельзя.
Все мои объяснения, почему это сделать можно проигнорированы.
Уверен аргументы из этого сообщения ты также не воспримешь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
VD>>Я бы описал ситуацию с точностью до наборот. Вот как-то (месяца три назад) я тебе подсунул идею использования Pratt-а, а через месяц ты меня задолбал объяснением того, что ты это все придумал. WH>Я придумал то, как скрестить ПЕГ с Праттом.
Молодец! Кто-то пытается присвоить эту заслугу? Вот если бы ты эту придумку еще и в реальный код воплотил, то благодарности прогрессивного человечества не было бы предела.
Якать то чего? Ты придумал как Пратт связать с Пегом. Я нашел этот самый всеми забытый Пратт и предложил скрестить его с ПЕГ-ом. В сумме мы молодцы.
WH>А ты очень долго мне объяснял, что это не возможно и нахрен никому не нужно.
Вот это вот чистая лож. Зачем мне было тебе это обяснять, если я же тебе этот Пратт и подсунул? Просто подумай... с какой еще целью я мог тебе подсунуть этот самый Пратт?
WH>Ибо все могут ручками по распарсенному пробежаться и все что нужно получить. WH>А потом заявил что я бы без тебя не смог парсер оптимизировать
У тебя какие-то необоснованные фантомные страхи. Я знаю, что ты хороший программист. Любой хороший программист может оптимизировать программу.
Но как это соотносится с обоснованиями идей?
WH>Про соединения ПЕГа с праттом ты мне тоже самое говорил.
Да, у тебя просто клинические провалы памяти. Еще раз предлагаю подумать о том зачем я тебе вообще подсунул этот Пратт.
Зачем я тогда вот эту
тему создавал?
WH>А до этого пытался убедить в том, что 2-3 деревья фигня и нужно обязательно делать RB дерево. При этом еще предлагал использовать кортежи, которые тормозят.
Я никогда не убеждал тебя, что 2-3. Я тебе только пытался донести мысль о том, что они не дадут зримого ускорения компилятора. И то что я не хочу заниматься их реализаций. В результате так и вышло. Ты заменил реализацию на 2-3, но компиляция не ускорилась ни на йоту.
WH>История повторяется в очередной раз.
Да какие истории? Пойми, ты высказываешь идею и тебя просят продумать ее практическое применение. Тебе высказывают критику и ждут от тебя аргументов. А что ты отвечаешь?
А уже устал повторять, что вся информация есть...
Начинаем тыкать носом:...
Это у тебя проблемы с памятью...
Я знал все что ты напишешь еще до того как ты это написал...
В моем варианте у компилятора всегда есть вся информация...
Он знает все типы...
Ну, кому интересна эта пурга? Тебя просят привести пример того как ты будешь решать реальные задачи. Видел я примеры приводил? Вот что-то вроде этого. С обоснованиями и комментариями. Так чтобы было понятно откуда таки взялись типы, которые "есть".
Ты вот привел пример простого if-а, и оказалось, что он во много раз сложнее того что было в Н1. Возникает резонный вопрос, если сложным стало простое, то насколько должно будет усложниться сложное? И мне не надо ответа в стиле "все будет просто". Мне нужна демонстрация. Так чтобы было что осмысливать, и если что, критиковать.
VD>>Я тебя понял. Идея типизации по SST придумана сильно раньше чем ты до нее дошел. WH>Я до нее дошел, когда начал вопросом интересоваться. WH>Просто раньше я не знал, как это сделать. А теперь знаю.
Проблема в том, что ты и сейчас не знаешь как это сделать. То что ты предлагаешь вызывает много вопросов. Но ты упорно их игнорируешь.
VD>>Я ее видел и долго обдумывал возможность ее применения. В результате я пришел к выводу, что в чистом виде она не работает. WH>Поправка: Ты не смог придумать алгоритм, который будет работать.
Ну, да я не смог. Ты же просто воздух сотрясаешь.
Заметь, ты 3 месяца не можешь реализовать интеграцию Пратта в ПЕГ. А там алгоритм, с твоих же слов, очень простой ведь. А тут ты рассуждаешь о сложнейшем алгоритме вывода типов. У тебя его тоже нет. Есть только общие мысли не учитывающие кучи деталей. А что, как известно, кроется именно в них.
VD>>Ты пока что не занимался глубоким анализом, от того и думаешь, что все будет шоколадно. Если бы ты просто потрудился рассмотреть все аспекты, то наверняка согласился бы со мной. WH>В том то и дело что занимался. WH>У меня остался всего один пробел.
Ты очень наивен. Я еще раз предлагаю тебе привести пример макроса типизирующий упрощенный линк (from x in xs where x.Test()).
WH>Формализация поиска имен.
В чем тут проблема? Ты и это предлагаешь на плечи прикладников возложить?
WH>Но интуитивно понятно, что это вопрос техники и ничего принципиально невозможного тут нет. WH>Когда я с ней закончу я тебе нарисую все твои "невозможные" примеры на раз-два.
ОК, с нетерпением жду. За одно подумай нед тем как твой подход облегчит интеграцию с IDE.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Я логирую это обсуждение для того чтобы ты потом не заявил мне что ты всегда говорил что типизация АСТ хорошая идея.
Это как это? Я именно за эту идею и выступал всегда. А ты перелагаешь всегда типизировать SST.
Более того, я в общем-то не против возможности типизации SST. Но как необязательной возможности, а не как единственной.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Кто там мне втирал, что я никогда бы не додумался использовать в ПЕГ парсере один инт для всего?
Не знаю. Я тебе всего лишь предложил это сделать. А додумался бы ты до этого или нет мне все равно.
WH>Особенно учитывая то, что я это и придумал.
Это не правда, так что учитывать мы это не будет .
ЗЫ
Предлагаю заняться делом. Мне просто жалко тратить время на обсуждения первенства идей и выслушивание очередной пачки заявлений в стиле "А уже устал повторять, что вся информация есть."
В следующий раз отвечу только на сообщение содержащее пример реализации linq и foreach с подробным объяснением происходящего. До тех пор считаю твою идею нежизнеспособной в чисто виде.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали: VD>Бэкэнды и есть плагины. Их архитектура уже проблемы тех кто их будет писать.
VD>Точно будут плагины до бэкэнда. Так то что я называю TAST скорее всего не будет монолитом, а будет иметь уровни. Вначале в TAST будут такие конструкции как замыкания, классы, методы, и т.п. Но будут преобразователи TAST цель которых может быть разной.
А теоретически возможно так внедриться в этот механизм, чтобы, скажем, получить перобразованное TAST в котором паттерн матчинг уже заменен на if'ы , но yield'ы (в том смысле как в C#) еще не раскрыты? Или там получится путаница с уровнями, с порядком раскрытия макросов, или чем-то подобным?
Чтобы это TAST преобразовать (заменить другое) и передать дальше.
Здравствуйте, WolfHound, Вы писали:
VD>>Это треп. Пустой и бесполезный. Тебе еще раз привести цитату из спецификации linq? WH>У нас есть ссылка на объект.
Нет никаких ссылок ни на какие объекты. Есть выражение "from x in xs select x.Test()". Для того чтобы правильно вычислить тип x надо подставить его в выражение xs.Select(x => x.Test()) и типизировать его по правилам языка. Только после этого можно будет сказать какой реально тип у "x". При этом должны учитываться такие вещи как наличие в xs реализации Select с подходящей сигнатурой, наличие открытых пространств имен открывающих методы расширения. То какая из перегрузок Select будет выбрана типизатором влияет на тип x. Например, может иметься перегрузка Select оперирующая с деревьями выражений. Это приведет к тому, что "x" станет не переменной, а частью дерева выражений. Плюс в дело могут вмешаться такие вещи как неявное приведение типов. Это тоже надо учитывать. В итоге, если попытаться выполнить всю эту работу, то получится, что ты повторишь все действия что производятся при типизации переписанного кода. А зачем это надо, если можно просто переписать код и произвести его типизацию? Ведь она уже есть.
WH>По ней мы можем получить тип этого объекта.
Не можем. У нас есть только имя. И еще у нас есть код x.Test() который так же зависит от наличия имеющихся перегрузок метода Select, и от того какую из перегрузок выберет типизатор.
Повторять эту работу просто глупо.
WH>У типа этого объекта мы можем получить методы с соответствующим именем. WH>Далее мы можем разрешить перегрузку.
Какую такую перегрузку? Напомню — ты предлагаешь типизировать SST. В SST нет даже вызова методов! В нем есть синтаксическая конструкция запроса. Макрос получит на входе всего лишь параметры содержащие имена и нетипизированные выражения.
WH>Типизация линка ничем. ПОВТОРЯЮ АБСОЛЮТНО НИЧЕМ не отличается от типизации точки.
Какой еще точки? Доступа к члену что ли? Дык ты даже не представляешь насколько не простая задача типизировать такие варжения. Оно в одиночку вообще не типизируется. Доступ к члену зачастую выливается в неоднозначность до тех пор пока этот член не начинают использовать. Далее следует сложный процесс разрешения перегрузки. В ходе этого процесса типизируются вложенные выражения. А в них могут быть свои макросы которые по твоей логике надо будет типизировать вручную.
И итоге для каждого отдельного языка ты будешь описывать процесс типизации отдельно. При этом ты будешь дублировать одно и то же по сто раз.
WH>Но ты продолжаешь махать линком и даже не замечаешь что в спецификации типизация линка фактически сводится к типизации точки.
Ага. Продолжаю. Потому что это приговор твоему подходу. И всем это будет очевидно как только ты начнешь писать код.
WH>Разница лишь в том что в линке имена методов захардкожены.
Как ты там говоришь? Сейчас я буду тыкать тебя носом! Вроде так?
В твоем подходе нет методов. Методы — это сущности более низкоуровневого языка. А ты хочешь типизировать до разложения.
Иначе чем это все будет отличаться от тупого раскрытия макроса без анализа типов и последующей типизации?
WH>Короче повторяю в пятисотый раз: У меня нет проблем с линком. У меня проблемы с поиском имен. Причем даже не проблемы, а просто слишком много вариантов того как это можно реализовать.
У тебя есть одни слова. Из них каши не сваришь.
Я же прелагаю не переваливать на прикладников задачи типизации и поиска имен. Это слишком сложные задачи. Можно дать прикладникам возможность типизировать SST в тех случаях когда это упрощает решение задачи. Для этого практически и делать то ничего не придется. Только предоставить АПИ. Это и сейчас можно делать.
WH>Я сейчас думаю над формализаций областей видимости и организации поиска имен.
Это по любому полезная работа. Давай! Но проблем с линком это не решает.
VD>>Я тебе напомню как дело было. WH>Я теперь все логировать буду
Давай! Только не интерпретируй по своему . ОК?
VD>>По сему я рассматриваю все идеи критически. Мне интересны не сами идеи, а идеи в разрезе конечной цели. Так что если ты что-то предлагаешь, то будь готов защищать свои идеи, и изменять их, если они не вписываются в общие задачи. WH>А критики не было.
Ну, как же не было? Вот твои предложения дальше общих слов не пошли. Потому и критику нельзя детальной сделать. Но как только ты покажешь код, то будет и детальная критика. Там уже за общими словами не спрячешься.
WH>Есть упертая вера в то, что это сделать нельзя.
Ты заблуждаешься. Если будут продемонстрировано что твой подход решает все проблемы и при этом не создает других, я тот част же стану сторонником твоей идеи. Но пока что я вижу обратное.
Что-то в твоей идее, несомненно, есть. Но проблем куда больше.
WH>Все мои объяснения, почему это сделать можно проигнорированы.
Да нет никаких обяснений. Ты путаешь свои голословные заявления с объяснениями. Объяснением могла бы быть демонстрация макроса linq-а и foreach с описанием происходящего. А фразы вроде "В моем варианте у компилятора всегда есть вся информация." это не более чем сотрясение воздуха. Они ровным счетом ничего не значат.
WH>Уверен аргументы из этого сообщения ты также не воспримешь.
Аргументы? Нет, конечно! Их попросту нет. Ты же не глупый человек и должен понимать чем аргумент отличается от голословных заявлений.
Пока что ты демонстрируешь не аргументы, а веру. А я в веру не верю .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Это как это? Я именно за эту идею и выступал всегда. А ты перелагаешь всегда типизировать SST.
Это все из-за твоей левой терминологии.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Silver_S, Вы писали:
S_S> А теоретически возможно так внедриться в этот механизм, чтобы, скажем, получить перобразованное TAST в котором паттерн матчинг уже заменен на if'ы , но yield'ы (в том смысле как в C#) еще не раскрыты? Или там получится путаница с уровнями, с порядком раскрытия макросов, или чем-то подобным? S_S>Чтобы это TAST преобразовать (заменить другое) и передать дальше.
Сложный вопрос. Преобразователи это просто функции на входе которого идет TAST в котором есть конструкции который он разбирает на запчасти, а на выходе TAST в котором эти конструкции уже разобраны.
Бэкэнд волен вызывать те преобразователи которые он считает нужным.
Вклиниться между этими вызовами, несомненно, будет можно.
Но можно ли будет переставлять местами такие преобразования я не могу сейчас сказать. Возможно между ними будут зависимости. Ведь преобразователи оперируют конкретным форматом. Если в этом формате не будет чего-то хватать или будет что-то лишнее, то они могут потерпеть неудачу или сгенерировать некорректный код.
В общем, это уже слишком глубокие детали, чтобы на них можно было ответить точно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Вот это вот чистая лож. Зачем мне было тебе это обяснять, если я же тебе этот Пратт и подсунул? Просто подумай... с какой еще целью я мог тебе подсунуть этот самый Пратт?
Ты доказывал что Пратт "сбоку" это хорошо.
Я говорил что плохо.
Ты упорно не верил.
VD>Да, у тебя просто клинические провалы памяти. Еще раз предлагаю подумать о том зачем я тебе вообще подсунул этот Пратт. VD>Зачем я тогда вот эту
тему создавал?
Вот сам эту тему и прочитай.
Что ты там мне про Пратт "сбоку" говорил...
VD>Ты вот привел пример простого if-а, и оказалось, что он во много раз сложнее того что было в Н1. Возникает резонный вопрос, если сложным стало простое, то насколько должно будет усложниться сложное? И мне не надо ответа в стиле "все будет просто". Мне нужна демонстрация. Так чтобы было что осмысливать, и если что, критиковать.
Я привел набросок без грамма сахара.
Можешь посмотреть на обновленный вариант
.
VD>Проблема в том, что ты и сейчас не знаешь как это сделать. То что ты предлагаешь вызывает много вопросов. Но ты упорно их игнорируешь.
Это ты упорно игнорируешь ответы.
VD>Заметь, ты 3 месяца не можешь реализовать интеграцию Пратта в ПЕГ. А там алгоритм, с твоих же слов, очень простой ведь.
Мне просто лень это делать.
VD>А тут ты рассуждаешь о сложнейшем алгоритме вывода типов. У тебя его тоже нет. Есть только общие мысли не учитывающие кучи деталей. А что, как известно, кроется именно в них.
Черт в деталях это к твоему подходу. Ибо он бессистемный.
Как ты собрался снимать работу с пользователя по типизации собственных ДСЛ? PegGrammar без типизации не сделать.
Как ты собрался делать автокомплит для пользовательских ДСЛ?
Как ты собрался реализовать ?. в своем подходе?
...
VD>Ты очень наивен. Я еще раз предлагаю тебе привести пример макроса типизирующий упрощенный линк (from x in xs where x.Test()).
Я абсолютно реалистичен.
Все что мне нужно это механизм поиска имен.
Его я пока не формализовал.
VD>В чем тут проблема? Ты и это предлагаешь на плечи прикладников возложить?
В простых случаях это будет не надо. Но для чего-то более сложного чем if он и так на их плечах.
Вон в том же PegGrammar приходится имена искать.
Жутким императивным кодом, между прочим.
VD>ОК, с нетерпением жду. За одно подумай нед тем как твой подход облегчит интеграцию с IDE.
Он изначально создается для интеграции с ИДЕ.
Так как вся типизация будет производиться декларативным кодом, по которому можно сгенерировать, что угодно то вся информация нужная ИДЕ будет автоматом.
Так что я уже подумал.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Не можем. У нас есть только имя. И еще у нас есть код x.Test() который так же зависит от наличия имеющихся перегрузок метода Select, и от того какую из перегрузок выберет типизатор.
У тебя в твоей системе есть только имя.
У меня есть все что нужно.
Читай тут.
Там есть половина ответов.
Остальная половина будет, когда завершу формализацию поиска имен.
VD>Повторять эту работу просто глупо.
А я и не собираюсь.
VD>Какой еще точки? Доступа к члену что ли? Дык ты даже не представляешь насколько не простая задача типизировать такие варжения.
Думаю я это представляю не хуже тебя.
VD>Оно в одиночку вообще не типизируется.
Я в курсе.
И я собираюсь его бесшовно вписать в систему.
VD>Доступ к члену зачастую выливается в неоднозначность до тех пор пока этот член не начинают использовать. Далее следует сложный процесс разрешения перегрузки. В ходе этого процесса типизируются вложенные выражения. А в них могут быть свои макросы которые по твоей логике надо будет типизировать вручную.
Ты упорно не понимаешь мою логику.
Совсем.
Я вообще ничего вручную делать не буду.
Паттерны куда более "веселая" штука, чем все линки вместе взятые.
Вон посмотри по ссылке.
Там все настолько просто, что даже скучно.
VD>И итоге для каждого отдельного языка ты будешь описывать процесс типизации отдельно. При этом ты будешь дублировать одно и то же по сто раз.
А повторное использование кода уже отменили?
VD>Это по любому полезная работа. Давай! Но проблем с линком это не решает.
Само по себе нет. Но в сочетании с остальным легко.
VD>Ты заблуждаешься. Если будут продемонстрировано что твой подход решает все проблемы и при этом не создает других, я тот част же стану сторонником твоей идеи. Но пока что я вижу обратное.
Так твои взгляды постоянно эволюционируют вот по такому паттерну:
1)Невозможно!
2)Круто!
3)Я всегда говорил что так и надо.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, VladD2, Вы писали:
VD>>Очень часто данных у тебя не будет. Я уже устал повторять христоматийные примеры: linq, foreach, ... В них конкретные типы зависят от того во что макрос раскрывается. Это прямо в спецификацию C# записано. WH>А уже устал повторять, что вся информация есть.
Информация то конечно есть но хотелось бы подробностей что такой механизм даст.
Ты предлагаешь, условно говоря, для макроса кроме тела хранить еще абстрактное представление. Это абстрактное представление закодировано констрейнтами, неважно в каком виде, хоть через require:..., хоть на урезаном mercury.
По этому абстрактному представлению код построить нельзя, но можно провести типизацию с точно таким же результатом как по получилось бы макросу, но с лучшим перфомансом.
А сам запутанный процесс типизации-раскрытия макросов, где макросы друг в друга вложены, перемешаны, повязаны связями, он как-то изменится? И как пострадают от этого возможности?
Если вопрос только в каком формате описывать констрейнты, то это, наверно, можно в любой момент безболезненно переписать,дополнить?
. ОК? 
