Quel langage de programmation pratique et non théorique n'a pas de mots-clés réservés?

22

Je cherchais un langage de programmation pratique qui n'a pas de mots clés réservés mais je n'ai pas eu de chance d'en trouver un.

Je travaille sur un langage de programmation pour ma propre édification et divertissement et je n'ai pas encore eu besoin d'inclure de mots-clés, c'est ce qui m'a conduit à ma recherche et à la question:

Je ne pense pas que la commodité de l'auteur du compilateur soit importante pour l'utilisateur final de la langue. Les ordinateurs sont suffisamment puissants de nos jours pour pouvoir déduire des significations à partir du contexte. Pas plus qu'un écrivain n'a besoin d'étiqueter des noms, des verbes et autres lors de l'écriture d'un roman, pourquoi un programmeur devrait-il étiqueter des fonctions et des variables avec function x() {}ou set x = 1ou var x = 1etc; quand je peux déduire du contexte des instructions qu'il s'agit d'une déclaration de fonction ou d'une invocation ou qu'une étiquette est une affectation à une valeur ou une référence à cette valeur d'étiquettes?

Voici un exemple concret de ce que fait mon analyseur actuel, pas besoin de mots-clés réservés pour supporter des choses courantes qui auraient normalement un tas de bruit comme funcou functionou decou quoi.

Déclaration de fonction

sum3(a,b,c) -> a + b + c.

Invocation de fonction

x = sum3(1,2,3).

Fonction anonyme nommée x

x = (a,b,c) -> a + b + c.
y = x(1,2,3).

J'aimerais savoir pourquoi les mots clés sont si importants pour un langage de programmation réussi?

theory languages

8

Forth est assez pratique et n'a pas de mots clés.

— SK-logic

4

@JamesAnderson, non, ce ne sont que des mots, comme tous les autres mots. Aucune signification particulière.

— SK-logic

7

Les opérateurs et la ponctuation comptent-ils comme "mot-clé"? si oui, alors aucun langage ne peut exister, car aucune syntaxe ne peut être définie.

— Emilio Garavaglia

2

@ SK-logic: généralement. Mais que sont les "identifiants" si vous ne souhaitez pas encore symboliser? Puisqu'un jeton est "quelle que soit la piqûre reconnaissable", "int", "mavaleur" et "+" ne sont pas différents, avant qu'une règle de syntaxe n'ait été donnée. Si "+" n'est pas défini comme opérateur, il peut s'agir simplement d'un nom pour quelque chose comme n'importe quelle autre chaîne de caractères unicode. Les opérateurs, par un point de vue purement syntaxique, ne sont rien de plus que des "mots clés à caractère unique".

— Emilio Garavaglia

2

