대화:추상 구문 트리

Talk:Abstract syntax tree
위키프로젝트 컴퓨팅 / 소프트웨어 / CompSci (정격화된 시작 클래스, 중간 중요도)
WikiProject icon이 글은 위키백과에 관한 컴퓨터, 컴퓨터, 컴퓨터, 정보 기술의 커버리지를 개선하기 위한 공동 노력인 위키프로젝트 컴퓨팅의 범위 내에 있다.참여하려면 프로젝트 페이지를 방문하여 토론에 참여하고 열려 있는 태스크 목록을 확인하십시오.
시작 이 기사는 프로젝트의 품질 규모에서 스타트 클래스로 평가되었다.
중앙의 이 기사는 그 프로젝트의 중요도에 대한 중간 평가로 평가되었다.
Taskforce icon
 이 글은 위키프로젝트 소프트웨어(중간 임베디멘션으로 표시됨)에서 지원한다.
Taskforce icon
 이 기사는 위키프로젝트 컴퓨터 과학(중간소수로 표시됨)이 지원한다.
WikiProject Computer Science에 도움이 되는 사항:
다음은 대기 중인 몇 가지 작업:

표현

"...AST에서 피연산자의 그룹화는 트리 구조에서 명백하기 때문에.""불충분하다"는 말이 더 말이 되지 않을까?

4개 추가되는 게시물에는 모두 서명하십시오.그것은 소스코드에 내포되어 있는데, 여기서 그것은 선결과 연관성 규칙에 의해 함축되어 있고, 게다가 모든 운용자의 경지(단일성, 이진성 등)에 의해 함축되어 있다.AST에서 그것은 명백하다: 각 피연산자 노드는 그것이 아들로서 가지고 있는 피연산자를 그룹화한다. --euyyn 23:37, 2006년 6월 18일 (UTC)[응답]

'내부 파충류 파충류'라고 부를 수 있는 사람이 있을까?

아니요.

컨텍스트 혼동

그 기사 때문에 좀 헷갈릴 것 같아.파서는 각 개별 프로그램에 대한 컴파일 프로세스의 일부로 추상 구문 트리를 만드는가?즉, 내가 컴파일하는 C 프로그램마다 다른 추상 구문 트리가 있을까?아니면 속성 그래머처럼 C의 언어에 대한 "추상적인 구문 트리"가 하나 있을까? -- 크리디키 18:07, 2005년 11월 10일 (UTC)[응답]

네, AST는 컴파일 과정의 일환으로 만들어지기 때문에 각 프로그램마다 AST --Pezzin 11:53, 2006년 3월 9일 (UTC)[응답]이 다르다.

션팅 야드 알고리즘

션팅 야드 알고리즘에 위키링크를 추가했어비록 이것이 현재 역폴란드 표기법으로 방향을 바꾸지만, 슌을 분할하는 것은 이미 제안된 바 있다.

"싱택스 트리?"

구문 트리는 현재 여기서 리디렉션되지만, 이 용어는 구체적인 구문 트리, 즉 구문 트리에도 동일하게 적용된다.언어학자로서, 내가 그냥 이렇게 말해도 될까: 요, 컴팩트 공상과학자 애들아, 물러나라.즉, 이 특정 리디렉션의 타당성은 신중하게 평가되어야 하며 적절한 숙고 후에 적절한 해명이 이루어져야 한다는 것을 의미한다.고마워. 69.140.12.19 05:32, 2007년 1월 20일 (UTC)[응답]

'합작나무'가 추상적이고 구체적인 구문 나무의 우산 용어라고 추측할 수도 있겠지만, 나는 용의 책을 주의 깊게 읽었고 (이 책은 그 주제에 관한 확정적인 책이라고 생각한다)라고 적혀 있다.
나는 최근 이 점을 분명히 하기 위해 두 기사를 모두 편집했다.에그리핀 15:55, 2007년 11월 30일 (UTC)[응답]
왜 드래곤북이 그 구별에 대해 "정의적"이 되었을까?저자들은 언어학자가 아니라 그저 특정한 언어 개념을 빌려 쓰고, 그 밖에 많은 책들이 있다.HenkeB (대화) 2008년 12월 13일 (UTC) 17:26 [응답]
그렇다면 추상적인 구문 나무와 구체적인 구문 나무의 차이점은 무엇일까?[1]의 구분이 보편적으로 받아들여지고 있는가?Rp (토크) 16:19, 2008년 5월 16일 (UTC)[응답]
구체적이고 추상적인 구문 사이: 그렇다; 파스 나무와 구문 나무 사이: 아니다, 이것들은 꽤 용어를 잃어버린다.HenkeB (대화) 17:37, 2008년 12월 13일 (UTC)[응답]

