F # domande fondamentali: mutevolezza, standard di capitalizzazione, funzioni vs. metodi

Question

Sentitevi liberi di puntare ad altre risposte se questi sono già stati chiesto!

Sto iniziando F # con la nuova release di questo mese. Ho un po 'di fondo sia in OO e linguaggi funzionali (Haskell e Scheme, ma non OCaml / ML). Un paio di domande sono sorti così lontano dalla lettura attraverso la piccola cosa tutorial che viene fornito con la F # CTP.

1) sono variabili mutabili preferite rispetto monadi? Se è così, sono monadi del tutto evitati in F #?

2) Sono un po 'confuso dalla capitalizzazione utilizzato. In questo file di codice esercitazione, a volte funzioni iniziano con una lettera minuscola, e talvolta maiuscolo. So MS tende a come tappi iniziali con funzioni e metodi, ma qui sembra che ci sono due modi per farlo. Non è un affare enorme per me, come io sto solo giocando il mio tempo, ma sono curioso di ciò che la norma sia.

3) Sono abbastanza confuso su tutta questa combinazione di OO e stili funzionali. print_string "string" ha un senso, ma allora qui è List.map fn list (a meno che non elenco è solo lo spazio dei nomi, mi perdoni se è così). Poi qui è str.Length. Chiunque cura di chiarire quando usare cosa, e che è preferito?

Grazie!

Answer 1

Per quanto riguarda la mutevolezza: F # permette di essere pragmatici. Raramente ho preferisco una monade di stato a un mutabile / ref, ma si può fare a seconda di quale ti piace. Monadi non sono evitati, ma penso che le persone tendono ad utilizzare solo loro quando sono una vittoria netta (ad esempio asincrona di programmazione).

Per quanto riguarda la denominazione: c'è una tensione nel fatto che 'le funzioni sono valori' significa che si potrebbe decidere di nominare una funzione let-bound con la lettera maiuscola (perché è una funzione, e le funzioni iniziano con lettere maiuscole) o con un minore lettera -case (perché è un valore let-bound (che guarda caso ha un '->' nel suo nome tipo)). Personalmente preferisco usare sempre i nomi maiuscoli per tutte le funzioni, ma vedrete entrambi gli stili (tanto più che lo stile della libreria F # stessa è stata lenta evoluzione / standardizzazione nel corso dell'ultimo anno o due). Sottolineatura sembrano essere evitato tutto .Net, e il # biblioteca F non è più un'eccezione (ci sono alcuni nomi hanno lasciato che l'uso sottolinea, ma si distinguono oggi come un pollice dolente e probabilmente essere modificate).

Per quanto riguarda la funzione di stile: Sono poco chiaro quello che chiedete. Nel caso di List.map, 'List' è il nome di un F # modulo , e 'mappare' è una funzione di quel modulo. funzioni membro (ad esempio str.length) hanno il vantaggio di essere comunemente utilizzati in tutto .Net, e forniscono una bella esperienza IntelliSense nell'editor.

Answer 2

1) Non mi spingerei così lontano come a dire monadi sono evitati ... Lei ha detto di avere un po 'di fondo con Haskell - in modo F # flussi di lavoro sono ciò che si vuole prendere in considerazione (il flusso di lavoro termine forse confuso, ma questi hanno solo un pochino a che fare con roba dei processi di business). In generale, le espressioni di sequenza e più in generale le espressioni di calcolo (a.k.a flussi di lavoro) stanno per essere vicino a monadi. Detto questo mutevole è abbastanza comune, anche se non sono sicuro 'preferito' sarebbe il modo di esprimerlo. Ognuno di essi ha un posto - Personalmente, ho iniziato con due libri - 'Fondazione di F #' - ma se stai cercando di fare immersioni in - go 'Expert F #' - entrambi sono buoni. Onestamente, avevo bisogno di fondazioni per aiutarmi a iniziare.

2) l'esperienza che ho avuto, la confusione è che le funzioni tradizionali in .NET hanno una convenzione che in realtà non si presta alla programmazione funzionale. In quanto tale, ritengo che in F # la confusione può essere a volte quando si sta guardando l'uso di 'NET tradizionale' funzioni denominate contro elementi di F # che sono chiaramente funzionali ... Per esempio, nel libro che ho citato sopra 'Expert F #' - accennano che vedrete lasciare valori come List.map e Dates.Today sia camelCase e PascalCase (caso Pascal essere un NET più tradizionale). Una buona regola è che se vi trovate nel mondo funzionale - usare più tradizionale funzionale (camelCase) denominazione - se quello che stai facendo è previsto per essere utilizzato da altri linguaggi .NET, andare con la più .NET norma (Pascal). Si noti inoltre nel mondo funzionale, v'è una tolleranza molto più elevato per le abbreviazioni (ITR, tbl, ecc ...) dove, come .NET, in generale, si è andato via da questo ... Quindi, di nuovo, vedrete un grado variabile di questo genere di cose basa su se stai chiamando elementi funzionali contro elementi esposti in F # che sono condivisi in tutta NET.

3) Sono d'accordo che la combinazione di stili di funzione OO e può essere fonte di confusione. Anche in questo caso, non sono sicuro che è preferito, al di là dicendo che F # (essendo funzionale) chiaramente stili di sé in termini di paradigma funzionale. Tuttavia, F # è un linguaggio funzionale nel mondo .NET (notare la confusione relativa di nominare ho citato sopra) ... Quindi, di nuovo, non è del tutto chiaro taglio.

Spero che questo aiuti ... Che ci crediate o no, come si usa F # e pensare ad altre lingue che hanno condiviso i concetti C ++ con C (per esempio) - diventa più facile. Personalmente, la denominazione ha cominciato ad avere un senso ed i concetti lavorato come ho iniziato a ottenere che ero un F # è un linguaggio funzionale operante su una piattaforma tradizionale - fatto di interagire (anche se non sono sicuro che chiamare la perfetta interoperabilità sarebbe opportuno: D)

Answer 3

In monadi generali ( "workflow" in F #) sono molto più rari rispetto a Haskell, in primo luogo perché le variabili mutabili sono disponibili quindi è improbabile che la gente avrebbe scegliere di utilizzare una monade Stato, invece. In secondo luogo vi sono non superiore-kinded variabili di tipo, il che significa che non è possibile scrivere codice che è sovraccarico di lavorare su qualsiasi Monade, il che rende il loro utilizzo molto meno attraente.

Un posto che essi sono comunemente usati è nelle espressioni di sequenza (che sono davvero come list comprehension a Haskell, ma quelli sono strettamente correlati alla lista Monade).