Dans ce contexte, qu'est-ce qu'un mot-clé? Est-ce un identifiant qui a une signification particulière pour le compilateur? Est-ce un identifiant que le programmeur ne devrait pas utiliser comme variable ou quelque chose? Est-il considéré comme sans mot-clé si les mots-clés doivent être spécialement désignés? (Il y a longtemps, j'ai vu un système ALGOL où les mots-clés devaient être cités pour être des mots-clés.)

— David Thornley

12

MUMPS a beaucoup de succès, est largement utilisé dans les assurances et les soins de santé et n'a pas de mots réservés. Je dirais qu'ils aident à écrire un code plus clair, mais ils ne sont pas strictement nécessaires. APL est un autre exemple. APL voit l'utilisation de scripts uniques dans l'industrie nucléaire, entre autres. J , membre de la famille APL manque également de mots clés.

Les mots clés aident les rédacteurs du compilateur à implémenter l'analyse plus facilement. APL est réputé associatif de droite. Ils aident également à renforcer les conventions et à améliorer la lisibilité. APL n'est pas connu pour être extrêmement lisible par la plupart.

— Ingénieur du monde
source

2

+1 pour "Les mots clés aident les rédacteurs du compilateur à implémenter l'analyse plus facilement". Je pense que c'est à peu près tout. Les mots clés ont été inventés pour réduire la quantité de contexte qu'un analyseur doit garder en mémoire, à l'époque où le compilateur entier et son ensemble de travail devaient tenir dans une douzaine de Ko de RAM.

— Jörg W Mittag

2

Il est plus facile d'écrire un analyseur pour APL que presque n'importe quelle autre langue! Considérez que la première implémentation d'un interpréteur APL a été réalisée à l'aide de transistors et de diodes.

— James Anderson

2

Je pense que la principale raison des mots-clés est de faciliter l'analyse de la langue par les humains. Les ordinateurs seraient plus heureux si le langage était entièrement composé de chiffres et de modèles de bits, tout comme leur code machine.

— James Anderson

6

Ce qui manque à APL dans les mots-clés, c'est plus que compenser en exigeant sa propre police.

— Blrfl

@Blrfl C'est le point de J, K et Q. Ils sont tous à un degré ou un autre, APL en ASCII.

— World Engineer

9

Un langage bien connu sans mots-clés est Lisp. Ce qui se rapproche le plus des mots-clés est ce qu'on appelle des formulaires spéciaux - leur nombre peut varier selon les dialectes - qui reçoivent un traitement spécial de l'interprète. En dehors de cela, ils ne se distinguent pas des fonctions normales en termes de la façon dont ils sont utilisés, à l'exception qu'ils ne peuvent pas être redéfinis (au moins en Lisps que je connais).

Cela se traduit par une syntaxe simple (mais lourde de paren), et est l'une des choses qui a permis à Lisp d'avoir un système de macro si puissant. D'un autre côté, Lisp est souvent considéré comme difficile à lire. APL et MUMPS, encore plus, j'ai vu les deux décrits comme à mi-chemin de Brainf * ck. Les mots-clés aident dans ce département et facilitent également la lecture du code pour nous les humains.

Je ne dirais donc pas que les mots clés sont nécessaires pour une langue réussie, mais ils aident certainement une langue à réussir.

— scrwtp
source

1

IIRC Lisp n'a AUCUN mot-clé. Les formulaires spéciaux doivent être traités spécialement par le compilateur, mais leurs noms sont des symboles réguliers.

— Jan Hudec

2

Les mots clés sont une caractéristique de la syntaxe, que Lisp n'a pas non plus. Je ne pense pas que cela ait vraiment de sens de parler de mots clés en Lisp, vraiment.

— Jörg W Mittag

2

Je suis d'accord avec Jörg. Je pense que l'on peut parler de mots-clés quand une langue a des jetons qui doivent être définis explicitement comme spéciaux pour être distingués des jetons avec une structure similaire. Différents jetons conduisent à différents arbres de syntaxe. Par exemple, ifen C serait un identifiant valide s'il n'était pas défini comme spécial (un mot-clé). Cela signifie que ce ifn'est pas un identifiant et if = 10donne une erreur de syntaxe. Si je ne me trompe pas, la syntaxe minimale de Lisp ne distingue pas defunde f, x, yet +dans (defun f (x y) (+ x y)).

— Giorgio

@Giorgio if est notamment un nom de variable valide dans Common Lisp (et d'autres Lisp-2) (defparameter if nil)ne cassera rien et il peut être utilisé sous des formes telles que(unless if (setf if t))

— tobyodavies

Sur la même note, cependant, (defun if ...)échouera. Prise en compte des commentaires et modification de la réponse. Je peux convenir que les formulaires spéciaux ne sont pas des mots-clés au même niveau qu'en C par exemple, ils sont toujours la chose la plus proche de Lisp.

— scrwtp

8

TCL n'a pas de mots clés, et en fait seulement 12 règles de syntaxe. bien que ce ne soit pas aussi populaire qu'autrefois, il a sa niche avec attente et intégré dans ECAD et les routeurs, donc cela compte certainement comme pratique à mon avis.

Je pense aussi que cela peut montrer pourquoi beaucoup de langues ne suivent pas cette voie. Oui, il est parfaitement possible d'écrire un analyseur TCL (sans doute plus facile que de nombreuses autres langues), mais vous ne pouvez pas écrire une grammaire BNF très utile pour la langue et beaucoup de gens semblent avoir du mal à apprendre la langue. Je soupçonne que c'est au moins en partie à cause du manque de mots clés.

— jk.
source

2

Tcl est très similaire à Lisp à cet égard, sauf qu'au lieu de "tout est une liste", il a "tout est une chaîne". Une liste est simplement une chaîne contenant des espaces et un appel de procédure n'est qu'une liste dont le premier élément est interprété comme le nom d'une procédure et le reste est interprété comme ses arguments. C'est essentiellement une expression S Lisp.

— Jörg W Mittag

oui, ils utilisent tous les deux une notation polonaise et sont homo-iconiques donc ont une sémantique assez similaire

— jk.

5

Les ordinateurs sont suffisamment puissants de nos jours pour pouvoir déduire des significations à partir du contexte.

Est-ce à dire que vous voulez une grammaire qui n'est pas sans contexte? Bonne chance.

Il ne s'agit pas d'être puissant ou non. Il y a des règles éternelles et immuables sur les langues - mathématiques. Ceci, et le fait qu'un langage de programmation doit être syntaxiquement facile fera que les CFG règneront pour quelques décennies à venir.

Btw., Dans Haskell comme la syntaxe, vous écrivez juste quelque chose comme

f x y = (x+1)*(y-1)

pour définir une fonction. Mais notez que le "mot-clé" dans ce cas est le '='. Si vous le manquez, des choses terribles se produiront dans l'analyseur.

Mais c'est un point où je suis d'accord avec vous, je trouve cela beaucoup plus intuitif que tous les mots-clés def, dcl, fun, fn, function ou autre qui introduisent des fonctions dans d'autres langues.

Pourtant, cette grammaire peut être écrite en clair et ancien LALR (1), aucune signification n'est "déduite du contexte" ici.

— Ingo
source

1

+1 pour répondre à cette affirmation (les ordinateurs sont suffisamment puissants de nos jours pour pouvoir déduire des significations à partir du contexte). Je pense que la raison pour laquelle les grammaires de CFG sont préférées est qu'elles permettent de définir la structure du programme de manière inductive. Je ne vois pas pourquoi on voudrait changer cela même dans 100 ans, peut-être que je manque juste d'imagination?

— Giorgio

2

Les CFG sont assez morts et étaient morts depuis des décennies. JavaScript dans HTML, même des chaînes de format C dans C, même des commentaires imbriqués dans, disons, OCaml - tout cela n'est pas sans contexte. Et, pourquoi voudriez-vous vous limiter à un tel formalisme arbitraire choisi, maintenant, à l'ère du PEG et du GLR?

— SK-logic

1

@Ingo, oui, vous avez raison, un mauvais choix d'exemple. Je voulais dire des grammaires mixtes et extensibles (c'est-à-dire d'ordre élevé), qui ne sont pas CFG.

— SK-logic

2

@ SK-logic: Je ne sais pas d'où vous tenez l'information que les CFG sont plutôt morts. J'ai parlé à un ancien collègue à moi qui enseigne la construction de compilateurs depuis 20 ans et les CFG semblent être loin d'être morts.

— Giorgio

1

@Ingo: Autant que je me souvienne, les aspects non CF sont traités par la suite en analysant sémantiquement l'arbre d'analyse. Par exemple, { int x = 0; x = "HELLO"; }devrait produire un arbre d'analyse mais lorsque le compilateur recherche x dans la deuxième affectation, il voit qu'il a été déclaré en tant qu'int et émet une erreur de type. Le programme est donc rejeté même si sa structure CF est correcte.

— Giorgio

4

Pour autant que je sache, Smalltalk est la langue qui a le moins de mots-clés (si je ne compte pas les langues comme Brainfuck). Mots - clés sont Smalltalk true, false, nil, self, superet thisContext.

J'ai conçu un langage, inspiré de smalltalk, qui n'avait pas de mots-clés. Mais après un certain temps d'utilisation, j'ai fini par ajouter quelques mots clés, principalement pour le sucre syntaxique.

Donc, mon avis est que la langue sans mots-clés est possible, mais ce n'est pas très pratique et c'est la raison pour laquelle toutes les langues populaires ont des mots-clés.

— del-boy
source

Si Smalltalk avait le support pour les envois de messages avec un récepteur implicite, alors au moins true, falseet nilpourrait être défini comme des méthodes sur ce récepteur implicite, et, compte tenu des capacités de réflexion, les trois autres probablement aussi.

— Jörg W Mittag

1

Ce ne sont pas des mots clés, ce sont des pseudovariables. "Pseudo" car true, falseet nilsont des valeurs bien connues fournies par l'environnement et self, superet thisContextsont des variables que vous ne pouvez pas définir mais dont les valeurs changent à la suite de l'exécution.

— Frank Shearar

3

Vous semblez travailler sous une fausse hypothèse, que les mots clés sont là pour faciliter les choses pour le compilateur. Bien qu'ils facilitent les choses pour le compilateur, ils ont un avantage beaucoup plus important: ils facilitent les choses pour la personne qui lit le code .

Oui, vous pouvez regarder un tas de contexte et comprendre que vous regardez une déclaration de fonction ou une déclaration de variable, mais selon le contexte et la complexité du code impliqué, cela pourrait prendre beaucoup de temps à comprendre . Ou, vous pourriez avoir un mot-clé pratique comme fonction ou var , et vous savez immédiatement ce que vous regardez.

Oui, ils compliquent le code écrire , mais étant donné que les programmes passent beaucoup plus de temps à la maintenance qu'à la production, et que leur code est lu, débogué et maintenu beaucoup plus qu'il n'a été créé, en essayant de concevoir votre langage pour rendre facile à écrire au lieu de facile à lire est un cas classique d'optimisation prématurée nuisible.

Aussi, ne dédaignez pas les concepts qui facilitent le travail du compilateur. Plus il est facile d'analyser, plus votre code sera compilé rapidement, ce qui signifie que les cycles d'édition-construction-débogage s'accélèrent, ce qui signifie que votre productivité augmente.

Lorsque vous avez une base de code volumineuse et complexe, cela peut représenter une différence non négligeable de productivité. Par exemple, là où je travaille, nous avons un programme à l'œuvre qui représente environ 4 millions de lignes de Delphi. Nous avons un autre module d'environ 300 000 lignes de C ++. Ils prennent tous deux à peu près la même durée de compilation. (Environ 3 minutes.) Si nous avions 4 millions de lignes de C ++, la construction pourrait prendre une heure!

— Mason Wheeler
source

Tous d'excellents points. +1

si chaque nom, verbe, adverbe et adjectif dans un roman était étiqueté comme tel, cela rendrait la lecture plus difficile!

@JarrodRoberson: Bien sûr, mais le code n'est pas un roman. Les langages naturels sont très différents des langages de programmation. Le langage naturel est compris intuitivement, tandis qu'un langage de programmation a une sémantique formelle. Les techniques utilisées pour le lire et en comprendre le sens sont très différentes, et c'est une erreur d'essayer de les assimiler comme vous le faites.

— Mason Wheeler

J'ai dit le compilateur qui est différent du compilateur . Les compilateurs deviennent plus rapides sur un matériel plus rapide, les rédacteurs de compilateurs sont humains, nous n'adhérons pas à la loi de Moore!

les bases de code avec lesquelles j'ai tendance à travailler sont des ordres de grandeur plus longs que les romans, la plupart sont> 1 000 000+ lignes de code, la plupart des romans les plus longs sont <2 000 000 de mots ! Et comme les romans, ils sont lus par les humains, en fait plus de temps est passé à lire le code qu'à l'écrire! Étant donné une base de code de plus de 10 ans et plus de 1 000 000 de lignes, le nombre de fois qu'il est lu par les développeurs sur 10 ans éclipse le temps qu'il a fallu pour créer en premier lieu.!

2

Il existe de rares exemples.

APL n'utilise que des symboles - mais beaucoup d'entre eux! Vous avez besoin d'un clavier spécial pour utiliser la langue.

Voir cet article wikipedia

CORAL 66 - avait des mots clés mais ne les reconnaissait que s'ils étaient cités avec des guillemets simples.

PL / 1 avait également des mots clés - mais vous pouvez également les utiliser comme noms de variables ou de procédures.

Dans l'ensemble, votre question revient un peu à demander "pourquoi les langues parlées ont-elles des mots?".

— James Anderson
source

Juste pour ajouter que si vous aimez le look d'APL mais que vous ne voulez pas acheter un nouveau clavier, alors J est juste la chose.

— AakashM

0

La raison principale est qu'il est plus facile pour les humains et les ordinateurs d'analyser. Désambiguïser un langage complexe sans mots-clés nécessiterait de nombreux symboles comme syntaxe, et cela serait source de confusion massive et inutile. C'est beaucoup plus facile à lire functionque $!{}. Et le contexte ne résout pas toutes les ambiguïtés.

— DeadMG
source

1

Je pense que le mot clé dans votre réponse est complexe , un langage suffisamment conçu doit être simple , pas complexe .

1

@Jarrod Roberson: Leonardo da Vinci: "La simplicité est l'ultime sophistication", Antoine de Saint Exupéry: "Il semble que la perfection n'est pas atteinte quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à emporter".

— Giorgio

1

@Jarrod: Tous les langages informatiques réellement expressifs sont complexes.

— DeadMG

1

@DeadMG: Le schéma est très simple et en même temps très expressif. Malheureusement, pour autant que je sache, il manque une bibliothèque standardisée.

— Giorgio

Erlang est très expressif et pas complexe syntaxiquement. Je pense que tous les langages fonctionnels finissent par être plus expressifs avec des mots-clés moins réservés.