Vaidehi Joshi

Follow

Nov 27, 2017 · 16 min read

Software is all about logic. プログラミングは、数学と狂気の方程式に重いフィールドであることの評判を集めています。 そして、コンピュータサイエンスは、この誤解の核心にあるようです。確かに、いくつかの数学があり、いくつかの式があります—しかし、私たちのマシンがどのように機能するかを理解するために、実際に微積分学の博士号を 実際、私たちがコードを書く過程で学ぶ多くのルールとパラダイムは、複雑なコンピュータサイエンスの概念に適用されるのと同じルールとパラダイムです。 そして時には、これらのアイデアは実際にコンピュータサイエンスに由来し、私たちはそれを知らなかった。

私たちが使用するプログラミング言語にかかわらず、私たちのほとんどがコードを書くとき、私たちは意図的に私たちのコードの異なる部分が関 言い換えれば、1つのクラス、オブジェクト、またはメソッドが1つのものだけに関係し、責任を負うように、コードを分割することは一般的に良いこと 私たちがこれをしなければ、物事は非常に乱雑になり、ウェブの混乱に絡み合う可能性があります。 時には、これは依然として懸念の分離でさえも起こります。

結局のところ、私たちのコンピュータの内部の仕組みでさえ、非常によく似た設計パラダイムに従います。 たとえば、コンパイラにはさまざまな部分があり、各部分はコンパイルプロセスの特定の部分を処理する責任があります。 先週、解析木の作成を担当するパーサーについて学んだときに、このことに少し遭遇しました。 しかし、パーサーはおそらくすべてを担当することはできません。

パーサーは仲間からの助けを必要とし、最終的に彼らが誰であるかを学ぶ時です！

最近解析について学んだとき、私たちは文法、構文、そしてコンパイラがプログラミング言語内でそれらのことにどのように反応し、応答するかに しかし、コンパイラが何であるかを実際に強調したことはありません！ コンパイルプロセスの内部の仕組みに入ると、コンパイラの設計について多くのことを学ぶことになるので、ここで何を話しているのかを正確に理

コンパイラは怖いように聞こえるかもしれませんが、彼らの仕事は実際には理解するにはあまりにも複雑ではありません。

しかし、最初に、可能な限り最も単純な定義から始めましょう。 コンパイラは、私たちのコード（または任意のコード、任意のプログラミング言語）を読み取り、それを別の言語に変換するプログラムです。

一般的に言えば、コンパイラは実際には高レベルの言語から低レベルの言語にコードを翻訳するだけです。 コンパイラがコードを変換する下位レベルの言語は、アセンブリコード、マシンコード、またはオブジェクトコードと呼ばれることがよくあります。 それはほとんどのプログラマーが実際に扱うか、または機械コードを書いていないことを述べる価値がある;むしろ、私達は私達のプログラムを取り、私達のコンピュータが実行可能プログラムとして動くものである機械コードに翻訳するためにコンパイラーに依存する。

私たちは、コンパイラを、私たち、プログラマ、そして私たちのコンピュータの間の仲介者と考えることができます。

コンパイラは、私たちのマシンが理解し、実行可能な方法で起こりたいことを翻訳する作業を行います。

コンパイラがなければ、マシンコードを書くことによってコンピュータと通信することを余儀なくされます。 マシンコードは、多くの場合、人間の目には0と1の束のように見えることがあります—それはすべてバイナリです、覚えていますか？ -これは、読み取り、書き込み、およびデバッグすることが非常に困難になります。 コンパイラは、マシンコードについて考えずに、はるかにエレガントで明確で読みやすい言語を使用してプログラムを書くことを非常に簡単にした

私たちは、今後数週間にわたって神秘的なコンパイラについてますます解凍していきます。 しかし、今のところ、手元の質問に戻りましょう：コンパイラの最も単純な部分は何ですか？

各コンパイラは、どのように設計されていても、異なるフェーズを持っています。 これらのフェーズは、コンパイラの固有の部分をどのように区別できるかです。Div>

: phase one of a compiler

