Existe um compilador ou pré -processador Haskell que usa avaliação estrita?

Question

Estou procurando um compilador Haskell que use avaliação estrita por padrão, em vez de avaliação preguiçosa. Eu apenas usaria o OCAML, mas a sintaxe de Haskell é muito melhor do que o OCAML (e Haskell é puro e possui recursos interessantes, como classes de tipo).

Eu realmente prefiro não colocar constantemente !areia $!está em todo o meu programa. Um compilador com um interruptor ou um pré -processador para colocar as anotações de rigor seria muito bom. Também seria útil se houvesse uma maneira de usar uma avaliação preguiçosa em determinados lugares, caso eu queira algo como uma lista infinita (provavelmente nunca o farei).

Por favor, não tente me convencer de que a avaliação preguiçosa é melhor, eu realmente preciso do desempenho. IIRC, Simon Peyton Jones até disse que a avaliação preguiçosa não era realmente necessária, estava lá principalmente para impedir que eles deixassem a linguagem impura.

Answer 1

Se você possui um compilador Haskell que usa avaliação estrita, ele não compila Haskell. Preguiça A não estriagem faz parte das especificações Haskell!

No entanto, existem alternativas.

• DDC é uma tentativa de criar uma variante explicitamente preguiçosa de Haskell, que apóia coisas como atualização destrutiva, mantendo todo o resto da bondade de Haskell. Há um problema: o compilador está atualmente apenas no estágio α, embora pareça ser pelo menos utilizável.

• Crie um pré -processador, como outros fizeram.

• Aprenda a usar Haskell "o caminho certo". Se você puder simplificar seu caso de teste para algo que seja publicamente displayable, você pode postá-lo no Lista de discussão Haskell-Café, onde as pessoas são muito úteis com esse tipo de pergunta sobre os efeitos da não ritção.

Answer 2

Eu realmente prefiro não colocar constantemente! S e $! S em todo o meu programa

Você está fazendo errado, se é assim que você está programando Haskell :) Você simplesmente não precisará fazer isso. Use GHC, use -o2, use tipos rígidos de dados Quando apropriado, use preguiçosos quando apropriado. Não presuma que a preguiça será um problema - é uma solução para muitos problemas.

Answer 3

Houve duas tentativas de avaliar estritamente Haskell no passado:

• Jan-Willem Maessen Ansioso Haskell
• Rob Ennals Tese de doutorado

Mas ambos estavam focados em manter a semântica não rigorosa de Haskell, mas o uso de uma estratégia de avaliação principalmente rigorosa, em vez de realmente mudar a semântica, e nenhum deles realmente viu a luz do dia.

EDIT: A sugestão de Martijn de plugina rigorosa parece ideal para seus propósitos, pois ele realmente faz o que você deseja e o autor ainda está ativo na comunidade Haskell, eu tinha esquecido.

Answer 4

Veja também GHC-Strict-Plugin, um exemplo para Estrutura de plug -in do GHC, descrito no Monad Reader 12.

Answer 5

Eu sinto sua dor. Minha maior pita na minha programação do dia-a-dia é lidar com isso!@#$%^& (Vazamentos de espaço.

No entanto, se isso ajudar, com o tempo, você aprende (da maneira mais difícil) sobre como lidar com isso, e melhorar. Mas ainda estou esperando Andy Gill sair com seu perfil de vazamento de espaço mágico para corrigir todos os meus problemas. (Estou levando o comentário de fora para mim no último ICFP de que ele havia sonhado essa ideia legal como uma promessa de implementá-la.)

Não vou tentar convencê -lo de que a avaliação preguiçosa é a melhor coisa do mundo, mas há certos pontos positivos sobre isso. Eu tenho alguns programas de processamento de fluxos que exploram listas preguiçosas por meio de qualquer variedade de combinadores que correm alegremente em gigabytes de dados enquanto usam apenas 3,5 MB de memória (dos quais mais de 2 MB é o tempo de execução do GHC). E alguém mais inteligente do que me apontou para mim no ano passado que você realmente ficaria bastante surpreso, como um programador típico de Haskell, quanto você depende da avaliação preguiçosa.

Mas o que realmente precisamos é um livro muito bom sobre como lidar com avaliação preguiçosa no mundo real (que não é tão diferente do mundo acadêmico, realmente, exceto que eles simplesmente não são publicados um artigo, e temos clientes que virão atrás de nós com facas) que cobrirão adequadamente a maioria dos problemas relacionados a isso e, mais importante, nos dará uma sensação intuitiva do que vai explodir nossa pilha e o que não é.

