Здравствуйте, oldjackal, Вы писали:
O>Здравствуйте, Tanker, Вы писали:
T>>Вот эта проблема, в дизайне, которя плохо поддается формализации, вынуждает делать UI максимально гибким. Вот здесь как бы и должны помочь DSL. Но чет слабо помогают.
O> Не представляю, как DSL может помочь. Программирование UI тривиально и так, да и DSL-ей и так полно под самые разные UI-задачи. Тот же Tcl/Tk или WPF (Xaml), или, пардон, HTML. Главная же проблема это собственно UI придумать, а ее и на бумажке с карандашом решать можно, или в каком либо Balsamiq Mockups. Когда эта задача решена, программирование становится тривиальным, и в сравнении с дизайном занимает исчезающе малое время, независимо от используемой технологии.
Люди занимающиеся мобайлом и десктопом с тобой не согласятся. UI только начинается с кнопочек и дале требует хорошей инфрастурктуры над тем же WPF и тд.
Здравствуйте, Tanker, Вы писали:
T>Конечно. Разве я это оспариваю ? T>Я говорю про другое — понимание специфики бизнеса это затраты времени, ктоорые часто в ущерб прокачке в программировании. ДСЛ позволяет разрешить этот конфликт. Но это толко кажущееся решение, т.к. ДСЛ требует затрат времени которые будут в ущерб пониманию специфики бизнеса.
T>Т.е. не бвает универсальных специалистов которые одинаково хорошо строят ДСЛ, решают задачи бизнеса и реализуют программы на своём ДСЛ. Как то так складывается, что архитектор SQL сам не пишет запросы. А те, кто пишут запросы, и те, кто строит дсл, задачи бизнеса понимают плохо, потому им нужен человек из бизнеса, который ставит и учавствует в формализации области.
Я это представляю так:
Исходная предпосылка — человек уже хороший программист.
Знания специфики бизнеса пока нет. Поэтому пишем лапшу. Постепенно выделяем части кода в библиотеки.
Со временем приходит понимание специфики. Хороший программист сразу же сможет выделить DSL. Точка.
Здравствуйте, Tanker, Вы писали: T>Не они пошли, а их туда завели практики. Пока практики не смогут накопить опыт, от теоретиков пользы не будет.
У практиков этого опыта полно, больше чем нужно. Но теоретикам такой опыт не интересен. Им математику подавай. Вот и выдумвают что-то свое, из носа выковыривают, а на практику даже и не смотрят.
T>Хочешь качетсвенно готовить студентов — теоретики должны выдать весь понятийный аппарат. А для этого практики должны накопить должное количетсво опыта да еще и формализовать его.
Там всего понятийного аппарата на две строки текста, не больше. Теоретики просто фигней страдают.
Здравствуйте, koodeer, Вы писали:
K>Я это представляю так: K>Исходная предпосылка — человек уже хороший программист. K>Знания специфики бизнеса пока нет. Поэтому пишем лапшу. Постепенно выделяем части кода в библиотеки. K>Со временем приходит понимание специфики. Хороший программист сразу же сможет выделить DSL. Точка.
Сразу же это когда ? Когда понимания еще нет или когда понимание уже есть ? Специфику бизнеса люди годами осваивают и даже десятками лет.
Здравствуйте, Tanker, Вы писали:
O>> Не представляю, как DSL может помочь. Программирование UI тривиально и так, да и DSL-ей и так полно под самые разные UI-задачи. Тот же Tcl/Tk или WPF (Xaml), или, пардон, HTML. Главная же проблема это собственно UI придумать, а ее и на бумажке с карандашом решать можно, или в каком либо Balsamiq Mockups. Когда эта задача решена, программирование становится тривиальным, и в сравнении с дизайном занимает исчезающе малое время, независимо от используемой технологии.
T>Люди занимающиеся мобайлом и десктопом с тобой не согласятся. UI только начинается с кнопочек и дале требует хорошей инфрастурктуры над тем же WPF и тд.
Я видел, как эти люди работают. Программирование занимает самую незначительную часть времени. Гораздо больше они спорят до хрипоты над карандашными рисунками и тестируют интерфейс на пользователях, используя бумажные аппликации. Так что их инструмент — бумажка, карандаш, ножницы и клей. Какие такие DSL им могли бы помочь?
Здравствуйте, Tanker, Вы писали:
WH>>Правильные методики были разработаны в середине 70х. WH>>Но драконисты их затоптали. Инквизиторы хреновы.
T>Затоптали — значит идейка была так себе.
Нет, это теоретики так себе. Практики то как пользовались правильными подходами, так и пользуются. А теоретики в это время всякую чушь в учебниках пишут и студентов этой чушью пугают.
Здравствуйте, oldjackal, Вы писали:
T>>Не они пошли, а их туда завели практики. Пока практики не смогут накопить опыт, от теоретиков пользы не будет.
O> У практиков этого опыта полно, больше чем нужно. Но теоретикам такой опыт не интересен. Им математику подавай. Вот и выдумвают что-то свое, из носа выковыривают, а на практику даже и не смотрят.
Развивать идею "все теоретики дураки" мне неинтересно дасже с учетом того что себя я причисляю к практикам-прагматикам.
T>>Хочешь качетсвенно готовить студентов — теоретики должны выдать весь понятийный аппарат. А для этого практики должны накопить должное количетсво опыта да еще и формализовать его.
O> Там всего понятийного аппарата на две строки текста, не больше. Теоретики просто фигней страдают.
Выдай эти два строки текста. Надеюсь их длина как в хорошей программе ограничена сотней символов ?
Здравствуйте, oldjackal, Вы писали:
T>>Люди занимающиеся мобайлом и десктопом с тобой не согласятся. UI только начинается с кнопочек и дале требует хорошей инфрастурктуры над тем же WPF и тд.
O> Я видел, как эти люди работают. Программирование занимает самую незначительную часть времени. Гораздо больше они спорят до хрипоты над карандашными рисунками и тестируют интерфейс на пользователях, используя бумажные аппликации. Так что их инструмент — бумажка, карандаш, ножницы и клей. Какие такие DSL им могли бы помочь?
Здравствуйте, Tanker, Вы писали:
O>> Меня более всего удивляет то, что вас этот простой факт удивляет. Преподаватели много в чем ни в зуб ногой. Я бы сказал, почти во всем ни в зуб ногой.
T>Повезло тебе.
В чем это мне повезло? В том, что пригодного к немедленному употреблению студента днем с огнем не найдешь? Не назвал бы это везением.
O>> Это только в теории так. А на практике же, и в особенности в случае с компиляторами, теория идет где-то своими, параллельными путями, с практикой вообще не пересекающимися. То есть, между той теорией, которой учат на этом предмете, и реальной практикой, нет вообще абсолютно ничего общего. Ни единой точки соприкосновения.
T>Это значит практика еще не накопила нужное количетсво опыта.
Поразительная упертость. Включите мозг! Практика лет 60 существует. Компиляторы всех мастей пишут, не напрягаясь. Наплевав на рассуждения теоретиков. Никаких сложностей и неясных моментов в практике нет уже очень давно. А теоретики как рассуждали про "формальные грамматики", как спорили про разницу между LALR(1) и SLR, так и спорят, тогда как абсолютно все практики всегда пишут ad hoc рекурсивные парсеры и знать не желают про баталии дебилов-теоретиков.
Советую прежде чем продолжать этот нелепый спор, где вы заведомо и на все 100% лажаетесь, посмотрите на существующие промышленные компиляторы. Попробуйте найти там хотя бы малюсенький след того, о чем рассуждают дебилы-теоретики. Найдите там хотя бы одну страницу драконьей книги, на которую теоретики молятся. Не найдете! Ни в gcc, ни clang/llvm, ни в HotSpot, ни в CPython, нигде!
Нет никакой связи между теоретиками и практикой. И не будет никогда. Теоретики не собираются обобщать практический опыт, потому как он и не нуждается в их нелепых услугах, да и противоречит всему тому, во что они слепо верят.
O>> Нет, это означает только то, что теоретики — дебилы. Только и всего. И что про практику они не знают вообще ничего, плевать они на практику хотели. Они сидят в своих башнях из слоновой кости и строят чисто умозрительные теории, в то время как практики прекрасно обходятся без всей этой мути.
T>Извиния, я далёк от таких обобщений.
Это от того, что вы далеки от темы и не имеете представления ни о том, что там накалякали теоретики, ни о том, чем реально пользуются практики. Советую ознакомиться, тогда вы будете вынуждены согласиться с моимим обобщениями.
O>> Я говорю про даже самые примитивные вещи. Студенты, выпускники CS-специальностей, не умеют программировать. Вообще. На fizz-buzz ломаются. Даже если круглые отличники. Умеют программировать только те, кто подрабатывал налево или программировал что-то реальное just for fun. А они как правило, наоборот, вовсе не отличники, на учебу у них времени маловато остается.
T>Мне честно интересно где ты видел таких студентов ?
Мне было бы очень интересно узнать, где можно взять других?
Здравствуйте, Tanker, Вы писали:
T>>>"понятее не поддерживаемее" — могу тлько догадываться что это могло означать. O>> Это опечатка. s/не/и/g
T>Ну и в качестве примера берем скул и орм
А не надо их брать. Я же сказал, это абсолютно иная тема, ничего общего с обсуждаемой не имеющая.
O>> Не, эквивалентное по глупости утверждение было бы "все частные задачи надо решать на ассемблере". Кстати, низкоуровневую оптимизацию на ассемблере давно уже никто не делает, в этом нет смысла.
T>Это ты сильно заблуждаешься. Шейдеры, аппаратные задачи, даже в менеджед приходится спускаться на il.
За последние лет двадцать я ни разу не сталкивался с необходимостью писать что либо на ассемблере. При том, что моя работа как раз тесно связана с HPC.
T>>>Как ты померил сложность разработки и реализации языков ? Наверняка "у меня получилось и следовательно это просто" ? O>> Сложность это понятие объективное. Не верите мне — спросите у Колмогорова.
T>То есть, два одинаковых бегуна пробегут две разные дистанции за одно и то же время ? Мне кажется Колмгоров такого не говорил.
Что-то вы совсем зарапортовались. Что за нелепая аналогия? Я говорю о том, что сложность областей несопоставимая. Компиляторы — это тупо и примитивно, и изучается за несколько часов полностью. UI — гигантских размеров дисциплина, на поверхностное знакомство с которой могут уйти годы.
Здравствуйте, oldjackal, Вы писали:
O> Это хорошо. А как это реализовано? Модуль создается динамически?
Зачем? Функции они и есть функции.
Ничем от обычных функций не отличаются.
O> А не ограничит ли эта декларативность возможные системы типов еще сильнее?
Не должна.
O> Кстати, тот же несчастный Хиндли-Миллнер это всего лишь подмножество Пролога. Если, например, декларативное описание типизации делать в виде правил генерации утверждений Пролога из термов AST, то получится бесплатно и сам Хиндли-Миллнер, и что угодно еще, сколь угодно сложное (Пролог-то Тьюринг-полный). Не рассматривали такой вариант? Это и просто, и матана не надо (весь матан уже придуман и приложен разработчиками Пролога), и гибкость бесконечная получается.
Рассматривали. И не только его.
Что получится в результате пока не до конца ясно.
Ибо у меня есть требование инкрементального обновления для работы в режиме ИДЕ.
Ибо перестраивать все дерево типов на каждый чих будет очень медленно.
WH>>Основная идея состоит в том, что каждая конструкция имеет, не только правила разбора, но и правила типизации. O> Что-то похожее на JetBrains MPS?
Да. Только намного технологичнее.
И разве MPS умеет типы выводить? Что-то не заметил. Там вроде все руками типизировать нужно.
WH>>
rule IfExpr is Expr
WH>>syntax "if" "(" cond : Expr ")" expr1 : Expr "else" expr2 : Expr;
WH>>{
WH>> assert(cond.Type == #bool, "Condition type must be bool.");
WH>> assert(Type <= expr1.Type && Type <= expr2.Type, "Branch types must be convertible to same type.");
WH>>}
WH>>
O> А, ну это не так уж и декларативно. Может и сработать.
Не декларативно? Фигасе.
Куда же декларативнее то?
O> Вообще-то по каждому. Тормозить динамическая типизация совершенно не обязана (внутри она может быть совершенно статической).
Ну да всякие V8 пытаются это делать. Но только что-то не получается.
И в процессе память жрут тоннами.
O>Памяти на RTTI мне не жалко совершенно (во время компиляции, чтоб рефлексию в макросах кормить, в рантайме его и не надо).
А мне жалко. Если проект большой, то это вызывает проблемы.
Ну и тормоза. Тот же компилятор немерла компилируется очень долго. А ведь там все статически типизировано.
Была бы динамическая типизация... ой... даже подумать страшно.
O>А что такое "ошибка" я хочу определять сам, на тех уровнях, на которых это имеет смысл. Потому как не существует такой системы типов, которая бы покрывала все возможные валидные выражения.
Ну так я и планирую ввести предметно ориентированные системы типов.
WH>>Динамически типизированный язык тоже можно будет сделать. Это путь я не смогу закрыть при всём желании. Просто я не вижу в них смысла. O> А зря, зря. Строить статические типизации поверх динамической проще, чем наоборот.
Чего?
WH>>Н2 не будет навязывать систему типов языку который на нем разрабатывается. O> А как же требование возможности статической проверки?
А одно другому не мешает.
O>Хотя, если эта базовая, минимальная система типов будет на уровне не выше чем в LLVM, то и не страшно.
А это вообще лишнее. Например, мои генераторы парсеров типизируют грамматику совершенно не оглядываясь на то в какой язык это будет скомпилировано.
А типы базового языка используются исключительно как черный ящик.
Вот таким вариантом задаются типы в парсере.
Выделенное это ссылки на типы немерла.
С тем же успехом там могут быть ссылки на типы чего угодно.
[Record]
public variant RuleType : Nemerle.Compiler.Located
{
| List { ty : RuleType; }
| Option { ty : RuleType; }
| Tuple { types : list[RuleType]; }
| PType { ty : PExpr; }| NType { ty : FixedType; }
| Chars
| Void
Одну из них по-хорошему нужно убрать. Руки не доходят.
Используя такой подход можно полностью избавиться от необходимости раскрывать макросы для проверки кода.
Причем сообщения об ошибках будут в терминах предметной области, а не того языка в который раскрывается код.
O> Вот еще такой вопрос — какая позиция насчет goto? Иметь возможность раскрывать макросы в код, использующий goto — это очень, очень удобно. Конечному пользователю его лучше в руки не давать, но вот иметь к нему доступ для компиляторов DSL очень важно.
Языки с goto безусловно будут.
O>В N1 отсутствие goto меня отпугнуло.
Скажу по секрету макры им могут пользоваться. https://github.com/rampelstinskin/ParserGenerator/blob/3666b1b364d3cbf942587a385aba13a07fa22661/Nemerle.Parser.Macro/Compiler/RuleCompiler/CompileFSM.n
Но по-хорошему goto не нужен.
Он отлично заменяется взаимно рекурсивными функциями с хвостовой рекурсией.
Нужно только чтобы она гарантированно оптимизировалась. Н1 так не умеет. Поэтому пришлось гото использовать.
O>А вот если на каждый уровень надо по отдельной DLL создавать, как сейчас в N1 — тогда да, тогда это невозможно. В Лиспе же таких ограничений нет в принципе.
Это не проблема.
O> Было бы очень интересно посмотреть на существующие наработки.
Сейчас есть только недописанный парсер. Остальное пока в теории.
Но я работаю над этим.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
N>>Но и там знают, что разработка языков — дело сложное и неблагодарное: выживает 1 из 1000, в лучшем случае. WH>А откуда, по-твоему, драконщина пошла?
А при чём тут её происхождение?
WH>Плюс ты специально, что ли путаешь ДСЛ и ЯОН? WH>ДСЛ они все выживают в том проекте, для которых их делают. А на большее они обычно и не претендуют.
Я не путаю, я не спешу различать, пока не нужно. Да, DSL на одну программу может быть кривым, но и у неё может быть миллион пользователей и долгая история развития, и тогда начинают править ошибки.
Здравствуйте, Tanker, Вы писали:
O>> У практиков этого опыта полно, больше чем нужно. Но теоретикам такой опыт не интересен. Им математику подавай. Вот и выдумвают что-то свое, из носа выковыривают, а на практику даже и не смотрят.
T>Развивать идею "все теоретики дураки" мне неинтересно дасже с учетом того что себя я причисляю к практикам-прагматикам.
Про "все" я не говорил. Я привожу конкретный факт, в компиляторостроении полностью отсуствует связь между теорией и практикой. Факт объективный и тривиально доказуемый.
T>>>Хочешь качетсвенно готовить студентов — теоретики должны выдать весь понятийный аппарат. А для этого практики должны накопить должное количетсво опыта да еще и формализовать его.
O>> Там всего понятийного аппарата на две строки текста, не больше. Теоретики просто фигней страдают.
T>Выдай эти два строки текста. Надеюсь их длина как в хорошей программе ограничена сотней символов ?
Уже выдал, чуть раньше, про TRS и алгебру. Ничего кроме этого во всей этой области нет. Денотационные и операционные семантики? Чушь, сводится к TRS. Грамматики? Вообще нерелевантно. Оптимизации? На высоких уровнях сводится к правилам и стратегиям переписывания деревьев, на самых суровых низких уровнях (про которые большинству писателей компиляторов и знать-то не надо) немного сложнее, сводится к правилам и стратегиям переписывания DAG-ов.
Так что, сложно простому смертному понять, что такое выражение, что такое дерево, и что такое правила переписывания? Да нет, элементарно. Уж всяко проще, чем зубрить сотни "паттернов", которые сейчас у любого промышленного программиста от зубов отскакивают.
Здравствуйте, Tanker, Вы писали:
O>> Я видел, как эти люди работают. Программирование занимает самую незначительную часть времени. Гораздо больше они спорят до хрипоты над карандашными рисунками и тестируют интерфейс на пользователях, используя бумажные аппликации. Так что их инструмент — бумажка, карандаш, ножницы и клей. Какие такие DSL им могли бы помочь?
T>Фильтр это UI или не UI ?
Здравствуйте, Tanker, Вы писали:
T>Ты похоже вещаешь про те задачки, которые хорошо формализованы еще десятки лет назад.
Я про любые.
T>Сложность семантики не зависит ни от дсл ни от библиотеки, она определеятся доменом. Есть специалист по домену — значит будет N-готовых решений и легкость проектирования. Нет такого — надо тратить время сначала на формализацию, а уже потом, если хватит времени — на ДСЛ.
А если не хватит, то потратить в 100 раз больше времени чтобы долбить код на языке низкого уровня.
WH>>Ты защищаешь подход с багами в коде. Типа и так все работает. T>Я демонстрирую тебе подход бизнеса.
К чему? Собственному разорению?
T>Не надо передёргивать. 10% это процент расходов на всех разработчиков. Т.е. сумма ЗП разрабов за период поделить на бюджет и помножить на 100.
И на что же тратятся остальные 90%. Похоже у вас там воруют. Либо просто управленцы дураки.
Это конечно если мы про контору, которая чисто разработкой живет, говорим.
T>Сами формализуем как умеем. А ты похоже вещаешь про те задачки, которые хорошо формализованы еще десятки лет назад.
Нет. Я могу легко формализовать что угодно.
Но для этого нужно провести анализ предметной области.
И в форуме на слабо я это делать не буду.
WH>>Тех, кто не учиться нужно, отправлять в дворники, а не программистом брать. T>Я только за. Предложи хорошее решение.
Не брать. В чем проблема то?
WH>>Хорошие инженеры учатся всегда. Они просто не могут, не учится. Иначе моментом тупеют и теряют квалификацию. T>Квалификация ради квалификации ? Я боюсь что это утопия.
Это реальность. Иначе программист за пару лет стане непрофпригодным.
T>Это типичная картина которую я наблюдаю в разных странах, разных городах как сам так и со слов людей в самых разных уровнях иерархии.
Ну, так и не надо таких брать.
Нужно взять в 10 раз меньше нормальных. И показать им как ДСЛи делать.
И они в 100 раз быстрее все сделают.
Сколько я видел тех, о ком ты говоришь весь их код, после увольнения переписывался. Его даже без ДСЛ становилось в разы меньше и все баги пропадали.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, oldjackal, Вы писали:
O> Гораздо раньше. Еще и компьютеров никаких не было, а все что надо уже знали и умели. Алгебру-то давно придумали.
Я про Пратт и ПЕГ.
Руками парсеры писать, мягко говоря, неудобно.
O> Что лишь подтверждает гниль всей академической системы в целом.
Она не вся гнилая. Есть там и полезные темы. Просто нужно перекопать кучу навоза, чтобы найти что-то полезное.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, oldjackal, Вы писали:
T>>3 Объясни, кем заменить тех, кто не в состоянии написать чтото большее string.split ? O> Я бы рассказал, что надо сделать с теми, кто выдумывает форматы, требующие чего-то большего чем String.Split. CSV это злобно и бесчеловечно.
"Яка розумная тому альтернатива?"
Для передачи в поле произвольного значения мы имеем или стаффинг, или эскейпинг.
Стаффинг требует разбора грамматики, пусть даже минимальной. Эскейпинг таким не страдает, но усложняет визуальное чтение и ручное редактирование.
Что лучше — иметь в поле "\"15%+20%\"" или %2215%25%2B20%25%22 ? (для примера был взят HTML form escaping)
T>>DSL, хочешь ты или нет, это очень сложная тема. O> Не-а. Простая. Проще некуда.
Её сложность ровно такая же, как с любым другим языком. Но средняя цена ошибки сильно меньше.
Здравствуйте, WolfHound, Вы писали:
O>> Это хорошо. А как это реализовано? Модуль создается динамически? WH>Зачем? Функции они и есть функции. WH>Ничем от обычных функций не отличаются.
Я просто пытаюсь понять, как компилятор позволяет определить макру в модуле, и тут же ее использовать, не скомпилировав ее и все, что в модуле было выше в динамический модуль (прошу прощения за тавтологию, тут два разных модуля — исходный файл и модуль в assembly).
WH>Ибо у меня есть требование инкрементального обновления для работы в режиме ИДЕ. WH>Ибо перестраивать все дерево типов на каждый чих будет очень медленно.
Такое требование может как раз существенно ограничить возможный диапазон систем типов.
WH>>>Основная идея состоит в том, что каждая конструкция имеет, не только правила разбора, но и правила типизации. O>> Что-то похожее на JetBrains MPS? WH>Да. Только намного технологичнее. WH>И разве MPS умеет типы выводить? Что-то не заметил. Там вроде все руками типизировать нужно.
Ну да, там только правила type propagation. Ничего более сложного сделать нельзя.
O>> А, ну это не так уж и декларативно. Может и сработать. WH>Не декларативно? Фигасе. WH>Куда же декларативнее то?
Я правильно понимаю, что в { ... } может быть произвольный императивный код?
O>> Вообще-то по каждому. Тормозить динамическая типизация совершенно не обязана (внутри она может быть совершенно статической). WH>Ну да всякие V8 пытаются это делать. Но только что-то не получается. WH>И в процессе память жрут тоннами.
Это можно делать статически. Даже такой простой компилятор, как SBCL, это в принципе делать умеет.
O>>Памяти на RTTI мне не жалко совершенно (во время компиляции, чтоб рефлексию в макросах кормить, в рантайме его и не надо). WH>А мне жалко. Если проект большой, то это вызывает проблемы.
При раздельной-то компиляции? Вряд ли.
Да и не стоит забывать, что в .NET от RTTI все равно не избавишься, так почему бы им не пользоваться тогда?
WH>Ну и тормоза. Тот же компилятор немерла компилируется очень долго. А ведь там все статически типизировано. WH>Была бы динамическая типизация... ой... даже подумать страшно.
Не представляю, чем динамика может помешать.
O>>А что такое "ошибка" я хочу определять сам, на тех уровнях, на которых это имеет смысл. Потому как не существует такой системы типов, которая бы покрывала все возможные валидные выражения. WH>Ну так я и планирую ввести предметно ориентированные системы типов.
Для чего нужна самая базовая система типов, которая никаких ограничений не накладывает вообще.
WH>>>Динамически типизированный язык тоже можно будет сделать. Это путь я не смогу закрыть при всём желании. Просто я не вижу в них смысла. O>> А зря, зря. Строить статические типизации поверх динамической проще, чем наоборот. WH>Чего?
А есть возражения?
WH>>>Н2 не будет навязывать систему типов языку который на нем разрабатывается. O>> А как же требование возможности статической проверки? WH>А одно другому не мешает.
Не понимаю. Как?
O>>Хотя, если эта базовая, минимальная система типов будет на уровне не выше чем в LLVM, то и не страшно. WH>А это вообще лишнее. Например, мои генераторы парсеров типизируют грамматику совершенно не оглядываясь на то в какой язык это будет скомпилировано.
А язык потом по рукам не надает, если что-то окажется не типизируемым по его мнению?
WH>Используя такой подход можно полностью избавиться от необходимости раскрывать макросы для проверки кода. WH>Причем сообщения об ошибках будут в терминах предметной области, а не того языка в который раскрывается код.
Буду думать. Пока не понимаю.
O>> Вот еще такой вопрос — какая позиция насчет goto? Иметь возможность раскрывать макросы в код, использующий goto — это очень, очень удобно. Конечному пользователю его лучше в руки не давать, но вот иметь к нему доступ для компиляторов DSL очень важно. WH>Языки с goto безусловно будут.
Это хорошо.
O>>В N1 отсутствие goto меня отпугнуло. WH>Скажу по секрету макры им могут пользоваться.
О как!
WH>Но по-хорошему goto не нужен.
Нужен, нужен, без него слишком сложные конструкции выходят, а толку от этой сложности никакого — ведь все равно все в конце в байткод упрется, где метки и goto.
WH>Он отлично заменяется взаимно рекурсивными функциями с хвостовой рекурсией.
Ну да, конечно же, SSA эквивалентен CPS. Только вот в SSA все намного короче и проще получается.
WH>Нужно только чтобы она гарантированно оптимизировалась. Н1 так не умеет. Поэтому пришлось гото использовать.
И зачем? С goto оптимизировать не надо, оно уже и так оптимально.
O>>А вот если на каждый уровень надо по отдельной DLL создавать, как сейчас в N1 — тогда да, тогда это невозможно. В Лиспе же таких ограничений нет в принципе. WH>Это не проблема.
Как это решается?
O>> Было бы очень интересно посмотреть на существующие наработки. WH>Сейчас есть только недописанный парсер. Остальное пока в теории. WH>Но я работаю над этим.
Здравствуйте, netch80, Вы писали:
N>"Яка розумная тому альтернатива?" N>Для передачи в поле произвольного значения мы имеем или стаффинг, или эскейпинг. N>Стаффинг требует разбора грамматики, пусть даже минимальной. Эскейпинг таким не страдает, но усложняет визуальное чтение и ручное редактирование.
Но за возможность разбора awk-ом такое можно и простить.
N>Что лучше — иметь в поле "\"15%+20%\"" или %2215%25%2B20%25%22 ? (для примера был взят HTML form escaping)
Эскейпить надо ровно один единственный символ — разделитель колонок. Остальное можно оставить как есть.
T>>>DSL, хочешь ты или нет, это очень сложная тема. O>> Не-а. Простая. Проще некуда.
N>Её сложность ровно такая же, как с любым другим языком. Но средняя цена ошибки сильно меньше.
Разговор был про сложность разработки DSL. А они уж всяко проще языков "общего назначения".
Здравствуйте, WolfHound, Вы писали:
O>> Гораздо раньше. Еще и компьютеров никаких не было, а все что надо уже знали и умели. Алгебру-то давно придумали. WH>Я про Пратт и ПЕГ. WH>Руками парсеры писать, мягко говоря, неудобно.
А, ну да, оба из 70х. В любом случае, парсеры это далеко не главное. Драконовщина нанесла непоправимый вред в первую очередь как раз зацикленностью на парсерах.
O>> Что лишь подтверждает гниль всей академической системы в целом. WH>Она не вся гнилая. Есть там и полезные темы. Просто нужно перекопать кучу навоза, чтобы найти что-то полезное.
Естественно, term rewriting, семантики и тому подобное это в целом полезно. Хоть и тут без ненужного переусложнения не обошлись.
Фигасе.
