Чому у Elisp немає просторів імен?

Питання: Чому у Elisp немає просторів імен, і як ми могли їх отримати?

У Elisp немає просторів імен, крім глобальних, що призвело до конвенції кодування префіксації всіх глобальних функцій, змінних та констант унікальним префіксом.

Окрім фактора роздратування, це також вражає мене проблемою закипання, що дається 1) постійно зростаючою кількістю великих бібліотек та пакетів та 2) постійним існуванням спадкових функцій та змінних, які або не дотримуються конфігурації префікса, або є достатньо ідіосинкратичними, що насправді не існує хорошого варіанта префікса, який вони могли б використати. Це також означає, що періодичні спроби раціоналізувати старіші коди (як і при переході від clдо cl-lib) є нетривіальним обсягом роботи. (Хоча я радий за прибирання, я все одно проливаю сльозу кожен раз, коли я набираю щось на кшталт cl-find).

Я пішов обдумувати, щоб дізнатись, чому після кількох десятиліть використання у Elisp все ще немає просторів імен, але трохи здивувався скромному врожаю. Сторінка вікі в просторах імен досить коротка. Nic Ferrier має дещо довше питання щодо вирішення цього питання, і на ньому також є доволі недавня тема щодо emacs-devel . Є стара нитка переповнення стека з 2010 року, яка обговорює можливість використання макросів для реалізації просторів імен; інший приклад макро підходу можна знайти тут . Існує хоча б пара реалізацій ( тут і тут , з описом останніх тут) там, але вони не спостерігали особливої ​​активності протягом двох років, і я не натрапляв на жодні бібліотеки, які ними користуються.

Я припускаю, що якби додати простори імен було легко, це вже було б зроблено. Тому:

• Які технічні бар'єри для додавання просторів імен до elisp?
• Чи додавання просторів імен порушить багато існуючого коду?
• Це функціональність, яка повинна бути органічною для elisp (зміни самого інтерпретатора), чи вона справді може бути побудована зверху за допомогою макросів?

Чому немає просторів імен?

Тому що це складно, і ніхто ще не вважав це достатньо терміновим, щоб зробити повну занурення. Про це йшлося в списку розробників раніше (більше разів, ніж один), і були обіцянки виправити це після переходу на git.

Тим часом я написав власне рішення (перелік варіантів див. Нижче).

Які технічні бар'єри?

Тільки біля дверей у вас є три великі перешкоди, які вам потрібно перевершити, щоб простори імен навіть мали шанс працювати над поточним Emacs:

• Потрібно змінити, як символи інтерновані (це найлегша частина).
• Байтовий компілятор повинен розуміти простори імен.
• Генерація автозавантаження використовується package.elдля розуміння просторів імен.

Виправлення цих 3 речей, з якими можна працювати, однак ви прийшли до впровадження просторів імен, не є тривіальним. Якщо ви присвячені лише останній версії Emacs, це, безумовно, можливо. Якщо ви хочете написати якийсь пакет, який також підтримує попередні версії (як, наприклад, ціла 24 сімейство), це перетворюється на пекельний виклик.

Крім цього, існує безліч інших необов'язкових перешкод. Elisp чудовий тому, що вся сила в доступних для вас інструментах, і ВСЕ з них потрібно буде виправити, щоб працювати з просторами імен. Серед найважливіших:

• edebug
• евал-дефун
• eval-last-sexp
• слиз

Чи зламає це чимало існуючого коду?

Не, якщо ви зробите це правильно.

Це щось, що має бути органічним, чи це справді може бути побудовано зверху за допомогою макросів?

В ідеалі це було б органічно, саме це зазвичай обговорюється, коли воно з’являється у списку розробників. Але це можна зробити досить хорошим, будуючи на вершині.
Ось кілька прикладів цього, взятих із цього списку :

• Імена
• з простором імен
• Кодекс
• Fakespace
• elisp-простори імен

Востаннє це обговорювалося на emacs-devel, дискусія припинялася, коли люди, як Ларс, вказували, що їм подобається мати можливість M-x grepчогось. Додавання просторів імен до Elisp не повинно бути надто важким, але отримати всі звичні інструменти для їх правильного використання - ще одна проблема.