Melhor maneira de lidar com a interoperabilidade de linguagens

5

Antecedentes

Em uma linguagem como o F #, a interoperabilidade direta com a maioria das outras linguagens .NET é possível. Por exemplo, é possível usar classes escritas em C # diretamente em F #, e é possível chamar o código F # diretamente do C #.

Em F #, os módulos são compilados em instruções CIL correspondentes a classes estáticas, ADTs a uma hierarquia de classes (classe abstrata + subclasses) e assim por diante. Isso facilita a interoperabilidade, mas coloca algumas limitações nos recursos de linguagem.

Por exemplo, o F # não suporta módulos de ordem superior como o OCaml e o SML (ou um mecanismo 'similar' como typeclasses ou similares). Se isso é crucial ou não é subjetivo, mas limita as opções para escrever código polimórfico (sem usar as partes OO da linguagem).

Interoperabilidade através de alguma interface

Naturalmente, uma alternativa não é ignorar as preocupações de interoperabilidade na parte principal da linguagem e fazer alguma interface de interoperabilidade específica. Isso pode ser unidirecional ou bidirecional.

Por exemplo, em um idioma como o F #, um design alternativo poderia ter sido algo como:

  • Deixe F # usar classes C # diretamente, como hoje. Desta forma, usando bibliotecas .NET ainda é fácil.
  • Ignora a capacidade do C # de acessar o código F # funcional diretamente. Isso removeria algumas limitações que atualmente são impostas ao design de linguagem - poderíamos, dessa forma, suportar facilmente um sistema de tipos mais strong, com módulos de ordem superior ou typeclasses, etc.
  • Deixe o C # acessar as partes OO do F # diretamente. Portanto, se você deseja permitir que nossas bibliotecas F # sejam acessíveis a partir de C #, teríamos que colocá-las em um wrapper OO thin'ish.

Isso exigiria um pouco mais de trabalho em alguns casos, mas, na minha experiência, provavelmente esperaria que a maioria das pessoas projetasse um wrapper OO, se uma biblioteca F # fosse usada em C #.

No caso de uma biblioteca F # não ter um wrapper OO, ainda seria possível fazer uma você mesmo (em F # obviamente).

No caso mais extremo, essa interface poderia ser bidirecional, de tal forma que o F # só poderia acessar classes .NET através de alguma interface - mas provavelmente haveria pouca razão para impor tal restrição neste caso. Mas para outras linguagens, pode ser uma opção - se, por exemplo, você quisesse escrever uma linguagem pura ou algo assim.

A pergunta atual: Prós e contras

  • Quais são os prós e contras de cada uma dessas abordagens?
  • Seria tecnicamente inviável ou impraticável?
  • Seria impossível para o C # interoperar com um assembly que está "usando indevidamente" o CLR ou algo assim? (note que a questão não é específica do .NET, e você pode também basear sua resposta em linguagens da JVM como Scala, ou o que você sabe melhor)
  • Há algum idioma que tenha usado a abordagem infundada? (em um nível mais alto, como o .NET para o .NET, e não apenas idiomas com uma FFI para um código de baixo nível ou algo semelhante)
por nilu 10.10.2014 / 18:25
fonte

1 resposta

1

Um dos problemas é programar para um modelo. A outra questão é programar para uma máquina. Assim, você pode programar para um modelo e criar uma compilação intermediária que mantenha qualquer tipo de recurso especial. O intermediário precisa ser algo que programe uma máquina. Pode haver código extra dado bibliotecas de suporte que fornecem compatibilidade para expandir a compreensão das máquinas ou para fazer downgrade do que o código executa.

Ignorar o código funcional do C # não melhora o F #. Atualmente, o F # está modelando em um estilo semelhante ao Ocaml (mas para um ecossistema .Net) com aprimoramentos e é mais uma situação do F # que trabalha com o tempo de execução e o sistema de tipos. Se você expandir o que pode ser expresso por esse tempo de execução, toda linguagem pode se beneficiar.

Como os delegados são projetados como as classes de um método que são usadas para incorporar unidades de execução, coisas como funções lambda em C # já são thinly wrapped. F # faz uma coisa semelhante com módulos como classes com métodos estáticos. Tudo isso é de graça.

Não é inviável cortar um idioma do outro. É impraticável tornar as linguagens mais difíceis de interoperar. As razões são muitos objetivos são estender e melhorar o tempo de execução para permitir mais idiomas e incentivar o uso de biblioteca cruzada. Particularmente com o C #, ele não está limitado em qual biblioteca ele pode chamar se puder consumir valores expostos e sensíveis em seu sistema de tipos. O código pode ser inseguro e pode ser marcado como tal. Ele poderia (possivelmente por alguma característica futura) marcar o código como avançado para permitir que ele faça mais que possa ser feito em IL.

O problema de gerenciar a base de código para as verificações para suportar os recursos extras no compilador e nos geradores é detalhar alguns padrões de código úteis encontrados. Então, se você é genérico em type, então o compilador geraria versões para cada tipo de todo tipo que é uma possibilidade resolvível ou uma base de gerador de jateamento preguiçoso em uso. Então você vai pensar sobre o que garante que um tipo é considerado? É apenas uma pesquisa de tabela para usos ou escopos incluídos?

A resposta fácil é tempo e desejo. Como a influência externa exprime suas várias opiniões sobre assuntos e tempo, atribui-se a essas questões, chama a atenção dos autores primários para considerar as opções. O site usersvoice ajuda. Eu mesmo tenho interesse em macros higiênicas para expandir além do que e como eu escrevo código. Obrigado. Bom dia.

    
por 01.10.2016 / 05:35
fonte