위키프로젝트 철학?

컴퓨터 과학의 주제인 데다 철학과는 관련이 없는 주제인 만큼 위키프로젝트 철학에서 삭제해야 한다고 본다.바이오테크놀로지 2007년 9월 26일 (UTC) 20:31[응답]

튜토리얼에 연결하시겠습니까?

자습서적 가치가 별로 보이지 않는 이른바 '튜토리얼'에 대한 링크가 있는데, 그것은 AST를 위한 표준을 제안하는 것 같다(내 생각에는 다소 헛된 것 같다).링크를 제거하면 이 기사가 실제로 개선될 것이라고 생각하겠지만, 누군가 무슨 이유로 거기에 넣었을까? --Lasse Hillerøe Petersen (토크) 21:47, 2012년 8월 12일 (UTC)[응답]

디자인 패턴

이 절에서는 이를 주어진 것으로 받아들이거나 최소한 AST가 객체 지향적으로 구현되어야 한다고 제안하며, 이러한 가정에 기초하여 방문자 패턴의 사용을 제안한다.그러나 이 패턴은 패턴 매칭의 부족을 보완하기 위한 보일러 판에 불과하다.만약 그렇다면, 이것은 객체 지향성이 AST를 구현하기 위한 최상의 패러다임이 아니라는 것을 암시한다.

기계적으로 구문 분석해야 하는 대부분의 문법은 결정적으로 문맥이 없으며 백커스-나우르 양식 또는 확장 백커스-나우르 양식을 사용하여 정의할 수 있다.이전의 지도는 대수 데이터 유형에 직접 연결된다.후자는 대수적 데이터 형식에도 매핑되지만, 표준 라이브러리가 옵션과 목록 형식을 제공하고, 이는 다시 대수적 데이터 형식을 사용하여 구현될 수 있다는 점을 감안한다.따라서 AST의 구현을 위한 백본으로서 대수적 데이터 유형을 사용하는 것이 더 좋은 제안일 것이다.에두아르도 레온 (대화) 21:35, 2013년 5월 1일 (UTC)[응답]

올드 위트 회고전

나는 용의 책 앞에 컴파일러를 쓰고 있다.우린 그냥 나무라고 불렀어.비록 그 도표들이 뿌리 체계와 더 닮았다.

나는 동등한 s-expression에 대한 무언가가 있어야 한다고 생각한다.나무 형태로 된 문장의 예는 여러 가지 방법으로 표현될 수 있다.여기서는 조금 단순하다.나는 단지 그 개념을 이해시키고 싶지 않다.아래에 세 가지 양식이 나와 있다.목록 양식은 첫 번째 요소로 노드 이름을 굵은체로 한다.오른쪽의 나무가 오른쪽으로 가지를 뻗는다.아래 버전은 에서 나온 상징적인 나무 입니다.목록 양식처럼 노드만 꺼내어 개구부 '[]' 괄호 앞에 놓았다.


한편 (NEQ b)
if (a > b)
a = a - b;
다른
b = b - a;
WHIGN / \ NEQ \ / \ ASGN IF / \ B SUB GT \ / \ ASGN b a b / \ SUB / \
그러는 동안[neq[a,b기타[IF][A,b]ASGN[a,SUB[a,b]]],ASGN[b,SUB[b,a]]]


[WHIF, [NEQ,a,b], [ELSE,[IF,GT,a,b],[ASGN,a,b],[ASGN,b],[ASGN,b,a]]]]


위의 나무를 보여주는 세 가지 형태를 화보형식, 나무형식, 목록형식이라고 불렀다.리스트와 나무 형태는 폴란드식 접두사 표기법과 같다.나무의 형태를 가지고 우리는 부품에 대해 이야기하고 분석할 수 있다.예를 들어 WID 노드에는 특정 분기가 있다. 

WHY[조건, 표현]

그 동안 조건이 참인 한 그 표현을 실행한다.컴파일러는 조건과 식에 대한 코드를 생성할 수 있다.코드 생성에 들어가지 않고서는 다른 나무 표기법의 장점을 설명하기 어렵다.그래서 나는 여기서 이것을 만질 것이고 만약 누군가가 이것이 주제에 포함되어야 한다고 생각한다면.쓰세요.

