Pourquoi utiliser un langage orienté pile ?

Question

J'ai récemment jeté un coup d'oeil à Facteur L'idée d'avoir un langage basé sur le concept de pile est très intéressante. (C'était ma première rencontre avec un langage orienté pile.) Cependant, je ne vois pas les avantages pratiques d'un tel paradigme. Pour moi, cela me semble être plus de problèmes que cela n'en vaut la peine. Pourquoi utiliserais-je un langage orienté pile comme Factor ou Forth ?

---

Je ne tiens pas compte de facteurs (excusez le jeu de mots) tels que la disponibilité des outils et des bibliothèques. Je m'interroge uniquement sur le paradigme du langage lui-même.

Answer 1

L'orientation de la pile est un détail d'implémentation. Par exemple, Joy peut être implémenté en utilisant la réécriture - pas de pile. C'est pourquoi certains préfèrent dire "concaténatif" ou "compositionnel". Avec les citations et les combinateurs, vous pouvez coder sans penser à la pile.

S'exprimer avec une composition pure et sans locaux ou arguments nommés est la clé. C'est extrêmement succinct et sans surcharge syntaxique. La composition permet d'éliminer très facilement la redondance et de manipuler "algébriquement" votre code, en le réduisant à son essence.

Une fois que vous serez tombé amoureux de ce style sans point, vous serez agacé par la moindre composition syntaxique dans d'autres langues (même s'il ne s'agit que d'un point). Dans les langages concaténatifs, l'espace blanc est l'opérateur de composition.

Answer 2

Je ne suis pas sûr que cela réponde tout à fait à votre question, mais vous trouverez que Factor se décrit lui-même comme un concaténatif la langue avant tout. Il se trouve qu'il possède également un modèle d'exécution basé sur la pile. Malheureusement, je n'arrive pas à trouver l'article du blog de Slava( ? ou peut-être sur le Wiki de Factor ?) qui parle de cela.

Le modèle concaténatif signifie essentiellement que vous faites circuler des "morceaux de code" (c'est ainsi que vous programmez de toute façon) et que la composition ressemble à la concaténation. Des opérations comme le currying sont également faciles à exprimer dans un langage basé sur la pile, puisqu'il suffit de pré-composer avec du code qui ajoute une chose à la pile. Dans Factor, au moins, ceci est exprimé par un mot appelé curry . Cela rend beaucoup plus facile la programmation d'ordre supérieur, et le mappage de séquences finit par devenir la "façon évidente de faire". Je venais de Lisp et j'ai été étonné, en revenant après avoir programmé un peu en Factor, de ne pas pouvoir faire des "choses évidentes" comme bi en Lisp. Cela change vraiment la façon dont vous exprimez les choses.

Par ailleurs, il est sage de ne pas trop s'attacher à la manipulation des piles. En utilisant le locals vocabulaire (décrit ici : http://docs.factorcode.org/content/article-locals.html ), vous n'avez pas à vous soucier de remuer les choses. Il existe souvent une façon élégante d'exprimer les choses sans variables locales, mais j'ai tendance à le faire en second.

Answer 3

L'une des raisons importantes pour lesquelles les langages basés sur les piles sont développés est que le minimalisme de leur sémantique permet une mise en œuvre simple de l'interpréteur et du compilateur, ainsi que l'optimisation.

Ainsi, l'un des avantages pratiques d'un tel paradigme est qu'il permet aux enthousiastes de construire facilement des choses et des paradigmes plus complexes par-dessus.

Le langage de programmation Scheme en est un autre exemple : syntaxe et sémantique minimalistes, mise en œuvre simple et beaucoup de plaisir !

Answer 4

[Nous avons déjà de bonnes réponses et je ne connais rien au langage Factor. Cependant, le fait de favoriser l'utilisation de la pile est un avantage pratique d'un paradigme orienté pile et une raison d'adopter un tel paradigme, comme demandé.

Je pense donc qu'il est utile d'énumérer les avantages de l'utilisation de la pile au lieu de l'allocation du tas pour être complet :

• Temps CPU -- Le coût temporel de l'allocation de mémoire dans la pile est pratiquement gratuit : peu importe que vous allouiez un ou mille entiers, il suffit d'une opération de décrémentation du pointeur de pile. exemple
• Fuite de mémoire -- Il n'y a pas de fuites de mémoire lorsque l'on utilise uniquement la pile. Cela se produit naturellement sans surcharge de code supplémentaire pour y faire face. La mémoire utilisée par une fonction est complètement libérée lors du retour de chaque fonction, même en cas de gestion d'exception ou d'utilisation de longjmp (pas de comptage de référencement, de garbage collection, etc).
• Fragmentation -- Les piles évitent aussi naturellement la fragmentation de la mémoire. Vous pouvez obtenir une fragmentation nulle sans aucun code supplémentaire pour y faire face, comme un pool d'objets ou une allocation de mémoire en bloc.
• Localité -- Les données dans la pile favorisent la localité des données, en tirant parti du cache et en évitant les échanges de pages.

Bien sûr, cela peut être plus compliqué à mettre en œuvre, en fonction de votre problème, mais nous favoriserons la pile plutôt que le tas chaque fois que nous le pourrons dans n'importe quel langage. Laissez malloc/new être utilisés uniquement lorsque cela est réellement nécessaire (exigences de taille ou de durée de vie).

Answer 5

Pour certaines personnes, il est plus facile de penser en termes de gestion de piles que d'autres paradigmes. Au minimum, faire un peu de hacking dans un langage basé sur les piles améliorera votre capacité à gérer les piles en général.

D'ailleurs, au début des calculatrices portables, on utilisait quelque chose appelé Notation polonaise inversée Il s'agit d'une notation postfixe très simple basée sur la pile, qui est extrêmement économe en mémoire. Les personnes qui apprennent à l'utiliser efficacement ont tendance à la préférer au calcul algébrique.