This site uses cookies.
Some of these cookies are essential to the operation of the site,
while others help to improve your experience by providing insights into how the site is being used.
For more information, please see the ProZ.com privacy policy.
français vers coréen anglais vers chinois japonais vers coréen coréen vers japonais japonais vers anglais coréen vers français chinois vers anglais chinois vers coréen coréen vers chinois allemand vers coréen coréen vers allemand coréen vers espagnol espagnol vers coréen russe vers coréen coréen vers russe
Indépendant et donneur d'ordre, Utilisateur confirmé du site
Data security
This person has a SecurePRO™ card. Because this person is not a ProZ.com Plus subscriber, to view his or her SecurePRO™ card you must be a ProZ.com Business member or Plus subscriber.
coréen vers anglais - Tarifs : 0.06 - 0.08 USD par caractère / 25 - 35 USD par heure anglais vers japonais - Tarif : 0.06 - 0.08 USD par mot / 25 - 35 USD de l'heure anglais vers coréen - Tarif : 0.06 - 0.08 USD par mot / 25 - 35 USD de l'heure français vers coréen - Tarif : 0.06 - 0.08 USD par mot / 25 - 35 USD de l'heure anglais vers chinois - Tarif : 0.06 - 0.08 USD par mot / 25 - 35 USD de l'heure
japonais vers coréen - Tarifs : 0.06 - 0.08 USD par caractère / 25 - 35 USD par heure coréen vers japonais - Tarifs : 0.06 - 0.08 USD par caractère / 25 - 35 USD par heure japonais vers anglais - Tarifs : 0.06 - 0.08 USD par caractère / 25 - 35 USD par heure coréen vers français - Tarifs : 0.06 - 0.08 USD par caractère / 25 - 35 USD par heure chinois vers anglais - Tarifs : 0.06 - 0.08 USD par caractère / 25 - 35 USD par heure chinois vers coréen - Tarifs : 0.06 - 0.08 USD par caractère / 25 - 35 USD par heure coréen vers chinois - Tarifs : 0.06 - 0.08 USD par caractère / 25 - 35 USD par heure allemand vers coréen - Tarif : 0.06 - 0.08 USD par mot / 25 - 35 USD de l'heure coréen vers allemand - Tarifs : 0.06 - 0.08 USD par caractère / 25 - 35 USD par heure coréen vers espagnol - Tarifs : 0.06 - 0.08 USD par caractère / 25 - 35 USD par heure espagnol vers coréen - Tarif : 0.06 - 0.08 USD par mot / 25 - 35 USD de l'heure russe vers coréen - Tarif : 0.06 - 0.08 USD par mot / 25 - 35 USD de l'heure coréen vers russe - Tarifs : 0.06 - 0.08 USD par caractère / 25 - 35 USD par heure
Points PRO : 16, Réponses aux questions : 21, Questions posées : 2
Payment methods accepted
Paypal
Portefeuille
Échantillons de traduction proposés: 1
anglais vers coréen: Sample Translation General field: Technique / Génie Detailed field: Ordinateurs : logiciels
Texte source - anglais 1 The Concepts of Bison
This chapter introduces many of the basic concepts without which the details of Bison will not make sense. If you do not already know how to use Bison or Yacc, we suggest you start by reading this chapter carefully.
1.1 Languages and Context-Free Grammars
In order for Bison to parse a language, it must be described by a context-free grammar. This means that you specify one or more syntactic groupings and give rules for constructing them from their parts. For example, in the C language, one kind of grouping is called an ‘expression’. One rule for making an expression might be, “An expression can be made of a minus sign and another expression”. Another would be, “An expression can be an integer”. As you can see, rules are often recursive, but there must be at least one rule which leads out of the recursion.
The most common formal system for presenting such rules for humans to read is Backus- Naur Form or “BNF”, which was developed in order to specify the language Algol 60. Any grammar expressed in BNF is a context-free grammar. The input to Bison is essentially machine-readable BNF.
There are various important subclasses of context-free grammars. Although it can handle almost all context-free grammars, Bison is optimized for what are called LR(1) grammars. In brief, in these grammars, it must be possible to tell how to parse any portion of an input string with just a single token of lookahead. For historical reasons, Bison by default is limited by the additional restrictions of LALR(1), which is hard to explain simply. See Section 5.7 [Mysterious Conflicts], page 116, for more information on this. As an experimental feature, you can escape these additional restrictions by requesting IELR(1) or canonical LR(1) parser tables. See Section 5.8.1 [LR Table Construction], page 118, to learn how.
Parsers for LR(1) grammars are deterministic, meaning roughly that the next grammar rule to apply at any point in the input is uniquely determined by the preceding input and a fixed, finite portion (called a lookahead) of the remaining input. A context-free grammar can be ambiguous, meaning that there are multiple ways to apply the grammar rules to get the same inputs. Even unambiguous grammars can be nondeterministic, meaning that no fixed lookahead always suffices to determine the next grammar rule to apply. With the proper declarations, Bison is also able to parse these more general context-free grammars, using a technique known as GLR parsing (for Generalized LR). Bison’s GLR parsers are able to handle any context-free grammar for which the number of possible parses of any given string is finite.
In the formal grammatical rules for a language, each kind of syntactic unit or grouping is named by a symbol. Those which are built by grouping smaller constructs according to grammatical rules are called nonterminal symbols; those which can’t be subdivided are called terminal symbols or token types. We call a piece of input corresponding to a single terminal symbol a token, and a piece corresponding to a single nonterminal symbol a grouping.
We can use the C language as an example of what symbols, terminal and nonterminal, mean. The tokens of C are identifiers, constants (numeric and string), and the various key- words, arithmetic operators and punctuation marks. So the terminal symbols of a grammar
for C include ‘identifier’, ‘number’, ‘string’, plus one symbol for each keyword, operator or punctuation mark: ‘if’, ‘return’, ‘const’, ‘static’, ‘int’, ‘char’, ‘plus-sign’, ‘open-brace’, ‘close-brace’, ‘comma’ and many more. (These tokens can be subdivided into characters, but that is a matter of lexicography, not grammar.)
Here is a simple C function subdivided into tokens:
int /* keyword ‘int’ */
square (int x) /* identifier, open-paren, keyword ‘int’,
identifier, close-paren */
{ /* open-brace */
return x * x; /* keyword ‘return’, identifier, asterisk,
identifier, semicolon */
} /* close-brace */
The syntactic groupings of C include the expression, the statement, the declaration, and the function definition. These are represented in the grammar of C by nonterminal symbols ‘expression’, ‘statement’, ‘declaration’ and ‘function definition’. The full grammar uses dozens of additional language constructs, each with its own nonterminal symbol, in order to express the meanings of these four. The example above is a function definition; it contains one declaration, and one statement. In the statement, each ‘x’ is an expression and so is ‘x * x’.
Each nonterminal symbol must have grammatical rules showing how it is made out of simpler constructs. For example, one kind of C statement is the return statement; this would be described with a grammar rule which reads informally as follows:
A ‘statement’ can be made of a ‘return’ keyword, an ‘expression’ and a ‘semi- colon’.
There would be many other rules for ‘statement’, one for each kind of statement in C. One nonterminal symbol must be distinguished as the special one which defines a com-
plete utterance in the language. It is called the start symbol. In a compiler, this means a
complete input program. In the C language, the nonterminal symbol ‘sequence of definitions and declarations’ plays this role.
For example, ‘1 + 2’ is a valid C expression—a valid part of a C program—but it is not valid as an entire C program. In the context-free grammar of C, this follows from the fact that ‘expression’ is not the start symbol.
The Bison parser reads a sequence of tokens as its input, and groups the tokens using the grammar rules. If the input is valid, the end result is that the entire token sequence reduces to a single grouping whose symbol is the grammar’s start symbol. If we use a grammar for C, the entire input must be a ‘sequence of definitions and declarations’. If not, the parser reports a syntax error.
1.2 From Formal Rules to Bison Input
A formal grammar is a mathematical construct. To define the language for Bison, you must write a file expressing the grammar in Bison syntax: a Bison grammar file. See Chapter 3 [Bison Grammar Files], page 51.
A nonterminal symbol in the formal grammar is represented in Bison input as an iden- tifier, like an identifier in C. By convention, it should be in lower case, such as expr, stmt or declaration.
The Bison representation for a terminal symbol is also called a token type. Token types as well can be represented as C-like identifiers. By convention, these identifiers should be upper case to distinguish them from nonterminals: for example, INTEGER, IDENTIFIER, IF or RETURN. A terminal symbol that stands for a particular keyword in the language should be named after that keyword converted to upper case. The terminal symbol error is reserved for error recovery. See Section 3.2 [Symbols], page 57.
A terminal symbol can also be represented as a character literal, just like a C character constant. You should do this whenever a token is just a single character (parenthesis, plus-sign, etc.): use that same character in a literal as the terminal symbol for that token.
A third way to represent a terminal symbol is with a C string constant containing several characters. See Section 3.2 [Symbols], page 57, for more information.
The grammar rules also have an expression in Bison syntax. For example, here is the Bison rule for a C return statement. The semicolon in quotes is a literal character token, representing part of the C syntax for the statement; the naked semicolon, and the colon, are Bison punctuation used in every rule.
stmt: RETURN expr ’;’ ;
See Section 3.3 [Syntax of Grammar Rules], page 59.
1.3 Semantic Values
A formal grammar selects tokens only by their classifications: for example, if a rule mentions the terminal symbol ‘integer constant’, it means that any integer constant is grammatically valid in that position. The precise value of the constant is irrelevant to how to parse the input: if ‘x+4’ is grammatical then ‘x+1’ or ‘x+3989’ is equally grammatical.
But the precise value is very important for what the input means once it is parsed. A compiler is useless if it fails to distinguish between 4, 1 and 3989 as constants in the program! Therefore, each token in a Bison grammar has both a token type and a semantic value. See Section 3.4 [Defining Language Semantics], page 61, for details.
The token type is a terminal symbol defined in the grammar, such as INTEGER, IDENTIFIER or ’,’. It tells everything you need to know to decide where the token may validly appear and how to group it with other tokens. The grammar rules know nothing about tokens except their types.
The semantic value has all the rest of the information about the meaning of the token, such as the value of an integer, or the name of an identifier. (A token such as ’,’ which is just punctuation doesn’t need to have any semantic value.)
For example, an input token might be classified as token type INTEGER and have the semantic value 4. Another input token might have the same token type INTEGER but value 3989. When a grammar rule says that INTEGER is allowed, either of these tokens is acceptable because each is an INTEGER. When the parser accepts the token, it keeps track of the token’s semantic value.
Each grouping can also have a semantic value as well as its nonterminal symbol. For example, in a calculator, an expression typically has a semantic value that is a number. In a compiler for a programming language, an expression typically has a semantic value that is a tree structure describing the meaning of the expression.
1.4 Semantic Actions
In order to be useful, a program must do more than parse input; it must also produce some output based on the input. In a Bison grammar, a grammar rule can have an action made up of C statements. Each time the parser recognizes a match for that rule, the action is executed. See Section 3.4.6 [Actions], page 64.
Most of the time, the purpose of an action is to compute the semantic value of the whole construct from the semantic values of its parts. For example, suppose we have a rule which says an expression can be the sum of two expressions. When the parser recognizes such a sum, each of the subexpressions has a semantic value which describes how it was built up. The action for this rule should create a similar sort of value for the newly recognized larger expression.
For example, here is a rule that says an expression can be the sum of two subexpressions:
expr: expr ’+’ expr { $$ = $1 + $3; } ;
The action says how to produce the semantic value of the sum expression from the values of the two subexpressions.
1.5 Writing GLR Parsers
In some grammars, Bison’s deterministic LR(1) parsing algorithm cannot decide whether to apply a certain grammar rule at a given point. That is, it may not be able to decide (on the basis of the input read so far) which of two possible reductions (applications of a grammar rule) applies, or whether to apply a reduction or read more of the input and apply a reduction later in the input. These are known respectively as reduce/reduce conflicts (see Section 5.6 [Reduce/Reduce], page 113), and shift/reduce conflicts (see Section 5.2 [Shift/Reduce], page 108).
To use a grammar that is not easily modified to be LR(1), a more general parsing algorithm is sometimes necessary. If you include %glr-parser among the Bison declarations in your file (see Section 3.1 [Grammar Outline], page 51), the result is a Generalized LR (GLR) parser
Traduction - coréen 1 Bison 개념
이 장에는 Bison의 기본 개념이 설명되어 있습니다. 기본 개념을 이해하지 못하면 Bison에 대한 자세한 설명을 이해하기 어렵습니다. Bison이나 Yacc의 사용법을 모르시면 이 장을 매우 주의깊게 읽으십시오.
1.1 언어 및 문맥 무관 문법(CFG)
Bison으로 언어를 구문분석하려면, 이 언어를 문맥 무관 문법(CFG: Context-Free Grammar)으로 기술해야 합니다. 즉, 하나 이상의 구문 그룹(syntactic groupings)을 지정하고 부속 요소로 구문 그룹을 작성합니다. 예를 들어, C 언어에서 그룹의 한 종류를 ‘식(expression)’이라고 부릅니다. 식을 구성하는 한 가지 규칙은 “식은 음수 부호와 다른 식으로 구성될 수 있습니다”. “식은 정수가 될 수 있습니다”도 식이 될 수있습니다. 알 수 있는 것처럼, 규칙은 흔히 회귀적이지만, 회귀에서 빠져나오도록 하는 규칙이 적어도 하나는 존재해야 합니다.
이런 규칙을 사람이 읽을 수 있도록 표현하기 위한 가장 흔한 방식은 BNF(Backus-Naur Form)입니다. BNF 방식은 Algol 60 언어를 지정하기 위해 개발되었습니다. BNF 방식으로 표현된 모든 문법은 문맥 무관 문법입니다. Bison에 입력하는 파일은 사실상 기계가 판독할 수 있는 BNF로 되어 있습니다.
문맥 무관 문법(이하 CFG)에는 중요한 다양한 하위 종류가 있습니다. CFG는 거의 대부분의 문맥 무관 문법을 처리할 수 있습니다. Bison은 LR(1) 문법에 최적화되어 있습니다. 간략하게 말하자면, LR(1) 문법에서는 미리 읽기 토큰 한 개만으로 입력 문자열의 모든 부분을 구문분석할 수 있습니다. 역사적인 이유로 인해, Bison은 기본적으로 LALR(1) 제약 조건에 의해 제한됩니다. LALR(1)을 간단하게 설명하기는 어렵습니다. 자세한 설명은 116쪽 단원 5.7 [불분명한 충돌]을 참조하십시오. 실험적인 기능이지만, IELR(1) 또는 표준 LR(1) 구문분석기 표를 요청하여 이런 추가적인 제약 조건을 피할 수 있습니다. 자세한 방법은 118쪽 단원 5.8.1 [LR 표 생성]을 참조하십시오.
LR(1) 문법용 구문분석기는 확정적입니다. 확정이란 말의 뜻은 입력의 특정 지점에서 적용할 다음 문법 규칙이 이전 입력과 남은 입력의 고정 유한 부분(미리보기, lookahead)에 의해 고유하게 결정(확정)된다는 것을 의미합니다. 문맥 무관 문법은 모호할 수도 있습니다. 동일한 입력값을 얻기위해 문법 규칙을 여러 가지 방식으로 적용할 수 있다는 뜻입니다. 모호하지 않은 문법도 불확정적일 수 있습니다. 적용할 다음 문법 규칙을 결정하는데 유한 길이 미리보기(lookahead)가 항상 충분하지는 않습니다. 올바르게 선언하면, Bison은 GLR(일반화된 LR) 구문분석 기법을 사용하여 이런 일반적인 문맥 무관 문법을 구문분석할 수 있습니다. 주어진 문자열의 가능 구문분석 방법 수가 유한할 경우, Bison의 GLR 구문분석기는 이런 모든 문맥 무관 문법을 처리할 수 있습니다.
언어의 정규 문법 규칙에서, 구문 단위 또는 그룹의 각각의 종류는 기호(symbol)에 의해 이름이 지정됩니다. 문법 규칙에 따라 더 작은 구성요소를 그룹화하여 작성되는 것들을 비말단 기호(nonterminal symbols) 라고 부릅니다. 더 이상 분해할 수 없는 것들을 말단 기호(terminal symbol) 또는 토큰 종류(token type)라고 부릅니다. 하나의 말단 기호에 해당하는 입력값을 토큰(token)이라고 부르고 하나의 비말단 기호에 해당하는 것을 그룹(grouping)이라고 부릅니다.
C 언어를 예로 들어, 기호, 말단, 비말단의 뜻을 살펴보겠습니다. C 언어의 토큰은 식별자, 상수(숫자 및 문자열), 다양한 예약어, 산술 연산자 및 구두점입니다. 그러므로 C 언어의 말단 기호는 ‘식별자’, ‘숫자’, ‘문자열’, 각 예약어의 기호, 연산자 또는 구두점입니다. 예를 들어, ‘if’, ‘return’, ‘const’, ‘static’, ‘int’, ‘char’, ‘덧셈 부호’, ‘열기 중괄호’, ‘닫기 중괄호’, ‘쉼표’ 등등이 있습니다. (이런 토큰들은 문자로 세분화할 수 있지만, 이것은 문자분석기에 관련된 것으로 문법과는 무관합니다.)
간단한 C 언어 함수를 토큰별로 세분화한 것입니다:
int /* 예약어 ‘int’ */
square (int x) /* 식별자, 열기 괄호, 예약어 ‘int’,
식별자, 닫기 괄호 */
{ /* 열기 중괄호 */
return x * x; /* 예약어 ‘return’, 식별자, 별표,
식별자, 세미콜론 */
} /* 닫기 중괄호 */
C 언어의 구문 그룹에는 식, 문, 선언 및 함수 정의가 포함됩니다. 이런 것들은 C 언어 문법에서 ‘expression’, ‘statement’, ‘declaration’ 및 ‘function definition’ 등과 같은 비말단으로 표현됩니다. 완전한 문법에서는 이런 것들 네 개의 의미를 표현하기 위해 십여개의 추가적인 언어 구성요소(각각에는 자신의 비말단 기호가 있음)가 사용됩니다. 위의 예는 함수 정의입니다. 여기에는 한 개의 선언과 한 개의 문이 포함되어 있습니다. 문에서, 각 ‘x’는 식이고 ‘x * x’도 역시 식입니다.
각 비말단 기호에는 더 간단한 구성요소를 사용하여 이것이 어떻게 구성되었는지를 알려주는 문법 규칙이 있어야 합니다. 예를 들어, C 언어 문의 한 종류는 return 문입니다. 이것은 아래와 같은 문법 규칙으로 표현될 수도 있습니다.
‘statement’는 ‘return’ 예약어와 ‘expression’ 및 ‘세미콜론’으로 구성될 수 있습니다. ‘statement’에 대한 여러 가지 다른 규칙이 있을 수 있으며 C 언어의 각 문마다 하나씩 규칙이 있습니다. 하나의 비말단 기호는 언어에서 완전한 전체 프로그램을 정의하는 특별한 것으로 구별되어야 합니다. 이것을 시작 기호(start symbol)라고 부릅니다. 컴파일러에서 이것은 완전한 입력 프로그램을 의미합니다. C 언어에서 비말단 기호 ‘정의와 선언 열’이 이 역할을 수행합니다.
예를 들면, ‘1 + 2’는 올바른 C 언어 식이고 C 언어 프로그램의 올바른 부분이지만 완전한 C 언어 프로그램은 되지 못합니다. C 언어의 문맥 무관 문법에서, ‘식’은 시작 기호가 아니기 때문입니다.
Bison 구문분석기는 일련의 토큰들을 입력값으로 읽어들이고 문법 규칙으로 토큰을 그룹화합니다. 입력값이 올바르면, 전체 토큰 열이 문법의 시작 기호인 하나의 단일 그룹으로 줄어듭니다. C 언어 문법을 사용할 경우, 전체 입력은 하나의 ‘정의와 선언 열’이 되어야 합니다. 그렇지 않으면, 구문분석기는 구문 오류를 보고합니다.
1.2 정규 규칙에서 Bison 입력으로
정규 문법은 수학적 구성요소입니다. Bison에 사용할 언어를 정의하려면 Bison 구문 형식으로 문법을 지정하는 파일을 작성해야 합니다. 이것을 Bison 문법 파일이라고 부릅니다. 51쪽 3장 [Bison 문법 파일]을 참조하십시오.
Bison 입력 파일에서, 정규 문법의 비말단 기호는 C 언어의 식별자처럼, 식별자로 표시됩니다. 일반적으로 비말단 기호는 expr, stmt 또는 declaration처럼 소문자로 표시해야 합니다.
Bison에서 말단 기호를 표시할 때, 말단 기호는 토큰 종류라고 불립니다. 토큰 종류도 C 언어같은 식별자로 나타낼 수 있습니다. 일반적으로, 이런 식별자들은 대문자로 표시하여 비말단 기호와 구별합니다. 예를 들어, INTEGER, IDENTIFIER, IF 또는 RETURN 등입니다. 언어에서 특정 예약어를 나타내는 말단 기호는 해당 예약어를 대문자로 변환한 이름을 사용해야 합니다. 말단 기호 error는 오류 복구를 위해 예약되어 있습니다. 57쪽 단원 3.2 [기호]를 참조하십시오.
또한 말단 기호는 C 언어 문자 상수처럼 문자 리터럴로도 나타낼 수 있습니다. 토큰이 단일 문자(괄호, 더하기 기호, 등)로 되어 있을 때는 항상 이렇게 해야 합니다. 리터럴에 들어있는 동일한 문자를 해당 토큰에 대한 말단 기호로 사용하십시오.
말단 기호를 나타내는 세번째 방법은 여러 문자가 들어 있는 C 문자열 상수를 사용하는 것입니다. 자세한 설명은 57쪽 단원 3.2 [기호]를 참조하십시오.
Bison 구문에서, 문법 규칙에는 식도 있습니다. 예를 들어, 다음은 C 언어 return 문에 대한 Bison 규칙입니다. 따옴표로 묶인 세미콜론은 리터럴 문자 토큰으로, C 언어 구문에서 문을 나타냅니다. 따옴표로 묶이지 않은 세미콜론과 콜론은 모든 규칙에서 사용해야 되는 Bison 구두점입니다.
stmt: RETURN expr ’;’ ;
59쪽 단원 3.3 [문법 규칙의 구문]을 참조하십시오.
1.3 의미소 값
정규 문법은 분류를 통해서만 토큰을 선택합니다. 예를 들어, 규칙이 ‘정수 상수’ 말단 기호를 언급할 때, 모든 정수 상수가 해당 위치에서 문법적으로 유효합니다. 상수의 정확한 값은 입력을 구문분석하는 방법과는 무관합니다. ‘x+4’가 문법적으로 올바르면 ‘x+1’ 또는 ‘x+3989’도 마찬가지로 문법적으로 올바릅니다.
그러나 일단 구문분석된 후에는 입력값의 의미를 알기 위해 정확한 값은 매우 중요합니다. 프로그램에서 4, 1 및 3989 상수를 구분할 수 없다면 컴파일러는 쓸모가 없어집니다. 그러므로, Bison 문법에 들어 있는 각 토큰에는 토큰 종류와 의미소 값이 들어 있습니다. 자세한 내용은 61쪽 단원 3.4 [언어 의미소 지정]을 참조하십시오.
토큰 종류는 INTEGER, IDENTIFIER 또는 ‘,’처럼 문법에 정의되는 말단 기호입니다. 이것은 해당 토큰을 올바르게 사용할 수 있는 위치를 결정하거나 다른 토큰과 그룹화하는 방법 등에 대한 모든 것을 알려줍니다. 문법 규칙은 토큰 종류 외에는 토큰에 대한 아무것도 알지 못합니다.
의미소 값은 정수의 값 또는 식별자의 이름처럼 토큰의 의미에 대한 나머지 모든 정보를 갖고 있습니다. (단순 구두점인 ‘,’ 같은 토큰에는 의미소 값이 필요없습니다.)
예를 들어, 어떤 입력 토큰은 INTEGR 토큰 종류로 분류되고 의미소 값 4를 가질 수 있습니다. 다른 한 입력 토큰도 INTEGER 토큰 종류가 될 수 있으나 값은 3989가 될 수 있습니다. 문법 규칙이 INTEGER 토큰 종류를 허용하면, 두 토큰 모두 INTEGER이므로, 이들 두 토큰 중 아무것을 사용할 수 있습니다. 구문분석기가 토큰을 받아들이면 해당 토큰의 의미소 값을 보관해 둡니다.
각각의 그룹도 비말단 기호처럼 의미소 값을 가질 수 있습니다. 예를 들어, 계산기에서 식은 일반적으로 숫자인 의미소 값을 갖습니다. 프로그래밍 언어의 컴파일러에서, 일반적으로 식은 해당 식의 의미를 표현하는, 트리 구조로 된 의미소 값을 갖습니다.
1.4 의미소 액션
쓸모있는 프로그램이 되려면 입력값을 구문문석하는 것만으로는 부족합니다. 프로그램은 입력값을 기반으로 출력할 수 있어야 합니다. Bison 문법에서, 문법 규칙에는 C 언어 문으로 구성된 액션이 있을 수 있습니다. 구문분석기가 해당 규칙에 일치하는 것을 탐지할 때마다 액션이 실행됩니다. 64쪽 단원 3.4.6 [액션]을 참조하십시오.
대부분의 경우, 액션의 목적은 구성요소의 의미소 값으로부터 구성 전체의 의미소 값을 계산하는 것입니다. 예를 들어 식이 다른 두 식의 합계가 될 수 있다는 규칙이 있다고 생각해 봅시다. 구문분석기가 이런 합계를 탐지할 때, 각각의 하위 식에는 식이 어떻게 구성되는지를 나타내는 의미소 값이 들어 있습니다. 해당 규칙의 액션은 새로 탐지된 더 큰 식을 위해 비슷한 종류의 값을 계산해야 합니다.
예를 들어, 특정 식이 두 하위 식의 합계가 될 수 있고 지정하는 규칙이 있습니다.
expr: expr ’+’ expr { $$ = $1 + $3; } ;
액션은 두 하위 식의 값으로 합계 식의 의미소 값을 계산하는 방법을 지정합니다.
1.5 GLR 구문분석기 작성
일부 문법에서 Bison의 확정적 LR(1) 구문분석 알고리듬은 특정 지점에서 특정 문법 규칙의 적용 여부를 판단할 수 없을 수도 있습니다. 즉, 지금까지 읽어들인 입력값을 기반으로 가능한 두 줄임(문법 규칙의 적용) 중에서 어느 것을 적용할지 결정할 수 없거나, 줄임을 적용할지 아니면 입력을 더 읽어들인 후에 입력의 나중 부분에서 줄임을 적용할지를 판단할 수 없을 수도 있습니다. 이것들을 각각 줄임/줄임 충돌(113쪽 단원 5.6 [줄임/줄임] 참조) 및 이동/줄임 충돌(108쪽 단원 5.2 [이동/줄임] 참조)이라고 부릅니다.
LR(1)으로 쉽게 수정할 수 없는 문법을 사용하려면 보단 일반적인 구문분석 알고리듬이 때때로 필요합니다. 파일의 Bison 선언 부분에 %glr-parser를 삽입하면(51쪽 단원 3.1 [문법 개요] 참조), GLR(일반화된 LR) 구문분석기가 만들어집니다.
More
Less
Études de traduction
Bachelor's degree - Inchon National Universtiy
Expérience
Années d'expérience en traduction : 28. Inscrit à ProZ.com : Jan 2000.
I am a professional freelance translator since 1996, but I also lead a team of professional translators, click the button below to visit our website:
You can either chat with us now by clicking the button below. It is web-based technology, and you do not need to install any software on your machine .
If you accept me as your English to Korean translator, you can benefit the following advantage from me over other English to Korean translators.
1. My translation is final, that said, my translation is of production quality. I mean you do not need to hire or have another Korean translator proofread and/or edit my translation. My translations have never been rejected by any Korean translation vendors.
2. I am very Responsive and Responsible, Fast, Efficient, and Proficient. For example, I usually translate 6,000 or more English words almost every day. Remember? I have been translating since 1996 as a professional freelance translator.
3. I do not miss a single source word in my translation, and my translation is professional and flawless, properly adapted to Korean culture.
You can save your budget and time as well as unnecessary concerns about your Korean translation.
Cet utilisateur a gagné des points KudoZ en aidant d'autres traducteurs sur des termes de niveau PRO. Cliquez sur le total des points pour afficher les traductions proposées.
Total des points gagnés: 24 Points de niveau PRO: 16
Compétences