синтаксис отдельно, сахар отдельно

Ты прямо как будто следишь за моими невысказанными мыслями. Следующий шаг — забить на текст вообще и хранить сразу нормальное дерево исходника, а в текст превращать только для редактирования (потому что в предкопиляционном коде бывает бардак и хранить структуру почти невозможно). Это сразу решит проблемы стиля — просто у каждого свой форматтер, больше никаких споров о табах/спейсах, рус/энг, даже {} vs begin-end. Рефакторинг тоже может заключаться в паре-тройке правок и переименовании в одном месте, если хранить не имена символов, а ссылки на них, как в любой нормализованной базе. При этом переименование не будет дырявить диффом полпроекта, а будет заменять лишь одну запись.

Но и в твоем виде идея хорошая, в плане и перспектив, и возможностей.

Детский сад. Это, собственно, примитивный транслятор, это любой прогер и так может сделать. Вообще, в нормальных языках нет никаких ключевых слов, там и так можно сокращать что угодно. Но для криворуких может быть да, вариант.

А вообще, если есть язык, что транслируется предварительно в код на С, разве это не то же самое?

С возвращением.

но элегантные квазицитаты, как в лиспе

`'@((`/#,((#,foo — образец элегантности. Чем то на балерину похоже, такая вся легкая и воздушная.

спасибо. Но я так, на минуточку зашел.

Ну это вообще-то не я придумал, о человек, далёкий от программирования. И где-то несколько месяцев тому.

Дополнительная возможность в этой же струе такая: в файле всегда писать namespace:name и никогда не писать просто name. Это решает такую неудобную проблему, как наличие одноимённых символов в разных пр-вах имён. Поиск по файлам в этом случае всегда позволяет понять, о чём речь. Правда, я этот вопрос собирался по-другому решать, т.е. тут не уникальное преимущество.

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

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

Ну и можно представить себе ситуацию, когда два человека сели за один компьютер и не могу прочитать один текст, потому что у каждого свой стиль сокращений.

И вообще получается смысловая подложка под исходником - это уже не очень хорошо.

Вопрос не в том, сложно ли это сделать, вопрос в том, полезно ли так сделать.

Нет, потому что трансляция необратима.

А то что ты предлгаешь обратимо? Если я залезу непосредственно в синтаксис, он потом сможет по этому сделать сахар?

Да.

А я скажу что нет, потому-что иначе твой вопрос не имеет смысла.

На что только не идут люди, лишь бы не использовать лисп...

Ты сам делаешь кофе, или 3 в 1 употребляешь?

Лисп он для роботов, не для человеков.

Интересная логика, даже не знаю, что ответить :)

Кто эти люди? Уж не я. Я использовал лисп на последних 5 местах работы, а также в 3-4 последних хоббийных проектах. Где-то так. Но лисп не идеален. Если бы было иначе, не было бы ни Явы, ни Перла, ни Питона, ни Раста.

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

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

Видел я тут недавно XML файлы сборки анта. По сравнению с XML лисп для человеков.

Почему?

Вот смотри, сахар описывает только ограниченное количество синтаксических конструкций. И если ты предполагаешь вмешательство в с чистый синтаксис, то он в большинстве случаев обратно в сахар не преобразуется. То есть придется оставлять в виде чистого синтаксиса. Либо это должен быть какой-то новый упоротый синтаксический сахар на все случаи жизни, а по сути второй синтаксис с обратимой трансляцией друг в первый, с сохранением человекочитаемости при этом. И что это тогда получится, и главное зачем? С этой точки зрения уже и не имеет смысла твой вопрос.

Потому-что это для человека нужны более бегло узнаваемые конструкции, чем подсчет скобочек. А в лиспе вся читаемость в итоге упирается в подбор годных идентификаторов. Но даже с этим, очень сложно добиться читаемости, потом-что в терминах человеков получатся контекстозависимый изолированный язык практически без какой-либо грамматики, просто слова записанные в строчку. И опять упирается в пересчет скобочек. Либо нужно извращаться с отступами, но зачем тогда лисп.

Это да, но только потому-что XML перегружает текст бессмысленным для человека мусором. А по сути не так уж и далеко от лиспа о XML.

Ты нормальный лиспокод когда-нибудь пробовал читать? Пробовал писать его в редакторе, который поддерживает автоформатирование его?

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

Ясно))

код хранится в файле именно в таком виде.

При открытии файла в среде к нему применяется сахар.

Похоже на XML-редакторы... там тоже переносы игнорировались и синонимы были и я даже помню, что мне там не нравилось.

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

(defvar prefs '(1   ; user number
                2   ; file number
                5   ; max connection
                0   ; no save
                7)) ; lucky number
