うわ〜い

＞どうも、MIO.H です。

  ついに、御体登場ですね。ばんざい。

＞皆さんの希望というのはほとんど同じようですね。新しいＫＩＳＳが欲しい・規格が

＞混乱してユーザの不利益になるようなことは無い方がいい→早く規格化せよ
＞ということですよね。（誰もがごく自然に発想することだと思う。）

  ぜひよろしく。


＞とりあえず、現在のところの私の考えです。（もちろん、皆さんの意見を踏まえてね



  でたあ。実は予想していたけど、やはり、ショッキングですね。


  個人的に、要約してみると、最初にしなければならない論点は、『最終的な
配布形態』として、小さいファイルの集合にするか、ひとつあるいは小数のフ
ァイルに統合するかということ。文字ベースなのか、バイナリなのか。という
ことになるでしょうね。

  それぞれに利点があると思います。最終配布形態がバイナリということにな
ると、その中に盛りこまれる機能のみが問題になり、その過程での表記方法と
かは、極端に言えば、結局は、どうでも良いことになります。

  製作の過程としては、小さなファイルや文字記述することもあり得ると考え
て良いでしょう。昔は機械語のプログラムを直接２進数で書きこんでましたが、
アセンブラ〜バイナリの命令と１対１で対応する〜、コンパイラ〜機能的に複
数の命令に置き替える〜と変化してきましたが、このあたりと同じことで、い
ろんな方法がありますね。そうなると、ツール作者さんの考えも重要になると
思います。（そして、それをつきつめると、記述言語の仕様になるような。）

  私の考えとしても、文字ベース、バイナリ記述、それぞれに利点があると思
います。その中で、MIO.H さんはバイナリを提示されたのですが。
  みなさんの意見と言うことですが、私自身については、純粋に両者の利点欠
点を考えてみるとバイナリ賛成です。でも、現行ＫＩＳＳやｆｋｉｓｓとの関
係を考えると、微妙ですね。


＞　（バイナリ化すれば、かなり複雑な処理も記述出来るようになります。もちろん
＞　周辺ツールが多数必要になりますが。）

  バイナリとなると、ローダ自体に多くの機能を付けるかわりに、元の記述を
複数の命令に展開する（コンパイラ的でも、マクロ的でも）ことができますか
ら、ツールさえ充実すればよく使う記述は楽にできるようになりますね。


＞・ｆｋｉｓｓはどうしよう？
＞　（機能的な拡張はｆｋｉｓｓで実験されてることのようです。ｆｋｉｓｓの
＞　上位拡張にはならないとは思いますが、既に多くのデータが出回ってるよう
＞　ですし・・・。う〜ん、どうしよう・・・。）

  バイナリということが、もし、決定されれば、あとはｆｋｉｓｓの命令が簡単
に置き替えられるかということが問題になると思います。そうなる可能性が高い
ならば、『現行のｆｋｉｓｓは、正規の規格化の際にツールによって変換可能と
なる可能性がある』という姿勢でも良いことになります。（その場合でも、その
変換を誰がするかという問題は残りますけど。）
  この関係がうまく働けば、インタプリタとコンパイラの関係のように、デバッ
グも楽にできて良いのでしょうが、ヘタすると、両社が混在することにも・・・

  あと、在来のＫＩＳＳのデータをどうするのか。これも変換して使うのか、直
接サポートするのか、今後切り分けるのか。変換については、変換して再配布し
てもらえる作者さんもあるでしょうが、そうでない方も多いと思います。ユーザ
が変換するということでは、遊べない人が出そうですし、無断で変換したデータ
が勝手に流通するようなことが起こりそうです。切り分けるとなると、両方遊べ
るｆｋｉｓｓとの関係がまた微妙なような。


＞って、ような事を考えています。（もちろん決定ではない。）
＞具体的な内容は現在のところ全く白紙です。だからすぐにはできません。(ｺﾞﾒﾝﾅｻｲ)

  まず、進む方向が決まって、ゆっくりでても進む動きが見えれば、私は、たと
え遅れ遅れでも期待して待ちます。

					ＭＡＲＳ