Тэкс, я хотел собственно вот что написать. Попробуем стартовать от очень простых аксиом:

• 1. \, после которой в строке есть только белое поле, является продолжением строки.
• 2. Во всех случаях, кроме п.1., конец строки является лексемой кнс.
• 3. Смысл лексемы кнс зависит от контекста парсера. В т.ч. некоторые контексты могут приравнивать её к пробелу.
• 4. кнс не предназначена для дублирования иного разделителя, в т.ч. для имитации точки с запятой.
• 5. Можно написать в коде идентификатор «кнс» и это будет эквивалентно лексеме кнс.

4. кнс не предназначена для дублирования иного разделителя, в т.ч. для имитации точки с запятой.

5. Можно написать в коде идентификатор «кнс» и это будет эквивалентно лексеме кнс.

Традиционно вместо идентификатора «кнс» используется идентификатор ";". Или у тебя точка с запятой имеет другой смысл?

Я ж борюсь с грустными смайликами :) Если взять ;, то борьба сразу проиграна.

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

Зато в лиспе скобки достали.

Какой-то ты странный лиспер.

Арифметика нужна редко, а её парсер изрядно добавляет сложности и неразберихи. Но это нужно преодолеть определённый барьер вхождения.

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

или левый аргумент оператора *, результат которого имеет переопредёленную операцию = ?

согласно указанной выше нотации однозначно разименование с присвоением, т.к.:

а)не указано ключевое слово начала списка объявления и нет скобок после а => остаётся только один вариант.

б)пожертвовав одним редкоиспользуемым в С оператором, выражение можно переписать как

a  x * = b

в)в вашем языке указатели, вообще, будут?

в С/С++ это объявление, т.к. результат оператора умножения * обычно не lvalue

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

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

согласно указанной выше нотации однозначно разименование с присвоением

Не понял, речь шла про С++. Я в целом хотел показать, что с грамматикой всё не настолько очевидно. Впрочем, я даже не знаю, тот ли ты анонимус или вы все разные.

в)в вашем языке указатели, вообще, будут?

В лиспе указатели бывают только из FFI. Обычно к ним не прилагается синтаксического сахара. Тип может быть записан примерно как указатель(иностранный_тип) или что-то в этом роде, а операция разыменования - как разыменовать_указатель(х). Нет мотива занимать звёздочку.

Вот это удобно по настоящему

Однако не удобно когда `1,` превращается в кортеж.

тот же анонимус

Про С++ написал же:

в С/С++ это объявление, т.к. результат оператора умножения * обычно не lvalue

В лиспе ... Нет мотива занимать звёздочку.

а, так у вас язык из лиспосемейста? тогда ваша задача ещё более упрощается

Скорее это его реализация из лиспосемейства. После борьбы с грустными смайликами язык больше всего похож на Бейсик.

Однако не удобно когда `1,` превращается в кортеж.

Ну так в кортеж должно превращаться `(1,)`.

Что? Ты "?" и «>» без шифта вводишь?

Яр - бе́рег, яр || берегово́й (татарский язык).

Ещё в татарском фамилия Деветьяров - означает девятый сын, вроде как.

Что, получилось совпадение? В Русском - ярость или любовный пыл, а в Татарском - берег? С Деветьяровым ситуация вообще непонятная. Сын относится к любовным отношения, а девять - это кто у кого взял числительное?

Впрочем, меня и слово «берег» тоже устраивает - это моё любимое место.

Думал-думал и вот что надумал. В лиспе есть полная и краткая форма для многих вещей. Например, поля класса могут быть просто имя, а может быть (имя и-ещё-всякая-байда-к-нему).

Не не совсем красиво выглядит такой код:

(defclass foo () (
 a
 (another-field :reader blabla)
 c
))

класс ура ()
  описание "Это мой класс"
  поля
    а
    другое_поле 
      :читатель блабла 
      :док "это описание другого поля"
      кн
    в - такой_то_тип
    г - \
      слишком_уж_длинный_тип_у_поля_г
  кнп
кнк

Как сообщество, одобрит? Мне кажется, неплохо получилось.

Внезапно открылось целых два новых изменения:

1. Списки с разделителем «пробел». Применимо там, где у нас список слов. Не вполне применимо там, где может чередоваться простое слово и более сложная конструкция. Например «select a b,c,d» - это случай, когда разделитель пробел неприменим. Поскольку запятые можно расставить неоднозначно, при этом получатся осмысленные, но разные и визуально похожие тексты. Т.е. такой синтаксис провоцирует ошибки.

Пример возможного применения списка с разделителем пробел - это описание различных атрибутов параметра поля, как в вышеприведённом определении класса «ура».

