Como um sistema de tipo estático afeta o design de uma linguagem baseada em protótipo?

O artigo da Wikipedia sobre idiomas baseados em protótipos contém o seguinte parágrafo:

Quase todos os sistemas baseados em protótipos são baseados em linguagens interpretadas e de tipo dinâmico. Sistemas baseados em linguagens estaticamente tipadas são tecnicamente viáveis, no entanto.

De que maneira um sistema de tipo estático impõe restrições ou introduz complexidade na linguagem baseada em protótipo e por que existem linguagens de protótipo mais dinamicamente tipadas?

A fronteira entre um tipo fundamental e um objeto é borrada e frequentemente introduzida artificialmente. Por exemplo, em C, uma estrutura é apenas um monte de registros, apenas um tipo não-objeto derivado. Em C ++, uma estrutura é uma classe com todos os campos públicos, um objeto. Ainda assim, C ++ é quase totalmente compatível com C ... a borda é realmente suave aqui.

Para programação baseada em protótipo, você precisa ter objetos mutáveis ​​em tempo de execução. Eles DEVEM ser digitados manualmente, porque cada um muda em tempo de execução, uma classe de um tipo muda para outra - seu tipo é alterado.

Você pode manter os tipos não-objetos fundamentais e derivados como estáticos. Mas isso introduz uma disparidade estranha, os objetos são de tipo suave, os não-objetos são de estática e um barier rígido deve ser estabelecido entre os dois. Você deve ser capaz de transformar uma estrutura? Uma linha? Number deve ser uma classe ou um tipo fundamental, ou um conjunto de tipos fundamentais, int / float / bignum / etc?

É apenas mais natural e fácil de aprender, usar e escrever para ter esse uniforme, todos os tipos são mutáveis ​​ou nenhum tipo é mutável em tempo de execução. Se você declarar que apenas um tipo (Objeto) é mutável, você terá dores de cabeça e problemas nos dois mundos.

O tipo estático é:

• mais fácil de implementar
• mais rápido / mais eficiente
• mais segura
• mais fácil de manter / documentar grandes sistemas devido à abstração.

O tipo dinâmico é:

• mais rápido para escrever,
• mais conciso
• idioma mais fácil de aprender
• mais tolerante por erros de design.

Ao misturar os dois, você sacrifica muito.

• A implementação se torna mais difícil do que qualquer uma das duas anteriores.
• a velocidade depende se você usa os tipos flexíveis ou não ... Se você usa, é baixo, se não usa, por que escolher o idioma?
• A segurança de tipos está fora da janela para todos os tipos de objetos.
• seguir como um tipo se transforma em outro é uma tarefa bastante difícil. Documentando - muito difícil.
• Você ainda precisa fazer toda a contabilidade com tipos fundamentais, o que reduz a concisão e a velocidade de gravação
• A complexidade do idioma é maior (mais difícil de aprender) do que qualquer um dos "específicos",
• o "perdão" de um tipo dinâmico é substituído pela tendência a alguns erros muito complicados em tipos de atributos incompatíveis.

A dificuldade é bem simples de se ver: Tendo em vista os objetos como dicionários de métodos ou como coisas que respondem a mensagens, observe o seguinte sobre linguagens OO comuns de tipo estatístico:

• Todas as chaves / mensagens do dicionário geralmente são declaradas com antecedência, usando identificadores declarados estaticamente.

• Certos conjuntos de mensagens são declarados com antecedência e objetos são associados a esses conjuntos para determinar a quais mensagens eles respondem.

• Os relacionamentos de inclusão de um conjunto de mensagens sendo um subconjunto de outro são declarados estaticamente e explicitamente; não declarado, mas os subconjuntos lógicos não são válidos.

• A verificação de tipo tenta garantir que todas as mensagens sejam enviadas apenas aos objetos que respondem a elas.

Cada um desses conflitos, em certa medida, com um sistema baseado em protótipo:

• Os nomes das mensagens podem ser declarados antecipadamente, na forma de "átomos", seqüências de caracteres internas ou outros enfeites, mas pouco mais; a plasticidade dos objetos significa que atribuir tipos a métodos é estranho.

• É indiscutivelmente o recurso essencial de um sistema baseado em protótipo que define os conjuntos de mensagens pelo que um objeto responde, e não o contrário. Seria razoável atribuir aliases a combinações específicas em tempo de compilação, mas os conjuntos de mensagens determinados em tempo de execução devem ser possíveis.

• O impacto real dos dois itens acima atinge os relacionamentos de inclusão, nos quais declarações explícitas são completamente impraticáveis. A herança no sentido estático de subtipo nominal é antitética a um sistema baseado em protótipo.

O que nos leva ao ponto final, que na verdade não queremos mudar. Ainda gostaríamos de garantir que as mensagens sejam enviadas apenas aos objetos que respondem a elas. Contudo:

• Não podemos saber estaticamente quais mensagens podem ser agrupadas.
• Não podemos saber quais agrupamentos são subconjuntos de outros.
• Não podemos saber quais agrupamentos são possíveis.
• Não podemos nem especificar que tipo de argumentos são enviados junto com uma única mensagem.
• Basicamente, descobrimos que não podemos especificar muita coisa no caso totalmente geral.

Então, como isso pode ser resolvido? Limite a generalidade total de alguma forma (o que é desagradável e pode rapidamente eliminar todos os benefícios do uso de um sistema baseado em protótipo) ou torne o sistema de tipos muito mais fluido e expresse restrições em vez de tipos exatos .

O sistema de tipos baseado em restrições rapidamente leva à noção de subtipagem estrutural , que em um sentido muito amplo pode ser considerada o equivalente estático da "tipagem de pato". Os maiores obstáculos aqui são que esses sistemas são muito mais complicados de digitar cheques e são menos conhecidos (o que significa pouco trabalho prévio para estudar).

Em resumo: é possível, é mais difícil de fazer do que um sistema de tipo estático nominal ou um sistema dinâmico baseado em metadados de tempo de execução e, portanto, poucas pessoas se incomodam.

Acredito que uma maneira de obter uma linguagem baseada em protótipo e com estaticamente seria basear a linguagem em modelos e conceitos.

Os conceitos já foram um recurso planejado para C ++ 0x. O código genérico nos modelos C ++ já é de fato "estaticamente tipado por pato". A idéia de Conceitos é poder dizer algumas coisas sobre membros necessários e características de tipos, sem exigir ou implicar um modelo de herança de classe subjacente a esse relacionamento (porque ele teve que trabalhar com o código de modelo existente que já era "estaticamente tipado" )

Em uma linguagem baseada em modelos e conceitos, os conceitos seriam baseados em protótipos, e os modelos o libertariam de se preocupar com qualquer modelo de classe que possa ou não ser usado para implementar os tipos de valores.

Além dos truques de usar a compilação faseada para permitir que a linguagem seja sua própria meta-linguagem, essas derivações prototípicas de Conceitos seriam necessariamente imutáveis ​​uma vez criadas. No entanto, a objeção de que isso não é baseado em protótipo é um arenque vermelho. Seria simplesmente uma linguagem funcional. Uma linguagem dinâmica de base de protótipo que também é funcional pelo menos foi tentada .