> それよりも，Konno さんの例で挙げれば，Ec（検索時の英大／小文字の同一視）を有効（デフォルトは無効）にしておくことに注意すべきかもしれません。
なるほど、いろいろと注意すべきことが湧いて出てきます。
> > このロジックでは、一旦変換した行番号が再変換の対象になりうる
> それを「最悪」と。
御意。
ところで、夕方、風呂掃除をしているときに思いついたことです。
そもそも、BASICインタプリタでのRENUMコマンドの実装ってどうなっているんだろう、というのが出発点。例えば、行番号1から始まって1番刻みで32000行あるプログラム、これを増分2でRENUMコマンドをかましても、仕様上は問題なく動作するわけですよ。実際に試すとどうなるかわかりませんが、他のマシンを含め、RENUMコマンドで問題が発生したという話は聞いたことがありません。ということは、これってテーブル方式ではなさそう。だってテーブル方式だと、かなり高い確率で破綻をきたしそう。
だとすると、私がやったような逐次変換方式か、はたまた全く別の方式か。でも、仮に逐次変換方式だとしても、テキスト処理でやっているわけではなく内部表現での置き換えだから問題が生じないんだろうな、と、一旦は納得しました。
が、風呂掃除を終えて落ち着いて考えると、この推論はおかしい。
例えば110行が130行に変わったとして、既存の110行にジャンプしているGOTOを全て130に変更します。次に130行が150行に変わるので、130行にジャンプしているGOTOを書き換えるとして、これが変更前の130行なのか、それとも旧110だったものが130に書き換え済みのものなのか、どうやって判別するのか。これ、どんな方式でやろうと、ついて回る問題だと気がつきました。
フラグ？
フラグなのか？
う〜ん、一体どうなっているんだろう。
関連記事一覧ツリー
（▼ を押すとツリー全体を一括表示します）
-
▼ - 5731.N88-BASICのRENUMのようなマクロ - としき 25/03/29-14:22
返信フォーム
（この記事に返信する場合は下記フォームから投稿して下さい）
- 以下のフォームから自分の投稿記事を修正・削除することができます -