I Imagine Scheme (et peut-être que LISP) pourrait être rendu plus «convivial» en utilisant une syntaxe différente. Par exemple, au lieu de s-expressions imbriquées avec des parenthèses laides, on pourrait concevoir une sorte de syntaxe plus proche de certaines des langues les plus largement utilisées (par exemple, de type Java sans avoir à définir des classes).
Ce n'est pas nécessairement une mauvaise chose si c'est plus verbeux. Par exemple, la syntaxe peut nécessiter des séparateurs de ligne et des virgules dans les endroits où de nombreuses personnes l'attendent et attendent des déclarations de retour explicites. En outre, il ne semble pas que ce soit difficile de permettre à certains opérateurs d'utiliser un style d'infixe (obéir aux règles de préférence de l'opérateur généralement acceptées).
Et si cela ne rend pas les choses trop sales, la syntaxe pouvait même être compatible à l'envers, de sorte que, dans n'importe quel endroit où une expression est attendue, une expression s normale entre parenthèses peut être utilisée.
Quelles sont vos opinions et idées à ce sujet? Et quelque chose comme ça existe? (Je m'attends à ce que ce soit, mais "schéma" est un terme Google sans valeur, je ne trouve rien!)
6 Réponses :
Essayez SRFI 49 pour la taille. :-P
(Sérieusement, comme Rafe commença, "Je pense que personne ne veut ça".)
Certaines personnes considèrent que Python est une sorte de schéma avec une notation d'infixe pour les opérateurs, la notation algébrique pour les fonctions et qui utilise une syntaxe plus «de type Java» pour la représentation de la langue. Je ne suis pas d'accord avec cette évaluation, mais je peux voir où vient l'idée.
Le gros problème avec la modification de la notation pour le schéma est que les macros deviennent très difficiles à écrire (pour voir à quel point la langue nimroprod ou BOO). Au lieu de travailler directement avec le code comme des listes, vous devez d'abord analyser la langue d'entrée. Cela implique généralement la construction d'une AST (arborescence de syntaxe abstraite) pour la langue de l'entrée. Lorsque vous travaillez directement avec le schéma, cela est inutile.
Cependant, vous pouvez consulter la syntaxe de six expressions dans le schéma de GAMBIT. Il y a un bel ensemble de diapositives ici qui contient une discussion sur ceci:
http://www.iro.umontreal.ca/~ gambit / gambit-infid-out.pdf
Mais ne lui en dire à personne! (La blague à l'intérieur est que quelqu'un suggère d'écrire un LISP sans parenthèses et d'une notation d'infixe à propos d'une fois par jour, et une personne annonce une mise en œuvre d'une fois par mois.)
Les gens considèrent que Python est une sorte de système dans le sens d'être une petite langue avec des fonctions de première classe et un espace de noms unique («LISP-1») - mais sans macros.
Je pense que "expressions douces" pourrait être l'une des approches les plus réfléchies de se débarrasser des parenthèses de Lisp. Il soutient apparemment des macros.
À l'origine, LISP était prévu d'utiliser une syntaxe appelée M-expressions, avec S-Expressions étant seulement une solution transitoire pour faciliter le bâtiment du compilateur. Lorsque les M-expressions étaient prêtes à être introduites, les programmeurs qui avaient déjà pris le LISP vient de rester avec ce qu'ils étaient devenus habitués et des expressions M ne jamais surgiées.
Il y a une notation infixe en Guile, mais elle est rarement utilisée. Un bon programmeur LISP ne voit même plus la parens, et la notation de préfixe a ses mérites ...
Totalement d'accord sur ne pas voir les parens. La clé utilise un éditeur avec un mode LISP. Alors ce que vous voyez est l'indentation. Qui est la fin à laquelle les parens sont juste les moyens. Raquette (anciennement PLT Schéma) a également un peu d'infixe: (a. F. B) ==> (F A b). Vous verrez cela parfois utilisé pour les contrats: (dans. ->. Out) au lieu de (-> sort). Mais pas toujours. Et pas pour beaucoup d'autre. Parce que le préfixe a ses mérites.
Visitez "Sweet-Expressions", qui fournit un ensemble d'abréviations supplémentaires pour les expressions s traditionnelles. Ils ajoutent une indentation syntaxiquement pertinente, un moyen de faire des infixes et des appels de fonction traditionnels tels que f (x). Contrairement à presque tous les efforts passés pour rendre Lisps lisible, les expressions douces sont compatibles à l'envers (vous pouvez mélanger librement des expressions S bien formatées et des expressions douces), génériques et homoiiconiques.
Les expressions douces ont été développées sur http://readable.sourceforge.net et il existe un exemple de mise en œuvre.
Pour le schéma Il y a un SRFI pour Sweet-Expressions: http://srfi.schemers.org/srfi-110/ < / a>
Outre les expressions douces elles-mêmes, SRFI.SCHEMERS.ORG/SRFI-110/ SRFI-110.HTML # Comparaisons Enquête beaucoup d'efforts alternatifs.
Pro TIP: Google pour
Langue du schéma :)Non, je ne pense pas que personne ne le veuille.
Je propose une alternative syntaxe JavaScript qui remplace le code laide de style C avec des expressions s élégantes.