다른 프로그래밍 언어로 번역하기 쉽게 하기 위해 코드에 어떤 패턴을 적용할 수 있습니까?
저는 프로그래밍 언어 간에 코드를 번역하는 것을 목표로 하는 부업 프로젝트를 시작하려고 합니다.우선 PHP와 Python(Python에서 PHP로 시작하는 것이 더 쉬울 것)이지만, 이상적으로는 (상대적인) 다른 언어를 쉽게 추가할 수 있습니다.계획은 다음과 같습니다.
이것은 웹 개발에 맞춰져 있습니다.원래 코드와 타깃 코드는 프레임워크 위에 배치됩니다(이것도 작성해야 합니다).이러한 프레임워크는 MVC 설계 패턴을 수용하고 엄격한 코딩 규칙을 따릅니다.이렇게 하면 번역이 다소 쉬워집니다.
IOC와 의존성 주입도 검토하고 있습니다.번역 프로세스가 쉬워지고 오류가 적어질 수 있기 때문입니다.
Python의 파서 모듈을 사용하여 Abstract Syntax Tree를 조작할 수 있습니다.PHP에서 얻을 수 있는 가장 가까운 것은 token_get_all()이며, 이것이 시작이라고 합니다.
그 이후로는 AST, 심볼 테이블, 플로우를 제어할 수 있습니다.
그러면 코드를 출력할 수 있을 것 같아요.완벽한 번역은 필요 없어요.생성된 코드를 확인하고 문제를 해결해야 합니다.번역자는 문제가 있는 번역에 플래그를 붙이는 것이 이상적입니다.
"도대체 이게 무슨 의미가 있는 거야?"라고 묻기 전에정답은...재미있는 학습 경험이 될 거예요.이 문제를 덜 부담스럽게 만드는 방법에 대한 의견이 있으면 알려주세요.
편집:
번역하기 쉽게 하기 위해 코드에 적용할 수 있는 패턴의 종류를 알고 싶습니다(즉,IoC, SOA?) 변환 방법보다 더 중요한 코드입니다.
저는 1995년부터 컴퓨터 사이언티스트 팀의 지원을 받아 범용 프로그램 조작(언어 번역이 특수한 경우)을 하기 위한 툴(DMS Software Reengineering Toolkit)을 구축하고 있습니다.DMS는 범용 해석, AST 구축, 심볼 테이블, 제어 및 데이터 흐름 분석, 번역 규칙 적용, 코멘트를 포함한 소스 텍스트 재생성 등을 제공하며, 이 모든 것은 컴퓨터 언어의 명시적 정의에 의해 파라미터화됩니다.
이것을 잘 하기 위해서 필요한 머신의 양은 막대합니다(특히, 일반적인 방법으로 복수의 언어에 대응하고 싶은 경우).그 후, 신뢰할 수 없는 정의를 가지는 언어의 신뢰할 수 있는 파서가 필요합니다(PHP가 그 예입니다).
언어간 번역기를 만들거나 시도하는 것은 문제될 것이 없지만, 실제 언어에서는 생각보다 훨씬 큰 작업이 될 것이라고 생각합니다.DMS에만 약 100명이 투자되고, 각 "신뢰할 수 있는" 언어 정의(PHP를 위해 힘들게 구축한 언어 포함)에 6~12개월이 더 투자됩니다.C++와 같은 불쾌한 언어에 대해서는 훨씬 더 많은 시간이 투자됩니다.이것은 「학습 체험의 지옥」이 될 것입니다.그것은 저희에 대한 것입니다.(위 웹 사이트의 「기술 논문」섹션에서는, 그 학습을 곧바로 개시하는 것이 흥미로울지도 모릅니다.
사람들은 흔히 자신에게 익숙한 기술을 사용하여 일반화된 기계를 만들려고 시도합니다. 이 기술은 업무의 일부를 담당합니다.(Python AST가 좋은 예입니다).좋은 소식은 그 일이 끝났다는 거야나쁜 소식은 기계에는 수많은 가정들이 내재되어 있다는 것입니다. 그 대부분은 다른 일을 하도록 노력하기 전까지는 발견하지 못할 것입니다.그러면 기계가 원래 하던 일을 하도록 배선되어 있다는 것을 알게 되고, 다른 일을 시키려는 당신의 시도에 정말 저항하게 될 것입니다.(Phython AST를 PHP 모델로 만드는 것은 매우 재미있을 것 같습니다.)
원래 DMS를 구축하기 시작한 이유는 그러한 전제 조건을 거의 갖추지 않은 기반을 구축하기 위해서입니다.두통을 일으키는 것도 있어요.지금까지 블랙홀은 없었습니다. (지난 15년간 제 직업에서 가장 어려웠던 부분은 그러한 가정이 슬금슬금 들어오는 것을 막는 것입니다.)
또한 많은 사람들이 구문 분석(그리고 AST를 취득할 수 있다면)이 복잡한 일을 잘 하고 있다고 착각하고 있습니다.어려운 교훈 중 하나는 프로그램 분석 또는 변환을 제대로 수행하려면 기호 테이블과 흐름 분석이 필요하다는 것입니다.AST는 필요하지만 충분하지 않습니다.그래서 Aho & Ullman의 컴파일러 북은 2장에서 끝나지 않는다(AST를 넘어 추가 기계를 만들 예정이라는 점에서 OP는 이 권리를 가지고 있다).이 항목에 대한 자세한 내용은 구문 분석 후 수명을 참조하십시오.
"완벽한 번역은 필요 없다"는 말은 귀찮다.번역자가 약한 것은 코드의 80%를 쉽게 변환하고 20%는 수작업으로 변환하는 것입니다.변환하려는 애플리케이션이 매우 작고 한 번만 올바르게 변환하려는 경우 20%로 충분합니다.많은 응용 프로그램(또는 시간에 따라 사소한 변경이 있는 동일한 응용 프로그램이라도)을 변환하려면 이 방법을 사용하는 것이 좋습니다.10K SLOC를 변환하려고 하면 20%는 코드 원행 20,000줄로 번역, 이해 및 수정이 어렵습니다.이러한 코드 8만줄은 이미 이해하지 못하는 번역 프로그램입니다.그것은 엄청난 노력이 필요하다.100만 회선 수준에서 이것은 실제로는 불가능합니다.(놀랍게도 자동화 툴을 신뢰하지 않고 수작업으로 백만 개의 회선 시스템을 번역해야 한다고 주장하는 사람들이 있습니다.이는 더욱 어렵고 보통 오랜 지연, 높은 비용 및 종종 명백한 장애로 고통스럽게 발견됩니다.)
대규모 시스템을 번역하기 위해 필요한 것은 90%의 높은 변환률입니다.그렇지 않으면 번역 작업의 수동 부분을 완료할 수 없을 가능성이 높습니다.
또 하나의 중요한 고려사항은 번역할 코드의 크기입니다.뛰어난 툴을 사용하더라도 기능하고 견고한 번역기를 구축하기 위해서는 많은 에너지가 필요합니다.단순한 수동 변환이 아니라 번역기를 만드는 것이 매력적이고 멋지다고 생각되지만, 소규모 코드 베이스(예: 우리의 경험상 최대 10만 SLOC)의 경우 경제적으로는 타당하지 않습니다.아무도 이 대답을 좋아하지 않지만, 만약 당신이 정말로 10K SLOC의 코드를 번역해야 한다면, 당신은 참지 못하고 그것을 하는 것이 더 나을 것이다.네, 고통스럽죠
저는 저희 툴이 매우 좋다고 생각합니다(그렇다면 저는 상당히 편견이 있습니다).그리고 좋은 번역기를 만드는 것은 여전히 매우 어렵습니다. 우리는 약 1.5년에서 2년 정도 걸리고 도구 사용법을 알고 있습니다.차이점은 이렇게 많은 기계로 인해 실패하는 것보다 성공하는 경우가 훨씬 더 많다는 것입니다.
내 답변은 Ira가 답변에서 잘 설명한 높은 수준의 측면이 아니라 다른 언어로 번역하기 위해 Python을 해석하는 구체적인 작업을 다룰 것이다.
즉, 파서 모듈을 사용하지 마십시오. 더 쉬운 방법이 있습니다.
그ast이 모듈은 Python 2.6이 사용자의 요구에 훨씬 더 적합하기 때문에 사용할 수 있습니다. 왜냐하면 이 모듈은 바로 사용할 수 있는 AST를 제공하기 때문입니다.작년에 이런 기사를 쓴 적이 있는데 간단히 말하면parse의 방법astPython 소스 코드를 AST로 해석합니다.그parser모듈은 AST가 아닌 해석 트리를 제공합니다.그 차이를 조심하라.
Python의 AST는 매우 상세하기 때문에 AST를 사용하면 프런트 엔드의 작업은 그다지 어렵지 않습니다.일부 기능에 대한 간단한 프로토타입을 매우 빠르게 준비할 수 있을 것입니다.그러나, 완전한 해결책에 도달하는 데는 시간이 더 걸릴 것입니다. 왜냐하면 주로 언어의 의미가 다르기 때문입니다.언어의 간단한 서브셋(기능, 기본형 등)은 쉽게 번역할 수 있지만, 보다 복잡한 레이어에 들어가면 다른 언어의 핵심을 에뮬레이트하기 위해 무거운 기계가 필요합니다.예를 들어 PHP에는 존재하지 않는 Python의 생성기와 목록 압축(PHP가 관련되어 있을 때는 확실히 빈약하다는 것을 내가 아는 한)을 생각해 보자.
마지막 힌트를 드리자면2to3Python 2 코드를 Python 3 코드로 변환하기 위해 Python 개발에서 만든 도구입니다.프런트 엔드로 보면 Python을 무언가로 변환하는 데 필요한 대부분의 요소를 갖추고 있습니다.그러나 Python 2와 3의 코어가 비슷하기 때문에 에뮬레이션 머신은 필요 없습니다.
번역기를 쓰는 것이 불가능한 것은 아닙니다. 특히 Joel's Internal이 여름 동안 번역기를 썼다는 것을 고려하면요.
한 가지 언어를 하고 싶다면 쉽다.더 하고 싶다면 조금 더 어렵지만 너무 많이 하지는 않아요.가장 어려운 점은 어떤 튜링완료언어라도 다른 튜링완료언어가 하는 것을 할 수 있지만 내장된 데이터형은 언어가 하는 것을 경이롭게 바꿀 수 있다는 것이다.
예:
word = 'This is not a word'
print word[::-2]
복제에는 많은 C++ 코드가 필요합니다(예, 일부 루프 구성에서는 짧은 시간 동안 수행할 수 있습니다).
그건 좀 편파적인 것 같아요.
언어 문법에 따라 토큰라이저/파서를 작성한 적이 있습니까?이 프로젝트의 주요 부분이기 때문에 아직 배우지 못했다면 아마 그 방법을 배우고 싶을 것입니다.기본적인 튜링 완전 구문을 생각해냅니다.이것은 Python 바이트 코드와 매우 유사합니다.그런 다음 언어 문법을 사용하는 렉서/파서를 만들고(아마도 BNF를 사용하여), 문법에 따라 언어를 중간 언어로 컴파일합니다.그리고 반대로, 문법에 따라 자신의 언어에서 대상 언어로 파서를 만듭니다.
가장 명백한 문제는 처음에는 특히 Python과 같은 더 강력한* 언어에서 매우 비효율적인 코드를 만들 수 있다는 것입니다.
하지만 이렇게 하면 향후 출력을 최적화할 수 있는 방법을 찾을 수 있을 것입니다.요약:
- 제공된 문법을 읽다
- 프로그램을 중간(그러나 튜링 완료) 구문으로 컴파일하다
- 중간 프로그램을 최종 언어로 컴파일한다(제공된 문법에 근거한다).
- ...?
- 이익!(?)
* 파워풀하다는 것은 4행으로 이루어진다는 것을 의미합니다.
myinput = raw_input("Enter something: ")
print myinput.replace('a', 'A')
print sum(ord(c) for c in myinput)
print myinput[::-1]
4줄로 할 수 있는 다른 언어를 보여주시면 Python만큼 강력한 언어를 보여드릴게요.
귀찮게 하지 말라는 대답이 몇 개 있어요.그게 얼마나 도움이 될까요?배우고 싶어?배울 수 있어요.이게 컴파일이에요.공교롭게도 당신의 타겟 언어는 기계어가 아니라 또 다른 고급 언어입니다.이건 항상 있는 일이야.
비교적 쉽게 시작할 수 있는 방법이 있습니다.우선, http://sourceforge.net/projects/lime-php/(PHP로 작업하고 싶은 경우)를 입수해, 샘플 코드를 참조해 주세요.다음으로 일련의 정규식을 사용하여 어휘 분석기를 작성하고 생성한 파서에 토큰을 공급합니다.시맨틱 액션은 다른 언어로 코드를 직접 출력하거나 데이터 구조(사고 객체, 사람)를 구축하여 마사지하고 통과할 수 있으며 출력 코드를 생성할 수 있습니다.
PHP와 Python은 여러 면에서 같은 언어이지만 구문이 다르기 때문에 운이 좋습니다.어려운 부분은 문법 형태와 데이터 구조 사이의 의미 차이를 극복하는 것입니다.예를 들어 Python에는 목록과 사전이 있지만 PHP에는 assoc 배열만 있습니다.
「학습자」의 어프로치는, 언어의 제한된 서브셋(인쇄문, 간단한 산술, 변수 할당등)에 대해서 정상적으로 동작하는 것을 작성하고 나서, 제한을 단계적으로 삭제하는 것입니다.현장의 거물들이 한 짓이 바로 그겁니다
아, 그리고 Python에는 정적 타입이 없기 때문에 Python_add와 같은 PHP 함수는 Python의 방법에 따라 숫자, 문자열 또는 오브젝트를 추가하는 것이 가장 좋습니다.
확실히, 당신이 허락한다면 이 일은 훨씬 더 커질 수 있습니다.
파서 대신 ast.parse를 사용하는 것에 대해서는, @EliBendersky의 견해에 대해서는, 제2탄으로 하겠습니다.그의 블로그를 리뷰해 볼 것을 강력히 추천합니다.Python->JavaScript 번역기(@http://bitbucket.org/amirouche/pythonium))를 사용하기 위해 ast.http://를 사용했습니다.저는 다른 실장들을 검토해서 직접 시도해보고 피토늄 디자인을 생각해냈습니다.저도 시작한 https://github.com/PythonJS/PythonJS에서 Pythonium을 검색했습니다.사실 완전 개서입니다.전체적인 디자인은 PyPy 및 http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-89-1.pdf 페이퍼에서 영감을 얻었습니다.
처음부터 최선의 해결책까지 내가 시도한 모든 것은 피토늄 마케팅처럼 보이지만 실제로는 그렇지 않다(네티켓에 맞지 않는 것이 있으면 주저하지 말고 말해 주세요).
프로토타입 상속을 사용하여 Plain Old JavaScript에서 Python 시멘틱을 구현합니다.AFIK JS 프로토타입 객체 시스템을 사용하여 Python 다중 상속을 구현하는 것은 불가능합니다.나중에 다른 트릭(getattribute 참조)을 사용하여 시도했습니다.JavaScript에 Python 다중 상속이 구현되어 있지 않은 것으로 알고 있는 한, 현존하는 가장 좋은 것은 Single inheritance + mixins이며 다이아몬드 상속을 취급하고 있는지 잘 모르겠습니다.스컬트와 비슷하지만 구글 클로져는 없다.
실제로 Skulpt 코드 #fail을 읽지 않고 Skulpt(컴파일러)처럼 Google clojure를 사용해 보았습니다.어쨌든 JS 프로토타입 기반 객체 시스템은 여전히 불가능합니다.바인딩을 만드는 것은 매우 어려웠기 때문에 JavaScript와 많은 보일러 플레이트 코드를 작성해야 합니다(cf).https://github.com/skulpt/skulpt/issues/50을 참조해 주세요).그 당시에는 빌드 시스템에 바인딩을 통합하는 명확한 방법이 없었습니다.Skulpt는 라이브러리이며 실행 시 .py 파일을 html에 포함하기만 하면 됩니다.개발자가 컴파일 단계를 수행할 필요는 없습니다.
pyjaco(컴파일러)를 시도했지만 바인딩(Python 코드에서 Javascript 코드 호출)을 만드는 것은 매우 어려웠고 매번 만들기에는 보일러 플레이트 코드가 너무 많았습니다.이제 피토늄 근처에 피자코가 있는 것 같아요.pyjaco는 Python(ast.parse도 마찬가지)으로 작성되지만, 많은 부분이 JavaScript로 작성되어 프로토타입 상속을 사용합니다.
실제로 잠옷 #fail 실행에는 성공하지 못했고 #fail 코드를 다시 읽어보지도 않았습니다.그러나 PyJamas는 Python에서 JavaScript로 변환하는 것이 아니라 API->API 번역(또는 프레임워크에서 프레임워크로 변환)을 하고 있었습니다.JavaScript 프레임워크는 이미 페이지에 있는 데이터 또는 서버의 데이터를 소비합니다.Python 코드는 "plumbing"일 뿐입니다.그 후, 파자마는 실제로 진짜 파이톤->js 번역가라는 것을 알게 되었습니다.
그래도 API->API(또는 프레임워크->프레임워크) 번역을 할 수 있다고 생각합니다.기본적으로 피토늄에서는 그렇게 하고 있습니다만, 하위 레벨에서는 그렇게 하고 있습니다.아마 파자마는 피토늄과 같은 알고리즘을 사용했을 거야
그러다가 Brython이 Javascript로 완전히 작성된 것을 발견했다. Skulpt처럼, 컴파일이 필요 없고, 많은 양의 솜털이...JavaScript로 작성되었습니다.
이 프로젝트 과정에서 처음 쓴 줄부터 PyPy에 대해 알고 있었고, PyPy용 JavaScript 백엔드도 알고 있었습니다.네, 찾으시면 PyPy에서 JavaScript에서 Python 인터프리터를 직접 생성할 수 있습니다.사람들은 그것이 재앙이었다고 말한다.왜 그런지 모르겠어요.하지만 인터프리터 RPython을 구현하기 위해 사용하는 중간 언어는 Python의 서브셋이기 때문에 C(asm)로 번역할 수 있다고 생각합니다.Ira Baxter에 의하면, 무언가를 작성할 때는 항상 전제를 하고, PyPy: Python->C 번역의 경우, 그것이 의도하는 바를 최대한으로 조정할 수 있다고 합니다.이러한 가정은 다른 맥락에서 적절하지 않을 수 있으며, 오버헤드를 더 악화시킬 수 있습니다.그렇지 않으면 직접 번역이 항상 더 나을 수 있습니다.
Python으로 된 통역사가 있다는 것은 좋은 생각처럼 들렸다.하지만 성능상의 이유로 컴파일러에 더 관심이 많았습니다. 또한 실제로 Python을 JavaScript로 컴파일하는 것이 해석하는 것보다 더 쉽습니다.
Python을 시작했습니다.JS는 Python의 서브셋을 조합하여 JavaScript로 쉽게 번역할 수 있도록 했습니다.처음에는 경험상 OO 시스템을 도입할 생각도 없었습니다.자바스크립트로 변환하기 위해 달성한 Python의 서브셋은 다음과 같습니다.
- 정의와 호출의 양쪽에서 완전한 파라미터 시멘틱을 가진 함수.이 부분이 가장 자랑스럽습니다.
- 그러는 동안/만약에/엘리프/거짓말하는 동안
- Python 타입이 JavaScript 타입으로 변환되었습니다(Python 타입은 없습니다).
- 는 Javascript 어레이에서만 반복할 수 있습니다(어레이 내의 경우).
- JavaScript에 대한 투과적 접근: Python 코드로 Array를 쓰면 Javascript로 Array로 변환됩니다.이는 경쟁사 대비 사용성 측면에서 가장 큰 성과다.
- Python 소스에 정의된 함수를 javascript 함수에 전달할 수 있습니다.기본 인수가 고려됩니다.
- add에는 new라는 특별한 기능이 있으며, new(Python)(1, 2, spam, egg)는 new Python(1, 2, spam, egg)로 번역됩니다.
- "var"는 번역자에 의해 자동으로 처리됩니다.(브렛(피톤)이 발견한 것은 매우 훌륭합니다.JS 컨트리뷰터).
- global 키워드
- 폐쇄
- 람다
- 포괄 목록
- Import는 requirejs를 통해 지원됩니다.
- 단일 클래스 상속 + classijs를 통한 믹스인
Python의 완전한 의미에 비하면 많은 것 같지만 실제로는 매우 좁습니다.Python 구문을 사용하는 JavaScript입니다.
생성된 JS는 완벽합니다.오버헤드가 없기 때문에 더 편집해도 성능 면에서 개선되지 않습니다.생성된 코드를 개선할 수 있다면 Python 소스 파일에서도 개선할 수 있습니다.또한 컴파일러는 http://superherojs.com/,에 의해 작성된 .js에서 찾을 수 있는 JS 트릭에 의존하지 않기 때문에 매우 읽기 쉽다.
Python의 이 부분의 직계 후손JS는 피토늄 벨로체 모드입니다.완전한 실장은 https://bitbucket.org/amirouche/pythonium/src/33898da731ee2d768ced392f1c369afd746c25d7/pythonium/veloce/veloce.py?at=master 793 SLOC + 다른 번역자와 공유 코드 약 100 SLOC에서 확인할 수 있습니다.
pystones.py 의 적응 버전은, Veloce 모드 cf 로 변환할 수 있습니다.https://bitbucket.org/amirouche/pythonium/src/33898da731ee2d768ced392f1c369afd746c25d7/pystone/?at=마스터
기본 Python->JavaScript 변환을 설정한 후 Python을 JavaScript로 완전히 변환하는 다른 경로를 선택했습니다.glib에서 오브젝트 지향 클래스 기반 코드를 실행하는 방법은 대상 언어를 제외하고 JS입니다. 따라서 어레이, 맵과 같은 오브젝트 및 기타 많은 트릭에 액세스할 수 있으며 모든 부분은 Python으로 작성되었습니다.IIRC에는 피토늄 번역기에 의해 작성된 Javascript 코드가 없습니다.단일 상속은 어렵지 않습니다. Python과 완전히 호환되는 Python의 어려운 점은 다음과 같습니다.
spam.eggin Python은 항상 로 변환됩니다.getattribute(spam, "egg")특별히 프로파일링한 것은 아니지만, 시간이 많이 걸리는 부분에서는 asm.js나 다른 것으로 개선할 수 있을지 모르겠습니다.- 메서드 해결 순서: Python으로 작성된 알고리즘에서도 Python Veloce 호환 코드로 변환하는 것은 큰 노력이었습니다.
- getattribute: 실제 getattribute 해결 알고리즘은 다소 까다롭고 여전히 데이터 기술자를 지원하지 않습니다.
- 메타클래스 클래스 베이스:코드를 어디에 꽂아야 할지 알지만 그래도...
- last bu list: some_callable(...)은 항상 "call(some_callable)"로 변환됩니다.AFAIK 번역자는 추론을 전혀 사용하지 않기 때문에 호출할 때마다 어떤 오브젝트인지 확인해야 합니다.
이 부분은 https://bitbucket.org/amirouche/pythonium/src/33898da731ee2d768ced392f1c369afd746c25d7/pythonium/compliant/runtime.py?at=master에 포함되어 있으며 Python Veloce와 호환되는 Python으로 작성되어 있습니다.
실제 준거 번역자 https://bitbucket.org/amirouche/pythonium/src/33898da731ee2d768ced392f1c369afd746c25d7/pythonium/compliant/compliant.py?at=master는 JavaScript 코드를 직접 생성하지 않으며, 가장 중요한 것은 ast->ast 변환도 하지 않습니다.cst보다 더 좋은 것은 ast와 함께 일해도 좋지 않다고 해도, 저는 ast->ast를 시도했습니다.Node Transformer, 그리고 더 중요한 것은 ast->ast를 할 필요가 없다는 것입니다.
내 경우 python ast를 python ast로 하면 적어도 퍼포먼스가 향상될 수 있습니다.예를 들어 블록과 관련된 코드를 생성하기 전에 블록의 내용을 검사하는 경우가 있기 때문입니다.
- var/global: 무언가를 바꿀 수 있으려면 무엇이 필요한지 알아야 합니다.블록 트래킹을 생성하여 생성된 함수 블록 위에 삽입하는 대신 실제로 자노드를 방문하여 관련 코드를 생성하기 전에 블록에 들어갈 때 수준 변수 할당을 찾습니다.
- yield, generators는 아직 JS에서 특별한 구문을 가지고 있기 때문에, 나는 "var my_generator = 함수"를 쓰고 싶을 때 어떤 Python 함수가 generator인지 알아야 한다.
따라서 번역 단계별로 각 노드를 한 번씩 방문하지는 않습니다.
전체 프로세스는 다음과 같이 설명할 수 있습니다.
Python source code -> Python ast -> Python source code compatible with Veloce mode -> Python ast -> JavaScript source code
Python builtins는 Python 코드(!)로 작성됩니다.IIRC에는 부트스트레이핑 타입과 관련된 몇 가지 제한이 있지만, Pythonium을 호환 모드로 번역할 수 있는 모든 것에 액세스할 수 있습니다.https://bitbucket.org/amirouche/pythonium/src/33898da731ee2d768ced392f1c369afd746c25d7/pythonium/compliant/builtins/?at=master를 참조하십시오.
피토늄 호환에서 생성된 JS 코드를 읽는 것은 이해할 수 있지만 소스 맵은 큰 도움이 됩니다.
이 경험에 비추어 제가 드릴 수 있는 귀중한 조언은 아주 오래된 방귀입니다.
- 문학 및 기존 프로젝트 모두에서 주제를 광범위하게 검토하거나 무료로 제공합니다.기존 프로젝트들을 검토했을 때 더 많은 시간과 동기를 부여했어야 했습니다.
- 질문하세요!C/Javascript 시멘틱 미스매치로 인한 오버헤드로 인해 PyPy 백엔드가 무용지물이라는 것을 미리 알았다면.아마 6개월 전에 피토늄 아이디어를 3년 전에 알았을 거예요.
- 뭘 하고 싶은지 알고 목표를 정하세요이 프로젝트에서는 javascript를 조금 연습하고, Python에 대해 더 많이 배우고, 브라우저에서 실행할 Python 코드를 쓸 수 있는 다른 목표를 가지고 있었습니다(아래와 더 많은 것).
- 실패는 경험이다.
- 작은 걸음은 한 걸음이다.
- 작은 것부터 시작하다
- 큰 꿈을 꾸다
- 데모를 하다
- 반복하다
Python Veloce 모드만 있으면 너무 행복해요!하지만 그 과정에서 제가 정말로 찾고 있는 것은 저와 다른 사람들을 Javascript로부터 해방시키는 것이지만, 더 중요한 것은 편안하게 만들 수 있다는 것입니다.이를 통해 Scheme, DSL, Models, 최종적으로는 도메인별 모델(cf.http://dsmforum.org/) 를 참조해 주세요.
Ira Baxter의 답변에 대해서:
그 견적은 전혀 도움이 되지 않는다.PythonJs와 Pythonium 둘 다 6개월 정도의 자유시간을 가지고 있었습니다.그래서 풀타임 6개월부터 더 많은 것을 기대할 수 있습니다.기업 환경에서 100명이란 의미가 있는 것이지 전혀 의미가 없는 것은 아닙니다.
누군가가 어떤 것이 어렵거나 더 자주 불가능하다고 말할 때, 나는 "불가능한 문제에 대한 해결책을 찾는 데 시간이 걸릴 뿐"이라고 대답한다. 그렇지 않으면 불가능한 것은 없다고 말했다. 이 경우 수학적인 증명으로 증명된 경우를 제외하고는...
그것이 불가능하다고 증명되지 않는다면, 그것은 상상의 여지를 남긴다.
- 불가능하다는 것을 증명하는 증거를 찾는 것
그리고.
- 이것이 불가능할 경우 해결 방법이 있을 수 있는 "중요한" 문제가 있을 수 있습니다.
또는
- 불가능하지 않다면 해결책을 찾는 것
낙관적인 생각뿐만이 아닙니다.내가 Python->Javascript를 시작했을 때 모두가 불가능하다고 말했다.PyPy는 불가능합니다.메타클래스가 너무 딱딱해서...Scheme->C 페이퍼(25년)보다 PyPy를 가져오는 유일한 혁명은 자동 JIT 생성(RPython 인터프리터에 기재된 힌트)이라고 생각합니다.
어떤 것이 "어렵다"거나 "불가능하다"고 말하는 대부분의 사람들은 그 이유를 제공하지 않는다.C++는 해석하기 어렵습니까?알아요, 그래도 C++ 파서예요.악이 디테일에 있다고?나는 그것을 알고 있습니다.혼자서는 불가능하다고 말하는 것은 도움이 되지 않고, "도움이 안 된다"는 것보다 더 나쁘고, 어떤 사람들은 다른 사람들을 낙담시키려고 합니다.저는 https://stackoverflow.com/questions/22621164/how-to-automatically-generate-a-parser-code-to-code-translator-from-a-corpus에서 이 질문에 대해 들었습니다.
당신에게는 어떤 것이 완벽할까요?이것이 다음 목표를 정의하고 전체 목표에 도달하는 방법입니다.
I am more interested in knowing what kinds of patterns I could enforce on the code to make it easier to translate (ie: IoC, SOA ?) the code than how to do the translation.
I see no patterns that can not be translated from one language to another language at least in a less than perfect way. Since language to language translation is possible, you'd better aim for this first. Since, I think according to http://en.wikipedia.org/wiki/Graph_isomorphism_problem, translation between two computer languages is a tree or DAG isomorphism. Even if we already know that they are both turing complete, so...
Framework->Framework which I better visualize as API->API translation might still be something that you might keep in mind as a way to improve the generated code. E.g: Prolog as very specific syntax but still you can do Prolog like computation by describing the same graph in Python... If I was to implement a Prolog to Python translator I wouldn't implement unification in Python but in a C library and come up with a "Python syntax" that is very readable for a Pythonist. In the end, syntax is only "painting" for which we give a meaning (that's why I started scheme). Evil is in the detail of the language and I'm not talking about the syntax. The concepts that are used in the language getattribute hook (you can live without it) but required VM features like tail-recursion optimisation can be difficult to deal with. You don't care if the initial program doesn't use tail recursion and even if there is no tail recursion in the target language you can emulate it using greenlets/event loop.
For target and source languages, look for:
- Big and specific ideas
- Tiny and common shared ideas
From this will emerge:
- Things that are easy to translate
- Things that are difficult to translate
You will also probably be able to know what will be translated to fast and slow code.
There is also the question of the stdlib or any library but there is no clear answer, it depends of your goals.
Idiomatic code or readable generated code have also solutions...
Targeting a platform like PHP is much more easy than targeting browsers since you can provide C-implementation of slow and/or critical path.
Given you first project is translating Python to PHP, at least for the PHP3 subset I know of, customising veloce.py is your best bet. If you can implement veloce.py for PHP then probably you will be able to run the compliant mode... Also if you can translate PHP to the subset of PHP you can generate with php_veloce.py it means that you can translate PHP to the subset of Python that veloce.py can consume which would mean that you can translate PHP to Javascript. Just saying...
You can also have a look at those libraries:
Also you might be interested by this blog post (and comments): https://www.rfk.id.au/blog/entry/pypy-js-poc-jit/
- This Google Tech Talk from Ira Baxter is interesting https://www.youtube.com/watch?v=C-_dw9iEzhA
You could take a look at the Vala compiler, which translates Vala (a C#-like language) into C.
ReferenceURL : https://stackoverflow.com/questions/3455456/what-kinds-of-patterns-could-i-enforce-on-the-code-to-make-it-easier-to-translat
'programing' 카테고리의 다른 글
| Python의 SFTP(플랫폼에 의존하지 않음) (0) | 2022.09.24 |
|---|---|
| AWS RDS MariaDB가 이유 없이 단순 대체 테이블에서 300GB를 소비함 (0) | 2022.09.24 |
| 사전 키로 사용자 지정 유형의 개체 (0) | 2022.09.24 |
| PHP array()와 []의 차이점 (0) | 2022.09.24 |
| 표준 각도JS 워크플로우 및 프로젝트 구조(Python Flask 포함) (0) | 2022.09.24 |