2. :ключевые-слова против ключевых-слов . Например,

если ... то
кне

:если ... :то
:кне

Менее очевидный пример - это defsystem. Обычно определение системы выглядит так:

(defsystem "hello-lisp"
  :description "hello-lisp: a sample Lisp system."
  :version "0.0.1"
  :author "Joe User <joe@example.com>"
  :licence "Public Domain"
  :depends-on ("optima.ppcre" "command-line-arguments")
  :components ((:file "packages")
               (:file "macros" :depends-on ("packages"))
               (:file "hello" :depends-on ("macros"))))

(defsystem "hello-lisp"
  :description "hello-lisp: a sample Lisp system."
  :version "0.0.1"
  :author "Joe User <joe@example.com>"
  :licence "Public Domain"
  :depends-on "optima.ppcre" "command-line-arguments"
  :components :file "packages"
              :file "macros" :depends-on "packages"
              :file "hello" :depends-on "macros"
)

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

(defsystem "hello-lisp"
  :components :file "packages"
              :file "macros" :depends-on "packages"
              :file "hello" 
  :depends-on "optima.ppcre" "command-line-arguments"
)

(defsystem "hello-lisp"
  :components (:file "packages"
               :file "macros" :depends-on "packages"
               :file "hello") 
  :depends-on "optima.ppcre" "command-line-arguments"
)

При этом надёжность синтаксиса практичеки восстановлена. Можно также потребовать, чтобы описание компонента всегда начиналось с новой строки, тогда синтаксис явно будет более читаем для человека, чем обычный синтаксис asdf. И тут, что самое внезапное, оказывается, что синтаксис «скобки лайт» пригоден и для Яра, достаточно лишь переделать его вот так:

система "hello-lisp"
  :компоненты (:файл "packages"
              :файл "macros" :зависит-от "packages"
              :файл "hello") 
  :зависит-от "optima.ppcre" "command-line-arguments"
кнс

Как-то мне это всё раньше не приходило в голову. Казалось бы, зачем лезть в лишние дебри? Ведь вроде был уже синтаксис? Но я обнаружил, что текущий проект синтаксиса Яра стал не вполне самосогласован после удаления точки с запятой. Вроде он стал улучшаться, но при этом стали появляться места, где выбор синтаксиса перестал быть однозначным.

Нарпимер, объединяя эти два измерения, получаем, что можно с помощью :кейвордов описывать такие важнейшие сущности, как параметры функций и поля классов.

Поэтому придётся ещё дорабатывать синтаксис.

Нда, что-то плохо события развиваются.

Становится неясно, когда использовать ключевое слово с двоеточием, а когда - без него. Нужно либо придумать простое общее правило на эту тему, либо помнить. Простое правило я пока не смог придумать.

Дальше. Получается несколько стилей завершения конструкции. В случае ключевых слов с двоеточием конструкцию завершает следующее ключевое слово. А ранее рассматривался только стиль, когда каждую конструкцию завершает соответствующее кн*. Также можно использовать круглые скобки. Все три стиля нужны в разных контекстах. Например, завершение следующим словом нужно для стиля командной строки, а кн* подходит для структурного программирования. Скобки традиционно используются для перечисления параметров функции.

Но! Возникает проблема - как определить область применения каждого из стилей? Как её не проведи, нужно будет ещё и помнить, в каком случае используется какой стиль. В итоге скорее всего правило будет сложным и нужно будет для каждого случая его просто помнить. Это плохо.

То же касается выбора разделителей. Есть аж три варианта: пробел, запятая, конец строки. Опять же придётся помнить.

Основная моя претензия к синтаксису лиспа - это избыточное количество скобок. Прежде всего, в конструкциях let и do. Их нужно не только помнить, но и читать каждый раз. Если сделать синтаксис с разными стилями, то читать становится вроде бы легче, но помнить при этом, оказывается, нужно гораздо больше! И вдруг может оказаться, что и читать будет труднее (т.е. прочитаешь, но неверно, если не будешь верно помнить синтаксис для данного конкретного случая). Вот что стало для меня вчера неприятным открытием.

Т.е., оказалось, что синтаксис лиспа лучше, чем то, что я о нём думал.

Это порождает грустные смайлики ");" и «};» и я попытаюсь от них избавиться.

golang

Нет, ты серьёзно?

}
;//-) 

Я серьёзно. А также я не понял, что ты нарисовал.

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

a = sin(x);

Никто не заставляет, но они получаются.

a = sin(x)
;//-)

А я про что?

на практике так никто делать не будет.

