Please use this identifier to cite or link to this item:
http://hdl.handle.net/1843/ESBF-935NQ7Full metadata record
| DC Field | Value | Language |
|---|---|---|
| dc.contributor.advisor1 | Carlos Camarao de Figueiredo | pt_BR |
| dc.contributor.referee1 | Fernando Magno Quintao Pereira | pt_BR |
| dc.contributor.referee2 | Mariza Andrade da Silva Bigonha | pt_BR |
| dc.contributor.referee3 | Andre Luís de Medeiros Santos | pt_BR |
| dc.contributor.referee4 | Lucilia Camarão de Figueiredo | pt_BR |
| dc.creator | Marco Túlio Gontijo e Silva | pt_BR |
| dc.date.accessioned | 2019-08-14T05:28:24Z | - |
| dc.date.available | 2019-08-14T05:28:24Z | - |
| dc.date.issued | 2012-12-20 | pt_BR |
| dc.identifier.uri | http://hdl.handle.net/1843/ESBF-935NQ7 | - |
| dc.description.abstract | The Haskell module system aims for simplicity and has a notableadvantage of being easy to learn and use. However, type classinstances in Haskell are always exported and imported betweenmodules. This breaches uniformity and simplicity of the module systemand introduces practical problems. instances created in different modules can conflict with each other, and can make it impossible to import two modules that contain instance definitions if this instance is used. Because of this, it is not very incovenient to define two distinct instances of the same type class for the same type in a program. As a workaround for this problem, the definition of instances in modules where the data type or the type class are not defined became a bad practice, and these instances were called orphans. Only these instances can cause the conflict since, as non-orphan instances are defined in the same module of the type or of the type class, there will be only one instance for each class and each type. In this dissertation we present and discuss a solution to these problems that simply allows control over importation and exportation of instances between modules, through a small change in the language. The solution is presented in two versions. The final version, more consistent, is not compatible with Haskell, that is, programs that work on Haskell may not work with this change. The intermediate version, on the other hand, brings the benefits of the proposal while being compatible with Haskell, although it is less consistent. In order to avoid that the programmer needs to write very long names for the instances in the importation and exportation control lists on modules, we propose another small change in the language in which it is possible to give shorter names to instances. We also show how a formal specification of the module system must be adapted to include our proposal. As the formal specification didn't handle instances in general, we adapt this specification to handle instances at first, and then show how our proposal can be formally specified. | pt_BR |
| dc.description.resumo | O sistema de módulos de Haskell objetiva a simplicidade e possui a notável vantagem de ser fácil de aprender e usar. Entretanto, instâncias de classes de tipo em Haskell são sempre exportadas e importadas entre módulos. Isso quebra a uniformidade e simplicidade do sistema de módulos e introduz problemas práticos. Instâncias criadas em módulos diferentes podem conflitar umas com as outras e podem fazer com que seja impossível importar dois módulos que contenham definições de uma mesma instância se essa instância for utilizada. Isso faz com que seja muito incoveniente a definição de duas instâncias diferentes da mesma classe de tipos para o mesmo tipo em diferentes módulos de um mesmo programa. A definição de instâncias em módulos onde nem o tipo nem a classe de tipos são definidos se tornou uma má prática, e essas instâncias foram chamadas de instâncias órfãs. Somente esse tipo de instância pode causar conflitos já que, se instâncias forem definidas apenas no mesmo módulo do tipo ou da classe de tipos, só poderá existir uma instância para cada par de classe e tipo. Nessa dissertação nós apresentamos e discutimos uma solução para esses problemas que simplesmente permite que haja controle sobre a importação e exportação de instâncias entre módulos, por meio de uma pequena alteração na linguagem. A solução é apresentada em duas versões. A versão final, mais consistente, não é compatível comHaskell, isto é, programas que funcionam em Haskell podem deixar de funcionar com essa alteração. A versão intermediária traz os benefícios da proposta, é compatível com Haskell, mas é um pouco menos consistente. Para evitar que o programador precise escrever nomes de instâncias muito longos nas listas de controle de importação eexportação de módulos, propomos outra pequena alteração na linguagem, que torna possível dar nomes mais curtos a instâncias.Também mostramos como a especificação formal do sistema de módulos precisa ser adaptada para lidar com nossa proposta. Como a especificação formal não tratava instâncias, primeiro adaptamos essa especificação para tratar instâncias e, em seguida, mostramos como nossa proposta é especificada formalmente. | pt_BR |
| dc.language | Português | pt_BR |
| dc.publisher | Universidade Federal de Minas Gerais | pt_BR |
| dc.publisher.initials | UFMG | pt_BR |
| dc.rights | Acesso Aberto | pt_BR |
| dc.subject | Módulos | pt_BR |
| dc.subject | Haskell | pt_BR |
| dc.subject | Instâncias de classes de tipo | pt_BR |
| dc.subject.other | Haskell (Linguagem de programação de computador) | pt_BR |
| dc.subject.other | Computação | pt_BR |
| dc.title | Controlando o escopo de instâncias em Haskell | pt_BR |
| dc.type | Dissertação de Mestrado | pt_BR |
| Appears in Collections: | Dissertações de Mestrado | |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| marcotuliogontijo.pdf | 3.01 MB | Adobe PDF | View/Open |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.