Lo scopo di questo file è delineare i principali obiettivi di sviluppo ed i problemi che incontriamo nello sviluppo della libreria.
Per quanto riguarda il modello di sviluppo, consiglio di usare un modello di organizzazione dei branch basato su questo workflow. Potete anche lasciare a me i dettagli, la sintesi è che vi sono sempre la branch `master` su cui vive il codice nella versione funzionante, la branch `develop` su cui vengono integrate le features di sviluppo, e infine una branch per ogni feature che si va a risolvere. Non è uno schema definitivo, sono molto interessato a conoscere sistemi migliori.
Per i momenti di maggiore condivisione (pair-programming) servirebbe:
- un tool di condivisione live del file in editing (toghetherly per (spac)emacs per esempio), o di desktop sharing
- un tool di conference anche solo audio: Mumble, o Skype o Hangout o altri
(Esprimete le vostre preferenze sui tool su #haskell.it)
Per i momenti di lavoro più indipendente basta:
- il nostro modello di lavoro per git
- la chat di #haskell.it per avvisare se ci sono novità o chiedere aiuto
Man mano che le push request si raffinano ci sarà il merge verso le branches più stabili.
Ci sono numerose tecnologie per l’analisi statica di codice imperativo. I linguaggi funzionali hanno meno esigenze, dato che le possibilita` di errori nel codice sono minori, dato che sono direttamente i tipi a dire se le funzioni sono composte bene.
Numerose librerie permettono di mantere informazioni sulle dipendenze fra funzioni e relative chiusure transitive, in maniera compatta in RAM o su disco, e di rispondere a query utili in fase di analisi, in tempi rapidissimi. È possibile memorizzare le informazioni derivate dall’analisi di una libreria su un database anche embeded in modo da usare poca RAM, e avere tempi di avvio dell’applicazione rapidi.
Si tratta di studiare l’esistente e pensare cosa può essere utile nel contesto dei linguaggi funzionali.
Tenere d’occhio anche le discussioni sul repository di `haskell-ide`, come questa.
Uno dei problemi che sto avendo nel codice è come ottenere l’import di tutti gli elementi di un modulo che non sono a loro volta esportati da altri moduli. Ad esempio, `Control.Lens` esporta grandi porzioni di librerie con cui l’utente è già familiare, e quindi sarebbe ingiusto includerle nella nostra analisi
Struttura dei moduli e dello scope della libreria in generale.
Quali sono le funzioni che dovremmo sviluppare per prime?
Come vogliamo che l’utente interagisca con documentator?
I put in ~/.nixpkgs/config.nix something like
But I have still run-time problems.
Supponiamo di dover usare la libreria Acme, che non ha documentazione su Haddock. Con Documentator possiamo scoprire i tipi e le funzioni principali della libreria, sia dall’analisi del codice sorgente che cercando dove e come la libreria è stata usata altrove.
In particolare sarà più facile individuare dei template d’uso tipici della libreria (ad esempio, come sono collegate fra di loro le funzioni nell’uso reale), e quindi scrivere più rapidamente del codice di esempio per testare la libreria.
A questo punto sarà possibile creare della documentazione che serva anche ad altri, e riportarla in qualche modo upstream, in una collezione di tutorial curata o, con la collaborazione del mantainer del pacchetto, in un modulo di documentazione come `Pipes.Tutorial`.
L’obiettivo finale del progetto è rendere più facile la lettura e la comprensione di una nuova base di codice in Haskell. Sarebbe anche bello integrare queste funzioni negli editor come un Hoogle on Steroids, che, in modalità server, restituisce a editor e IDE informazioni come funzioni e tipi utili, code snippet e templates.