cons = (:)
main = do let l = 1 `cons` (2 `cons` [])
          print l

А насчёт определения собственных операторов посмотри на Haskell.

фун, прменя, измнямя, кнецикл, кнецфун, :рлзаця, :пртет

Да и с веществами завязывай, читать такое невозможно.

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

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

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

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

Вон из популярных языков с пользовательскими операторами есть Swift и Scala. Смотри, как они там используются.

прменя рлзаця кнецфун

ЛОР еще не видел такого упоротого пацака

А по теме, не смог толком распарсить твой язык, но что-то подобное в SML.

Да и с веществами завязывай, читать такое невозможно.

Трать-тарарать. А это лучше что ли?

функция СложитьСтрокиФункция(С - строка;остальные_аргументы(Хв) - однородный_список(строка));
  переменная Рез - строка = С, изменяемая;
  цикл по_списку(Сл,Хв)
    Рез = Рез -- Сл;
  конец_цикл
конец_функция
  
инфиксная_операция(:имя СложитьСтроки,
                   :реализация СложитьСтрокиФункция,
                   :приоритет 123);

печать("аффтор" СложитьСтроки " " СложитьСтроки "жжот");

Почему «vs»? См. Algol68.

прменя рлзаця кнецфун

ЛОР еще не видел такого упоротого пацака

Как ты прав.

Вот как это пишется на CL:

(defun сложить-строки-функция (s &rest xb)
  (let ((res s))
    (dolist (sl xb)
      (_f str+ s sl))
    res))

(defun сложить-строки (&rest args) (сложить-строки-функция))

(print (сложить-строки "аффтор" " " "жжот"))

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

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

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

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

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

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

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

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

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

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

swift, алгол 68, Хаскель - никто из них (пока) толком не взлетел. Более-менее взлетел только Пролог.

Ага, в свифте нашёл

infix operator ~> { associativity left precedence 150 }

Такое есть в Swift. См. Custom Operators.

Кстати, планируемые приоритеты операций в моём языке:

* /
+ - --
< > <= >=
равно 
не
и
или
=

Спасибо. За свифт рано радоваться ещё.

Кстати, зачем ограничивать кириллицей круг людей, способных пользоваться языком? Чтобы меньше человек пострадало?

Особой такой цели нет, но и тратить усилия на поддержание двух версий я не готов. Мало сделать ключевые слова, нужно же ещё всю рантайм-библиотеку, все сообщения об ошибках и всю документацию поддерживать двухязычной. Это совсем не мало дополнительной работы.

Почему бы не сделать просто на английском?

1с++ ?

это какой-то ктулху фхтагн. лучше используй суахили, будет читабельнее.

Какие только велосипеды люди не изобретают, вместо того, хорошую книжку по истории развития языков программирования прочесть. А потом рука и лоб от фейспалмов болеть будут.

ЛОР еще не видел такого упоротого пацака

Он использует старый стандарт псевдокода, в котором только 6 значимых символов в идентификаторах.

Лучше, если напрягает количество ключевых слов - см. на синтаксис Haskell.

То-есть, в одном месте создал оператор, в другом месте (подключенной библиотеке от другого разработчика) уже не создашь/не перезагрузишь?

кнецфун

ну ладно

кнецикл

уже нарушение соглашения об именовании(если оно вообще есть), по идее должно быть кнеццикл

измнямя

ГОСПОДИ 228/10

прменя

пдлись вщесвми

даже если считать так, то вещества всё равно мешают ему справляться даже с этой задачей, ибо в некоторых их таки 7

прменя измнямя рлзаця пртет

С уму сйдешися, трбмя зъбану!

В 100-500 раз. Увы, прямяня быстро разворачиваются только у тебя в голове.

По сабжу: грамматика становится сильно контекст-dependent, как для парсера, так и для человека.

фун

совсем не фан. ай со сам щит.

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

Это какую?

измнямя

Забавно. Но лучше откажись от кириллицы. Не порть восприятие русского языка.

напиши скрипт для транслита, и потом из транслита в англ по словарю

слоговую азбуку, типа катаканы с хираганой — только промптом переведённую на русский.

чтобы зазвучало и слоги сохранялись.

