Minicurso Haskell

Olá!!

Eu me interesso em participar do mini curso.

Opa, vai ser bacana e tbm é bom algo.

Não sei se consiguirei acompanhar igual os outros, pq ainda só tenho um conteudo solido de lógica, mas tentarei entender. http://forum.imasters.com.br/public/style_emoticons/default/natal_happy.gif

Como vai começar só no prox. ano, ainda da tempo para pegar o básico da linguagem, sabe indicar algo?

Assim naum ficarei mto perdido ^^

Forte abraço e sucesso brother. http://forum.imasters.com.br/public/style_emoticons/default/natal_happy.gif

Leonardo,

Relaxa cara, a ideia do curso é mesmo essa, introduzir o pessoal do fórum à linguagem e dar uma ideia do que é programação funcional.

Não é preciso nenhum conhecimento em programação para acompanhar!

É claro que um contato com outras linguagens de programação ajudará, mas não muito.

A programação funcional é bem diferente da programação imperativa (visualG segue o paradigma imperativo).

E como eu falei, seria bacana sugestões sobre um software que podemos fazer em Haskell...

A ideia é fazer um curso que seja realmente útil, isto é, ao fim de 8 semanas (uma aula por semana) eu quero que vocês saiam daqui com sólidos conhecimentos em Haskell, e saibam colocar isso em prática.

Eu pensei em fazermos um software que faz testes de escolha múltipla, o que acham?

Abraços!

Eu me interesso.

Mas seria aqui pelo fórum ? (Pergunta talvez dirretórica)

E dando minha opinião, seria legal sim um software que faz teste de ME. Acharia interessante um Simulador de alguma coisa também.

Sim Dee, as aulas serão ministradas aqui pelo fórum.

Ainda bem que você perguntou, pois eu ja havia esquecido de explicar como serão organizadas as aulas.

As aulas serão postadas em tópicos separados, por exemplo,o tópico da primeira aula será entitulado:

"[Curso Haskell 01] Listas"

E, durante um periodo de uma semana as dúvidas podem ser expostas nesse tópico (qualquer um pode responder dúvidas durante esse tempo), após uma semana, fecharei o tópico e criarei o tópico da próxima aula.

O problema de criarmos um simulador é que é bem complexo abstrair um simulador seguindo o paradigma funcional,

Quando programamos corretamente utilizando o paradigma funcional, devemos ser capazes de prever o resultado de todas as funções apenas olhando para elas.

E, tratando-se de um simulador não sabemos o que resultará da simulação.

É preciso fazer um extenso uso de monads, o que pode ser bem "chato".

Abraços

Haa Entendi.

É uma Linguagem de Programação parecida com C ?

Qual Software Utilizaríamos para Programar em Haskell Curry ? ;)

Não, não é nem um pouco parecido com C, pra falar a verdade, é diferente de tudo o que a maioria dos programadores ja viram.

Todo mundo se concentra muito em programação imperativa e programação orientada a objetos, e esquece os outros paradigmas.

No curso utilizaremos o GHC, na primeira aula explicarei como utilizá-lo.

Entendi, que leegal.

Estarei esperando então.

