Мне нужно создать DSL для не-программистов (клиентов нашей компании), которым необходимо предоставить некоторые языковые функции более высокого уровня (циклы, условные выражения, переменные... - так это не просто "простая" DSL).
Работа с DSL должна быть простой; люди должны уметь экспериментировать с ним и изучать его, играя вокруг. Мы хотим добиться чего-то похожего на макросы в Microsoft Excel - многие пользователи Excel могут создавать простые формулы, суммы или вычисления и никогда не работали с "реальным" (общим) языком программирования.
Очевидно, что не каждый пользователь Excel понимает более сложные встроенные методы (например, When()), но они могут использовать простые методы, такие как SUM() или AVG(). Я хочу добиться аналогичного эффекта, поскольку DSL-uesrs должны иметь возможность интуитивно работать с ним и определять простые правила или выполнять простые вычисления. В то же время DSL должен предлагать функции более высокого уровня для более технически наклонных петель, if-statements, возможно, методов или лямбда.
И это приводит меня к моим вопросам: Какие языковые конструкции интуитивно понятны, понятны и понятны?
В текущей экспериментальной версии DSL мы попытались использовать метод-цепочку, например: list.where(item -> item.value > 5).select(item -> item.name + " " + item.value)).
Подумайте о where и select как конструкциях foreach, где item - это переменная, которая представляет текущий элемент в цикле.
Причина, по которой мы сначала попытались использовать этот подход, заключается в том, что было бы легко поддерживать завершение кода - всякий раз, когда пользователь вводит период (.), отображает список возможных методов. Однако я не уверен, что эта концепция соответствует моим критериям того, чтобы быть интуитивным и понятным и понятным.
Легче ли читать/читать для пользователей, нет ли скобок? (например, в LINQ: from item in list where item.value > 5 select item.name + " " + item.value). Однако в этом случае нет "границ" - в предыдущем примере пользователь знает, что оператор заканчивается последней замыкающей скобкой - в этом случае, если он вводит больше кода после select части инструкции, он не делает '- знать, принадлежит ли это утверждению или нет (кроме того, что синтаксический анализатор тоже не знал, и должно было быть какое-то закрытие).
Надеюсь, мой вопрос немного ясен с этими двумя примерами - я ищу рекомендации по дизайну, лучшие практики, опыт в реальной жизни, возможно исследовательский материал какие языковые конструкции благоприятны для других - или некоторая оценка плюсов и минусов определенных языковых конструкций.
Я не ищу информацию о том, как создать DSL, о том, какие генераторы парсеров я могу использовать и т.д., и я также не могу использовать существующий язык общего назначения (Ruby, Python,...) вместо того, чтобы использовать DSL. (DSL, когда разбирается, работает непосредственно с нашей объектной моделью - я не буду вдаваться в подробности здесь, так как этот вопрос уже достаточно длинный, как есть).
Изменить: Возможно, я должен указать, что под "языковыми конструкциями" я подразумеваю синтаксис, то, как что-то написано, а не то, какую функциональность должен предлагать язык - у нас уже есть список которые должен предоставить DSL. Вопрос в том, как эти функции лучше всего выражать, чтобы создать (и поддерживать) простые и сложные формулы.
