Pourquoi Lisp permet-il le remplacement des opérateurs mathématiques dans let?

Dans Scheme, vous créez une liaison locale, en omettant tout ce qui est supérieur, avec let . Étant donné que + et * ne sont que des variables qui se comparent à des procédures, vous donnez simplement aux anciennes procédures d'autres noms de variables.

parseFloat = parseInt;
parseFloat("4.5") 
// ==> 4

Dans Scheme, il n'y a aucun mot réservé . Si vous regardez d'autres langues, la liste des mots réservés est assez élevée. Ainsi, dans Scheme, vous pouvez faire ceci:

#!r6rs
(import (rnrs base)) ; imports both * and +   
(define + *)         ; defines + as an alias to *

(+ 10 20) 
; ==> 200 guaranteed

La chose vraiment intéressante à ce sujet est que si vous choisissez un nom et que la prochaine version de la norme utilise le même nom pour quelque chose de similaire, mais non compatible, votre code ne cassera pas. Dans d'autres langues, j'ai travaillé avec une nouvelle version pourrait introduire des conflits.

R6RS rend les choses encore plus faciles

De R6RS, nous avons des bibliothèques. Cela signifie que nous avons un contrôle total sur les formulaires de haut niveau que nous obtenons de la norme dans nos programmes. Vous avez plusieurs façons de le faire:

#!r6rs
(import (except (rnrs base) +))    
(define + *)

(+ 10 20) 
; ==> 200 guaranteed

C'est également OK.

#!r6rs
(import (rename (except (rnrs base) +) (* +)))

(+ 10 20) 
; ==> 200 

Et enfin:

(define (test v)
  (define let 10)           ; from here you cannot use let in this scope
  (define define (+ let v)) ; from here you cannot use define to define stuff
  define) ; this is the variable, not the special form
;; here let and define goes out of scope and the special forms are OK again
(define define +) ; from here you cannot use top level define
(define 5 6) 
; ==> 11

D'autres langues le font aussi:

JavaScript est peut-être le plus évident:

(let ((+ *))
  +)
; ==> #<procedure:*> (non standard visualization of a procedure)

Mais vous ne pouvez pas toucher leurs opérateurs. Ils sont réservés car la langue doit faire beaucoup de choses pour la priorité des opérateurs. Tout comme Scheme, JS est un langage agréable pour la frappe de canard.

La philosophie de Scheme est d'imposer une restriction minimale afin de donner une puissance maximale au programmeur.

Une raison d'autoriser de telles choses est que dans Scheme vous pouvez intégrer d'autres langages et dans d'autres langages vous voulez utiliser le * avec une sémantique différente.

Par exemple, si vous implémentez un langage pour représenter des expressions régulières, vous voulez donner au * la sémantique du kleene algébrique opérateur et écrivez des programmes comme celui-ci

(* (+ "abc" "def"))

pour représenter une langue contenant des mots comme celui-ci

empty
abc
abcabc
abcdef
def
defdef
defabc
....

À partir de la langue principale, lambda calcul non typé, il est possible de créer une langue en que vous pouvez redéfinir absolument tout sauf le symbole lambda . C'est le modèle du schéma de calcul sur lequel est construit.

Les dialectes Lisp traditionnels n'ont pas de jetons réservés pour les opérations d'infixe. Il n'y a pas de différence catégorique entre + , expt , format ou open-file : ce ne sont que des symboles.

Un proram Lisp qui exécute (let ((+ 3)) ...) est spirituellement très similaire à un programme C qui fait quelque chose comme {int sqrt = 42; ...} . Il y a une fonction sqrt dans la bibliothèque C standard, et comme C a un seul espace de noms (c'est un Lisp-1), ce sqrt est maintenant masqué.

Ce que nous ne pouvons pas faire en C, c'est {int + = 42; ...} car + est un jeton d'opérateur. Un identifiant est demandé, il y a donc une erreur de syntaxe. Nous ne pouvons pas non plus faire {struct interface * if = get_interface (...); } car if est un mot-clé réservé et non un identifiant, même s'il en ressemble à un. Les lisps ont tendance à ne pas avoir de mots-clés réservés, mais certains dialectes ont certains symboles ou catégories de symboles qui ne peuvent pas être liés en tant que variables. Dans ANSI Common Lisp, nous ne pouvons pas utiliser nil ou t comme variables. (Plus précisément, les symboles nil et t qui proviennent du package common-lisp ). Cela ennuie certains programmeurs, car ils aimeraient une variable t pour "time" ou "type". En outre, les symboles du package de mots-clés, apparaissant généralement avec un deux-points, ne peuvent pas être liés en tant que variables. La raison en est que tous ces symboles s'auto-évaluent. nil , t et les symboles de mots-clés s'évaluent d'eux-mêmes, et n'agissent donc pas comme des variables pour désigner une autre valeur.

Pourquoi Lisp permet-il de relier les opérateurs mathématiques?

• pour la cohérence et
• car cela peut être utile.

Cela ne crée-t-il pas de confusion?

• Non.

La plupart des langages de programmation, suivant la notation algébrique traditionnelle, ont une syntaxe spéciale pour les fonctions arithmétiques élémentaires d'addition et de soustraction, etc. Les règles de priorité et d'association rendent certains appels de fonction implicites. Cette syntaxe facilite la lecture des expressions au prix de la cohérence.

Les LISP font basculer la bascule dans l'autre sens, préférant la cohérence à la lisibilité.

Dans Clojure (le Lisp que je connais), les opérateurs mathématiques ( + , - , * , ...) n'ont rien de spécial .

• Leurs noms ne sont que des symboles ordinaires.
• Ce sont des fonctions principales comme toutes les autres.

Vous pouvez bien sûr les remplacer.

< finalUtilité

Pourquoi voudriez-vous remplacer les opérateurs arithmétiques de base? Par exemple, la bibliothèque units2 les redéfinit pour accepter des quantités dimensionnées ainsi que nombres simples.

L'algèbre de Clojure est plus difficile à lire.

• Tous les opérateurs sont des préfixes.
• Toutes les applications de l'opérateur sont explicites - pas de priorités.

Si vous êtes déterminé à avoir des opérateurs infixes avec des priorités, vous pouvez le faire. Incanter le fait: voici quelques exemples et ici est le code source.