Jest to część serii pytań, które koncentrują się na projekcie o nazwie Projekt abstrakcji, którego celem jest wyodrębnienie pojęć używanych w projektowaniu języka w formie frameworka.
Kolejną związaną z tym stronę związaną z typowaniem strukturalnym można obejrzeć tutaj . Meta-temat związany z zapytaniem dotyczącym frameworka i odpowiedniego miejsca do opublikowania można znaleźć tutaj .
Jak łatwo powinno być korzystać z ram rozwoju języka?
Napisałem frameworki do generowania kodu na dużą skalę, które zawierały również możliwość wysłania wyniku do kompilatora specyficznego dla języka. Temat łatwości użycia pochodzi z jednego z takich ramowych przykładów: CodeDOM lub Code Document Object Model.
Jest to framework napisany przez Microsoft, który opisuje typowe struktury kodu, ale generalnie pozostawiał wiele (koercje wyrażeń) i miał tendencję do nieco abstrakcyjnej reprezentacji niektórych konstrukcji, do wręcz emitowania złego kodu w oparciu o to, co robiłeś: wcześniej CodeDOM słabo emitujący obsługiwane PrivateImplementationTypena CodeMemberMethodprzy typu użyto ogólnego interfejsu. CodeDOM był moim pierwotnym powodem do napisania mojego pierwszego generatora kodu.
Jedną rzeczą, którą próbuję zrobić, aby uprościć strukturę, jest zmniejszenie ilości pracy, którą musisz zrobić, i skupienie się na działaniach w porównaniu do konkretnych typów, które składają się na te działania.
Oto porównanie obok tego, jak działa framework, który piszę:
//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));
Kontra 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));
Głównym celem frameworka są entuzjaści języków, a także osoby zainteresowane generowaniem kodu lub aplikacji. Biorąc pod uwagę skupienie się na kompilacji, generowaniu kodu i rozwoju języka, czy ramy powinny skupiać się na łatwości użycia lub czystej mocy?
Moim głównym celem jest zwiększenie dostępności takich narzędzi, aby osoby zainteresowane domeną nie wymagały dużego doświadczenia w dziedzinie teorii języków, zanim będą mogły rozpocząć pracę nad własnymi projektami zorientowanymi na język.
Biorąc pod uwagę, że jestem autorem frameworka, mój pogląd na „użyteczność” jest stronniczy. Dlatego muszę zapytać kogoś innego, czy koncentracja i cel mają sens dla osób niezwiązanych z projektem.
źródło
Odpowiedzi:
Trudno jest zbudować ramy rozwoju języka. Musisz zdecydować, jakie rzeczy chcesz wspierać, a następnie zdecydować, które z nich wiesz, jak to zrobić i jak zintegrować je ze sobą w spójną całość. Wreszcie, masz wystarczająco dużo inwestycji, więc działa z prawdziwymi językami (np. Typowymi językami komputerowymi oraz DSL) i faktycznie robi coś pożytecznego. Mój kapelusz jest dla ciebie za próbę.
Możesz porównać swój wysiłek z tym, który zacząłem 15 lat temu, DMS Software Reengineering Toolkit . DMS ma na celu zapewnienie parsowania, analizy i transformacji kodu ogólnego przeznaczenia. Biorąc pod uwagę wyraźną specyfikację języka, będzie analizował kod, budował AST, regenerował kod z AST (ładny odcisk), przekształcał kod za pomocą wzorców zapisanych w docelowym języku programowania, budował tablice symboli, sterował obliczeniami i przepływem danych itp. Dodając niestandardowy kod, jeden sprawia, że DMS wywołuje szeroką gamę efektów. (Zobacz narzędzia na stronie; wszystkie są DMS w takiej czy innej formie).
Oto dokument techniczny na temat DMS, tak jak kilka lat temu. (Ciągle go ulepszamy)
Chociaż sam DMS był trudny do zbudowania, okazało się, że zdefiniowanie prawdziwych języków do DMS wymagało odpowiednio dużego kawałka inżynierii, w tym IBM COBOL, C # 4.0, Java 1.7, C ++ 11 (i wielu innych).
To, co naszym zdaniem robi (dość dobrze): obniżenie kosztów budowy narzędzi o 1-2 rzędy wielkości. Oznacza to, że zadania, które w innym przypadku mogłyby zająć 1-10 lat, mogą być rozważani przez zwykłych śmiertelników jako projekty trwające 1 miesiąc-1 rok. Co wciąż nie jest łatwe:
Jest więc dużo miejsca na ulepszenia. Niech kwitnie wiele kwiatów.
źródło
Na to pytanie można było odpowiedzieć w The Mythical Man Month, w sekcji „Conceptual Integrity”. Jeśli nie, jest to co najmniej bardzo istotne dla twojego pytania. Chociaż Brooks opisuje architekturę całego systemu komputerowego, esej doskonale pasuje do frameworków i nowych języków.
Uważam, że istnieje pozytywna korelacja między tempem wdrożenia dowolnej technologii a jej integralnością koncepcyjną i łatwością użycia. Powinno być studium przypadku najnowszych technologii, takich jak języki, frameworki i systemy operacyjne, aby udowodnić tę korelację, ale jeszcze o niej nie wiemy.
źródło