Eu não acho que isso seja uma coisa nova; Tenho certeza de que outros idiomas e arquiteturas também passaram por isso. Como os primeiros programadores a lidar com pilhas de hardware e tudo isso, afinal? Não tão bem, aposto.

Answer 6

Eu acho que Jan-Willem Maessan's compilador de pH é/foi rigoroso. O próximo mais próximo é o garfo de avaliação especulativo de Robert Ennal para o GHC 5. O garfo spec_eval não é rigoroso, mas avalia otimista. Não sei se um desses ainda é atual/utilizável/etc.

Answer 7

O uso de NFDATA e RNF em todos os lugares não é uma solução, pois significa atravessar repetidamente grandes estruturas que já foram avaliadas.

O capítulo introdutório da tese de doutorado de Ben Lippmeier (sobre DDC) é sobre a melhor crítica de Haskell que eu já vi-discute questões de preguiça, atualização destrutiva, Monad Transformers etc. DDC tem preguiça, mas você precisa solicitá-lo explicitamente , e é considerado um efeito, que é rastreado e gerenciado pelo sistema de tipo e efeito do DDC.

Answer 8

Eu vi recentemente algum trabalho nesta área:

https://ghc.haskell.org/trac/ghc/wiki/stritpragma

Você pode ouvir um pouquinho sobre isso na atualização de status do GHC do SPJ aqui:

http://youtu.be/ex79k4lvjno?t=9m33s(O link começa na peça relevante às 9:33)

Answer 9

Estou procurando um compilador Haskell que use avaliação estrita por padrão, em vez de avaliação preguiçosa.

Esse compilador não seria um compilador Haskell. Se você verdade Quer, você pode considerar colocar {-# LANGUAGE Strict #-} Pragmas em seus arquivos. Isso funcionará com o GHC 8.0.2, 8.2.2 e 8.4.1, também conhecido como os três últimos lançamentos do compilador.

Também seria útil se houvesse uma maneira de usar a avaliação preguiçosa em certos lugares, apenas caso eu queira algo como uma lista infinita

Não existe esse método. Em vez disso, use o GHC como se destinava - como uma linguagem preguiçosa. Aprender a pensar em seu código, perfil e usar as estruturas de dados funcionais corretamente será muito mais útil do que aplicar rigorosamente pragmas em todos os lugares. O GHC já tem um analisador de rigor.

(Eu provavelmente nunca o farei).

Isso é exatamente o que os autores do LLVM-HS pensamento Quando eles escolheram usar uma mônada estatal estrita em vez de preguiçosa. Em vez disso, causou um inseto inesperado no futuro. Preguiça e recursão andam de mãos dadas.

Por favor, não tente me convencer de que a avaliação preguiçosa é melhor, eu realmente preciso do desempenho.

Estou duvidoso que isso é realmente o que você deseja quando não aumenta com segurança o desempenho do código Haskell, ao mesmo tempo em que quebra o código existente e torna inútil os recursos existentes. Se é assim que você pretende escrever programas, use o OCAML ou o Scala e deixe a comunidade Haskell em paz.

IIRC, Simon Peyton Jones até disse que a avaliação preguiçosa não era realmente necessária, estava lá principalmente para impedir que eles deixassem a linguagem impura.

Isso não é verdade. Você pode ler mais sobre a história real de Haskell aqui

Answer 10

Há também Seqaid, que visa no meio do espectro preguiçoso.

O Seqaid é um plug-in GHC que fornece instrumentação automática não invasiva de projetos Haskell, para controle dinâmico de rigor (e paralelismo). Em breve, isso incluirá otimização para alívio automatizado de vazamentos de espaço usando o mínimo de restrição.

Answer 11

Você claramente decidiu o valor da avaliação estrita, mas acho que está perdendo o objetivo de usar o Haskell. A avaliação preguiçosa de Haskell permite que estratégias de otimização muito mais flexíveis sejam empregadas pelo compilador/intérprete. Forçar sua própria rigidez substitui o otimizador. No final, o uso de avaliação estrita excessiva nunca será tão eficiente quanto a otimização automatizada. Experimente uma soma dobrável sobre uma sequência de números no GHCI, com e depois sem avaliação preguiçosa. Você pode ver a diferença com muita clareza - neste caso, a avaliação preguiçosa é sempre mais rápida.