То-есть, в одном месте создал оператор, в другом месте (подключенной библиотеке от другого разработчика) уже не создашь/не перезагрузишь?

В лиспе есть понятие «родовая функция», т.е. функция с множественной диспатчеризацией. Примерно то же, что в С++ - виртуальная, только по нескольким параметрам. В любом месте, где можно использовать обычную функцию, можно использовать и обобщённую. Если хочешь сделать оператор, к-рый можно перекрыть, его можно реализовать родовой функцией:

рдвая_функця СложитьЧтоТоФункция(С;остлные_аргменты(Хв));

метд СложитьЧтоТоФункция(С - стрка;остлные_аргменты(Хв) - списк);
// первый аргумент - строка
кнецметд

Можно ещё сделать, чтобы символы «+» могли быть из разных пакетов. Тогда будет и перегрузка, и невозможность перепутать, и свобода в выборе имён.

Например:

пкет
  псевдонимы ц = врженя/цлчислне,п = врженя/плавще;
кнецпкет

И далее

2 ц:+ 2
2.5 п:+ 2.5

Но всё равно набора спец.букв недостаточно - хотя бы для стандартных операций эквивалентности в лиспе их нужно 4 штуки.

Принцп скрщеня слов опсан здесь: https://bitbucket.org/budden/l2/src/default/doc/клчвые-слва-вранты.md?filevie... И давайте его не будем обсуждать здесь, тема совсем не про то. Ну и вообще, тут пока идут постоянные эксперименты. Слово фун является исключением из общего правила, хотя его следует убрать.

Лучше, если напрягает количество ключевых слов - см. на синтаксис Haskell.

Не понял, к чему это. Если это к системе сокращений, то проблема не в количестве слов, а в том, что Русские слова длиннее Английских.

Если к приоритетам операций, то можешь привести пример и аргументировать его? Из описания языка не всегда очевидно, что является преимуществом, а я на Хаскеле никогда не писал.

Мужик, твой язык настолько совершенен, что уже пофигу, перегрузка или пользовательские операторы. Что ты нас, убогих-то, пытаешь?

Увы, прямяня быстро разворачиваются только у тебя в голове.

Любой ЯП нужно сначала учить, а потом уже будет быстрота. Зато потом язык с короткими словами будет читаться и писаться быстрее.

— «Вопрос: что у нея… гм… у нея внутре за лпч?» Лэпэчэ… Кэпэдэ, наверное? Что еще за лэпэчэ?
— Лампочка, значит, — сказал старичок, хихикая и потирая руки. — Кодируем помаленьку.

Любой ЯП нужно сначала учить, а потом уже будет быстрота. Зато потом язык с короткими словами будет читаться и писаться быстрее.

А птм бдм псть пргрмы так же бстро, как ппусы лзят по дрвьям.

Извини, не удержался.

Lol

А птм бдм псть пргрмы так же бстро, как ппусы лзят по дрвьям.

А птом будм псать прграмы так же быстро, как пасы ...

В шкосолесе мысы госовосорисилиси наса восот тасакосом ясазысыкесе, носо эсэтосо прасактисичесескиси бесеспосолесезносо. А вот скрщеня прдумне мною, дстатчно плезны. Я сегодня написал человеку СМСку на этом языке - мне понравилось. Правда, забыл спросить, понял ли он меня.

Станислав Лем — Экстелопедия. Про метаязыки забавно и очень похоже на то что ден втирает.

упячка какая-то

и щачло попяченное

Этот вариант, видимо, и придётся принять, и пойти на такой риск.

пкет
  псвднимы ц = врженя/цлчислне,п = врженя/плавще;
кн

И далее

пчать(2 ц:+ 2); // целочисленное сложение
пчать(2.5 п:+ 2.5); //плавающее

Просто потому, что я не понимаю, в чём проблема. В конце концов, плюсы с перегрузкой операторов существуют, а этот вариант уж не хуже.

Перед сном прочитал две страницы из «Основных концепций языков программирования», 5-е издание, и понял, что лисп - это всё же мерседес среди языков программирования. Операции можно перекрывать, можно при этом сохранять проверку типов, а можно полиморфизм навести. Именно за счёт пространств имён. Расплатой за это является необходимость всегда писать скобки.