Сделать правило, что если в строке есть несбалансированная открывающая круглая скобка, то следующая строка является продолжением предыдущей, и так до тех пор, пока скобка не будет сбалансирована. Так, по сути, сделано в лиспе.

Думаю, тебе понравится JavaScript.

CoffeeScript

Думаю, тебе понравится JavaScript.

Спасибо! Нашёл вот это: https://habrahabr.ru/post/111563/ . Смотрю.

Понял, что восприятие текста настолько сильно зависит от его раскраски, что без неё не стоит даже и примеряться. Раскрасил вручную фрагмент кода, вот результат

Основные изменения за последнюю неделю:

• пришло понимание, что грустные смайлики заложены в саму математическую нотацию: а=(b+c)*d, поэтому изжить их не получится
• заодно я вспомнил, что скобки в мат.нотации перегружены: они служат для преодоления приоритета операций и для выделения аргументов функции. Я разделил два вида скобок. Для выделения аргументов функции и для описания списков остались обычные скобки. Для преодоления приоритета операций я применил скобки из смайликов (: :) . Таким образом, не сумев изжить грустные смайлики, я их компенсирую весёлыми и заодно убираю неоднозначность в синтаксисе.
• поглядев, как красив код на прологе, решил разрешить для символов дополнительные буквы. Пока это тире, процент и доллар. Над остальными думаю. Видимо, надо сделать как в лиспе - там почти все буквы и значки можно применять, в т.ч. символами являются >=, + и т.п.
• свёл воедино весь код и написал его в едином стиле, ссылка на результат в начале данного комментария.
• для конкатенации строк задействовал амперсанд (&) - всё равно без спец.раскладки с AltGr неудобно работать с Русской раскладкой. Сейчас у меня под офтопиком используется раскладка Чистова. Для консерваторов можно в IDE сделать пункт меню для выбора значков - будет что-нибудь типа Alt-4 нужная-кнопка. В принципе, это для меня удобнее, чем AltGr, который неудобно расположен.

Похоже, что синтаксис теперь меня устраивает. Хотя ещё не закончен пересмотр всех требований и проверка соответствия им.

Я прочитал, как в JavaScript и мне не понравилось:

К сожалению, есть пять токенов, которые могут как начинать оператор, так и продолжать уже завершённый. Это "(", «[», ... ... Многие начинающие программисты на яваскрипте получают советы ставить ";" везде, и полагают, что если они не используют правила автовставки ";", это свойство языка можно игнорировать. Это не так ... А когда они знакомятся с ... , они начинают боятся переносов строк, и избегают их даже когда они улучшают читабельность. ... Ставить ли точки с запятой? Дело ваше.

Я проглядел правила целиком (не сказать, что в деталях разобрался, но нашёл то, что искал в них). Процитированного достаточно, чтобы отвергнуть эту версию. Во-первых, видим, что проблемы с обучением. Во-вторых, не нужна лишняя неоднозначность в языке, которая будет сказываться в каждой строчке. Я считаю, это правило - ошибка дизайна JavaScript. Теперь могу я задать вопрос: в CoffeeScript приняты во внимание ошибки JavaScript? Если да, то напишите, пож, в двух словах, в чём отличия (и где это прочитать).

боремся с грустными смайликами

используй лисп. Там кол-во грустных смайлов совпадает с кол-вом весёлых xD

Я свой ЯП разрабатываю, на основе лиспа, с более удобным (как я надеюсь) синтаксисом. Но в лиспе оно тоже не совпадает:

(defun foo ()
  (some-fun :keyarg1 (+ 2 2) :keyarg2 nil)
  (+ 2 2); попробуем просто добавить 2 к двум
  ) ; defun 

Из немецкого-таки: https://ru.wiktionary.org/wiki/цуг

Длинные строки, требующие переноса, возникают тогда, когда у функции много аргументов. Других вариантов я не могу придумать.

Сложные условия в if/while, сложные выражения в присваивании.

Ruby, никто не использует «;», но это не запрещено.

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

Вот к чему пришёл на данный момент

Хотя не факт, что удалось избавиться от всех противоречий. В частности, не удастся обойтись без доп.значков, которых нет в обычной Русской раскладке. Для офтопика есть раскладка Чистова. Для линукса тоже бывают нестандартные раскладки (здесь тоже в своё время обсуждалось).

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

Этот синтаксис пока только в проекте. Сначала доделаем раскраску текста, потом будем синтаксис делать.

Пиши на фортране

«кличка библиотеки»

facepalm.jpg

Ну, хорошо хоть не «погоняло».

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

итак, боремся с грустными смайликами

:) ;) ) ...

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