Pourquoi y a-t-il deux opérateurs d’affectation, ` `dans R?

Je sais comment utiliser <- et -> , et il y a plusieurs écritures sur la différence entre l’assignation equals et l’assignation de flèche, mais je ne sais pas quand préférer -> plus <- .

Il semble que la communauté se soit unie autour de l’utilisation de <- pour la mission.

Ni le guide de style R de Google, ni le guide de style R de Hadley Wickam ne mentionnent même -> dans la section des tâches.

Je suis curieux de connaître les considérations de conception qui ont amené les développeurs S / S-PLUS à placer la flèche droite assigner un opérateur -> . Dans quel (s) paramètre (s) utiliserait -> être considéré plus lisible (ou plus facile à taper) par rapport à <- ou = ?

Je ne connais aucun autre langage permettant la sémantique de l’affectation correcte. Quelles langues ont inspiré R à cet égard?

Je cherche des réponses qui citent des livres / des documents de conception précoce / des manuels d’utilisation / des listes de diffusion archivées ou d’autres références pour déterminer l’intention de l’auteur / concepteur S dans la mise en place de l’opérateur d’affectation des flèches vers l’avant.

    De la réponse à un exercice dans The New S Language (Becker, Chambers et Wilks 1988), via Google Books:

    Lorsque vous tapez une expression longue uniquement pour vous rappeler que ce serait une bonne idée de sauvegarder le résultat, une flèche à droite vous permet d’effectuer une affectation sans ressaisir la ligne.

    Cela suggère que les utilisateurs de S travaillaient directement dans la console, sans fonctionnalités d’édition de ligne disponibles dans la plupart des environnements REPL / interactifs modernes …


    Un peu d’archéologie: j’ai fouillé dans des sources fondamentales sur Google Books. Il existe trois livres pertinents:

    • le Brown Book: S: Un environnement interactif pour l’parsing des données et des graphiques RA Becker, JM Chambers (CRC Press, 1984)
    • Extension du système S , Becker et Chambers (Taylor et Francis, 1985)
    • le livre bleu: le nouveau langage S Becker, Chambers et Wilks (Wadsworth et Brooks / Cole 1988, mais réédité en 2018 !! par CRC Press)

      1. Le Brown Book ne mentionne pas -> dans le texte principal:

    entrer la description de l'image ici

    mais cela se fait en annexe:

    entrer la description de l'image ici

    1. Extension des mentions du système S -> dans le texte principal:

    entrer la description de l'image ici

    Je ne peux pas chercher beaucoup dans le livre, donc -> peut aussi être mentionné quelque part dans l’annexe.

    1. Le Blue Book fait référence à la flèche droite, mais semble en fait avoir une faute de frappe:

    entrer la description de l'image ici

    J’interprète les passages rouges soulignés comme soutenant qu’il y a une faute de frappe dans la première ligne soulignée, qui devrait être -> plutôt que ← …

    Voici la capture d’écran de la réponse à l’exercice mentionnée ci-dessus:

    entrer la description de l'image ici

    Si vous voulez une copie du livre de 1985, vous pouvez l’obtenir pour 34,41 $ – ou 1070,99 $ (mais avec la livraison gratuite!) …

    entrer la description de l'image ici

    Je pense que c’est juste une question de préférence personnelle.

    Bien que -> canaux magrittr prédéfinis, un cas d’utilisation récent est que -> peut être utilisé pour conserver le stream de gauche à droite dans de tels tuyaux:

     library(magrittr) input %>% fun1 %>% fun2 -> result 

    D’un autre côté, étant donné que <- est principalement utilisé, vous pouvez utiliser <- même dans ce cas.

    L'argument pour <- est qu'il commence la ligne avec la valeur en cours, ce qui est en quelque sorte le but de l'instruction, surtout si la variable résultat est bien nommée, alors que le côté droit est la mécanique et le détail au résultat - et on aime commencer par un aperçu et ensuite entrer dans le détail plus tard. Nous définissons ci-dessous le paramètre k . Que ce soit 3 ou si elle est définie par une constante telle qu’elle est ici ou une expression complexe, cela semble accessoire au but de la déclaration.

     k <- 3 

    Personnellement, je n'utilise jamais -> .

    Je ne peux pas spéculer sur les raisons de R pour permettre l’affectation de gauche à droite. Et il est certainement vrai que la plupart des langages de programmation (presque tous, en fait) n’effectuent que des tâches de droite à gauche.

    Cela dit, R n’est pas entièrement autonome.

    Je ne connais aucun autre langage permettant la sémantique de l’affectation correcte.

    Je peux penser à au moins trois autres langues (familles) qui le permettent:

    • Les langages d’assemblage effectuent souvent une affectation de gauche à droite; Par exemple, la syntaxe AT & T influente écrit l’affectation comme ceci:

       movl $1, %eax 

      Cela assigne la valeur 1 au registre EAX. (D’un autre côté, la syntaxe x86 d’Intel effectue une assignation de droite à gauche.)

    • L’opération STO (“store”) de TI-BASIC s’écrit comme suit:

       1→A 
    • COBOL utilise plusieurs formes d’affectation de gauche à droite:

       MOVE 1 TO x ADD 2 TO x 

      etc.

    Je doute cependant que l’une de ces langues ait servi d’inspiration pour la syntaxe d’atsortingbution de R. En revanche, le langage de programmation APL utilise l’affectation des flèches et il est généralement admis que S (et donc indirectement R) s’en est inspiré; mais APL n’effectue que l’atsortingbution de droite à gauche ( var ← value ).

    R est censé avoir une syntaxe assez naturelle pour exprimer les mathématiques. Il est intéressant de noter que -> est en fait une notation courante pour décrire certaines opérations de ligne élémentaires sur des masortingces. Par exemple, s*R_i -> R_i serait utilisé pour désigner l’opération consistant à remplacer la ligne i par la ligne s fois i. Quelque chose comme 2*A[1,] -> A[1,] est parfaitement valide R. Je ne sais pas si ces considérations ont quelque chose à voir avec la décision de conception, mais cela montre que c’est un choix raisonnable pour un langage mathématique.