или
(defvar prefs '(,user no-save ,max-conn 7))
;                   lucky number -------^

все равно

list(1, 2, 3) map(x, x + 1) reduce(+)
// лучше чем
(reduce + 
 (map (lambda(x) (+ x 1))
  (list 1 2 3)))

Вот смотри, сахар описывает только ограниченное количество синтаксических конструкций.

Так в языках вообще ограниченное число синтаксических конструкций. Условно (if a b c) <=> if a then b else c для любых a b и с.

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

Если останется годным синтаксисом, то преобразуется. При наличии сахара для этого синтаксиса. Можешь считать, что сахар — это «раскраска синтаксиса». Ведь тебя не удивляет, что IDE всегда правильно ключевые слова раскрашивает и отступы ставит.

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

list(1, 2, 3) map(x, x + 1) reduce(+)

Это надо сравнивать с

(@ '(1 2 3) (map #L(+ !1 1)) (reduce +))

А

(reduce + 
 (map (lambda(x) (+ x 1))
  (list 1 2 3)))

с

reduce(+, 
  map(function(x) { return x + 1; }, 
      list(1, 2, 3)))

По-моему, одинаково читаемо

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

ну, речь то была об общем сравнении, зачем же выборочно сравнивать.

зачем же выборочно сравнивать.

Так и я про то же. Если надо писать в именно функциональном+ООП стиле, то на лиспе (в смысле Common Lisp) будет использоваться библиотека с соответствующим макросом. Если просто человек будет переписывать алгоритм на лиспе, то использует стандартные конструкции и будет (для любого map/reduce) что-то вроде

(loop for i in '(1 2 3)
      sum (+ i 1))

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

а для общего — хрен. Надо учитывать и число аргументов, и их последовательность, и место в коде, и тип и много чего еще.

Я же тебе привёл пример. с (@ ...). Он уже написан.

Как у тебя будут хранится комментарии?

Да, это проблема. По второму случаю можно сделать 7#|lucky number|# , а с первым случаем явно не повезло и сделать ничего нельзя. Разве только ввести понятие таблицы (я в Mathematica одно время хотел так кодить, но до дела не дошло).

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

Я встретил проблему в том, что не хватает коротких слов. Можно наполнить язык всевозможными !@#$%^&*, а можно всё выписывать словами. На самом деле для каждой конкретной ситуации короткие значки нужно задействовать под те последовательности слов или иных знаков, которые в этой ситуации встречаются более часто. Т.е., нужно как бы заархивировать текст. Тогда он станет короче.

Я столкнулся с невозможностью выработать универсальный набор значков. Их тупо не хватает. Особенно если хочется часть оставить пользователю на DSL-и. Отсюда и возникает мысль: создать набор длинных выражений, которые годятся на все случаи жизни. При этом все короткие значки останутся свободными! Сахар состоит в том, что для конкретного случая существует свой оптимальный способ сопоставления коротких значков длинным, и невозможно придумать этот способ на этапе разработки языка. Тем более один способ невозможно придумать - его просто нет в природе.

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

Есть определённая граница между лиспом и не-лиспом. Она проходит по тому месту, где возникает инфиксная запись и приоритет операторов. Например, писать формулы в лиспе просто очень и очень неудобно, при всём моём опыте мне это не понравилось. Формулы должны быть похожи на формулы, потому что их мы будем сверять с бумажкой.

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

длинное_выражение1 or длинное_выражение2 and длинное_выражение3

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

(or
  длинное_выражение1 
  (and длинное_выражение2 длинное_выражение3))

Это объективно проще распарсить. Можно конечно

длинное_выражение1 or (длинное_выражение2 and длинное_выражение3)

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

По второму случаю можно сделать 7#|lucky number|# , а с первым случаем явно не повезло и сделать ничего нельзя.

Так можно и с первым 1#|user number|#, 2#|file number|#. Проблема исключительно в парсинге/генерации текста. Либо парсер должен быть сильно интеллектуальным, чтобы догадаться к какой лексеме какой комментарий, либо надо делать IDE с плавающими рядом комментариями...

Ещё в комментариях бывает псевдографика (таблицы, диаграммы, ...). Это тоже надо учесть. Хотя если нагружать IDE, то можно хоть картинки и видео вставлять :-)

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

Гм. Берём простейшую формулу дискриминанта:

\frac{-b - \sqrt{b^2 - 4ac}}{2a}

произносим "отношение разности между -b и квадратным корнем из
 разности квадрата b и четырёхкратного произведения a и c, к удвоенному a"

на лиспе пишем
(/ (- (- b) (sqrt (- (sqr 2) (* 4 a c))))
   (* 2 a))

на фортраноподобном
(-b - sqrt(sqr(b)-4*a*c))/(2*a)

Тебе точно фортраноподобный кажется естественней?

Я встретил проблему в том, что не хватает коротких слов.

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

3 в 1 говорят, содержит много бензола.

Однако кофе, сахар и молоко до начала употребления храню в отдельных ёмкостях.

Вот кофе и молоко, говорят, лучше и употреблять по отдельности (как впрочем чай и молоко).

Кстати, а есть уже соответствующий файлик для bison/flex, re2c, ragel (или аналогов)? Когда язык ещё пишется, реальность компактного описания грамматики была бы хорошим знаком.

Я столкнулся с невозможностью выработать универсальный набор значков. Их тупо не хватает.

В юникоде не хватает?

произносим

Однако, ТС писал «Формулы должны быть похожи на формулы, потому что их будем сверять с бумажкой», а не «код должен быть похож на русский язык, потому что будем его читать вслух».

В юникоде не хватает?

Даже юникод не обязателен. Бери пример с Haskell:

sextupleTest = (0,1,0,1,0,1)
    & _1 .~ 7
    & _2 %~ (5 *)
    & _3 .~ (-1)
    & _4 .~ "orange"
    & _5 %~ (2 +)
    & _6 %~ (3 *)

Лексер/парсер я написал руками, но теперь его надо полностью переработать, поскольку синтаксис с тех пор сильно поменялся. Есть описание на примерах, в нём почти всё устаканено.

https://bitbucket.org/budden/yar/src/default/doc/описание-языка/синтаксис-201...

На юникод пока не хочу закладываться.