Здравствуйте, VladD2, Вы писали:
V>>Элегантность была в однозначности конструкций. Это ушло.
VD>Ты высосал ее из пальца. Подобные проблемы были в шаре всегда.
Например?
V>>Нет, спецификации и правила ресолвинга сигнатур ф-ий постоянно добавляются.
VD>Ага. Но исходные проблемы идут из 1.0. Правила для params с тех пор вообще не менялись.
Упомянутый мною "глюк" без params.
VD>Правила выбора перегрузки и переопределения все родом из 1.0. Почитай этот стандарт так как это делает Ников и поймешь, что ты не прав.
Я уже понял, что не в курсе про это ломающее изменение, но зачем же сразу пресловутое "пойди почитай"?
Вот простой код, что выведет?
namespace ConsoleApplication2
{
class Base
{
public void Method(short value) {
Console.WriteLine("short");
}
}
class Derived : Base
{
public void Method(int value) {
Console.WriteLine("int");
}
}
class Program
{
static void Main(string[] args) {
short value = 0;
new Derived().Method(value);
}
}
}
В разных версиях компилятора разный результат.
VD>Покажи что изменилсь в Шарпе, что привело к проблеме.
Раньше выводил short, теперь int. И как теперь наследоваться от BinaryWriter с целью, например, расширения сигнатуры Write?
В принципе, понятно как, нельзя использовать такое же имея метода Write, или же нельзя наследоваться, а нужно агрегироваться и писать два десятка делегирующих методов, и так на каждый наш BinWriter, но это ...
(приводить явно к базе в нужных местах — самое ненадежное решение)
Здравствуйте, VladD2, Вы писали:
V>>Каждый из них более специализирован относительно другого, примерно так. Но они оба разработаны как языки общего применения, поэтому пример не очень удачный.
VD>Во-вот. Это бред плиз больше не повторяй. Это два универсальных языка. Они возможно отличаются мощностью. Но по возможностям они идентичны.
Я че-то не догоняю манеру спора, объяснишь мое и твое выделенное, и как ты получил несогласие?
VD>В тебя какое-то свое определение ДСЛ-ей. ДСЛ — это язык прикладной области, а не ограниченый ЯПОН. Может от того ты и споры эти разводишь...
Тем не менее, если DSL не декларативный, а алгоритмический, обычно его делают на основе урезанной версии некоего ЯПОН, и сие факт. И я не столько спорю, сколько информацию тебе сообщаю.
V>>Нууу... с позиции активного пользователя языка с развитой макросистемой, ты конечно можешь себе позволить поострить.
VD>Вообще-то с вами не согласны AVK и IB. Они, мягко говоря, Немерл не используют.
Ну значит для их задач им хватает одного языка общего назначения. Мне для моих задач одного C# не хватает. Двльше что? Я ведь не только DSL приводил, если помнишь, упоминал C++/CLI и VB.Net.
Да и вообще, можно я твои остальные рассуждения проигнорирую? Сейчас объяснюсь: ты проводишь эдакую жииирную красную черту м/у DSL и языками общего назначения. Это твое личное право, но это никакой не агрумент в споре, и тем более не оправдание для высказываний насчет "каши" в голове у собеседника. Для меня все языки — суть инструменты, для каждой задачи я выбираю наиболее удобный. Да, учитывая, что есть перегрузки операторов, или макросы в твоем N, иногда некое подобие DSL можно сделать в самом языке, и если это не во вред задаче — я только ЗА, ибо мне, как разработчику только проще. Но и это не всегда так, ибо бывают уже и наработки и не только мои, например есть очень хитрые наработки по сериализации протокольных структур в поток на основе CORBA IDL, хотя сам протокол CORBA не используется, и лишь используется компилятор от нее для генерации кода эффективной сериализации данных и генерации discriminated unions.
На самом деле, конкретные решения я принимаю исходя из требуемой трурдоемкости, наличия инфраструктуры, наработок и т.д., и только в последнюю очередь по причине DSL это или ЯПОН. Да, солянка зыков в проекте получается автоматически, и среди них обычно как несколько ЯПОН, так и несколько DSL.
V>>Но в ситуации, когда никто разрешение на использование Nemerle не даст, даже для разработки внутреннего инструментария, приходится пользовать DSL.
VD>Некорректное противопоставление. Немерле не заменяет DSL-и. Он, наоборот, упрощает их разработку и поощряет их использование.
Он способен заменить зоопарк DSL, именно по той причине что ты написал. С чес споришь?
VD>Что до ваших менеджеров, то или они придерживаются консервативных позиций, или они дятлы.
Это не менеджеры, а заказчики. Это не дятлы, это перестраховка — где они потом найдут программистов на Nemerle, если потребуется что-то менять/развивать в проекте?
VD>Ну, не все же так действуют? Кое кто и ПО продает, а не его исходники. VD>Если нужно решать более сложные задачи малыми силами, то очень даже стоит задуматься о выборе более мощных средств разработки. Не находишь?
Блин, я же тебе конкретно описал, в каких условиях Nemerle неприменим. Пойми, практически всегда заказная разработка происходит с передачей исходников, и очень редко наоборот.
Здравствуйте, vdimas, Вы писали:
V>Вот простой код, что выведет? V>
V> class Base
V> {
V> public void Method(short value)
V> }
V> class Derived : Base
V> {
V> public void Method(int value)
V> }
V> short value = 0;
V> new Derived().Method(value);
V>}
V>Раньше выводил short, теперь int.
Хм. А когда он выводил short? В C# 2.0 правило о самой производной реализации уже точно было. Неужели в 1.0 было по-другому? Мне сейчас уже не вспомнить.
Здравствуйте, vdimas, Вы писали:
V>Конечно не противоречит. Противоречит лишь их эмуляция на наследовании. Кстати, в Немерле типы-члены АТД запечатаны вроде, т.е. по ним нельзя далее наследоваться?
Да. Но в Скале, например, это не так (хотя опять же можно запечатать классы вручную). Да и в Немерле сами варианты можно наследовать от классов. Более того можно делать МП по классам. Порой это очень удобно.
Надо заметить, что нет ни одного ООЯ в котором нельзя было бы нарушить принципов Лисковой. Так что возможность нагородить невнятного кода есть везде. И эти приципы нужны только чтобы не опытные программисты на нагородили огород.
Та же фигня и с ПМ. Его бездумное использование может привести к проблемам на уровне дизайна приложения. Но можно же делать и грамотный дизайн.
На практике я не встречал никаких проблем с МП, даже когда он соуществлялся по типам или значениям. Возможно это потому, что я несколько перерос стадию бездумно быдлокоденья. Но я далеко не идеал. Я весьма ленив и не всегда могу оторваться от куска кода чтобы подумать обо всем приложении. Но все же это не создает особых проблем.
Так что все эти страхи высасоны из пальца. Теоретики, вроде тебя, раздувают эти страхи до масштабов вселенского зла. Меж тем возможно имеет смысл задуматься над выработкой новых правил и табу вроде принципов подстановки Лисковой, но уже учитывающих наличие более мощьных механизмов анализа данных вроде МП.
V>Почему я высказался? Нарушение инвариантов некоего базового типа крайне неприятно природой своего проявления, т.е. это не та ошибка, которая бросается в глаза и вылазит на юнит-тестах. Эта та ошибка, которая вносится в код "потом", по мере накопления этих нарушений, и может проявится в одном из сочетаний типов-наследников в реальном графе объектов. Не факт, что именно такое сочетание будет проверено в тестировании, например из-за комбинаторно-большого кол-ва всевозможных сочетаний, или же наследовать реализацию может и некий "внешний" код, не подозревая о заложенных в нем минах.
V>Мне иногда приходится искать ошибки не только в своем коде, но и в "трудных случаях" ошибок у коллег. Так вот, если отбросить всякие "семечки", типа ошибок аргументов, недописанный if и т.д. которые находятся мгновено через юнит-тесты, Debug.Assert() и просто выскакивающие эксепшены, остальная часть ошибок, из тех, что действительно добавляют хлопот и требуют времени на поиск — это поведение программы не согласно ожидаемому и полная неочевидность таких причин. Практически всегда вот эти ошибки, требующие времени для своей локализации, связаны с нарушением инвариантов, и обычно решаются лишь "небольшим" перепроектированием иерархии. Я вот когда с Wolfhound спорил по поводу зависимых типов, то исходил именно из того, что ошибки выхода за диапазон легко находятся, в отличие от более сложных ошибок, которые возникают как "наведенные эффекты". Тут просто нельзя оставлять простора для наведения этих эффектов, и принцип подстановки Лисков нам в помощь.
Не надо тут за советскую власть агетировать. Несомненно лучше быть богатым и здоровым. Но вот на практике сплошь и рядом используются паттерны as / cast или is / as. Погляди на совершенно новую реализацию Expression Tree от MS. Там на ваши принципы Лисковой насрали по полной программе. Ради чего? Ради гибкости и краткости кода.
При этом, конечно, негативные проявления нарушения этих принципов сидят в засаде.
Если бы в шарпе был ПМ и алгебраические типы или хотя бы только ПМ, то негативные стороны можно было бы неверлировать или хотя бы контролировать. А так грабли заложены и ждут своих героев.
V>Тут не зря AVK (и не только) постоянно озвучивает, что наследование реализаций — зло, достаточно наследования интерфейсов. Настолько крайне я утверждать не могу, не "зло", конечно, ИМХО очень удобный, но и на столько же опасный сам по себе инструмент, требующий определенных правил при использовании.
Он не опасный, а гибкий. Я бы сказал, что нужны не правила, а просто напряжение мозгов. Программирование без мозгов всегда ведет к полной заднице. И наследование тут всего лишь одно из мест где можно нагородить огород.
Лично я считаю наследование реализации весьма удобной возможностью для многих случаев. В прочем как и передачу лямбд или использование ПМ.
Ну, для остальных есть VB6. Там этих проблем нет. Плюс язык устоялся .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, VladD2, Вы писали:
V>>>Каждый из них более специализирован относительно другого, примерно так. Но они оба разработаны как языки общего применения, поэтому пример не очень удачный.
VD>>Во-вот. Это бред плиз больше не повторяй. Это два универсальных языка. Они возможно отличаются мощностью. Но по возможностям они идентичны.
V>Я че-то не догоняю манеру спора, объяснишь мое и твое выделенное, и как ты получил несогласие?
См. выделение.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Тем не менее, если DSL не декларативный, а алгоритмический, обычно его делают на основе урезанной версии некоего ЯПОН, и сие факт. И я не столько спорю, сколько информацию тебе сообщаю.
Не позорься. Прочти определение ДСЛ-я.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IB, Вы писали:
IB>То есть задачи, которые не укладываются в гомоморфную иерархию для ООП не годятся, так?
Я не знаю, есть ли подвох в твоем вопросе. В принципе, на всех популярных языках можно сделать что угодно, а чего не хватает в языке — сэмулировать с той или иной степенью бубноплястства. Понятное дело, что решения архитектор принимает не только исходя из пригодности самого языка, интересует всё вокруг него: наработки, библиотеки, инструменты, девелоперы и т.д. Но если задать вопрос при условии прочих равных, то ответ разумеется нет.
Конечно, и задачу про AST можно вложить в семейство гомоморфных иерархий (и нужно, если решил на наследовании делать), если чуть тщательнее попроектировать, просто обычно никто так не делает. Из различных компиляторов IDL, ASN.1 и прочих рассмариваемых когда-то — обычно наблюдаю костыли в коде с уточнением реального типа AST узла, это первый сигнал некачественного проектирования. Вот эти все возможности, с аттрибутами и рефлексией, с дешевизной проверки типа с одной стороны — мощный инструмент, с другой стороны запросто провоцируют создание некачественных решений. Нарушение принципа Лисков препятствует расширению иерархии типов новыми членами. Мне нужно было дорабатывать компилятор CORBA, так плевался несказанно от "прибитых гвоздями" подобных проверок. Кстати, низкая связанность в ООП помимо прочих усилий достигается и за счет соблюдения такового принципа.
IB>А что годится для этих задач? И что делать, когда обработка этой иерархии лучше всего получается на ООП?
Значит, учитываем практики ООП, вот что делать.
В принципе, я не против, чтобы часть типов в программе составляли чистую ООП-иерархию, а часть являлись теми же алг.ТД, ИМХО, нет проблем в агрегировании самодостаточных блоков одного в другое.
V>>Сам по себе матчинг по типам (!!!) противен духу ООП (а только по значениям это будет недоматчинг). IB>Наследование тоже противно духу ООП, так как тоже позволяет нарушить Лисковский принцип, на который ты напираешь, но никого это не смущает ни в одном месте.
Спасибо, посмеялся. Принцип формирования подтипа без наследования в современном мейнстриме. С ума решили организованно посходить?
IB>Но в данном случае мне это теоретизирование совершенно пофиг. Понимаешь, я прекрасно знаю, что такое ООП и границы его применимости, проблема в том, что я хочу, чтобы мой инструмент не ограничвался рамками ООП.
Да я понял, тебе нужна такая дрель, чтобы и пилить, и строгать, и гвозди забивать. Возможно, что-то в этом есть. Однако, если у меня будет возможность оперативно и без трудозатрат сменить в руке отвертку на рубанок, мне достаточно и прежнего набора инструментов.
IB>И на данный момент, стереть границу между парадигмами проще в рамках одного языка, а не в рамках целой платформы на разных языках. Я вижу и знаю, как это может работать в одном языке, но у меня нет идей, как такой же гибкости получить в рамках одной платформы — у тебя есть?
Что именно интересует? Как должна называться базовая сущность и какая ее функциональность? В разных реализациях Лисп, Пролог, Хаскель "это" обычно называют cell. Сия cell имеет тип, собирается GC, но обычно не имеет методов, типа GetHashCode и не участвует в системе типов, являясь подробностью платформы. А раз меньше ограничений, то больше возможностей, например для реализации первоклассных объектов ф-ий прямо в платформе. Пусть себе для объектов будет некий базовый тип Object, но он вовсе не нужен для АТД, value-type или алгебраических типов данных. В общем, содрали с Java не особо проектируя.
V>>В каждой методологии есть свои практики, которые позволяют писать достаточно надежные программы. Смешение практик приведет только к ухудшению надежности, в этом плане thesz категорически прав. IB>По мере добавления ФП в шарп, надежности только прибавляется, так что пока это утверждение противоречит практике.
Пока что это ФП не пересекается с ООП, а "агрегирует" одно в другое. Вот будет матчинг по типам, тогда и посмотрим на надежность.
IB>Вот Nemerle, как раз и был такой научной работой.
Открыли нечто новое? ИМХО, удачно собрали в одном месте старое. Но открытых новых принципов пока не вижу.
Здравствуйте, nikov, Вы писали:
N>Хм. А когда он выводил short? В C# 2.0 правило о самой производной реализации уже точно было. Неужели в 1.0 было по-другому? Мне сейчас уже не вспомнить.
Здравствуйте, vdimas, Вы писали:
V>Ну значит для их задач им хватает одного языка общего назначения. Мне для моих задач одного C# не хватает.
В том то и дело, что не хватает. Но скрещивать C# и F# — это вообще убожество. Как минимум для наших задач.
V>Я ведь не только DSL приводил, если помнишь, упоминал C++/CLI и VB.Net.
Только совсем не к месту.
Здравствуйте, vdimas, Вы писали:
V>Я не знаю, есть ли подвох в твоем вопросе.
Подвоха нет. Если годятся, то объясни как, если не годятся — предложи замену и что делать, если сама задача смешенная.
V>В принципе, на всех популярных языках можно сделать что угодно, а чего не хватает в языке — сэмулировать с той или иной степенью бубноплястства.
Вот именно, все что угодно можно сделать на любом языке полном по тьюрингу, вопрос лишь в удобстве и защите от дурака. Классическое бубноплясовство для предложенной задачи — это паттерн визитор, то еще угробище, которое устанешь поддерживать. Был бы ПМ, забыли бы об этом паттерне, как о страшном сне, и о многих других ритуальных приседаниях. При этом опасность прострелить себе ногу при наличии ПМ, существенно ниже, чем при вышеупомянутых приседаниях.
V>Значит, учитываем практики ООП, вот что делать.
Какие практики? Предметная область такова, что структура модели очень напоминает AST. А работать с ним надо в ООП языке — какие практики ООП мне здесь помогут? Чем мне здесь может повредить ПМ или хотя бы банальный Type switch или какой нибудь другой аналог множественной диспетчеризации встроенный в язык?
V> Возможно, что-то в этом есть. Однако, если у меня будет возможность оперативно и без трудозатрат сменить в руке отвертку на рубанок, мне достаточно и прежнего набора инструментов.
Нету у тебя такой возможности сейчас. Сейчас, для того, чтобы сменить отвертку на рубанок тебе нужно сбегать в сарай в соседнем районе.
V>Что именно интересует?
Мне нужны в языке типа C# возможности имеющиеся у традиционных ФП языков. Мне пофиг как их получить в одном языке или в платформе. Однако как получить их в одном языке и как это могло бы работать — я знаю. А вот все что я могу представить в рамках одной платформы не затрагивая язык — к практическому применению мало пригодно. Повторяю вопрос — у тебя есть идеи как добиться этого результата оставляя язык чистым в рамках одной конкретной парадигмы?
V>Открыли нечто новое? ИМХО, удачно собрали в одном месте старое. Но открытых новых принципов пока не вижу.
Лично мне не нужны новые принципы, мне нужны старые, но собранные в одном месте. Я не ищу революционных прорывов — мне работать надо.
Здравствуйте, vdimas, Вы писали:
N>>Хм. А когда он выводил short? В C# 2.0 правило о самой производной реализации уже точно было. Неужели в 1.0 было по-другому? Мне сейчас уже не вспомнить.
V>Проверь на VS2005.
Специально поставил VS2005 и VS2003. И там, и там выводится int.
Здравствуйте, VladD2, Вы писали:
VD>Разговор явно не получается. Пока.
На любом более-менее универсальном языке можно написать все что угодно, что на голом С, что на VB. Это ты на этой точке зрения в своей обычной манере настаивал?
Действительно, говорить не о чем.
Здравствуйте, vdimas, Вы писали:
V>На любом более-менее универсальном языке можно написать все что угодно, что на голом С, что на VB. Это ты на этой точке зрения в своей обычной манере настаивал? V>Действительно, говорить не о чем.
Вспомни о чем шел спор в который ты влез. И подумай причем тут DSL-и обсуждение которых вы тут начали навязывать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IB, Вы писали:
IB>Вот именно, все что угодно можно сделать на любом языке полном по тьюрингу, вопрос лишь в удобстве и защите от дурака. Классическое бубноплясовство для предложенной задачи — это паттерн визитор, то еще угробище, которое устанешь поддерживать.
ИМХО, это очень плохой паттерн, из серии попыток прилепить мультиметоды к ООП. Он нужен только тогда, когда конкретика типа должна учитываться внешним, по отношению к типам, коду, а меня такая постановка напрягает сама по себе.
Т.е. когда у тебя код спроектирован так:
void Process(AstNode node) { node.CallMyProcessPlz(this); } // паттерн-костыль, где гарантия, что не обманет? :)void Process(AstNode1 node);
void Process(AstNode2 mode);
Вместо так:
void Process(AstNode node, Context context) { node.Process(context); } // или просто node.Process(this); если сам себе контекст.
Обсуждать, какой из способов удобнее я не буду, сам делал и так и так. Я знаю, что есть много аргументов в пользу первого варианта, особенно при небольшом кол-ве типов узлов, но именно он не в духе ООП и требует дополнительного обслуживающего паттерна. Второй способ "распыляет" логику по классам и глобальным ф-ям, но когда этой логики дофига (как в компиляторе CORBA, например), это только плюс, легче развивается и поддерживается. Меньше связанность.
Второй способ, помимо прочего, позволяет выносить/отделять общие механизмы/алгоритмы за пределы классов в глобальные процедуры/ф-ии (или же в статические классы-хелперы в дотнете), что тоже ну крайне удобно в случае большой грамматики/сложной семантики, ибо облегчает классы от тяжести наследования реализаций. Наследование тут используется исключительно для главной цели — достижения поведенческого полиморфизма, а не для отличия одного типа от другого (!!!). Это тоже разновидность способа облегчить себе жизнь в "развесистой" иерархии. Сущностей будет больше (каждый отдельно вынесенный алгоритм — отдельная сущность), но ими проще оперировать, ибо, при соблюдении принципа Лисков, каждый такой алгоритм оперирует лишь самым базовым типом из некоей подветки всей иерархии, обычно прост и имеют ту самую низкую связанность, т.е. не сломается при развитии остального кода.
IB>Был бы ПМ, забыли бы об этом паттерне, как о страшном сне, и о многих других ритуальных приседаниях. При этом опасность прострелить себе ногу при наличии ПМ, существенно ниже, чем при вышеупомянутых приседаниях.
ПМ на полсотни матчей и более выглядит страшно. Если столкнешься с таким, тебе надо будет выстраивать иерархию "агрегации" узлов (предположим, что у нас алг.ТД.), т.е. сначала разветвились в некоем вменяемом ПМ по признаку верхнего уровня и вызвали соотв. функцию, уже внутри нее опять матч по уточняющему признаку и т.д., в случае ООП и использования второго варианта ты можешь получить аналогичное естественным образом, создавая сколь угодно ветвистую иерархию без боязни утонуть.
V>>Значит, учитываем практики ООП, вот что делать. IB>Какие практики? Предметная область такова, что структура модели очень напоминает AST. А работать с ним надо в ООП языке — какие практики ООП мне здесь помогут? Чем мне здесь может повредить ПМ или хотя бы банальный Type switch или какой нибудь другой аналог множественной диспетчеризации встроенный в язык?
Они тебе не повредят, если ПМ будет небольшой. Если же он будет большой, то, как показал выше, ты на нем станешь эмулировать иерархию наследования, а в языке с ООП это будет смешно выглядеть.
Опять же, мы не тебя лично обсуждаем, а инструмент. Я уверен, большинству из здешнего топа не составит труда писать что угодно на чем угодно, ловко избегая встроенных граблей и не поддаваясь на провокации. Но команда у меня разношерстная, а тренер я играющий, мне бы как-нибудь так, чтобы я не сильно волновался и мог тоже на своей части работы спокойно сосредоточиться.
V>> Возможно, что-то в этом есть. Однако, если у меня будет возможность оперативно и без трудозатрат сменить в руке отвертку на рубанок, мне достаточно и прежнего набора инструментов. IB>Нету у тебя такой возможности сейчас. Сейчас, для того, чтобы сменить отвертку на рубанок тебе нужно сбегать в сарай в соседнем районе.
Вот, и я про то, что здесь как минимум два пути: построение универсальной дрели, либо удобного слесарского пояса для инструментов. ИМХО, подходы вполне конкурентноспособны. Более того, те же WindowsForms дизайнеры в студии — это именно демонстрация второго подхода, когда ты не выходя из зала, переключаешься на другое кино. Точно так же я прикручивал всякие DSL в проект, по которым генерился код. Влад опять может сказать, что я сливаю, упоминая DSL, но он не дает себе времени сообразить, что возможно с применением DSL задача ПМ по AST в основном коде отпадет сама собой. Да и не ПМ загвоздка, а в отделении декларативного от подробностей реализации, что просто спасает при большом кол-ве кода.
IB>Мне нужны в языке типа C# возможности имеющиеся у традиционных ФП языков. Мне пофиг как их получить в одном языке или в платформе. Однако как получить их в одном языке и как это могло бы работать — я знаю. А вот все что я могу представить в рамках одной платформы не затрагивая язык — к практическому применению мало пригодно.
Учитывая сегодняшнюю степень интеграции языков, возможно ты и прав, думая что знаешь. Отличная интероперабельность получилась сегодня только м/у VB.Net и C#, языками-близнецами. К сожалению, DSL tools и прочее аналогичное практически в зачаточном состоянии сегодня, что не дает нам почувствовать бенефитов. И вот тебе хочется если не DSL, то хотя бы "ну вот как в том другом языке", чтобы хоть как-то уменьшить себе трудоемкость.
А чем Немерле не подошел?
Ну и опять же, у всех разные ситуации. Я с тех пор, как начал пользоваться дотнетом в 2002-м, еще ни разу не сталкивался с приличным проектом на дотнете, чтобы без нативной части, так что минимум 2 языка обычно использую. Да, "стык" требует дополнительного обслуживания, непрозрачен для рефакторинга... Т.е. требует повышенного внимания, угу. Зато получается красивее всего остального, сам любуюсь.
IB>Повторяю вопрос — у тебя есть идеи как добиться этого результата оставляя язык чистым в рамках одной конкретной парадигмы?
Думаю, код должен пользовать типы некоей парадигмы по всем ее правилам. Т.е. матч — по туплам и алгебраическим типам, но не по типам из ОО-иерархий. Опять же, никакого наследования от алгебраических типов или туплов. Агрегировать одно в другое, соблюдая эти, и возможно еще несколько простых правил, можно запросто. Более того, есть чудесная точка интероперабельности помимо взаимного агрегирования — это интерфейсы. Они называются классы типов в Хаскель, но суть одно и то же — определяет контракт на операции с типом.
Но это что касается языка. В плане же платформы — нужна ее доработка или некий стандарт на такие вещи как функциональные объекты (ибо создание делегата довольно дорого), интероперабельные правила размещения глобальных ф-ий в неймспейсах и т.д.
V>>Открыли нечто новое? ИМХО, удачно собрали в одном месте старое. Но открытых новых принципов пока не вижу. IB>Лично мне не нужны новые принципы, мне нужны старые, но собранные в одном месте. Я не ищу революционных прорывов — мне работать надо.
Ну так почему не Немерле?
Сам бы давно на него прыгнул, если бы язык получил признание у потенциальных заказчиков, но не столько из-за ПМ, сколько из-за возможностей управления синтаксисом для генерации своих DSL (Владу опять передаю пламенный...)
Здравствуйте, VladD2, Вы писали:
V>>Вот и нет: V>>- лексер удобнее всего табличный на голом С, полученный из регулярной грамматики (не та, что перловая, а та, что класс грамматик);
VD>А ну-ка накайтай-ка мне лексер Nemerle на этом своем чудо-средтве . VD>А если не сможешь, то в следующий раз будь поаккуратнее в высказываниях. ОК?
А если смогу, сколько часов оплатишь?
Табличный лексер есть, автогенерилка таблицы минимизированного ДКА есть, тут всей работы — отладить грамматику для лексического анализатора. В принципе, мог и исходники выслать, если бы поуважительнее с оппонентами был, там ничего сверхъестественного.
VD>Потом лексер сгенерированный на С будет иметь море ограничений. Мне для реализации многих задач нужно создавать несколько копий лексера и запускать их в разных потоках. Для этого идеально подходят классы или ленивые вычисления. В С-и нет ни того, ни другого.
Да заверни токенайзер во что угодно. На С лишь потому, что он гораздо быстрее всего "скользит" по потоку символов, в отличие от энумератора по System.String или System.Array, и быстрее выбирает из таблиц переходов состояния, а если скорость не важна, то по той же таблице может работать и дотнетный сканер, у меня есть и тот и другой.
VD>Опять же все не совсем так. От парсеров может требоваться парсить код отдельных конструкций и работать в ленивом режиме. Любой ФЯ (ФП — это описка ведь?) тут не прокатит. Хаскель наверно справитя, но что-то решения на хаскеле мне кажутся далекими от прсотых.
Да, ленивость обязательно, я думал это и так понятно, без нее комбинаторный парсер не работает принципиально.
VD>К тому же комбинаторый парсер — это тормоз. Но это уже дело десятое.
Ну... прямой перебор, он и в Африке прямой перебор.
Не хочешь комбинаторный — можно любой параллельный, типа Эрли. В любом случае — предпочтителен ленивый ФЯ.
V>>- типизатор — однозначно логический, на прологе или чем-то похожем, ибо задача из области баз знаний и поиска решений (взаимно-рекурсивные альфа/бета редукции);
VD>Да ну? О как? А пролог мы будем из комндной строки вызвать? Вот в Немерле Пролог, точнее подсистема унификации выделена в отдельный объект (класс). Получается очень удобно.
Прологи они зачастую в виде либ идут, и вызывал я их прямо из кода. Наверняка есть уже и на дотнете. Просто проверка соответствия типов и упрощение выражений в одном из компиляторов с IDL мне показались близкими по духу к использованию Пролог-машины, с чем работал до этого на проекте распознавания естественного английского.
V>>- генератор кода — некий язык трансформации, желательно декларативный, возможно сам язык написанный опять же на прологе (ближе всего получается).
VD>Вот незадача. Но код то нужно генерировать средствами SRE. А он имеет объектный интерфейс. Облом, да?
Нет, но что-то мне кажется, подробности тебя не очень интересуют.
VD>Можно узнать сколько компиляторов ты создал описанным тобой образом?
Именно таким образом — ни одного. А что, есть ленивый ФЯ для дотнета? Я его эмулировал для EDI-транслятора. Преобразование байт-код .Net было полудекларативно в рамках C#, т.е. не тот максимум удобства, который хотелось бы. Понятное дело, что ради одной задачи городить такой огород смысла нет, но если сделать в виде либ/макросов для того же Немерле, то почему бы и нет?
V>>Ну... осталось вам написать для Немерле библиотеку генерации табличных сканеров по регулярным выражениям + пролог машину + научиться ей пользоваться + написать язык трансформации данных на основе этой пролог-машины и тогда согласен, достаточно будет одного языка.
VD>Меня умиляют эти доморощенные теоретики путающие ДСЛ и ЯПОН, но с высоко задранной головой советующие окружающим чем им заняться и чему научиться.
Так уж и путающие?
VD>Уважаемый, все перечисленное и так есть в немерле. А для того что нет, есть макросы. Вы же продолжайте сосать баранку и завидовать. Ведь вам дяди серьёзный инструмент использовать не разрешают.
Есть реализация пролог-машины и синтаксис для фактов и правил под нее?
А насчет "разрешают" — детский сад. Дяди или покупают, или ищут другого продавца.
VD>Ну, и за одно продолжайте нести эту чушь оправдывая применение в одном проекте 25 языков общего назначения вроде C# и F# тем, что ДСЛ-и для некоторых задач рулят. Это конечно глупо, но если глупость повторять много раз с умным выражением лица, то многие могут в нее поверят.
Спасибо за разрешение, в свою очередь разрешаю и дальше горлопанить, преувеличивать, превращать 3 в 25 и наслаждаться очередным "разгромом" оппонента. Смешно в этом всем только одно, у тебя много букв в ответе, но по сути не наберется и 10%, одно бесполезное эмо по тексту.
.
Мы уже победили, просто это еще не так заметно...
.