Isso faz parte de uma série de perguntas que se concentra em um projeto chamado Abstraction Project, que visa abstrair os conceitos usados no design de linguagem na forma de uma estrutura.
Outra página associada a ela relacionada à tipagem estrutural pode ser vista aqui . O meta-tópico associado a uma consulta sobre a estrutura e o local apropriado para publicação pode ser encontrado aqui .
Quão fácil deve ser usar um Framework de Desenvolvimento de Linguagem?
Escrevi estruturas de geração de código em larga escala que também incluíam a capacidade de enviar o resultado ao compilador específico do idioma. O tópico da facilidade de uso surge de um exemplo de estrutura: CodeDOM, ou o Code Document Object Model.
É uma estrutura escrita pela Microsoft que descreve estruturas de código comuns, mas geralmente deixa muito de fora (coerção de expressão) e tende a ser um pouco abstrata na representação de certas construções, emitindo códigos ruins com base no que você estava fazendo: anteriormente CodeDOM mal tratada emitindo PrivateImplementationTypeem CodeMemberMethod, quando o tipo utilizado foi uma interface genérica. O CodeDOM foi minha razão original para escrever meu primeiro gerador de código.
Uma coisa que estou tentando fazer, para simplificar a estrutura, é reduzir a quantidade de trabalho que você precisa para fazer alguma coisa e se concentrar nas ações versus os tipos específicos que compõem essas ações.
Aqui está uma comparação lado a lado de como a estrutura que estou escrevendo funciona:
//Truncated...
/* *
* From a project that generates a lexer, this is the
* state->state transition character range selection logic.
* */
var nextChar = nextMethod.Parameters.Add(new TypedName("currentChar", typeof(char).GetTypeReference()));
//...
char start = rangeElement.B.Value.Start;
char end = rangeElement.B.Value.End;
/* *
* 'start' <= nextChar && nextChar <= 'end'
* */
currentExpression = start.LessThanOrEqualTo(nextChar).LogicalAnd(nextChar.LessThanOrEqualTo(end));
Versus CodeDOM:
//Truncated...
var nextChar = new CodeVariableReferenceExpression("nextChar");
//...
var start = new CodePrimitiveExpression(rangeElement.B.Value.Start);
var end = new CodePrimitiveExpression(rangeElement.B.Value.End);
currentExpression = new CodeBinaryOperatorExpression(new CodeBinaryOperatorExpression(start, CodeBinaryOperatorType.LessThanOrEqual, nextChar), CodeBinaryOperatorType.BooleanAnd, new CodeBinaryOperatorExpression(nextChar, CodeBinaryOperatorType.LessThanOrEqual, end));
O foco da estrutura são os entusiastas da linguagem, bem como aqueles interessados em gerar código ou aplicativos. Dado seu foco na compilação, geração de código e desenvolvimento de linguagem, a estrutura deve se concentrar na facilidade de uso ou no poder bruto?
Meu principal objetivo é aumentar a disponibilidade dessas ferramentas, para que os interessados no domínio não exijam muita experiência no domínio da teoria da linguagem antes de começarem a trabalhar em seus próprios projetos centrados na linguagem.
Dado que sou o autor do framework, minha visão de "usabilidade" é tendenciosa. Portanto, devo perguntar a outro se o foco e a meta fazem sentido para outras pessoas que não estão associadas ao projeto.
fonte
Respostas:
É difícil criar uma estrutura de desenvolvimento de linguagem. Você precisa decidir que tipo de coisas deseja apoiar e, em seguida, decidir quais daquelas que você sabe fazer e como integrá-las em um todo coerente. Por fim, você fez um investimento suficiente para funcionar com linguagens reais (por exemplo, linguagens típicas de computador e DSLs) e, na verdade, faz algo útil. Meu chapéu está fora de você por tentar.
Você pode comparar seu esforço com o que iniciei há 15 anos, o DMS Software Reengineering Toolkit . O DMS destina-se a fornecer análise, análise e transformação de código de uso geral. Dada uma especificação explícita de linguagem, ele analisará o código, criará ASTs, regenerará o código de ASTs (prettyprint), transformará o código usando padrões escritos na linguagem de programação de destino, criará tabelas de símbolos, computará o controle e o fluxo de dados etc. um faz com que o DMS realize uma ampla variedade de efeitos. (Veja as ferramentas no site; todas elas são DMS de uma forma ou de outra).
Aqui está um artigo técnico sobre o DMS, como está há vários anos atrás. (Continuamos melhorando)
Embora o próprio DMS tenha sido difícil de construir, descobrimos que era necessário um pedaço de engenharia correspondente para definir langauges reais para o DMS, incluindo IBM COBOL, C # 4.0, Java 1.7, C ++ 11 (e muitos outros).
O que achamos que faz (razoavelmente bem): reduza o custo de construção de ferramentas em 1-2 ordens de magnitude. O que isso significa é que tarefas que, de outra forma, levariam de 1 a 10 anos, podem ser contempladas por meros mortais como projetos de 1 mês a 1 ano. O que ainda não é fácil:
Portanto, há muito espaço para melhorias. Deixe muitas flores florescerem.
fonte
Esta pergunta pode ter sido respondida no The Mythical Man Month, na seção "Integridade conceitual". Caso contrário, é pelo menos altamente relevante para sua pergunta. Embora Brooks descreva a arquitetura de um sistema de computação inteiro, o ensaio se aplica perfeitamente a estruturas e novas linguagens.
Acredito que exista uma correlação positiva entre a taxa de adoção de qualquer tecnologia e sua integridade conceitual e facilidade de uso. Deve haver um estudo de caso de tecnologias recentes, como linguagens, estruturas e sistemas operacionais, para provar essa correlação, mas ainda não sabemos nada sobre isso.
fonte