LINUX.ORG.RU

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

 ,


0

1

Есть такая вот идея на тему ключевых слов.

Сделать их полными (полной длины). В том числе и для знаков. Например, сложение - это будет «плюс» или «сложить». Составной оператор будет «составной оператор».

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

При открытии файла в среде к нему применяется сахар. Который представляет из себя отдельную таблицу сокращений. В ней записано, что составной оператор - это, скажем, «{}», а в плюс - это «+». И к тому добавляется затеняющая последовательность на случай, если совпадёт сокращение с реальным содержанием файла. Например, если мы сократим слово начать_вычисления до нв, а в файле уже есть слово нв, то «нв» - это будет начать_вычисления, а эскейп(нв) - это будет слово «нв».

Сахар, существует только в памяти и на экране. Можно печатать сахарными словами, которые при сохранении преобразуются в полные.

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

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

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

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

★★★★★

Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от monk

Проблема исключительно в парсинге/генерации текста. Либо парсер должен быть сильно интеллектуальным,

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

Ещё в комментариях бывает псевдографика (таблицы, диаграммы, ...)

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

den73 ★★★★★
() автор топика
Ответ на: комментарий от monk

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

Да. Потому что его можно сверить с бумажкой слева направо. Хотя конечно в реальной жизни далеко не все формулы так можно запрограммировать. Но хотя бы и ногда.

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

Ничего особенного.

Ты написал, что такое

(defvar prefs '(,user no-save ,max-conn 7))
;                   lucky number -------^
должно парситься в 7#|lucky number|#

Самое простое правило: комментарий относится к тому, справа от чего он идёт.

Иногда к тому, перед чем, иногда сразу к нескольким объектам далее.

monk ★★★★★
()
Ответ на: комментарий от den73

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

Да. Потому что его можно сверить с бумажкой слева направо.

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

antares0 ★★★★
()
Ответ на: комментарий от monk

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

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 2)
Ответ на: комментарий от monk

Иногда к тому, перед чем, иногда сразу к нескольким объектам далее.

Придётся поменять стиль. Или просто читать комментарии глазами. Да и вообще, я же не меняю порядок следования. Да, табличная вёрстка, где часть из комментария, а часть - нет - развалится.

den73 ★★★★★
() автор топика
Ответ на: комментарий от antares0

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

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

Т.е., нужно как бы заархивировать текст.

А потом каждый, кто читает, будет вынужден его разархивировать? Зачем?

anonymous
()

Написал несколько документов на эту тему, кому интересно, можно тут почитать, начиная с «сокращения-идентификаторов» и заканчивая «каноническая форма-исходного-текста»

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

(in-package :a)
(with-added-package :b 
  (list
  'internal-symbol-from-a
  'external-symbol-from-b
  'a::conflicting-symbol
  'b:conflicting-symbol
  ; просто conflicting-symbol - это была бы ошибка чтения
  ))

Здесь (some code) видит все символы из a и внешние символы из b. В случае, если какой-то символ конфликтует, он становится не виден.

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

den73 ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.