Alguns comentários soltos
Voltando a estudar e praticar Haskell, o que me fez voltar a ler sobre mônadas. Uma coisa que eu ainda não tinha entendido direito é que, apesar da aparência imperativa da notação usando
E por falar em Haskell, é interessante ver como DSLs como Fran (ou outras que utilizam a idéia da reatividade funcional) são expressivas e só são possíveis em Haskell. Elas utilizam exatamente o conjunto que distingue a linguagem: avaliação preguiçosa, type classes e mônadas.
Sim, também tenho lido sobre uso de código carregado dinamicamente em uma linguagem com verificação estática de tipos (Haskell, novamente), um interesse antigo pois tem tudo a ver com sistemas distribuídos e código móvel. O hs-plugins faz o possível mas algumas coisas ainda são impossíveis, e talvez menos flexíveis do que deveriam. Por exemplo, uma aplicação que tenha plugins deve definir a priori as interfaces que os plugins devem obedecer, algo similar aos pontos de extensão da plataforma Eclipse. Por que não ter plugins que não necessariamente sigam (ou nao estritamente) a API delimitada pela aplicação? O maior problema é, como verificar os tipos de um plugin arbitrário, o que já é significantemente difícil no cenário com uma interface definida. Uma idéia poderia ser usar proof-carrying code para isso, de fato um uso talvez simplório, mas realizável, da idéia. É uma das coisas que eu espero investigar em breve. E Typed Assembly Language é o futuro.
do
, um valor envolto em uma mônada é apenas um valor, não é a execução da ação em si. Algo tem que executar as ações. Minha intenção em estudar mônadas é entender suas relações com sistemas de tipos e efeitos, o que leva a regiões para gerenciamento de memória.E por falar em Haskell, é interessante ver como DSLs como Fran (ou outras que utilizam a idéia da reatividade funcional) são expressivas e só são possíveis em Haskell. Elas utilizam exatamente o conjunto que distingue a linguagem: avaliação preguiçosa, type classes e mônadas.
Sim, também tenho lido sobre uso de código carregado dinamicamente em uma linguagem com verificação estática de tipos (Haskell, novamente), um interesse antigo pois tem tudo a ver com sistemas distribuídos e código móvel. O hs-plugins faz o possível mas algumas coisas ainda são impossíveis, e talvez menos flexíveis do que deveriam. Por exemplo, uma aplicação que tenha plugins deve definir a priori as interfaces que os plugins devem obedecer, algo similar aos pontos de extensão da plataforma Eclipse. Por que não ter plugins que não necessariamente sigam (ou nao estritamente) a API delimitada pela aplicação? O maior problema é, como verificar os tipos de um plugin arbitrário, o que já é significantemente difícil no cenário com uma interface definida. Uma idéia poderia ser usar proof-carrying code para isso, de fato um uso talvez simplório, mas realizável, da idéia. É uma das coisas que eu espero investigar em breve. E Typed Assembly Language é o futuro.
0 Comments:
Post a Comment
<< Home