2015-03-22 19:23 GMT+01:00 enrico franchi <enrico.fran...@gmail.com>:
> > > 2015-03-22 16:24 GMT+00:00 Manlio Perillo <manlio.peri...@gmail.com>: > >> 2015-03-22 17:06 GMT+01:00 enrico franchi <enrico.fran...@gmail.com>: >> >>> >>> 2015-03-22 15:35 GMT+00:00 Manlio Perillo <manlio.peri...@gmail.com>: >>> >>>> Tra l'altro il tutto è complicato dal fatto, AFAIK, che ciascuno degli >>>> operandi può avere effetti collaterali. >>>> Ad esempio: >>>> https://play.golang.org/p/jc0vKCWFu7 >>>> >>> >>> Scusa non comprendo... in C (e in Go) && introduce un sequence point. >>> Quindi *sai* l'ordine in cui le cose sono valutate. >>> >> >> Logical operators apply to boolean values and yield a result of the same >> type as the operands. The right operand is evaluated conditionally. >> Senza il "conditionally", il compilatore potrebbe evaluare `*p` anche se >> `p != ni`l è falso. >> > > Si, ovvio. Ma non capisco quale sia il tuo punto. > Il punto è che voglio gli operatori corto circuitati per avere un comportamente sempre ben definito. AFAIK se && in Go non fosse corto circuitato, il compilatore potrebbe valutare `*p == 2`anche se p è nullo. > In realtà, come dici dopo, Go non ha la nozione di sequence point. >> > > Veramente, rileggendo quello che ho scritto, mi e' scappato un Go di > troppo e ho scritto una minchiata. Ovvero, in C & *non* ti da un sequence > point. > > In Go, invece, come dicevo piu' sotto, te lo da. Appunto perche' in C una > generica espressione non ti da garanzie sull'ordine di valutazione (per > esempio invece , lo fa && lo fa || lo fa, etc). Viceversa, in Go il > linguaggio ti dice l'ordine di valutazione delle cose, che vuole dire che > essenzialmente ogni operazione introduce un sequence point o giu' di li. > > Quello che volevo dire è che la specifica del linguaggio non parla mai di sequence point, a differenza del C (ed è una delle parti più complesse del linguaggio). > Ovvero se in go scrivi f() & g() sai che f() sara' completamente valutata > prima di iniziare a valutare g() [nota, go routine et similia non contano, > perche' se dentro f c'e' qualcosa tipo go h(), il side effect e' "lanciare > una go-routine che esegue h, i side effect di h non contano). > > >> >>> Dopo di che mi gira il cazzo perche' in Go non c'e' un singolo modo >>> decente per convertire un booleano in intero (no, fare un if non e' un modo >>> decente) e per *nessuna* ragione che a me paia sensata (per favore, >>> qualcuno mi spieghi il perche') & e | non funzionano con operandi >>> booleani. Voglio dire, sarebbero operazioni perfettamente definite e type >>> safe. WTF! >>> >>> >> La risposta ufficiale credo sia : "ti scrivi delle funzioni apposite " >> > > E la risposta alla risposta ufficiale e' fare torreggiare un dito medio > alto quattro piani. :) > > Cioe', davvero... e' una delle cose che non comprendo. Veramente... Go mi > e' piaciuto un sacco, mi ha intrigato un sacco. Posso arrivare a dire che > dopo Python nessun linguaggio mi aveva intrigato altrettanto... ma ci sono > una piccola serie di cose che proprio non riesco a digerire. > All'inizio la pensavo come te, e in alcuni punti lo penso ancora. Però dopo averlo usato ne apprezzi meglio la semplicità. Spero proprio che la semplicità, dopo i "danni" fatti dal C++, sia l'eredità di Go per i futuri linguaggi. Ciao Manlio
_______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
