25-08-2011, 07:48 PM
(Modification du message : 25-08-2011, 07:49 PM par Sephi-Chan.)
Après l'avoir installé (avec Homebrew), j'ai lancé la console Erlang pour tester un peu le langage.
Le premier choc : les lignes doivent être terminées par un point.
Second choc : les variables d'Erlang (qui commencent toujours par une majuscule) sont des variables au sens mathématique du terme et on ne peut pas changer leur valeur une fois affectée. On utilise l'opérateur = qui est une affectation, mais pas seulement (le suspens est à son combe)…
Ce mécanisme qui paraît très contraignant empêche d'avoir un programme a état mutable : une case mémoire est associée à une valeur et c'est tout. Ainsi, dans le cas d'un accès concurrent à une même variable, on sait toujours à quoi s'attendre et il n'y a pas de mécanisme de lock qui ralentissent : ça permet au langage d'être temps-réel. Ça facilite grandement la parallélisation des programmes.
Ensuite, j'ai rencontré une autre notion à laquelle j'étais déjà habitué en Ruby (avec les symboles) : les atoms. Ils représentent des valeurs constantes et non numériques. Les atomes sont de simples mots (qui commencent par une minuscules). En interne, ils sont associés à des nombres (et ont donc une occupation mémoire très faible). En tant que tel, ils ne servent à rien. On les utilise pour mettre en place le pattern matching et pour donner un contexte au tulples.
Les tuples sont des structures au contenu arbitraire :
Ici, person, name et age sont des atoms.
On peut extraire des valeurs d'un tuple en faisant du pattern matching : on fait correspondre un motif à une valeur (ou une variable contenant cette valeur). On utilise à nouveau l'opérateur = pour faire ça.
La suite une autre fois.
Le premier choc : les lignes doivent être terminées par un point.
Second choc : les variables d'Erlang (qui commencent toujours par une majuscule) sont des variables au sens mathématique du terme et on ne peut pas changer leur valeur une fois affectée. On utilise l'opérateur = qui est une affectation, mais pas seulement (le suspens est à son combe)…
1> A = 5.
5
2> B = 9.
9
3> A = 6.
** exception error: no match of right hand side value 6
4> A = B.
** exception error: no match of right hand side value 9
5> A =
Ce mécanisme qui paraît très contraignant empêche d'avoir un programme a état mutable : une case mémoire est associée à une valeur et c'est tout. Ainsi, dans le cas d'un accès concurrent à une même variable, on sait toujours à quoi s'attendre et il n'y a pas de mécanisme de lock qui ralentissent : ça permet au langage d'être temps-réel. Ça facilite grandement la parallélisation des programmes.
Ensuite, j'ai rencontré une autre notion à laquelle j'étais déjà habitué en Ruby (avec les symboles) : les atoms. Ils représentent des valeurs constantes et non numériques. Les atomes sont de simples mots (qui commencent par une minuscules). En interne, ils sont associés à des nombres (et ont donc une occupation mémoire très faible). En tant que tel, ils ne servent à rien. On les utilise pour mettre en place le pattern matching et pour donner un contexte au tulples.
Les tuples sont des structures au contenu arbitraire :
1> Point = { 12, 66 }.
{12,66}
2> Person = { person, { name, "Romain" }, { age, 22 } }.
{person,{name,"Romain"},{age,22}}
Ici, person, name et age sont des atoms.
On peut extraire des valeurs d'un tuple en faisant du pattern matching : on fait correspondre un motif à une valeur (ou une variable contenant cette valeur). On utilise à nouveau l'opérateur = pour faire ça.
1> { X, Y } = Point.
{12,66}
3> X.
12
4> Y.
66
5> { Type, { _, Name }, { _, Age } } = Person
{person,{name,"Romain"},{age,22}}
6> Type.
person
7> Name.
"Romain"
8> Age.
22
La suite une autre fois.