코드는 먼저 또는 마지막으로 생성될 수 있다.우리가 처음 출력하는 것보다 먼저 표현 코드를 생성해 조건 코드로 점프한 다음 루프를 시작하기 위한 레이블을 생성한다.만약 우리가 먼저 조건을 생성한다면 우리는 루프를 시작하기 위해 라벨을 출력할 것이다.그러니 우선 조건을 해 보자.컴파일러는 기호를 만드는 방법이 필요하다.컴파일되는 언어의 일부가 아닌 생성된 기호를 gensyms 줄임말이라고 부른다.상징적으로 생성된 기호를 %G<숫자> %G1, %G2 등으로 나타내겠다.우리가 조건부 나무 벡스와 젠심 로크를 갖는 falsegen(bexpr, loc) 기능을 가지고 있다고 하자.젠셈(gensem)은 조건이 거짓일 때 가는 곳이다.일반 트리에 대한 코드를 생성하는 또 다른 함수 gencode(트리)이 예에서 %g1: 현재 코드 위치를 할당한다.아직 정의되지 않은 기호의 주소를 가져오거나 생성할 수 있는 메커니즘이 있다고 가정하십시오.수정, 현금화 코드 또는 추적은 앞으로 참조하는 코드였다.그래서 그림의 형태에서 잠깐 루프의 코드 생성은 다음과 같을 것이다.

%G1: falsegen(조건, %G2); gencode(표현), goto(%G1); %G2:

Truegen 함수를 사용하여 먼저 식을 생성하는 방법:

goto(%G2); %G1: gencode(표현); %G2: truegen(조건, %G1);

다음에 대한 참조 코드 생성:

WHY[조건, 표현]

나무의 다른 표현은 그들에 대해 말하는 방법을 제공한다.설명 이름을 사용하여 트리 분기를 추상화하는 것은 코드를 생성하는 방법을 이해하는 데 이점이 있다.1970년에 컴파일러 컴파일러가 있었는데, 이 컴파일러는 실제로 나의 사례와 매우 유사한 코드를 생성했다.나는 젠심이 기능 인스턴스의 지역적 요소라는 것을 언급해야 한다.

--Steamerandy (talk) 08:02, 2014년 10월 30일 (UTC) 오른쪽 Steamerandy (talk) 22:32, 2017년 5월 4일 (UTC)[응답]

이게 말이 돼?

기사에는 "이 방법이 보다 효율적인 컴파일러로 이어질 수 있지만 프로그램 작성과 유지보수의 소프트웨어 엔지니어링 원칙에 어긋난다"는 문장이 담겨 있다.프로그램 작성 및 유지보수의 소프트웨어 엔지니어링 원칙은 무엇인가?그것 자체로 그 진술은 무의미하다.그것이 의미를 가지려면, 그 방법이 위반하는 (그리고 위반이 발생하는 방법을 표시하기 위해 필요한) 주체를 명시할 필요가 있을 것이다.FreeFlow99 (대화) 12:58, 2021년 1월 18일 (UTC)[응답]

말도 안 되는 일이라는 것에 동의해.앞의 문장 "이 파스 트리는 구문 지시 번역을 통해 컴파일러의 거의 모든 기능을 수행할 수 있다."는 말은 "대부분 컴파일러의 모든 기능"이 의미하는 바를 오해하는 것처럼 보인다.아마도 저자는 "이 파스나무는 AST의 모든 정보를 담고 있다"고 말하려 했지만, 이것은 명백하다.구문 트리에 쓸모없는 토큰을 보관하면 어떻게든 "더 효율적인 컴파일러로 이어질 것"이라는 주장도 처음 들어봤다.나는 이것을 삭제했다가 다시 말하려고 하는데, 왜냐하면 나는 그것을 뒷받침할 RS가 존재하지 않는다고 생각하기 때문이다. 그 주장은 냄새 검사도 통과하지 못한다.어떤 엔지니어가 보다 효율적인 컴파일러로 이어지는 것을 효과적으로 사용하지 않을 것인가?트릭스터울프 (토크) 16:05, 2021년 12월 7일 (UTC)[응답]
나는 또한 앞의 단락에서 '+' 연산자는 숫자적 덧셈과 문자열의 연결 둘 다인 훌륭한 예를 제시한다"고 삭제했다.연산자 과부하가 문맥에 민감하다는 것을 설명하기 위해 예를 들 필요는 없다고 생각하지만, 컴파일러와 JVM이 스트링 결합을 얼마나 다르게 다루는지, 그리고 이것이 다른 언어에서 연산자 과부하와 실질적으로 어떻게 다른지 때문에 이것이 '우수한 예'라고 확신할 수는 없다.Java의 +와 += 과부하는 Java 언어와 JVM의 기본 부분인 많은 복잡성(객체 생성, 호출 방법, 컴파일 시 일부 및 런타임 시 일부)을 유발한다.나는 나중에 돌아와서 시간이 있으면 이 부분을 전부 다시 쓸지도 몰라.트릭스터울프 (토크) 16:18, 2021년 12월 7일 (UTC)[응답]