Mudanças entre as edições de "Turing Clube/Oficina de Linguagens de Programação"

De Garoa Hacker Clube
Ir para navegação Ir para pesquisar
Linha 17: Linha 17:
 
{|
 
{|
 
!1
 
!1
!Pascal
+
|'''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
+
|'''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
+
|'''APL'''
 
|Manipulação de estruturas de dados agregadas.
 
|Manipulação de estruturas de dados agregadas.
 
|-
 
|-
 
!4
 
!4
!Scheme
+
|'''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).