最近、パーサーと解析ツリーについて学んだとき、コンパイルの冒険ですでにフェーズの一つに遭遇しました。 私たちは、解析は、いくつかの入力を取り、それから解析ツリーを構築するプロセスであることを知っています,これは時々解析の行為と呼ばれています. 結局のところ、構文解析の作業は、構文解析と呼ばれるコンパイルプロセスのフェーズに固有のものです。

しかし、パーサーは薄い空気から解析ツリーを構築するだけではありません。 それはいくつかの助けを持っています！ パーサーにはいくつかのトークン(端末とも呼ばれます)が与えられ、それらのトークンから解析ツリーが構築されていることを思い出します。 しかし、それはどこからそれらのトークンを取得しますか？ パーサーにとって幸運なことに、それは真空中で動作する必要はありません。

これは、構文分析フェーズの前に来るコンパイルプロセスの別のフェーズ、すなわち字句分析フェーズに私たちをもたらします。div>

“語彙”という用語は、それを含む文から分離して、その文法的な文脈にかかわらず、単語の意味を指します。 この定義だけに基づいて自分の意味を推測しようとすると、字句解析フェーズはプログラム自体の個々の単語/用語と関係があり、単語を含む文の文法や意

字句解析フェーズは、コンパイルプロセスの最初のステップです。 それは文の文法やテキストやプログラムの意味を知っていたり気にしたりしません。

ソースプログラムのコードを解析するには、字句解析を行う必要があります。 パーサーが読み取る前に、プログラムを最初にスキャンし、分割し、特定の方法でグループ化する必要があります。

先週、構文解析フェーズを見始めたとき、構文解析ツリーは文の個々の部分を見て、式をより単純な部分に分解することによって構築されることを学びま しかし、字句分析段階では、コンパイラはこれらの「個々の部分」を認識していないか、アクセスできません。 むしろ、最初にそれらを識別して見つけてから、テキストを個々の部分に分割する作業を行う必要があります。たとえば、To sleep, perchance to dream.のようなシェイクスピアの文を読むと、スペースと句読点が文の「単語」を分割していることがわかります。 これは、もちろん、文を読んで”lex”し、文法のために解析するように訓練されているためです。しかし、コンパイラにとっては、同じ文が最初に読み込まれたときにTosleepperhachancetodreamように見えるかもしれません。 この文を読むと、実際の「言葉」が何であるかを判断するのは少し難しいです！ 私たちのコンパイラは同じように感じていると確信しています。だから、私たちのマシンはこの問題をどのように処理しますか？ さて、コンパイルプロセスの字句解析フェーズでは、常に二つの重要なことを行います：コードをスキャンし、それを評価します。

スキャンと評価の仕事は、時には一つのプログラムにまとめたり、互いに依存する二つの別々のプログラムにすることができます。 スキャンと評価の作業を担当するコンパイラ内のプログラムは、しばしば字句解析またはトークナイザと呼ばれ、字句解析フェーズ全体は、字句解析またはトークナイザのプロセスと呼ばれることがあります。

スキャンするには、読むためのperchance

字句解析の二つのコアステップの最初はスキャンです。 スキャンは、入力されたテキストを実際に”読む”作業と考えることができます。 この入力テキストは、文字列、文、式、またはプログラム全体である可能性があることに注意してください！ プロセスのこの段階では、それはまだ何も意味しない文字の巨大な塊であり、連続した塊であるため、実際には問題ではありません。これがどのように正確に起こるかを確認するための例を見てみましょう。

ソーステキストまたはソースコードである元の文To sleep, perchance to dream.Tosleep,perchancetodream.のような入力テキストとして読み取られます。p>

私たちのコンパイラがしなければならない最初のことは、実際にテキストのblobを可能な限り小さな部分に分割することで、テキp>

巨大なテキストの塊をダイビングする最も簡単な方法は、それをゆっくりと体系的に、一度に一つの文字を読むことです。 そして、これはまさにコンパイラが何をするかです。

多くの場合、スキャン処理はスキャナと呼ばれる別のプログラムによって処理され、その唯一の仕事はソースファイル/テキストを一度に一 私たちのスキャナにとって、それは本当に私たちのテキストがどのように大きな問題ではありません;それは私たちのファイルを”読み取る”ときに表示されますすべては、一度に一つの文字です。

ここで私たちのシェイクスピアの文は、私たちのスキャナによって読み取られるものです: