Every compiler passes code through several stages, each a sort of mini- compiler of its own. Thus each stage may deal with the code in a different representation, which may have little to do with the source or target language. We can describe these in-memory representations as languages in their own right, which we call intermediate languages. Each intermediate language is designed to accomodate the stage of compilation that handles it. Those toward the end of the compilation pipeline, for instance, tend to have features expressing low-level details of computation. A subtler case is that of the optimization stage, whose role is to transform the program so that it runs faster, uses less memory, and so forth. The optimizer faces tradeoffs: The language should provide enough information to guide optimization algorithms, but all of this information must be kept up to date as the program is transformed. Also, establishing invariants in the language can be helpful both in implementing algorithms and in debugging the implementation, but each invariant may complicate desirable transformations or rule them out altogether. Finally, a ivlanguage where the invariants are obviously correct may have a form too awkward or otherwise unsuited to the compiler’s needs. Given the properties and invariants that we would like the language to provide, we can approach the design task in a way that gives these features without necessarily sacrificing implementability. Namely, begin with a formal language that makes the desired properties obvious, then translate it to one more suitable for implementation. We can even translate theorems about valid transformations in the formal language to derive correct algorithms in the implementation language. This dissertation explores the connections between different intermediate languages and how they can be interderived, then demonstrates how translation lead to an improvement to the Glasgow Haskell Compiler opimization engine. This dissertation includes previously published coauthored material.

Made available in DSpace on 2014-06-12T15:57:39Z (GMT). No. of bitstreams: 2 arquivo3216_1.pdf: 6659432 bytes, checksum: 29ec979f8895b39460684d09a38f9764 (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2010 / Coordenação de Aperfeiçoamento de Pessoal de Nível Superior / Diferentes linguagens de programação disponibilizam diferentes formas de se implementar uma funcionalidade. Por exemplo, acessar um banco de dados usando C++ ou Python podem ser duas tarefas completamente diferentes. Por outro lado, com o surgimento da Plataforma .NET o acesso a dados com C++ .NET ou IronPython, por exemplo, se tornaram atividades muito parecidas tendo apenas algumas diferenças sintáticas. A Plataforma .NET é distribuída com um conjunto padrão de compiladores para diferentes linguagens como C#, Visual Basic .NET, JScript e J#, todas são orientadas a objetos. Com isso podemos notar uma maior atenção comercial dada ao paradigma de orientação a objetos. No entanto, esse dado não significa que devamos concluir que outros paradigmas não possam ser suportados, pelo contrário e a criação da linguagem F# é um exemplo de que a Plataforma .NET pode dar suporte a diversos paradigmas. Haskell é uma linguagem puramente funcional, não-estrita e fortemente tipada. E por ser uma linguagem de alto poder de expressão e não permitir efeitos colaterais durante sua execução, um programa escrito em Haskell se torna mais fácil de testar, otimizar e paralelizar. No entanto há um grande vazio quando tocamos na questão de ferramentas e APIs para Haskell. Devido ao fato de desenvolvedores usarem uma grande gama de ferramentas e tecnologias, cada qual com diferentes funcionalidades e tipos, tem sido historicamente difícil garantir a interoperabilidade entre as linguagens. No entanto, os compiladores e ferramentas que tem como alvo máquinas virtuais como a Plataforma .NET tiram proveito do suporte a interoperabilidade entre linguagens inerente a esses tipos de sistemas. O presente trabalho propõe um novo esquema de compilação de Haskell para a Plataforma .NET utilizando F# como linguagem intermediária. Tal abordagem nos livra dos inúmeros problemas que a geração de código diretamente para MSIL pode trazer, possibilitando irmos um pouco mais além na questão da interoperabilidade

This paper presents a concurrent interpreter for a general-purpose concurrent logic programming language, Guarded Horn Clauses (GHC). Unlike typical implementations of GHC in logic programming languages, the interpreter is implemented in the Actor language Acore. The primary motivation for this work was to probe the strengths and weaknesses of Acore as a platform for developing sophisticated programs. The GHC interpreter provided a rich testbed for exploring Actor programming methodology. The interpreter is a pedagogical investigation of the mapping of GHC constructs onto the Actor model. Since we opted for simplicity over optimization, the interpreter is somewhat inefficient.