Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, batu, Вы писали:
B>>Хотя время есть.. Попробую подробней.. Концепт это некая фигня с которой может работать некая виртуальная машина. Что нужно машине? Во первых размер.
Z>Давай начнем с размера. Что это? Чему равен размер концепта For? Почему он так важен, что ты его ставишь во главу тройки?
Не торкнуло?
Разделяем термины. DSL — не метапрограммирование (как термин). DSL — не прикладная библиотека.
Для справки: язык программирования 1С не дсл, а язык общего назначения. Изначально в нем нет проблемной специфики, специфика введена архитектурой и прикладными объектами. Они этого идеологического подхода придерживались, не знаю уж, кто им его разработал.
Расчет зарплаты в 1С не дсл, это комплекс средств — язык + платформа (база и прикладные объекты). В составе платформы 1С есть и DSL — язык запросов на базе SQL. Как частный случай этот dsl еще и метапрограммирование, поскольку напрямую транслируется в известный нам язык SQL и работает в известном окружении, вполне специализированном на решение определенных задач и 1С-ники потом и с итоговым SQL работают.
Введи поддержку прикладного объекта или прикладной специфики на уровень языка и вот тебе DSL.
Язык общего назначения может стать DSL-м и без изменения его синтаксиса в явном виде. Например, если поднять обработку сценариев известной нам проблемной области на уровень языка не меняя самого синтаксиса, тем самым ограничивая область применимости данного языка, мы сделаем язык domain-specific.
Использование вами термина DSL для обозначения решений задач метапрограммирования видится неверным с точки зрения формальной логики, да в общем тоже.
> Введи поддержку прикладного объекта или прикладной специфики на уровень языка и вот тебе DSL.
Ать еть, ашипка. Формально _расширение_ языка общего назначения не делает его domain-specific. Как точки зрения придерживаться при расширении языка, нужно подумать.
Здравствуйте, grosborn, Вы писали:
G>Разделяем термины. DSL — не метапрограммирование (как термин). DSL — не прикладная библиотека.
G>Для справки: язык программирования 1С не дсл, а язык общего назначения. Изначально в нем нет проблемной специфики, специфика введена архитектурой и прикладными объектами. Они этого идеологического подхода придерживались, не знаю уж, кто им его разработал. G>Расчет зарплаты в 1С не дсл, это комплекс средств — язык + платформа (база и прикладные объекты). В составе платформы 1С есть и DSL — язык запросов на базе SQL. Как частный случай этот dsl еще и метапрограммирование, поскольку напрямую транслируется в известный нам язык SQL и работает в известном окружении, вполне специализированном на решение определенных задач и 1С-ники потом и с итоговым SQL работают.
С написанным выше я согласен. Что из сказанного выше, по твоему, противоречит моим словам?
G>Введи поддержку прикладного объекта или прикладной специфики на уровень языка и вот тебе DSL.
И получишь встроенный в язык ДСЛ. Не более того. Иначе Лисп и Немерле по твоему определению автоматически становятся ДСЛ-ями (ведь в них можно легко вводить поддержку прикладной специфики), что явно не так.
G>Язык общего назначения может стать DSL-м и без изменения его синтаксиса в явном виде.
Это противоречит сказанному тобой выше.
G>Например, если поднять обработку сценариев известной нам проблемной области на уровень языка не меняя самого синтаксиса, тем самым ограничивая область применимости данного языка, мы сделаем язык domain-specific.
А как же пример с 1С?
G>Использование вами термина DSL для обозначения решений задач метапрограммирования видится неверным с точки зрения формальной логики, да в общем тоже.
Для начала хорош бы устранить противоречия в твоих же высказываний.
По моей классификации ДСЛ должен быть нацелен на решение задач в одной предметной области. Универсальный язык автоматически этому противоречит. Другими словами ориентации на домен мало. Это всего лишь один из признаков. В противном случае в ДСЛ-и можно будет записать почти любой язык, и смысл этого термина просто исчезнет, так как он будет синонимом термина "язык".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
> С написанным выше я согласен. Что из сказанного выше, по твоему, противоречит моим словам?
Мое замечание по использованию термина, я не спорю с тобой. Но призываю не обобщать DSL по своему усмотрению. Если есть потребность в термине, при имеющихся противоречиях с существующими скорее нужно вводить новый или даже систему.
DSL это определение в рамках классификации языков GP/DSL/another-SL.
> G>Введи поддержку прикладного объекта или прикладной специфики на уровень языка и вот тебе DSL. > > И получишь встроенный в язык ДСЛ. Не более того. Иначе Лисп и Немерле по твоему определению автоматически становятся ДСЛ-ями (ведь в них можно легко вводить поддержку прикладной специфики), что явно не так.
Уже поправился. Расширение не всегда приводит к появлению domain-specific языка, само расширение так же не обязательно domain-specific, тут нужно смотреть частные случаи.
На Немерле, насколько я его не знаю, нет поддержки конкретной проблемной области на уровне языка, так же его средства для метапрограммирования не ограничивают область применимости языка (с точки зрения идеологии, а не конкретной реализации). Если это не так, назови проблемную область или как-то по другому обозначь домен.
Не используй понятие DSL, если домен не обозначен.
> G>Язык общего назначения может стать DSL-м и без изменения его синтаксиса в явном виде. > > Это противоречит сказанному тобой выше.
Ничуть. Можешь задать уточняющие вопросы.
> G>Например, если поднять обработку сценариев известной нам проблемной области на уровень языка не меняя самого синтаксиса, тем самым ограничивая область применимости данного языка, мы сделаем язык domain-specific. > > А как же пример с 1С?
Выверен, верен. Да ты спроси светил 1С, если они еще не вымерли, хы
> G>Использование вами термина DSL для обозначения решений задач метапрограммирования видится неверным с точки зрения формальной логики, да в общем тоже. > > Для начала хорош бы устранить противоречия в твоих же высказываний.
Вроде бы Их нет.
> По моей классификации ДСЛ должен быть нацелен на решение задач в одной предметной области. Универсальный язык автоматически этому противоречит. Другими словами ориентации на домен мало. Это всего лишь один из признаков. В противном случае в ДСЛ-и можно будет записать почти любой язык, и смысл этого термина просто исчезнет, так как он будет синонимом термина "язык".
Если ты убираешь из определения домен, то автоматически теряешь право называть DSL-ем. Домен тут определяет, домен должен быть. "specific" и "purpose" дает нам направление к применимости, проблемной области. То есть если скажем четко выделяющийся домен, это методология, то нужно смотреть, если это не дает эффекта ограничения на область применимости, то этот домен даже с натяжкой не даст нам domain-specific часть в термине DSL.
Если ты вводишь некоторый набор макросов не общего назначения, то DSL-ем можно назвать только этот набор, а не язык в котором ты его ввел. Средства трансляции не DSL, общие ограничения на синтаксис макросов у вас в Немерле ограничивает как-то область применимости?
Так же для формального соответствия хорошо бы это было не "изменение синтаксиса", а язык. Так же трансляция каких-нибудь невербальных данных выпадает из понятия термина DSL (этот формат данных).
> G>Например, если поднять обработку сценариев известной нам проблемной области на уровень языка не меняя самого синтаксиса, тем самым ограничивая область применимости данного языка, мы сделаем язык domain-specific. > > А как же пример с 1С?
Если я правильно понял твой вопрос, ты предполагаешь в 1С поддержку предметной области на уровне языка. Идеологически и практически ее не было на уровне языка, не думаю что она появилась в последние годы (давно не смотрел). Повторю, вся поддержка проблемной области в 1С на уровне архитектуры и специальных прикладных объектов, создаваемых командами общего назначения, а уже сами они публикуют проблемной области интерфейсы и имеют проблемно-ориентированную логику внутри. DSL который язык запросов, проблемная область у него это не расчет зарплаты, а структура базы данных, движок самой 1С. И он не встроен в язык, он представлен строкой текста в языке 1С.
Здравствуйте, grosborn, Вы писали:
>> А как же пример с 1С?
G>Если я правильно понял твой вопрос,
Похоже, не правильно.
G>ты предполагаешь в 1С поддержку предметной области на уровне языка.
Я говорю, что по твоим же словам 1С не ДСЛ. А раз так, то это противоречит твоим же словам из второй половины твоего сообщения.
G> Идеологически и практически ее не было на уровне языка, не думаю что она появилась в последние годы (давно не смотрел). Повторю, вся поддержка проблемной области в 1С на уровне архитектуры и специальных прикладных объектов, создаваемых командами общего назначения, а уже сами они публикуют проблемной области интерфейсы и имеют проблемно-ориентированную логику внутри. DSL который язык запросов, проблемная область у него это не расчет зарплаты, а структура базы данных, движок самой 1С. И он не встроен в язык, он представлен строкой текста в языке 1С.
Ну, так теперь внимательно прочти свои же слова во второй половине своего исходного сообщения и увидишь противоречие.
1С — это не ДСЛ. Тут я согласен. Это ЯОН в который встроен ДСЛ для доступа к данныи и который прикручен к визуальному ДСЛ который и дает реальные преимущества. А язык 1С — это не более чем скрипт в этой системе.
Но все тоже самое относится и к любому другому ЯОН который прикручивается к некоторой системе или в которой встраиваются расширения позволяющие упростить решение прикладной задачи.
А ДСЛ — это сужение (что ли) возможностей в неотносящихся к задаче вопросах и нацеливание (специализация) языка на одну конкретную задачу.
Отсюда в 1Э есть несколько ДСЛ, но сам язык 1С не ДСЛ, а ЯОН.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
>>Язык общего назначения может стать DSL-м и без изменения его синтаксиса в явном виде. Например, если поднять обработку сценариев известной нам проблемной области на уровень языка не меняя самого синтаксиса, тем самым ограничивая область применимости данного языка, мы сделаем язык domain-specific.
Написано "может стать", значит для доказательства непротиворечивости я могу привести абстрактный пример.
Пример:
Предположим, фирма 1С ввела обработку сценариев предметной области на уровень языка, скажем таких как: решение не компилируется, если в коде не предусмотрена обработка сущностей "Пользователь:Администратор, Пользователь:Руководитель организации, Хрень:Расчетный счет" (проверяется наличие соответствующих по наименованию справочников и предопределенных элементов).
Если такие сценарии ограничат применение языка некоторым множеством предметных областей, по классификации GP(general purpose)/DSL язык станет DSL, хотя синтаксис мы не меняли.
(Сами разработчики платформы 1С таких зависимостей целенаправленно и тщательно избегали.)
Теперь предположим, конкурент выпустил альтернативную платформу, но использовал тот же базовый синтаксис языка, но не ввел обработку ограничивающих сценариев. То есть это как бы диалект языка, не классифицируемый как DSL. Сущности разделяются, язык в общем, а не его диалекты, скорее всего будет рассматриваться и классифицирован как GP.
Здравствуйте, grosborn, Вы писали:
G>Если такие сценарии ограничат применение языка некоторым множеством предметных областей, по классификации GP(general purpose)/DSL язык станет DSL, хотя синтаксис мы не меняли.
G>(Сами разработчики платформы 1С таких зависимостей целенаправленно и тщательно избегали.)
G>Теперь предположим, конкурент выпустил альтернативную платформу, но использовал тот же базовый синтаксис языка, но не ввел обработку ограничивающих сценариев. То есть это как бы диалект языка, не классифицируемый как DSL. Сущности разделяются, язык в общем, а не его диалекты, скорее всего будет рассматриваться и классифицирован как GP.
Берем листинг на С++ если нет там строки :
int i = 0;
Отказываемся компилироваться !!!!
У нас получился супер приплюснутый DSL. Это для сокращения трудозатрат вместо разработки собственного синтаксиса отрубаются возможности ЯОН? Помоему это не DSL. Максимум чего можно достичь — это заузить использование ЯОН до рамок некоторой прикладной области, но синтаксис будет плохо пригоден для нее. DSL в таком случае может быть только набор макросов написанный на таком приплюснутом ЯОН, а сам ЯОН так и останется ЯОН. Просто в ЯОН всегда останется возможность дописать новый макрос, который явно не подходит выбранной прикладной области, а в случае набора макросов мы как бы говорим — эти и только эти макросы будут нами использоваться. Помоему DSL не должен давать использовать синтаксис не сочетающийся с прикладной областью. Вопрос такой — в какой момент ЯОН превращается в DSL если в него все время добавлять новые и новые ограничения? Думаю что надо считать DSL следующим более сложным механзмом по сравнению с библиотеками. Т.е. всякие макросы и наборы процедур это скорее относится к библиотекам. Имхо проще соотносить DSL с декларативным программирование, листинг задает что должно быть сделано, а в DSL должна быть выполнена работа по выяснению что нужно сделать чтобы получить указанный результат. Правда и в ЯОН это происходит, а вместо листинга можно забацать множество библиотечных вызовов. Вот и моя очередь пришла самому себе противоречить.