А ты просто выбери за дефолтный язык - английский, а не русский. Как сделано во всех нормальных языках программирования, кроме очень узкоспециализированных (1С) или учебных (Кумир). В любом случае для полноценного занятия этой деятельностью (программирование) нужно знать международный язык, ибо на нём материалов гораздо больше, чем на родном.

1. Если тебе хочется - разработай свой язык, в котором по дефолту английский.

2. Тема про перегрузку операций.

остлные_аргменты

переименовать как «ещё». и вообще, подобрать синонимы покороче, пооднозначней, попонятнее.

псевдонимы и пакеты с переименованием — имхо, ОК подход. ну, то есть: не нравится кому-нибудь семантическая упячка и фейлы в денотате — он импортирует пакет/пишет макросы для переименования при импорте стдрнх смвлв опрцй езыговыхъ мдлй и обзывает их как ему угодно.

пусть хоть в партию ПДРС вступают, его дело — в его личном модуле. глвне, в стд пктх бдт прдкъ.

английские синонимы проще в том, что там с падежами и склонениями проблем нет. проще парсер получается. русский парсер с правильной морфологией по идее должен падежи и склонения/спряжения учитывать: хотя бы обрезать суффиксы и окончания, и искать задом наперёд оставшиеся приставки+корни, или просто корни, в словаре корней (задом наперёд, инкрементально)

спряжения и склонения вообще толком нигде не поддерживаются, хотя вру: был такой язык Nadesico, японский типа Gellish English — пиджин специально для упрощённого NLP, text mining-a (ср. например BDD подход и спеки на ествественном языке в Cucumber, например).

там можно было писать типа foo of bar = bar.foo = (slot-value 'foo bar) и т.п.

причем эти типа склонения 'of' были разные, их было много, и они были однозначно понятны из контекста (операции разных объектов, разных DSL).

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

а вообще да, интересно допилить лисп-адынэс до почти натурального русского языка, писать на нём исполняемые спецификации в духе BDD хотя бы, и чтобы всей лисповской машинерией это из человекопонятного ограниченного русского раскручивалось в работающий код (на лиспе, ага; или на чём-то более близком к машине).

вот всё равно какой-то язык должен получиться, чтобы было понятно, что `остлные_аргменты` или там `остлные_аргменты` употребимо только в списке формальных параметров при определении, а не где-то ещё.

язык абстрактного синтаксиса, где проверка семантики (типа семантических или если простые, синтаксических предикатов, типа как в ANTLR) — это проверка на WFF, корректно сформулированные выражения на этом языке.

правда, чего там придираться к конкретному синтаксису «вступайте в партию ПДРС!» если он может быть любой. вопрос в абстрактном и семантике.

многозначность, полисемия

foo of bar

кстати, из естественного языка это можно перевести как foo o'bar или «foo, bar-ов сын» (ср. до отчеств: Иван сын Петров), а можно и как «foo из рода bar», то есть: в первом случае объекты, экземпляры, переменные и динамические типы — а во втором, типы классов, родовые функции и т.п., которые в идеале с ограничениями могут разрешиться в статический тип (типа как в C++ non-virtual метод вычисляется в конкретный метод, или вирутальный — через VTable, относительно простой lookup-table с дважды косвенностью, а сама таблица считается CTFE). ну или как в vala например public static void main разрешается не в метод, а в функцию, например: stdout.printf(«asd:%s»,s); => UFCS переписывается в printf(stdout,«asd:%s»,s), где stdout — статический объект, синглтон (может даже, вычисленный CTFE тип, enum например).

из естественного языка тут однозначно понятно эту разрешимость по контексту, по словоупотреблению. в неестественном прогязыке — надо контекст задавать вручную, либо позаботиться везде слова разные ставить (что хорошо в случае простой однозначной грамматики типа LL(1), но плохо в смысле композиции языковых модулей).

например, в META II эта композиция может быть любая, а в OMeta и т.п. в сторону nanopass framework — это фактически объекты, языковые модули, метаязык языковых модулей, написаный на себе самом.

а вообще да, отчего-то кажется что ты изобретаешь CGOL (алгольный синтаксис с трансляцией в лисп из 90х). может, проще просто к нему русские синонимы прикрутить?

или чего-то не хватает в CGOL ?