Зачем использовать стек-ориентированный язык?
Недавно я взглянул на Factor, и идея иметь язык, основанный на концепции стека, очень интересна. (Это было мое первое знакомство со стек-ориентированным языком.) Однако я не вижу практических преимуществ такой парадигмы. Мне кажется, это больше проблем, чем стоит. Зачем мне использовать стек-ориентированный язык, такой как Factor или Forth?
Я игнорирую факторы (извините за каламбур), такие как доступность инструментов и библиотек. Я спрашиваю только о самой языковой парадигме.
5 ответов
Ориентация стека - это деталь реализации. Например, Joy может быть реализован с помощью переписывания - без стека. Вот почему некоторые предпочитают говорить "конкатенационный" или "композиционный". С цитатами и комбинаторами вы можете кодировать, не задумываясь о стеке.
Выражение себя с чистой композицией и без местных жителей или именованных аргументов является ключом. Это очень кратко без синтаксических накладных расходов. Композиция позволяет очень легко выделить избыточность и "алгебраически" манипулировать вашим кодом; сводя его к сути.
Как только вы влюбитесь в этот стиль без точек, вы будете раздражены даже малейшим синтаксисом композиции в других языках (даже если это просто точка). В сцепленных языках пробел является оператором композиции.
Я не уверен, что это вполне ответит на ваш вопрос, но вы обнаружите, что фактор в первую очередь описывает себя как конкатенационный язык. Также бывает, что у нас есть модель исполнения на основе стека. К сожалению, я не могу найти в блоге Славы сообщение (или, может быть, на вики-факторе?), Где говорится об этом.
Конкатенационная модель в основном означает, что вы пропускаете "куски кода" (ну, в любом случае, так вы программируете), а композиция выглядит как конкатенация. Такие операции, как каррирование, также легко выразить на языке, основанном на стеке, поскольку вы просто предварительно скомпоновали код, который добавляет в стек одну вещь. В Факторе, по крайней мере, это выражается словом curry, Это значительно облегчает программирование более высокого порядка, и отображение последовательностей в конечном итоге становится "очевидным способом сделать это". Я приехал из Лиспа и был поражен, когда вернулся на программирование в Factor на некоторое время, что вы не могли делать "очевидные вещи", такие как bi в Лисп. Это действительно меняет то, как вы выражаете вещи.
Между прочим, не стоит слишком зацикливаться на манипуляциях со стеком. С использованием locals словарный запас (описанный здесь: http://docs.factorcode.org/content/article-locals.html), вам не нужно беспокоиться о том, чтобы что-то перемешивать. Часто есть хороший способ выразить вещи без локальных переменных, но я склонен делать это вторым.
Одна из важных причин, по которой разрабатываются основанные на стеке языки, заключается в том, что минимализм их семантики допускает простую реализацию интерпретатора и компилятора, а также оптимизацию.
Итак, одно из практических преимуществ такой парадигмы состоит в том, что она позволяет энтузиастам легко создавать более сложные вещи и парадигмы поверх них.
Язык программирования Scheme является еще одним примером этого: минималистский синтаксис и семантика, простая реализация и много веселья!
У нас уже есть хорошие ответы, и я ничего не знаю о языке Фактор.
Тем не менее, я думаю, что стоит прокомментировать для полноты:
- CPU Time - временная стоимость выделения памяти в стеке практически свободна: не имеет значения, выделяете ли вы одну или тысячу целых чисел, все, что требуется, - это уменьшение указателя стека. пример
- Утечка памяти - нет утечек памяти при использовании только стека. Это происходит естественным образом без дополнительных накладных расходов на код. Память, используемая функцией, полностью освобождается при возврате из каждой функции даже при обработке исключений или использовании longjmp (без учета ссылок, сбора мусора и т. Д.).
- Фрагментация - стеки также позволяют избежать фрагментации памяти естественным образом. Вы можете достичь нулевой фрагментации без какого-либо дополнительного кода, чтобы иметь дело с этим, как пул объектов или выделение памяти в слэбах
- Локальность - данные в стеке способствуют локальности данных, используя преимущества кэша и избегая перестановок страниц.
Конечно, это может быть более сложным для реализации, в зависимости от вашей проблемы, но мы всегда будем отдавать предпочтение стеку, а не куче.
Некоторым людям проще думать с точки зрения управления стеками, чем с другими парадигмами. По крайней мере, взлом на языке, основанном на стеке, улучшит вашу способность управлять стеками в целом.
Кроме того: в первые дни портативных калькуляторов они использовали так называемую нотацию "Обратный польский", которая представляет собой очень простую постфиксную нотацию на основе стека и чрезвычайно эффективно использует память. Люди, которые учатся использовать его эффективно, склонны предпочитать его алгебраическим вычислениям.