Mudanças entre as edições de "Turing Clube/Oficina de Linguagens de Programação"
Linha 17: | Linha 17: | ||
{| |
{| |
||
!1 |
!1 |
||
− | + | |'''Pascal''' |
|
|Declarações de funções separadas do corpo principal do programa. Closures são desnecessárias (como em C). |
|Declarações de funções separadas do corpo principal do programa. Closures são desnecessárias (como em C). |
||
|- |
|- |
||
!2 |
!2 |
||
− | + | |'''Lisp''' |
|
|Declarações de funções no corpo do programa. Não há closures porque o escopo é dinâmico. |
|Declarações de funções no corpo do programa. Não há closures porque o escopo é dinâmico. |
||
|- |
|- |
||
!3 |
!3 |
||
− | + | |'''APL''' |
|
|Manipulação de estruturas de dados agregadas. |
|Manipulação de estruturas de dados agregadas. |
||
|- |
|- |
||
!4 |
!4 |
||
− | + | |'''Scheme''' |
|
|Funções anônimas e escopo léxico obrigam a implementação de closures. |
|Funções anônimas e escopo léxico obrigam a implementação de closures. |
||
+ | |- |
||
+ | !5 |
||
+ | |'''SASL''' |
||
+ | |''Lazy evaluation'': o interpretador adia até o último momento possível a computação das expressões (como em Haskell). |
||
+ | |- |
||
+ | !6 |
||
+ | |'''CLU''' |
||
+ | |Abstração de dados através de encapsulamento e funções (ou "métodos") agrupadas em ''clusters'' (como tipos em Go). |
||
+ | |- |
||
+ | !7 |
||
+ | |'''Smalltalk''' |
||
+ | |Polimorfismo através da sobrecarga de métodos; herança. |
||
+ | |- |
||
+ | !8 |
||
+ | |'''Prolog''' |
||
+ | |Programação através de cláusulas de Horn, uma forma de lógica de predicados de primeira ordem. |
||
|} |
|} |
||
Edição das 09h26min de 16 de novembro de 2018
Vamos estudar o funcionamento de linguagens de programação e praticar a construção de interpretadores e compiladores, desde o início. O único pré-requisito para participar é saber programar.
Estratégia
Nesta oficina vamos seguir a pedagogia introduzida por Samuel Kamin em seu livro PLIBA. Em vez de partir direto para a construção de um compilador, Kamin começa por interpretadores, que são mais fáceis de implementar. Em 8 capítulos, Kamin apresenta 8 interpretadores que implementam características fundamentais de linguagens procedurais, funcionais, orientadas a objeto, e lógicas.
As principais estratégias de Kamin são:
- Foco na simplicidade: os interpretadores foram escritos para serem fáceis de ler e modificar, sempre usam a sintaxe de s-expressions. O gerenciamento de memória fica para o final do livro.
- Foco na semântica: reduzindo todas as linguagens implementadas à sintaxe de s-expressions, as características essenciais das linguagens ficam mais evidentes. Por exemplo o capítulo 7 apresenta um interpretador de um sub-conjunto de Smalltalk com sintaxe de LISP. O que importa é que este interpretador permite criar programas organizados na forma de classes e métodos, ilustrando encapsulamento, polimorfismo, e herança.
Estrutura do PLIBA
Os capítulos de 1 a 8 implementam interpretadores para linguagens inspiradas nas seguintes linguagens:
You get
1 | Pascal | Declarações de funções separadas do corpo principal do programa. Closures são desnecessárias (como em C). |
---|---|---|
2 | Lisp | Declarações de funções no corpo do programa. Não há closures porque o escopo é dinâmico. |
3 | APL | Manipulação de estruturas de dados agregadas. |
4 | Scheme | Funções anônimas e escopo léxico obrigam a implementação de closures. |
5 | SASL | Lazy evaluation: o interpretador adia até o último momento possível a computação das expressões (como em Haskell). |
6 | CLU | Abstração de dados através de encapsulamento e funções (ou "métodos") agrupadas em clusters (como tipos em Go). |
7 | Smalltalk | Polimorfismo através da sobrecarga de métodos; herança. |
8 | Prolog | Programação através de cláusulas de Horn, uma forma de lógica de predicados de primeira ordem. |
O capítulo 9, Compilation apresenta a teoria de geração de código de máquina a partir da linguagens do capítulo 1 e 4 (Scheme), tendo como alvo uma linguagem de máquina hipotética.
O capítulo 10, Memory Management, aborda algumas estratégias para a coleta de lixo -- descarte de estruturas de dados que não serão mais usadas. Os interpretadores básicos não têm esse recurso, o que significa que ao longo da execução do programa o uso de memória só cresce, nunca diminui. Isso não afeta a semântica de cada linguagem, pois o reuso de memória pode ser considerado uma otimização. O interpretador original de LISP escrito por John McCarthy também não gerenciava a memória. O capítulo 10 apresenta as mudanças no interpretador LISP do capítulo 2 para fazer coleta de lixo.
Referências
- PLIBA
- S. Kamin, Programming Languages: An Interpreter-Based Approach, (Reading, Mass.: Addison-Wesley, 1990).