История изменений

Как минимум нехорошо то, что пользовательские операторы качественно усложняет парсер, делая его контекстно-зависимым, что косвенно влияет на экосистему языка через усложнение написания всяких утилит.

На этот вопрос у меня есть ответ - будет интерфейс парсера, чтобы его можно было включать в утилиты и в IDE вместе со всеми расширениями.

Далее, операторы необходимо запоминать, так что их лучше вводить как можно меньше, только для самых центральных понятий DSL. Если применять их где попало, то язык рискует превратиться во write-only кашу.

Вот. Именно это меня и смущает.

Далее, если операторы-слова слишком многословны для частоиспользуемых операций, так что нужны символы.

Я вижу такой вариант использования. Написали а == б, потом поняли, что надо не ==, а equalp. Переписывание в виде equalp(а,б) сильно меняет вид кода и можно внести ошибку. Ошибка в сложном логическом выражении обычно стоит очень дорого. Вот и хочется сделать все эти equalp операторами сравнения. В лиспе их много (5, что ли) и всегда можно добавить новый.

Второй вариант использования - это арифметика. Есть сложение целых чисел ограниченных, неограниченных, плавающих одинарных, плавающих двойных, и BCD для бухгалтеров, сложение в линейной алгебре. Ошибка опять же дорого стоит. Повесить всё это на один и тот же плюс выглядит стрёмным. В ocaml вроде есть +. , но я уже перечислил 6 разных операций, а не два. Например, дурно пахнет, если умножение матриц и умножение матрицы на скаляр пишутся одинаково.

Делать всё это вызовами функций, как в лиспе - тоже радости мало.

А человеческое указание приоритетов через отношения с другими операторами поднимает неудобные вопросы модульности.

Поправил пример. Теперь можно ставить новую операцию только в ряд с уже существующими. Новых приоритетов заводить нельзя. Где-нибудь такое пробовали уже? Что вышло?

Как минимум нехорошо то, что пользовательские операторы качественно усложняет парсер, делая его контекстно-зависимым, что косвенно влияет на экосистему языка через усложнение написания всяких утилит.

На этот вопрос у меня есть ответ - будет интерфейс парсера, чтобы его можно было включать в утилиты и в IDE вместе со всеми расширениями.

Далее, операторы необходимо запоминать, так что их лучше вводить как можно меньше, только для самых центральных понятий DSL. Если применять их где попало, то язык рискует превратиться во write-only кашу.

Вот. Именно это меня и смущает.

Далее, если операторы-слова слишком многословны для частоиспользуемых операций, так что нужны символы.

Я вижу такой вариант использования. Написали а == б, потом поняли, что надо не ==, а equalp. Переписывание в виде equalp(а,б) сильно меняет вид кода и можно внести ошибку. Ошибка в сложном логическом выражении обычно стоит очень дорого. Вот и хочется сделать все эти equalp операторами сравнения. В лиспе их много (5, что ли) и всегда можно добавить новый.

Второй вариант использования - это арифметика. Есть сложение целых чисел ограниченных, неограниченных, плавающих одинарных, плавающих двойных, и BCD для бухгалтеров, сложение в линейной алгебре. Ошибка опять же дорого стоит. Повесить всё это на один и тот же плюс выглядит стрёмным. В ocaml вроде есть +. , но я уже перечислил 6 разных операций, а не два. Например, дурно пахнет, если умножение матриц и умножение матрицы на скаляр пишутся одинаково.

Делать всё это вызовами функций, как в лиспе - тоже радости мало.

А человеческое указание приоритетов через отношения с другими операторами поднимает неудобные вопросы модульности.

Здесь я бы ограничился небольшим количеством классов приоритетов (уж точно меньше, чем в С) и не позволял бы заводить новые приоритеты. Где-нибудь такое пробовали уже? Что вышло?

Как минимум нехорошо то, что пользовательские операторы качественно усложняет парсер, делая его контекстно-зависимым, что косвенно влияет на экосистему языка через усложнение написания всяких утилит.

На этот вопрос у меня есть ответ - будет интерфейс парсера, чтобы его можно было включать в утилиты и в IDE вместе со всеми расширениями.

Далее, операторы необходимо запоминать, так что их лучше вводить как можно меньше, только для самых центральных понятий DSL. Если применять их где попало, то язык рискует превратиться во write-only кашу.

Вот. Именно это меня и смущает.

Далее, если операторы-слова слишком многословны для частоиспользуемых операций, так что нужны символы.

Я вижу такой вариант использования. Написали а == б, потом поняли, что надо не ==, а equalp. Переписывание в виде equalp(а,б) сильно меняет вид кода и можно внести ошибку. Ошибка в сложном логическом выражении обычно стоит очень дорого. Вот и хочется сделать все эти equalp операторами сравнения. В лиспе их много (5, что ли).

Второй вариант использования - это арифметика. Есть сложение целых чисел ограниченных, неограниченных, плавающих одинарных, плавающих двойных, и BCD для бухгалтеров, сложение в линейной алгебре. Ошибка опять же дорого стоит. Повесить всё это на один и тот же плюс выглядит стрёмным. В ocaml вроде есть +. , но я уже перечислил 6 разных операций, а не два. Например, дурно пахнет, если умножение матриц и умножение матрицы на скаляр пишутся одинаково.

Делать всё это вызовами функций, как в лиспе - тоже радости мало.

А человеческое указание приоритетов через отношения с другими операторами поднимает неудобные вопросы модульности.

Здесь я бы ограничился небольшим количеством классов приоритетов (уж точно меньше, чем в С) и не позволял бы заводить новые приоритеты. Где-нибудь такое пробовали уже? Что вышло?

Как минимум нехорошо то, что пользовательские операторы качественно усложняет парсер, делая его контекстно-зависимым, что косвенно влияет на экосистему языка через усложнение написания всяких утилит.

На этот вопрос у меня есть ответ - будет интерфейс парсера, чтобы его можно было включать в утилиты и в IDE вместе со всеми расширениями.

Далее, операторы необходимо запоминать, так что их лучше вводить как можно меньше, только для самых центральных понятий DSL. Если применять их где попало, то язык рискует превратиться во write-only кашу.

Вот. Именно это меня и смущает.

Далее, если операторы-слова слишком многословны для частоиспользуемых операций, так что нужны символы.

Я вижу такой вариант использования. Написали а == б, потом поняли, что надо не ==, а equalp. Переписывание в виде equalp(а,б) сильно меняет вид кода и можно внести ошибку. Ошибка в сложном логическом выражении обычно стоит очень дорого. Вот и хочется сделать все эти equalp операторами сравнения.

Второй вариант использования - это арифметика. Есть сложение целых чисел ограниченных, неограниченных, плавающих одинарных, плавающих двойных, и BCD для бухгалтеров, сложение в линейной алгебре. Ошибка опять же дорого стоит. Повесить всё это на один и тот же плюс выглядит стрёмным. В ocaml вроде есть +. , но я уже перечислил 6 разных операций, а не два. Например, дурно пахнет, если умножение матриц и умножение матрицы на скаляр пишутся одинаково.

Делать всё это вызовами функций, как в лиспе - тоже радости мало.

А человеческое указание приоритетов через отношения с другими операторами поднимает неудобные вопросы модульности.

Здесь я бы ограничился небольшим количеством классов приоритетов (уж точно меньше, чем в С) и не позволял бы заводить новые приоритеты. Где-нибудь такое пробовали уже? Что вышло?