昨日 Bertrand Joël によって報告された問題を修正しました。match_attr_spec()これには、型のために完全に書き直す必要がありましたCHARACTER。問題は、ダブル コロンが表示されるまで、型が文字の場合に属性指定を参照していると確信できないことです。標準では、次のようなことが許可されています。
CHARACTER*(*)、保存、ターゲット、パラメータ
save、 targetおよびparameter! という名前の 3 つの変数を定義します。他のタイプの類似コード
INTEGER、保存、ターゲット、パラメーター
違法です。仕様キーワード (コンマで始まる) を見れば、属性仕様が表示されていることが保証されると当初は思っていましたが、そうではないことが判明しました。
newmatch_attr_specがしなければならないことは、各属性キーワードを読み取り、二重コロンが得られるまでそれらを保存することです。この時点で、属性が意味を成していることを確認することができます。これより前は、 を返すことしかできませんMATCH_NO。
7月12日
Bertrand Joël さんは、文字型宣言に関するパーサーのバグに関するバグを報告しました。この混乱は、古いスタイルの宣言と新しいスタイルの宣言が混在していたために生じました。今夜はそれを修正する時間はありません。
Tobi Schlüter は、変数のマッチングによって生成された式ノードに遺伝子座情報を追加する小さなパッチを送信しました。
7月11日
昨夜は更新がありませんでした。私のモニターには、多くの内部電気アークの問題がありました。私は買い物に行き、今では新しい、はるかに優れたモニターを手に入れました. コンピュータの価格が下がっているのは驚くべきことです。この新しい 17 インチは、数年前に古い 15 インチに支払った金額の約半分でした。
そして、最高の部分の1つ?? あの「新しいパソコン」の匂い！
とにかく、私は複雑な算術に少し取り組みました。複素数の足し算、引き算、掛け算、割り算、比較ができるようになりました。部分文字列のジレンマを解決する方法は、関数ルートに行くことだと考えています。EXPR_CONSTANT の定数を保持し、実行する必要があるすべてのことを実行できます。
G95 は現在 19,000 行の長さです。
7月9日
部分文字列参照の解析に少し取り組みました。たくさんのコードがありますが、何かのジレンマにぶつかったため、呼び出されていません。問題は、定数文字列の後に現れる部分文字列参照の大文字と小文字をどのように格納するかに関係しています。通常、サブオブジェクトへの参照 (構造参照、配列参照、部分文字列参照など) は、親シンボルを指す式ノードに関連付けられた g95_ref 構造の単一リンク リストに格納されます。
文字列定数の部分文字列を格納する「明らかな」方法は、定数文字列を表す式ノード構造に参照構造 (開始インデックスと終了インデックスを保持する) を追加するだけです。問題は、ノードが EXPR_CONSTANT のタイプを持っていることです。これは、範囲が他の変数で構成される可能性があるため、もはや実際には定数ではありません。代入できないため、変数でもありません。
私の経験では、このように微妙な方法でフラグの意味を変更することは悪い考えです。長い間忘れていた仮定を非常に簡単に破ることができます。これを行う他の同様に嫌な方法は次のとおりです。ノードのタイプをEXPR_OPにし、新しい組み込みの「部分文字列」演算子を定義します。または、おそらく最良の方法は、式ノードを事前に解決された関数を持つEXPR_FUNCTIONノードにすることです。部分文字列を「実行」します。いずれにせよ、現時点で行う最善の方法は、それについて寝て、後で決定を下すことです.
配列での類似のケース
i = 1、5を行います
print *, (/ 5, 4, 3, 2, 1 /)(i)
遠藤
何らかの理由で標準によって明確に禁止されています。
いくつかの組み込み関数解決の問題をいじって、私もそこに頭を悩ませていることに気づきました-プログラミングで多くの人が犯す最大の間違いの1つは、どこに行くのかをあまり考えずに、ただ飛び込んでコードを書くことだと思います.
