Elixir: logica alla base della possibilità di legare nuovamente le variabili

Question

Qual è la logica alla base della possibilità di riconciliare le variabili in elisir, quando Erlang non lo consente?

Answer 1

Perché è più semplice.

Date un'occhiata a this question inviato alla mailing list Erlang nel 2009. In particolare questa parte:

---

mi piace pattern matching nella maggior parte dei casi, ma trovo che scrivo abbastanza codice dove necessario aggiornare incrementalmente una struttura di dati, e sostenendo che il codice è un dolore quando ho codice come:

X = foo(), 
X1 = bar(X), 
X2 = xyzzy(X1), 
blah(X2). 

e successivamente si desidera cambiarlo in:

X = foo(), 
X1 = whee(X), 
X2 = bar(X1), 
X3 = xyzzy(X2), 
blah(X3). 

Ndr - questa è la risposta a questa domanda.

Questo passa attraverso IRC molto. Questo è il risultato della pratica di denominazione variabile delle variabili e non è necessario introdurre il rebinding per "correggerlo"; smetti di usare lettere singole e contatori come nomi di variabili.

Se per esempio che è stato scritto

FooStateX = foo(), 
PostBarX  = bar(FooStateX), 
OnceXyzziedX = xyzzy(PostBarX), 
blah(OnceXyzziedX). 

---

Il codice ha dimostrato, non v'è tutto ciò che raro in Erlang (notare la scritta "questo passa attraverso IRC molto"). L'abilità di Elisir di rifondare semplicemente i nomi ci salva dal dover generare nuovi nomi fittizi per le cose in ogni momento. È tutto. È saggio ricordare che i creatori originali di Erlang non stavano cercando di costruire un linguaggio funzionale. Erano semplicemente degli sviluppatori pragmatici che avevano un problema da risolvere. L'approccio di Elisir è semplice pragmatismo.

Answer 2

Ecco la logica direttamente dalla bocca del cavallo:

http://blog.plataformatec.com.br/2016/01/comparing-elixir-and-erlang-variables/

Answer 3

lingue più funzionale non consentono rilegatura di variabili nello stesso ambito. Quindi, l'elisir che consente questo, gli conferisce sicuramente un aspetto non funzionale e imperativo. Il problema di Erlang è piuttosto la mancanza di scopo, o per essere più precisi che esiste un solo ambito in un'intera clausola di funzione. Abbiamo avuto serie discussioni riguardo l'introduzione del campo di applicazione, ma alla fine abbiamo deciso di non farlo perché era incompatibile con il sistema esistente. E gli sviluppatori odiano le modifiche inconsistenti al contrario.

Il modo in cui Erlang ha un grave vantaggio: quando si sbaglia in generale si verifica un errore in modo che è possibile VEDERE l'errore.Questo ha messo a confronto solo un comportamento strano quando una variabile non ha il valore che ci si aspetta che sia MUCH più difficile da rilevare e correggere.

Personalmente penso che il problema dei nuovi nomi di variabili, ad esempio utilizzando lo schema numerico, sia enormemente esagerato. Rispetto al tempo che mi ci vuole per risolvere WHAT Ho intenzione di fare cambiare i nomi delle variabili è banale. E dopo un po 'lo vedi senza rifletterci. Onestamente.

EDIT:

Anche quando concatenamento dati attraverso una successione di funzioni il significato reale dei dati cambia così riutilizzare lo stesso nome della variabile può essere molto fuorviante. Può finire per significare solo un generico "dati che sto passando da una funzione all'altra".