Aprendendo F#

Atualmente tenho instalados o mono junto com trocentas coisas. Aliás, embora isso não tenha nada a ver, é somente com o monodevelop que estou conseguindo definitivamente usar F# [1]. Não dei jeito ainda no meu emacs. Vou verificar depois se consigo usar.

Mas para instalar o .NET Core precisei dos seguintes pacotes que estão no AUR:

• dotnet-sdk-2.0
• dotnet-host
• dotnet-runtime-1.1
• dotnet-sdk-1.1

Já instalei tanta coisa que nem sei mais o que é realmente necessário. Mas, bem, na verdade o setup mais estável que consegui foi instalando os seguintes pacotes do AUR:

• dotnet-host (cli dotnet, cross-sdk manager)
• dotnet-runtime-1.1
• dotnet-sdk-1.1 (actually 1.0.4)

De resto estou conseguindo me virar.

[1]: Na verdade estou conseguindo usar o Emacs e VS code também. Só tenho problemas com o MonoDevelop na hora de usar .NET Core quando faz referências a pacotes do paket. O Emacs estou tendo problemas apenas com os templates usados pelo .NET Core SDK 1.0.4. VS Code está supostamente funcionando tudo, tirando a parte que ele me dá kernel panic.

É possível definir a versão por projeto do .NET Core, criando um arquivo global.json na raíz do projeto:

{
  "projects": [ "src", "test" ],
  "sdk": {
    "version": "1.0.4"
  }
}

Inclusive é a que estou usando atualmente pra mexer com Fable. Pois simplesmente a versão 2.0 preview está com muitos problemas e não é recomendada pelo pessoal do fable. Na verdade, eles até falam que é possível fazer desenvolvimento do projeto, embora recomendem usar o SDK 1.0.4, no entanto simplesmente os templates não funcionam. Queria apenas um template que funcionasse…

EDIT <2017-08-16 Wed 06:55>: Isso na verdade gera um outro problema, que é do cache ficar sendo repopulado toda vez que é chamado. Não sei se corrigiu recentemente, mas estava tendo sérios problemas com isso! Se eu precisar novamente fazer isso e vê que não funciona setar o global.json, venho comentar isso aqui.

A maioria dos métodos de F# que fazem wrapping na API da .NET não são funções com múltiplos argumentos, mas sim tuplas. Isso pode ser confuso no começo, mas é assim que funciona no ecossistema de F#. O tipo int * int denota uma tupla de inteiros (int, int). Enquanto na notação de tipos int -> int é uma função curry que recebe uma parâmetro int e retorna int.

open System.Net

// usando tuplas como argumento (url, file) e definindo uma função curry
// do tipo: string -> string -> unit
let download (url:string) (file:string) = new WebClient().DownloadFile(url, file)

download "www.google.com" "google.html" // faz download de um arquivo

Curried functions são muito úteis por causa da possibilidade de fazer partial application. Onde você passa apenas alguns dos primeiros parâmetros e então uma nova função é definida. Um exemplo simples é dado a seguir:

open System

[<EntryPoint>]
let main argv =
  let print = printfn "%d" // canonical print
  [1..10] |> List.map print |> ignore

Uma função recursiva recebe a keyword rec antes da definição.

let rec fat n =
    match n with
    | 1 | 0 -> 1
    | _ -> n * fat (n - 1)

A precisão de entrada e saída, por padrão é Int32.

Em F# há três tipos de coleções usadas:

• Seq
• List
• Array

List e Array possuem a diferença em que Arrays possuem tamanho fixo, mas acesso constante. Listas possuem tamanhos arbitrários, mas por outro lado o acesso é O(n).

Sequências são definidas como lazy lists, onde os elementos são avaliados de forma preguiçosa. Um bom exemplo é um algoritmo para cálculo de números primos de forma assíncrona:

/// A simple prime number detector
let isPrime (n:int) =
   let bound = int (sqrt (float n))
   seq {2 .. bound} |> Seq.forall (fun x -> n % x <> 0)

// We are using async workflows
let primeAsync n =
    async { return (n, isPrime n) }

/// Return primes between m and n using multiple threads
let primes m n =
    seq {m .. n}
        |> Seq.map primeAsync
        |> Async.Parallel
        |> Async.RunSynchronously
        |> Array.filter snd
        |> Array.map fst

// Run a test
primes 1000000 1002000
    |> Array.iter (printfn "%d")

• Giraffe é um webframework funcional para F#
• Fable é usado para fazer transpiler de JS

Ou seja, Giraffe é recomendado para fazer backend em F# e Fable frontend.

Algumas coisas úteis que encontrei na API do .NET core:

• System.IO.GetTempPath retorna /tmp

Quem está me salvando ultimamente para criação de projetos na linha de comando é o Forge. Um sistema de gerenciamento de projetos/soluções criado para atuar em conjunto com o FAKE(build system de F#) e Paket, o gerenciador de dependências.

Em geral você cria uma solução, então cria um projeto anexado a essa solução. Quero ainda ver se é possível criar um projeto sem precisar criar uma solução, mas não tenho certeza ainda se é possível.

Então, environment .NET Core é simplesmente infernal, como fazer com que o seu target host não sofra o mesmo? Microsoft pensou nisso considerando a dor descomunal que é ter uma instalação do .NET. Então provê um meio de disponibilizar aplicações que contém o próprio runtime.

Para exemplo desse tópico estarei criando um aplicação hello-world de exemplo baseado no template console pra F#. Estou assumindo aqui que esteja sendo usado .NET Core SDK 2.0 e o runtime também. Legacy is dead.

dotnet new console -lang 'f#' -n test

Isto irá cria uma nova aplicação já pronta em test/ com o seguinte arquivo Program.fs:

open System

[<entryPoint>]
let main argv =
    printfn "Hello World, F#!"
    0 // return an integer exit code

Isso funciona até bem, mas infelizmente eu tenho alguns problemas que realmente me incomoda um bucado. Um desses problemas envolve a uma certa necessidade de instalar dependências na máquina host. As que precisei instalar explicitamente pra funcionar foram no Ubuntu Xenial (16.04) libicu-dev e libunwind8. É importante também lembrar que o aplicativo publicado fica em /<conf>/<runtime/publish. Isso embora pareça óbvio, eu me confundi inicialmente pq é compilado também na raíz do runtime outra versão que não sei nem pq existe lá…

Mas então, voltando aos passos, foi necessário os seguintes:

sudo apt install libunwind8 libicu-dev

Sendo que o procedimento de rele

dotnet publish -c Release -r ubuntu.16.04-x64 --self-contained

A flag --self-contained parece fazer pouco sentido no começo, tendo em vista que publish deveria já fazer isso de toda maneira, mas no entanto não é o comportamento padrão. Se eu não passar essa flag, a aplicação será apenas free-framework e dependências, mas ainda precisará do runtime do .NET Core.

Eu ainda não achei uma forma de listar os runtimes disponíveis pela linha de comando e se quer achei também uma documentação clara sobre isso.

O que me incomoda ainda é o fato de eu ainda ter que instalar algumas coisas no host para a self-contained application funcionar como é o esperado. Se é self-contained porque eu tenho que instalar alguma coisa a mais no host? Isso é muito chato…

Uma compilação self-contained não é nada leve. É cerca de 70MB puro e uns 24MB com .tar.gz, algoritmo de compactação gzip. Por que tanto sofrimento?

Referências de problemas:

• Self-contained applications in Linux does not work
• Self-contained Linux applications
• How to use .NET Core on RHEL 6 / CentOS 6 (fala sobre embarcar third-libraries)