Является ли "Лисп-1 против Лисп-2" актуальным в языке со статическими типами?

Question

(Это вопрос типа теории CS; я надеюсь, что это приемлемо.)

Дискуссия " Lisp-1 против Lisp-2" касается того, должно ли пространство имен функций отличаться от пространства имен всех других переменных, и это актуально в динамически типизированных языках, которые позволяют программисту передавать функции как значения. Языки Lisp-1 (такие как Scheme) имеют одно пространство имен, поэтому нельзя использовать обе функции с именем f а также целое число с именем f (одно будет затенять другое, как два целых по имени f). Языки Lisp-2 (такие как Common Lisp) имеют два пространства имен, так что вы можете иметь оба f переменные, но вы должны указать, какой из них вы имеете в виду со специальным синтаксисом (#'f это функция и f является целым числом).

Мне кажется, что основная техническая проблема, необходимость устранения неоднозначности функции от целого числа, не является проблемой, если язык также статически типизирован (в отличие от большинства Lisps). Например, если sort функция требует список и функцию меньше, чем явная подпись,

def sort[X](list: List[X], lessThan: Function[X, Boolean])    // Scala syntax; had to pick something

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

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

(Я думаю об этом в контексте конкретного предметного языка, над которым я работаю, и я хочу убедиться, что у меня не возникнет проблем в будущем. Это было бы проще реализовать с двумя пространствами имен (Lisp-2), и поскольку он статически типизирован, нет необходимости в эквиваленте #'f, Я задал вопрос в целом, потому что я хочу услышать общие моменты и, возможно, узнать о вопросах, которые я еще не знаю, задавать.)

Answer 1

Одно очень распространенное возражение против нескольких пространств имен состоит в том, что это усложняет формальную семантику, чтобы иметь произвольное количество пространств имен. Одно пространство имен делает вещи простыми. Следующее самое простое, так что мне сказали (я не пишу эти вещи), это бесконечное количество пространств имен - то, что я пытался сделать один раз и только на полпути ( смотрите здесь, если любопытно, хотя я думаю, что это не то, что Вы просите в этом случае). Когда вы ограничиваете его конечным числом пространств имен, формальная семантика становится грязной, или мне так сказали. И, конечно, это делает любой компилятор или интерпретатор немного более сложным. Это возражение колеблется между эстетическим и техническим в том смысле, что это не возражение, основанное на технических сложностях как таковых, поскольку не требуется сверхчеловеческий интеллект для выполнения нескольких пространств имен, просто много дополнительного ручного труда, а скорее возражение, которое делает более сложным семантика означает больше кода, больше особых случаев, больше шансов на ошибку и т. д. Лично я не склоняюсь к таким аргументам, я просто указываю на них, поскольку вы спрашиваете. Я думаю, что вы найдете, что такие аргументы не являются фатальными, и что можно продолжить, что вы делаете, и посмотреть, к чему это приведет. Меня больше волнует опыт программиста / конечного пользователя, чем трудности разработчика. Но я упоминаю этот аргумент, потому что другие люди, которых я уважаю, кажется, думают, что это большое дело, и я считаю, что это правильный ответ на ваш вопрос о трудностях и подверженности ошибкам.

Заметьте, кстати, что когда мы с Габриэлем писали " Технические вопросы разделения в функциональных ячейках и ячейках значений", мне нужны были слова, которые помогли бы мне избежать высказывания "Подобный Схеме" и "Подобный Лиспу", потому что у людей были несвязанные причины для предпочтения Схемы. это не имеет ничего общего с пространством имен. Использование терминов "Lisp1" и "Lisp2" позволило мне не превращать статью в дискуссию "Схема против Lisp" и сосредоточить внимание читателей на вопросе пространства имен. В конце концов, ANSI Common Lisp получил как минимум 4 пространства имен (функции, значения, теги go, блочные теги) или, может быть, 5, если вы считаете типы (которые в некотором смысле похожи на пространство имен, но не в других), но в ни в коем случае не 2. Так что строго это будет Lisp4 или Lisp5. Но в любом случае это все еще ужасает тех, кто предпочитает одно пространство имен, потому что любое произвольное конечное число больше единицы, как правило, для них неприемлемо.

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

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

Настаивайте на том, чтобы думать о вещах, как вы хотите. Worry more about making your language have a good feel and about whether what you want to do is implementable at all, even if it does require work and extra checking of the code. No language design decision is the right one for every language--languages are ecologies and what matters is that language elements work well with one another, not that language elements match other languages. Indeed, if languages were going to be all the same, it would be pointless to have multiple languages.