Linguagens interpretadas – aproveitando a linguagem compilada por trás do intérprete

Question

Se houver algum designer de linguagem por aí (ou pessoas simplesmente bem informadas), estou curioso sobre a metodologia por trás da criação de bibliotecas padrão para linguagens interpretadas.Especificamente, qual parece ser a melhor abordagem?Definir funções/métodos padrão na linguagem interpretada ou realizar o processamento dessas chamadas na linguagem compilada na qual o intérprete está escrito?

O que me fez pensar sobre isso foi a pergunta SO sobre uma função semelhante a stripslashes() em Python.Meu primeiro pensamento foi "por que não definir o seu próprio e chamá-lo quando precisar", mas levantou a questão:é preferível, para tal função, deixar a linguagem interpretada lidar com essa sobrecarga, ou seria melhor escrever uma extensão e aproveitar a linguagem compilada por trás do intérprete?

Answer 1

A linha entre linguagens "interpretadas" e "compiladas" é muito confusa atualmente.Por exemplo, a primeira coisa que o Python faz quando vê o código-fonte é compilá-lo em uma representação de bytecode, essencialmente o mesmo que o Java faz ao compilar arquivos de classe.Isto é o que os arquivos *.pyc contêm.Em seguida, o tempo de execução python executa o bytecode sem consultar a fonte original.Tradicionalmente, uma linguagem puramente interpretada consultaria continuamente o código-fonte durante a execução do programa.

Ao construir uma linguagem, é uma boa abordagem construir uma base sólida sobre a qual você possa implementar funções de nível superior.Se você possui um sistema de manipulação de strings sólido e rápido, o designer da linguagem pode (e deve) implementar algo como stripslashes() fora do tempo de execução base.Isso é feito por pelo menos alguns motivos:

• O designer da linguagem pode mostrar que a linguagem é flexível o suficiente para lidar com esse tipo de tarefa.
• O designer da linguagem realmente escreve código real na linguagem, que possui testes e, portanto, mostra que a base é sólida.
• Outras pessoas podem ler, pegar emprestado e até mesmo alterar funções de nível superior com mais facilidade, sem precisar construir ou mesmo compreender o núcleo da linguagem.

Só porque uma linguagem como Python compila em bytecode e executa, isso não significa que seja lenta.Não há razão para que alguém não possa escrever um compilador Just-In-Time (JIT) para Python, nos moldes do que Java e .NET já fazem, para aumentar ainda mais o desempenho.Na verdade, o IronPython compila o Python diretamente no bytecode .NET, que é então executado usando o sistema .NET incluindo o JIT.

Para responder diretamente à sua pergunta, a única vez que um designer de linguagem implementaria uma função na linguagem por trás do tempo de execução (por exemplo.C no caso do Python) seria maximizar o desempenho dessa função.É por isso que módulos como o analisador de expressões regulares são escritos em C em vez de Python nativo.Por outro lado, um módulo como getopt.py é implementado em Python puro porque tudo pode ser feito lá e não há benefício em usar a biblioteca C correspondente.

Answer 2

Há também uma tendência crescente de reimplementar linguagens que são tradicionalmente consideradas “interpretadas” em uma plataforma como JVM ou CLR – e então permitir fácil acesso ao código “nativo” para interoperabilidade.Portanto, a partir do Jython e do JRuby, você pode acessar facilmente o código Java, e do IronPython e do IronRuby, você pode acessar facilmente o código .NET.

Em casos como estes, a capacidade de “aproveitar a linguagem compilada por trás do intérprete” poderia ser descrita como o principal motivador para a nova implementação.

Answer 3

Consulte a seção 'Artigos' em www.lua.org.

Especialmente A implementação de Lua 5.0

Lua define todas as funções padrão no código subjacente (ANSI C).Acredito que isso seja principalmente por motivos de desempenho.Recentemente, ou sejaas funções 'string.*' obtiveram uma implementação alternativa em Lua pura, o que pode ser vital para subprojetos onde Lua é executada em .NET ou Java runtime (onde o código C não pode ser usado).

Answer 4

Contanto que você esteja usando uma API portátil para a base de código compilada como o Biblioteca padrão ANSI C ou STL em C++, aproveitar essas funções evitaria que você reinventasse a roda e provavelmente forneceria um interpretador menor e mais rápido. Lua adota essa abordagem e é definitivamente pequeno e rápido em comparação com muitos outros.