Erlang: pippa mentale su and e andalso

[rossomoto]

Alura, premesso che:

• di erlang non so un cazzo nè capisco un cazzo

• già di mio non so un cazzo e non capisco un cazzo

La domanda è: ci sono dei casi in cui and è preferibile ad andalso?

Ad esempio, qualcuno è mai incappato in casi in cui fosse necessario che tutte le condizioni venissero verificare?
Che so, magari motivazioni di accounting, tipo: “voglio che tutte le funzioni chiamate dalla and vengano eseguite e tengano un log”?

Oppure per motivazioni di sviluppo, tipo: “voglio evitarmi di stare qui a risolvere il problema di UNA delle funzioni per poi scoprire che ne falliva anche una seconda (e poi una terza e così via)”?

[Aethiss]

rossomoto said in Erlang: pippa mentale su and e andalso:

La domanda è: ci sono dei casi in cui and è preferibile ad andalso?

Leggendo la documentazione, andAlso vuoi evitare di valutare il secondo confronto per evitare uno short-circuit se il primo e’ gia’ falso.
Pero’ conosco poco Erlang e sinceramente non e’ che mi piaccia cosi’ tanto, quindi magari qualche altro puo’ integrare/sconfessare/migliorare quello che ho scritto.

imho, se sono 2 booleani, e non ci sono strane pippe mentali dietro, un and basta ed avanza.

[absc]

Onestamente mai successo.

Peró chi ha scritto Erlang è un fisico. Ho l’impressione che da qualche parte, evitare lo short-cicuiting sia stato necessario, nel mondo telco.

Ma sapere di poterlo fare, non è che mi dispiaccia tanto.

È una di quelle cose che non usi mai, ma se non ce l’hai e ti farebbe comodo, bestemmi come un ghiro per non averla.

[amigaunicorn]

Cioccolataio Svizzerese said in Erlang: pippa mentale su and e andalso:

Ho l’impressione che da qualche parte, evitare lo short-cicuiting sia stato necessario, nel mondo telco

Onestamente, non credo che il mondo telco di per se’ abbia dei requisiti che riguardano il linguaggio di programmazione. Dopotutto, il codice viene compilato e viene mandato alla VM. Come descrivi quel che vuoi conta poco, al massimo poi e’ come il compilatore lo implementa…

[somedude]

rossomoto said in Erlang: pippa mentale su and e andalso:

La domanda è: ci sono dei casi in cui and è preferibile ad andalso?

Controdomanda: non ti basta

1> X = 0.
0
2> (X =/= 0) andalso (10 div X > 1).
false

?

Da persona che NON ha mai usato Erlang IRL, direi che il rhs potrebbe anche essere qualcosa di side-effectful che non necessariamente vuoi che succeda, ma non so se è una cosa che si usa davvero.

[rossomoto]

somedude said in Erlang: pippa mentale su and e andalso

Da persona che NON ha mai usato Erlang IRL, direi che il rhs potrebbe anche essere qualcosa di side-effectful che non necessariamente vuoi che succeda, ma non so se è una cosa che si usa davvero.

Io mi sono immaginato un caso in cui, per motivi di accounting/logging/“completezza di business” (???) si volesse che tutte le espressioni venissero valutate.

Qualcosa per cui, in un caso del genere, :

1> (expr1) and (expr2) and (expr3)
false

Ti chiedessero quali expr sono andate a buon fine e quali sono fallite.
Con andalso se la prima va male le altre due non vengono nemmeno chiamate e non puoi rispondere alla domanda.

Ma, appunto, non ho idea se sia un’esigenza reale che ha portato inizialmente ad implementare lo and senza cortocircuito.

Magari è solo un incidente storico…

[absc]

rossomoto

IMHO, per togliersi il dubbio bisognerebbe sbirciare se andalso è usato nella codebase di Erlang stesso.

[absc]

rossomoto

Leggendo in giro, gli operatori short-cicuiting sono stati aggiunti dopo per aiutare a semplificare certo codice.

In effetti, Erlang tratta and, or, xor e compagnia strettamente come operatori booleani e non come anche operatori di controllo (a-la C etc…).

Insomma, andalso è una convenienza, come a onor del vero ne sono state aggiunte molte in Erlang nel tempo (non dispiace affatto farlo agli sviluppatori).

Vedi alla voce l’espressione maybe

[vertigo]

Un po’ come la differenza tra & e && in C.