Q&A
interpreter は「通訳者」という意味なので「翻訳しない」というのが間違いです。文脈や正確な言葉をよく確認してから質問してください。
インタプリタ言語の処理の仕組みを理解したく勉強しています。
「インタプリタは逐次的に解釈しながら実行していくものであって、機械語に翻訳しない」と書かれていますが、どういう意味でしょうか？
まず初心者は、プログラムは人間が書いたものなのでそれを機械語にする必要があって...ということから教えてもらうのですが、その上でインタプリタの上記の説明を聞くと、矛盾しているように聞こえます。
すなわち、解釈と翻訳の違いがよく分からないので、どなたか教えていただけませんでしょうか？
回答4件
0
機械語に翻訳しない
これは、機械語の翻訳したものを生成・保存しない ということです。
コンパイラでは、機械語への翻訳結果を保存 (例えば foo.exe とか) に保存して、
実際のプログラム実行は foo.exe を実行するようにします。
インタープリタでは、機械語の翻訳を保存しません。
プログラム実行は、ソースコードのファイルを読み込んで実行します。
英語の文章を日本語に翻訳して本にして、日本人がその本を読む というのが コンパイラ言語の実行の仕組みです。
英語の会話をその場で同時通訳して、その日本語を聞く というのが インタープリタ言語の実行の仕組みです。
これは あくまでも BASICな考えです。
実際には、機会後を保存せず、別の堅固の翻訳・保存し、実行ときはその別言語をインタープリトするとか、
インタープタで通訳した結果を保存しておいて、同じ文書が現れたときは、その翻訳結果を使うようにするなど、
コンパイラ・インタープリタが混在したようなものなっていることもあります。
(コンパイラー, インタープリタの各デメリットをなるべく無くそうとする工夫の結果です)
参考情報
- １分で理解できる！コンパイラとインタプリタの違い【初心者向け】
https://it-biz.online/it-skills/interpreter-compiler/
- インタープリタ方式とコンパイル方式
投稿2021/02/06 23:09
総合スコア22324
0
インタプリタは、そのコードを、いかにもそのとおりに実行しているように見せかけているだけ、です
そのコードに対応した機械語を生成してるわけではないです
投稿2021/02/06 08:11
総合スコア87800
0
ベストアンサー
今はそういう典型的なインタプリター言語はほぼないと思いますが、昔はありました。
例えば、下記の2種類の文だけがある簡単な言語を考えます。
print 10進定数 その数値を出力する
end プログラムの終了
この言語のインタプリターは例えば、
Python
1while True: 2 prog = input().split() 3 if prog[0]=="print": 4 print( int(prog[1]) ) 5 elif prog[0]=="end": 6 break
です。何も機械語に翻訳していませんよね？
繰り返し文や条件文など、またちゃんとした文法エラーメッセージも、同じ要領で機能追加していけます。
投稿2021/02/06 08:20
総合スコア84798
手抜きなので、読んで実行するの繰り返しですが、
while等の繰り返し文を実装するためには、前に戻らないといけないので、最初にソースファイルからプログラム全部を変数に読み込む必要があります。
ありがとうございます！
otn様の例であれば、例えばprintという文があったときに、それがインタープリタのif文の判定が真か偽かを判定する際には、機械語に翻訳して判定すると思うので、その意味では機械語に翻訳しているのではないでしょうか？
あなたの言う「機械語に翻訳」とは？
普通の意味での「機械語に翻訳」というのは、「print 3」とあった場合に、「3を出力する機械語プログラム」を作成してそれをファイルやメモリーに書き込むことです。
これがコンパイル言語です。
なるほど、私のいう機械語に翻訳とは、インタプリタ内での判定も含めた広い意味で使用してしまってました。あくまでも機械語に翻訳とは、その文に対応する機械語プログラムを作成するかどうかの意味ですね、ありがとうございました！
ああ、そういうことであれば、「上記のプログラムは翻訳しているのでコンパイラーだが、全く同じ処理をアセンブラ(機械語)で書けば翻訳していないのでインタープリター」というおかしな話になりますね。
otnさんの定義だとJAVAはコンパイラ言語ですか、それともインタプリタ言語ですか？
コンパイラ言語でしょう。
pythonは、読み込み時に内部でコンパイラが動いてバイトコードにコンパイルしていますが、これはコンパイラ言語ですか、それともインタプリタ言語ですか？
https://docs.python.org/ja/3/library/compileall.html
JavaScript や PHP は後から JIT が導入されていますね。
PythonやRubyはメモリ上でコンパイルしてそのまま動く言語ですが、それらに対してのコンパクトな名称を知りません。
内部動作を知らないとインタプリター言語に見えるということから、そう呼ばれることもあるようです。
Rubyは1.8までは、仮想マシンコードにコンパイルするのじゃなくて、ソースコードに対応する構文木をメモリ上に作って、それを読みながら実行していたそうですが、それだとインタプリターかなという気がします。ただ、境界線が厳密なわけじゃ無い。
pyhtonは.pyというファイルに格納されたソースをコンパイルしたバイトコードを.pycファイルに保存して、可能な限りそれを再利用していますので、メモリ上だけではありません。
境界線はあいまいだ、というのが正解だと思います。
https://www.cqpub.co.jp/hanbai/books/30/30851.HTM
C++インタプリタ ―― CINT
pycはimportされるものだと思っていましたが、
python foo.py と実行すると、foo.pyc があれば（タイムスタンプは見るとして）それが読まれるんでしたっけ？であれば、私の認識違いでした。
コンパイラ言語・インタプリタ言語というのは昔あった分類で、コンパイルされることが前提に設計された言語・インタプリタで実行されることが前提に設計された言語のことだと思いますが、実際にコンパイルされるかどうかは言語とは無関係なので別問題だと思います。
境界線が厳密とか曖昧とかいう問題ではなく、その言語で記述されたプログラムをどう扱うかは言語のあずかり知らぬところで、実行するためにどの処理系を使うかということでしかないため、境界は「線」に限らず、言語上には「無い」と思います。
つまりコンパイラ言語・インタプリタ言語というカテゴライズそのものがナンセンスです。
https://ja.wikipedia.org/wiki/REPL
C#, F#, Java, Kotlin などはコンパイルして使用されることが多いですが、REPL つまりインタプリタが存在します。
少なくとも私の書いているのは処理系の話です。コンパイラーもインタプリターも処理系の区分なので。
メジャーな処理系が複数種類ある言語もあるわけなので、「この言語が」と言った途端に厳密な話では無くなるのですが、そのあたり承知の上での話かと思っていました。
コンパイラやインタプリタは処理系ですが、それに「言語」とつければ言語の話になります。
はい。そのあたり承知の上での話かと思っていました。
承知の上であれば、どの言語がコンパイラ言語という話はナンセンスだと思いませんか？
> otnさんの定義だとJAVAはコンパイラ言語ですか、それともインタプリタ言語ですか？
> コンパイラ言語でしょう。
元の質問は「（純粋な）インタプリターとはどういう物か？」という趣旨だと思うので、そういう回答をしています。
回答はその通りだと思ったので高評価しましたが、その後のやり取りをみて外しました。
ああ、 ppaulさんには、「処理系次第だ」と回答すべきだった言うことですか？
それは ppaulさんも認識あると思っています。
そう回答すると、「では、一般にJDKとして配布されている物は？」とかいう質問になって、
その後の話もあまり変わらないのですが。
言語と処理系が混同されているように見えます。「コンパイラ言語」は言語の話です。先ほど書いたように、コンパイラ言語はコンパイラを前提とした言語であり、実際の実行にコンパイルという過程があったかなかったかは無関係でしょう。なぜなら、どのように実行しても言語が変わるわけではないからです。
まあ、ただ、言われて振り返ると、このコメント群を見た初心者が、勘違いする可能性を作り出してしまったのは事実ですね。
そういった意味では、 Zuishinさんにコメントいただいたおかげでそういう心配は無くなりました。
ありがとうございます。
話が合わない理由が分かった気がします。
「コンパイルされることを前提に設計された言語」は確かにあるけど、私は、それらを「コンパイラ言語」としてくくる意識が無かったです。
なので、コンパイラー、インタプリターという話になった途端、処理系を離れた言語の話では無くて、それぞれの言語のメジャーな処理系の話という風に思い込んで話してます。
JavaScript のメジャーな処理系はコンパイラです。つまり JavaScript はコンパイラ言語ということですか？
また PHP のメジャーな処理系はまだインタプリタですが、近いうちにコンパイラになると思われます。その場合、PHP はインタプリタ言語からコンパイラ言語になるわけですか？
私の考えでは、インタプリタ言語・コンパイラ言語というカテゴライズは古いもので、現在の多くの言語ではそのような分類はナンセンスと思っています。
> PythonやRubyはメモリ上でコンパイルしてそのまま動く言語ですが、それらに対してのコンパクトな名称を知りません。
と書きましたが、仮に「X型言語」と呼ぶとすると、
主要な処理系がインタプリター型からX型に変わるのであれば、X型言語と呼んで良いと思っています。
それにより将来、言語仕様が影響を受ける可能性もありますね。
> 内部動作を知らないとインタプリター言語に見えるということから、そう呼ばれることもあるようです。
とも思いますが。
つまり、今でもコンパイラ言語・インタプリタ言語というカテゴライズは有益であり、それなのに内部動作とは無関係にインタプリタ言語と呼ばれることもあるが、内部動作がどのように見えても X 型言語(しかし名前は決まっていない)であるということですか？
> 私の考えでは、インタプリタ言語・コンパイラ言語というカテゴライズは古いもので、現在の多くの言語ではそのような分類はナンセンスと思っています。
古いかどうかはともかく、これは同意ですが、分類したい人を許容しますので、否定はしません。
個人的には、（言語自体をインタプリタ型/コンパイラ型と区分するのはあまり有益な区分ではないことには同意するとして）、成果物を配布する場合に「ソースコード」で行う以外にないのか、「機械語・バイトコードなど、ソースコードから隔たった形式」として行えるのかで見分けるというのは、一定の意味があるかなと考えています。
ただ、これとてTypeScriptなどのような「成果物は別な言語のソースコード」という言語はどう区分するのかなど、確実に切れない点は残ります。
> つまり、今でもコンパイラ言語・インタプリタ言語というカテゴライズは有益であり、
有益とは言ってませんけど。呼びたい人がそう呼んでも許容しますし、
可能なら話を合わせます。（あまりむちゃくちゃを言わない限り）
今も昔も同じでは？昔は有益だったんですかね？
> 内部動作がどのように見えても X 型言語(しかし名前は決まっていない)であるということですか？
ここはちょっと意味がわかりません。
典型的なコンパイラー型でもインタプリター型でもない処理系があると言うことですが。
> 成果物を配布する場合に「ソースコード」で行う以外にないのか、「機械語・バイトコードなど、ソースコードから隔たった形式」として行えるのかで見分けるというのは、一定の意味があるかなと考えています。
難読化の需要は大きいですね。
> 昔は有益だったんですかね？
それぞれの特長がはっきりしていて使い分けられていた頃には有益だったと思います。
> 典型的なコンパイラー型でもインタプリター型でもない処理系があると言うことですが。
処理系ではなく X 型「言語」の話です。
＞ppaul 2021/02/06 20:21
＞pythonは、読み込み時に内部でコンパイラが動いてバイトコードにコンパイルしていますが、これはコンパイラ言語ですか、それともインタプリタ言語ですか？
CPython処理系に限って言えば、Python→Pythonバイトコードへの変換はコンパイラが行い、Pythonバイトコードはバイトコードインタプリタによって実行される。
よって言語はともかく処理系はインタプリタ（と、言いたい）。
（と、言いたい）の理由。
何らかの形で中間表現を置けば、コンパイラは重ねられる訳で、
本質的な対立は、「ネイティブコードへコンパイルするコンパイラ」/「インタプリタ」のところにある、と捉えれば、「言語」はともかく「処理系」はどちらかを含まないといけないため、非インタプリタ型/インタプリタ型、という形で分類することは可能、と捉えます。
hayataka2049さんの定義だと、Javaバイトコードを出力してJava仮想マシンが実行するJava処理系はインタプリタなのですね。
Java仮想マシンはJITコンパイル使うので、ギリギリコンパイラ……という（苦しいような）説明が一応可能。
100%インタプリタ実装のJVM作ったら（超大昔はそれだったらしいですが）、それはインタプリタじゃないの？ とは思っちゃったりはします。その場合でもJavaコードがJavaコンパイラによってJavaバイトコードに変換されると言うことはまったく妨げられない。
JITコンパイルができるのがコンパイラなら、python+numbaとか、python+Xbyakもコンパイラということですかね。
というように、この議論はそれぞれの人の主観的な判断になってしまうんじゃないでしょうか。
たとえばnumbaならLLVMのJITコンパイラがある訳で、ASTだかバイトコードか（どっちか正確に把握してないんですが）までCPythonでその下はまるっきり別の処理系にぶん投げてます……という話は客観的に可能なのでは？
どの範囲で言語処理系って称するかにもよるか……そこは確かに主観的というか自由に決められちゃう範囲かもしれません。
（common lispとか両方あるし）
0
ありがとうございます！
otn様の例であれば、例えばprintという文があったときに、それがインタープリタのif文の判定が真か偽かを判定する際には、機械語に翻訳して判定すると思うので、その意味では機械語に翻訳しているのではないでしょうか？
投稿2021/02/06 08:27
総合スコア4
a=1+2
という式を実行する場合、インタプリタは、aというキーワードを読み、変数だと判断し、１という数値を読み、＋という記号を読み、２という数値を読みます。
そして、１という数字と２という数字を加算して、その結果をaと名付けた変数(としているモノ)に格納します。
あくまで、インタプリタというプログラムが、その文字列を解釈して、そういうふうに実行させている、ってことですね
＋の処理を行う機械語、ってのはインタプリタの中で用意されてるかもしれませんが、これを使いまわしてるだけで生成はしません
最後の文の説明でしっくりきました。具体的に説明くださり、ありがとうございます！
あなたの回答
tips
プレビュー
