che sto guardando il codice sorgente della libreria pipes e per esempio nel Core module non capisco il motivo per cui l'autore è tutto il luogo utilizzando il modello di funzioni che definiscono così:perché tubi definisce le funzioni interne
runEffect = go
where
go p = ...
Oppure:
pull = go
where
go a' = ...
Oppure:
reflect = go
where
go p = ...
I s questo qualche trucco per abilitare alcune ottimizzazioni? Lo trovo brutto, se si tratta di un trucco di ottimizzazione vorrei davvero che il compilatore potesse farlo senza cose del genere. Ma forse c'è un'altra ragione?
'pipes' è una piccola libreria con astrazioni componibili che possono essere utilizzate per creare molte logiche complesse, quindi è naturale che l'ottimizzazione pesante si ripaga a livello di libreria di base. Ha anche regole di riscrittura non banali. Al contrario, nel normale codice di produzione non è necessario occuparsi di involucri manuali. Di solito GHC lo fa bene. –
Grazie. Grazie alle tue parole chiave "completamente applicate", mi sono imbattuto in questo: http://stackoverflow.com/questions/11690146/why-does-ghc-consider-the-lhs-syntactically-when-inining che spero condivideranno un po 'più di luce sul problema per me. È piuttosto deludente vedere tutte le altre magie che haskell può raggiungere. –
se è così facile "in linea" una funzione ricorsiva, perché GHC non fa questo trucco da solo? – mb14