En fait, l'affectation avec =, au début j'étais un peu sceptique, mais finalement je suis assez fan. L'argumentaire de Graham à ce sujet, c'est que le signe =, c'est deux bandes, ce qui attire l'attention (et signale un danger).
Pour ce qui est des principales différences :
- Pas de différence entre le symbole nil, la liste vide et le booléen faux : le mal absolu pour les schemeurs (et même pour McCarthy lui-même) ; on aime ou on n'aime pas, il y a des avantages et des inconvénients, l'avantage étant la concision, l'inconvénient étant de prendre une liste vide pour un booléen faux dans un cas où ça n'a rien à voir.
- Macros non hygiéniques : en scheme, les variables définies dans une macro ne peuvent pas entrer en conflit avec celles qui sont définies par l'utilisateur (la capture de variable). C'est une source de bug fréquente et assez difficile à repérer. Mais la capture de variable peut parfois être voulue. Par exemple, arc définit une macro "aif" (anaphoric if) qui affecte à la variable "it" le résultat du test :
- Des divergences dans la façon de concevoir les programmes. Par exemple, là où Scheme incite fortement le programmeur à suivre le paradigme fonctionnel, Arc est assez "agnostique" : il y a tout ce qu'il faut pour écrire des algos fonctionnels (map, filter, reduce, tail-recursion, ...) comme des algos procéduraux (notamment beaucoup de types d'itérateurs) ; ce qui explique en partie l'absence de "!" dans les noms des fonctions.
Toutes ces divergences, c'est ce que Graham a retenu de Common Lisp. Mais globalement, je trouve Arc plus proche de Scheme.
[^] # Re: Différences notables avec scheme ?
Posté par sacado . En réponse à la dépêche Le langage Arc, issu de Common Lisp et Scheme, a un mois. Évalué à 3.
Pour ce qui est des principales différences :
- Pas de différence entre le symbole nil, la liste vide et le booléen faux : le mal absolu pour les schemeurs (et même pour McCarthy lui-même) ; on aime ou on n'aime pas, il y a des avantages et des inconvénients, l'avantage étant la concision, l'inconvénient étant de prendre une liste vide pour un booléen faux dans un cas où ça n'a rien à voir.
- Macros non hygiéniques : en scheme, les variables définies dans une macro ne peuvent pas entrer en conflit avec celles qui sont définies par l'utilisateur (la capture de variable). C'est une source de bug fréquente et assez difficile à repérer. Mais la capture de variable peut parfois être voulue. Par exemple, arc définit une macro "aif" (anaphoric if) qui affecte à la variable "it" le résultat du test :
(aif (max une-liste-très-longue) (prn it) (prn "vide !"))
équivalent de :
(let it (max une-liste-très-longue) (if it) (prn it) (prn "vide !"))
- Des divergences dans la façon de concevoir les programmes. Par exemple, là où Scheme incite fortement le programmeur à suivre le paradigme fonctionnel, Arc est assez "agnostique" : il y a tout ce qu'il faut pour écrire des algos fonctionnels (map, filter, reduce, tail-recursion, ...) comme des algos procéduraux (notamment beaucoup de types d'itérateurs) ; ce qui explique en partie l'absence de "!" dans les noms des fonctions.
Toutes ces divergences, c'est ce que Graham a retenu de Common Lisp. Mais globalement, je trouve Arc plus proche de Scheme.
Enfin, Arc contient un peu de syntaxe :
(~f x) <=> (not (f x))
(f:g x) <=> (f (g x))
a.b <=> (a b)
a!b <=> (a 'b)