(=

Não sou muito fã quando o assunto é mudança de paradigma, penei em prolog, mas vo fazer o possível pra acompanhar pelo menos esse básico ai.

Abs e boa iniciativa.

hahahah

Você vai curtir sim kisuke.

É bem "elegante" programar em haskell.

Semana passada implementei uma pequena lib, para ler arquivos XML, em menos de 100 linhas.

>
É bem "elegante" programar em haskell.

Victor, uma pergunta leiga sobre o tema:

Pelo que percebi perguntando para o Google, Haskell (e talvez programação funcional) se trata de programação baseada na implementação; Se esse for o caso, como fica a reutilização ?

É possível DRY com programação funcional já que não desenvolvemos para interfaces ?

João,

A programação funcional, como o próprio nome ja diz, trata de funções, e apenas isso!

É possível programar interfaces, mas como disse acima (sobre simuladores) não é fácil:

>
O problema de criarmos um simulador é que é bem complexo abstrair um simulador seguindo o paradigma funcional,

Quando programamos corretamente utilizando o paradigma funcional, devemos ser capazes de prever o resultado de todas as funções apenas olhando para elas.

E, tratando-se de um simulador não sabemos o que resultará da simulação.

É preciso fazer um extenso uso de monads, o que pode ser bem "chato".

interfaces também são imprevisíveis... não sabemos o que o usuário fará.

>
É possível DRY com programação funcional já que não desenvolvemos para interfaces ?

Sim, é possível aplicar qualquer princípio, como o DRY, no paradigma funcional.E vale lembrar que o DRY é o que mais vamos aplicar!

Em haskell escreve-se código apenas uma vez, e utiliza-se de mil e uma formas diferentes depois.

>
Sim, é possível aplicar qualquer princípio, como o DRY, no paradigma funcional.

E vale lembrar que o DRY é o que mais vamos aplicar!

Em haskell escreve-se código apenas uma vez, e utiliza-se de mil e uma formas diferentes depois.

Certo, lembre-se que além de leigo em Haskell sou apaixonado por OOP, por isso, talvez, esse POST saia do escopo (principalmente desse tópico que trata sobre o curso de Haskell), caso isso aconteça, não exite em movê-lo para um outro lugar mais adequado.

No tópico Leia antes de postar você fez a comparação entre as implementações de Quick Sort em Haskell e C:

Quick Sort em Haskell

quickSort :: (Ord a) => [a] -> [a]
quickSort [] = []

quickSort (h:t) = let maiores = [n | n <- t, n > h]
 ; menores = [n | n <- t, n <= h]
 in (quickSort menores) ++ [h] ++ (quickSort maiores)

Quick Sort (traduzido para PHP)

function swap( &$a , &$b ){
$tmp = $a;
$a = $b;
$b = $tmp;
}

function qsort( &$array , $begin , $end ){
$pivot = $array[ $begin ];
$i = $begin + 1; $j = $end; $k = $end;

while ( $i < $j ){

	if ( $array[ $i ] < $pivot ) $i++;
	else if ( $array[ $i ] > $pivot ){
 $j--; $k--;
 $t = $array[ $i ];
 $array[ $i ] = $array[ $j ];
 $array[ $j ] = $array[ $k ];
 $array[ $k ] = $t;
	} else {
 $j--;
 swap( $array[ $i ] , $array[ $j ] );
	}
}

$i--;

swap( $array[ $begin ] , $array[ $i ] );

if ( $i - $begin > 1 ) qsort( $array , $begin , $i );
if ( $end - $k > 1 ) qsort( $array , $k , $end );
}

>
A programação funcional, como o próprio nome ja diz, trata de funções, e apenas isso!

Nos dois casos, estamos diante de uma forma totalmente funcional de programação, uma vez que não foi utilizado nada além de funções. O fato da estrutura léxica de Haskell ser muito mais enxuta que a do PHP ou de C não faz de Haskell mais 'funcional' que qualquer uma das outras duas.

Porém, o problema central na programação funcional, ao meu modo de ver, está principalmente no foco da implementação e isso é antagônico a reutilização.

No mesmo algorítimo do QuickSort, temos um problema se tivermos que ordenar um outro tipo de dado, como strings por exemplo; ou ainda pior, se tivermos caso onde precisarmos ordenar strings diferentemente de texto em linguagem natural ou até outras estruturas de dados mais complexas.

Com a programação funcional, teríamos 10, 20, ou sabe-se lá quantas implementações completas para cada situação diferente, já na programação orientada a objetos, separaríamos a abstração da implementação e dessa forma, alcançaríamos a reutilização.

>
É possível programar interfaces, mas como disse acima (sobre simuladores) não é fácil:

Simular uma característica da orientação a objetos em uma linguagem que tem como propósito ser funcional, ao meu modo de ver, é deturpar o conceito principal da própria linguagem; Acredito que a dificuldade de se trabalhar com interfaces em Haskell esteja diretamente relacionada ao fato de se tratar de uma linguagem funcional, ou seja, que não foi feita para isso.

PS: Por favor, não compreenda esse POST como qualquer coisa diferente de um kara curioso querendo compreender sobre o que se trata, como disse logo no início, adoro OOP e talvez por isso eu não esteja conseguindo ver a funcionalidade de se programar de forma funcional.

>

>

A programação funcional, como o próprio nome ja diz, trata de funções, e apenas isso!

Nos dois casos, estamos diante de uma forma totalmente funcional de programação, uma vez que não foi utilizado nada além de funções. O fato da estrutura léxica de Haskell ser muito mais enxuta que a do PHP ou de C não faz de Haskell mais 'funcional' que qualquer uma das outras duas.

Desculpe, me referi mal.Quando disse que a programação funcional trata de funções, quiz dizer funções em um aspecto mais matemático.

A programação funcional evita aspectos e dados mutáveis.

Note que não existem variáveis em haskell.

O let apenas cria "macros" (com algumas diferenças) para facilitar a leitura, mas o quickSort também pode ser escrito como mostrado a seguir:

quickSort :: (Ord a) => [a] -> [a]
quickSort [] = []
quickSort (h:t) = (quickSort [n | n <- t, n <= h]) ++ [h] ++ (quickSort [n | n <- t, n > h])

>
Porém, o problema central na programação funcional, ao meu modo de ver, está principalmente no foco da implementação e isso é antagônico a reutilização.

No mesmo algorítimo do QuickSort, temos um problema se tivermos que ordenar um outro tipo de dado, como strings por exemplo; ou ainda pior, se tivermos caso onde precisarmos ordenar strings diferentemente de texto em linguagem natural ou até outras estruturas de dados mais complexas.

Com a programação funcional, teríamos 10, 20, ou sabe-se lá quantas implementações completas para cada situação diferente, já na programação orientada a objetos, separaríamos a abstração da implementação e dessa forma, alcançaríamos a reutilização.

Note a abstração da implementação do algorítmo quicksort,a primeira linha é a assinatura da função, e lá está escrito que recebe uma lista de coisas do tipo "a" e devolve uma lista de coisas do tipo "a", desde que o tipo "a" possua a caracterísica Ord.

Em outras palavras, suporta qualquer tipo que possua overloading do operador ">=".

Essa implementação serve para qualquer tipo ordenável em haskell e vale lembrar que podemos definir um tipo nosso, e, apenas ao fazer o overloading do operador ">=" essa implementação torna-se válida para esse tipo também.

o "a" representa um tipo de dados arbitrário.

>
Simular uma característica da orientação a objetos em uma linguagem que tem como propósito ser funcional, ao meu modo de ver, é deturpar o conceito principal da própria linguagem; Acredito que a dificuldade de se trabalhar com interfaces em Haskell esteja diretamente relacionada ao fato de se tratar de uma linguagem funcional, ou seja, que não foi feita para isso.

Interfaces não são características da programação orientada a objetos.antes de existirem as linguagens OOP, tiveram que implementar interfaces de alguma forma.

Como eu disse, existem recursos que nos permitem implementar qualquer coisa em Haskell, o problema é certas coisas precisam de um nível matemático ligeiramente alto

para começarem a fazer algum sentido.

>
PS: Por favor, não compreenda esse POST como qualquer coisa diferente de um kara curioso querendo compreender sobre o que se trata, como disse logo no início, adoro OOP e talvez por isso eu não esteja conseguindo ver a funcionalidade de se programar de forma funcional.

hahahaha, relaxa!São posts como o seu que acrescentam informação por aqui.

Se ninguém pergunta, ninguém responde.

Abraços!

(ps.: Acho que o post aqui é pertinente, estamos esclarecendo características da linguagem aqui.)

>
Note a abstração da implementação do algorítmo quicksort, a primeira linha é a assinatura da função, e lá está escrito que recebe uma lista de coisas do tipo "a" e devolve uma lista de coisas do tipo "a", desde que o tipo "a" possua a caracterísica Ord.

...

Em outras palavras, suporta qualquer tipo que possua overloading do operador ">=".

Essa implementação serve para qualquer tipo ordenável em haskell e vale lembrar que podemos definir um tipo nosso, e, apenas ao fazer o overloading do operador ">=" essa implementação torna-se válida para esse tipo também.

o "a" representa um tipo de dados arbitrário.

Então de uma forma superficial e fazendo uma analogia à orientação a objetos, o a seria um tipo que implementa uma interface conhecida e que possui um método gtEq(); Se for isso mesmo que entendi, Haskell começou a parecer interessante.

>
São posts como o seu que acrescentam informação por aqui.

Se ninguém pergunta, ninguém responde.

(ps.: Acho que o post aqui é pertinente, estamos esclarecendo características da linguagem aqui.)

Valeu Victor,

Esse seu último POST foi o suficiente para me deixar bastante curioso, vou acompanhar o minicurso de Haskell e pesquisar um pouco mais sobre a linguagem e sobre programação funcional.

Além das versões 6.10.1-13 e da 6.10.3-3, existe uma lista de pacotes complementares para Fedora, será utilizado algum pacote especifico nesse curso ou apenas o compilador é suficiente ?

Então de uma forma superficial e fazendo uma analogia à orientação a objetos, o a seria um tipo que implementa uma interface conhecida e que possui um método gtEq(); Se for isso mesmo que entendi, Haskell começou a parecer interessante.

Quase isso.Traduzindo para algo mais funcional:

O "a" pode ser qualquer tipo.

Basta que em algum lugar exista o operador ">=" definido para esse tipo.

Isto é, ele precisa possuir a característica de poder ser comparado e, consequentemente, ordenado.

quickSort ['a', 'e', 'f', '6'] //--> O "a" é Char.
quickSort [1, 5, 6, 12, 3, 1] //--> O "a" é Integer.
quickSort [5.6, 32.4, 53.4] //--> O "a" é Double.

Resumindo tudo, aquela função serve para todo e qualquer tipo que possa ser ordenado.

(E o melhor é que, basta definir o operador ">=" que o haskell define os outros operadores de ordem (<, >, <=) automaticamente)

E nós, programadores, podemos implementar essa característica a um tipo que seja definido por nós.

sobre o compilador, basta o GHC para o curso...

Não vou me aprofundar muito mais, a ideia é dar uma ideia geral da linguagem, a biblioteca padrão do Haskell ja é bem extensa.

To dentro.

Até dia 3.

beleza Victor.

Abs