<p dir="ltr">Il 27/lug/2015 10:50, "enrico franchi" <<a href="mailto:enrico.franchi@gmail.com">enrico.franchi@gmail.com</a>> ha scritto:<br>
><br>
> Per fare questo devi stravolgere il linguaggio. In pratica devi fare scomparire il concetto di statement. Che va bene.<br>
> Pero' poi devi accettare:<br>
><br>
> if a = 3:<br>
>     print a<br>
><br>
> cosa sara' a?<br>
Immagino che a sarà qualcosa che può essere paragonato e che può essere stampato. Ma, con un po' di fantasia, se ti riferisci al caso in cui a = 3 non valga, direi che manca l'alternativa (sì, sono di quella corrente lì).<br>
><br>
> Oh, volendo puoi fare stravolgimenti della grammatica per fare funzionare comunque come si vuole... ma in generale se vai in direzione del "tutto e' un'espressione, ci vai fino in fondo."<br>
Il che mi sta abbastanza bene.</p>
<p dir="ltr">><br>
> Comunque la "semantica del corpo della funzione" (che non mi e' chiaro cosa intendi) non sembra a prima vista il problema.<br>
Intendo il significato che assume la sequenza di istruzioni contenute nella definizione di una funzione<br>
><br>
> Diciamo che per poter dire che "return e' obbligatorio" (che risolverebbe il problema di cui sopra) devi essere in grado di dimostrare staticamente che ogni path di esecuzione incontra un return. Che probabilmente non e' eccessivamente complicato da fare.<br>
><br>
> E ovviamente avresti un botto di funzioni che finiscono con return None. Oggettivamente non e' che mi piace troppo... pero' va bene cosi'.<br>
Ma io vorrei proprio l'opposto, cioè che il return sia facoltativo (e solo necessario nel caso di un early return).<br>
>><br>
>> Il null implicito fa molto php.<br>
><br>
> I linguaggi che menzioni .. a parte che per certi versi Rust non fa una cosa troppo diversa da Python. Se non metti return, lui ritorna ().<br>
Solo se termini l'ultima espressione con un punto e virgola.</p>
<p dir="ltr">> Dopo di che il fatto che sia staticamente tipizzato mi fa anche pensare che se provi ad usare () per assegnarlo a qualcosa che non dovrebbe avere quel tipo intervenga.<br>
Ed è un bel favore.</p>
<p dir="ltr">> Per il resto, gli altri linguaggi che menzioni di fatto hanno altre convenzioni: per esempio che l'ultima espressione che compare e' quella che viene ritornata. La cosa e' relativamente ovvia e poco sorprendente nei linguaggi "veramente" funzionali.<br>
Che poi nei linguaggi *veramente* funzionali non hai un'ultima espressione (il che implicherebbe una sequenza procedurale), ma un'unica espressione.<br>
> E una volta che hai static typing, anche la gamma di errori che puo' causare cala moltissimo. In Ruby? Non cosi' intuitivo, dal mio punto di vista. Fra le due, preferisco il None implicito rispetto che "quello che e' ultimo implicito".<br>
Posso chiederti perchè?</p>
<p dir="ltr">Io lavoro per la stragrande maggioranza del tempo in php (no comment please) e più di una volta vengo morso da return dimenticati (sarà per via che poi la domenica sto su haskell e rust, boh...)</p>
<p dir="ltr">Poi, vabbè, evitiamo proprio di iniziare il discorso null/bottom, penso si sia tutti d'accordo ;)</p>
<p dir="ltr">--<br>
Nadir</p>