問題タブ [oberon]

64 ビット マシンで OpenBUGS をコンパイルする必要がありますが、そのリポジトリ ( http://sourceforge.net/projects/openbugs/develop ) は多数の .ocf ファイルで構成されています。Linux で動作するコンパイラはどこにありますか?

CFカードにQNXパーティションがあり、SBCで実行されています。Explorerインターフェイスなどを使用して、Windowsのファイルシステムにアクセスするにはどうすればよいですか？

ファイルシステムはQNXOberonにあります。QNX Momentics IDEも持っていますが、それも役に立ちません。

私はオベロンを学ぶことに本当に興味があります。独自の継承とポリモーフィズムがあり、GUIが組み込まれていると聞きました（GUIが大好きです！）。

いくつかのドキュメント（できれば単純なドキュメント）とIDE/コンパイラへのリンクをいただければ幸いです。

ありがとう。

AdaにはGUIが組み込まれていますか？また、継承に対する独自のアプローチはOberonと同じですか？

次のEBNF文法（PL / 0のウィキペディアにあります）を考えると、「ODD」キーワードの前にある式は何ですか？簡単な言語を小さなプロジェクトとして実装したいのですが、これが何を意味するのか理解できないようです。私がその言語のコンパイラを正しく書くことができるように、誰かが以前にこれの頭を持っているか、奇妙な表現が何であるかを解釈することができますか？

私はオベロン言語に興味を持っています。知りたいのですが、この言語は実際に一般的なプログラマーによって使用されているのでしょうか、それともまだ研究者だけが使用しているのでしょうか。本番環境に対応していますか？私が念頭に置いているのは、GUIサポートとおそらくインターネット接続（少なくともクライアント側のPOP3およびSMTP機能）を必要とする非科学的なアプリケーションです。また、私のニーズに合ったOberonフレーバー（Oberon2、Active Oberonなど）はどれですか？それがよく維持され、いくつかのコミュニティを持っている限り、シンプルであるほど良いです。可能であれば、特別なランタイム環境や特別なオペレーティングシステムを必要とせずに、従来のホスト環境（WindowsまたはLinux）でアプリケーションを実行したいと思います。

ありがとう

私は Oberon に関する Wirth の本を読んでいます (または、少なくともそうしようとしています)。そして、Oberon でオブジェクト指向プログラミングに関して何が起こっているのかを理解することになると、精神的な障害にぶつかっています。

彼のメソッドは、「標準」の OOP 構文を回避することでオブジェクト指向プログラミングを簡素化することになっていることを私は知っています。しかし、誰かがオベロンの方法を標準的な OOP 言語に翻訳したり、少なくとも概念的に説明したりできますか。

私は現在、Antlr と Eclipse を使用して Oberon 言語のパーサーを構築しようとしています。

これは私がこれまでに得たものです：

私の問題は、文法をチェックすると、次のエラーが表示され、これを修正する適切な方法が見つからないことです。

また、declarationsequence と simpleexpression にも問題があります。

私がそれを使用するoptions { … backtrack = true; … }と、少なくともコンパイルされますが、テストファイルを実行すると明らかに正しく動作しなくなりますが、自分で左再帰を解決する方法が見つかりません (または、盲目すぎるかもしれません)あまりにも長い間これを見てきたため、現時点では）。エラーが発生した行を変更して機能させる方法はありますか?

編集 3つの間違いのうちの1つを修正できました。statement今すぐ動作します。問題はそれでassignment、procedurecall両方ともdesignator.

Oberon が、レコードの型宣言には存在せず、その拡張機能の 1 つにのみ存在するレコード内のフィールドのアドレス指定を許可するかどうかを調べようとしています。

PIO (" Programming in Oberon ") の 62 ページ、最初のパラグラフの最後の文で、Wirth は次のように書いています (1):

これで、プログラミングのオブジェクト指向パラダイムの簡単な紹介を終わります。Oberon をサポートするために Oberon に追加する必要のある言語機能はほとんどないことを認識しています。レコードと手続き型の既存の機能とは別に、型拡張の概念だけが必要かつ重要です。型の階層を構築し、不均一なデータ構造を構築することができます。厳密な静的型付けのルールを放棄した結果、動的型付けテストの導入が必要になりました。型ガードのその他の機能は、便利な機能の 1 つにすぎません。

PIO の 59 ページ、セクション 23.2 の前の最後の段落の最初の 3 つの文で、彼は次のように書いています (2):

p はフィールド半径を持たない Figure 型であるため、単純な指定子 p.radius は受け入れられません。型ガードを使用すると、プログラマーは、この場合 p も Circle 型であることを確認できます。この場合、フィールド半径は実際に適用されます。p は基本タイプの Figure ですが、p(Circle) はタイプ Circle です。

一方で、指定子の型宣言に含まれていないフィールドをアドレス指定できるようにするために、型ガードが絶対に必要であると #2 を解釈します。型ガードがなければ、そのようなフィールドをアドレス指定すると、コンパイル時エラーが発生するはずです。

一方、#1 で示唆されているように、タイプ ガードが単なる便宜上のものである場合は、省略することもできます。その機能は単に assert の機能であり、その結果、コンパイラは指定子の型宣言に含まれていないフィールドのアドレス指定を許可する可能性があります。

後者はタイプ セーフではないため、Wirth がそのように意図していたとしたら驚きです。

したがって、私は #1 を完全に無視して #2 を実装する傾向があります。

Wirth に電子メールを送信する前に、Oberon の実践者 (およびコンパイラの実装者) が、それぞれの Oberon コンパイラでこれがどのように解釈されるかを共有していただければ幸いです。

前もって感謝します