この時期になるもまだ詳細が未確定で、 ショーストッパーになりかねないM17N開発を加速するべく 開発会議を開催した。
ほんとは松江でとか思ってたんだけど、 結局秋葉原ダイビルで。
参加者は、私、ささださん、akrさん、なかださん、mputさん、 Martinさん、青学の学生さん。
で、最初の議論は、最近主流っぽいUCS(Universal Character Set)モデルを 採用するか、日本の伝統的文字列処理の延長線上で(ある意味、茨の道)なんとかするか という話。結局、後者で頑張ることに。
で、伝統を尊重して
エンコーディング情報を使うメソッドは
となる
これは議論していないんだけど、JRubyなどでこれをどう実現するかと考えると
とすればいいんじゃないかな。
追記
成瀬さんからコメントをいただいた。
すでに世界がUTF-8で統一されつつある今、UCSでもCSIでもそう変わらなかったりはするかもしれませんね。
UTF-8はともかくUnicode系では統一されつつありますね。
> (optional)ASCIIの範囲内しか含まない文字列のエンコーディングはASCIIになる
これを optional にするのは危険な気がするのですが、互換性とか大丈夫ですか。
あ、ここでのoptionalというのは「現状の実装ではASCIIにしてる」が、最終的には分からないと言う意味です。1.8との互換性の問題はないでしょう。JRuby的には難しそうなので、なくした方が良いかもしれません。
> 二つのエンコーディングが等しい時→そのエンコーディングに基づき処理
> 二つの文字列内容がASCIIのみの時→ASCIIエンコーディングで処理
> それ以外→エラー「一方のみASCIIのとき→もう一方エンコーディングで処理」ですよね？
そうですね。
> primary encoding(仮称)
まずこの「primary encoding」が指す対象が何かを決めた方が決めた方がいいように思います。
上でも書きましたように「明示しない時の入力のエンコーディング」です。 それ以上でもそれ以下でもありません。
スクリプトのエンコーディングはmagic comment(pragmaという言葉は使わないことにしました)で 決まりますが、primary encodingとは関係ありません。
なお、[0x82, 0xA0].pack('C*') は BINARY でしょうか。
packの結果はBINARY(ASCII)です。前にもどこかで書きましたが、 実用上の観点からASCIIエンコーディングとbinaryは区別しません(が、8bit目が立っているASCIIエンコーディング文字列は7bitの特別扱いを受けません)。
> primary encoding(仮称)はUTF-16で固定。UCSモデル
ここでいう「primary encoding」は何に関わるのでしょう。String#encodigが常にUTF-16になるという趣旨だと解釈します。
それは違うのでは。primary encodingはあくまでもデフォルトですから、 明示的に指定すればString#encodingは変化するでしょう。 実装としては、おそらくはバイナリのままエンコーディングタグがつくのだと思います。
ので、ここ以降の考察はちょっとズレちゃってるかも。
CにPythonのインデントによるブロック指定を導入する、という話。
しかし、考えてみれば、Cってのは
と、Pythonでよく見かけるインデントによるブロックの弊害の原因がほとんどない言語 ではないだろうか。
もしかして、これって理想の組み合わせ？
せっかく東京に引っ越したということで、今年の東京ゲームショウに行ってみました。 ...
家に帰って、Xtalのコンパイラに定数伝播、定数畳み込みの機能を実装しつつ寝ました。
ゲームショウに行ったというエントリなのに、 Xtalコンパイラをいじった話が登場しちゃう。 ほんとに言語実装が好きなんだなあ。
共感しちゃう。
それはそれとして、Xtalは最近導入された言語仕様が、独自性が強すぎてちょっと不安なんだけど(first_stepとかblock_catchとか)。 言語デザイナーってのは頑張って独自性・新規性を追求しすぎちゃうと ユーザが離れちゃうし、なにも独自性がないと関心を持ってもらえないし、 難しいバランスが要求される責任だよね。