#2ch のスレしか見てないですが、R5RS からの差分が載ってるそうですね。Scheme も偶数リビジョンはうまくいかないみたいなジンクスができたりして。
#r5rsにモジュールとunicode対応とblobといくつかのポピュラーなsrfiを加えた感じかな。セマンティクスに大きな変更を加えてないので自然な拡張に見える。r6rsは機能拡張とセマンティクスの変更を同時にやろうとしたのが混乱のもとだったのかもしれん。
#さくっと R7RS に対応したいところだ。
#R5RSを基本としてインクリメンタルな追加で実現できそうなので、R6RSよりうんとハードルが低そうですね。
#ただ、これはdraftなんで、あせって対応してもfinalで変わる可能性が。
#Ikarus が R6RS のときにすぐに対応（というか Draft 時から対応）してたのがずるいなと思ったので。採用見込みが高そうなところはやっておいても良いかなと。
#まだ一行も読んでないですが。
#こんなこともあろうかとchibi-schemeのsyntax-rulesを移植しておいたので、nmoshは(やる気になれば)対応出来る見込み。
#モジュール周りはドラフトで結構かわったのでやり直すけど。。
#srfiから持ち越しているようなやつは多分素直に行くんじゃないですかね。とそう言ったらほとんどかなあ。r6rs draftの時の「え、ちょ、ちょっと待ってなにこれ」感がない。
#nmosh と言わず mosh でも。
#nmosh はメモリフットプリントが気になるくらいであとは psyntax mosh より良い気がする。
#chibi-scheme の位置づけがやっと理解できた。
#psyntax-moshはマクロ展開がlazyなので、パフォーマンスを犠牲にせずにしようとするとちゃんとsyntax-rulesを実装しないと。。
#mosh/nmosh は hashtable に数万件のデータとか大きな文字列などで GC が異常に遅くなるのだよな。きちんと調べてないけど。
#chibi-scheme の syntax-rules は C? Scheme?
#Scheme。
##0.2.7 だしたら nmosh を mosh に rename 作戦やってしまうか。
#やばそうな気配はマクロの厳密な仕様くらいかなあ。今 => などの補助シンボルとモジュールの相互作用について議論になってるけど。厳密に突き詰めようとするとr6rsみたいになっちゃうんで、うまくダークコーナーを残したまま妥協できるかがポイントかなあ。
#いまはnmoshのfree-identifier=?がR7RSのセマンティクスと合わないので、そこを直さないと動かない。
#R7RSは => とか elseはunboundにしようということになってるけど、nmoshはunboundなシンボルはfree-identifier=?で比較するときにモジュールを超えられない。
#moshってgcはboehmだっけ? Gaucheではhashtableの実装でfalse pointerが多発して問題になったことはあったけど。ILP32で。
#boehm です。amd64 でも起きているので別の問題かと思っています。
#nmoshのweak-pointerは通常のシチュエーションでもGaucheほど消えないんで、何か間違ってる感触は有る。。
#PRINT_GC_STATS でみると mark&sweep で 100msec 以上かかってひどいパフォーマンスです。
#reader labels 入るのか。
#record シンプルになったな。良い。R6RS の構文は全然覚えられなかった。
#ああR6RSから仕様が変わった部分を入れてなかったな。。
#syntax-rules、error、define-record-typeあたりは変わった。
#blob 識別子短くていいな。blob-copy もやっと入ったか。
#Readerででかいのは |hoge fuga|で(string->symbol "hoge fuga")になったことかな。。またひとつ予約シンボルが消えた
#以前入れていたので対応するのは簡単かな。Gaucheにもありますよね。
#endian はなかったことになったのかな＜blob
#まぁ#"hoge fuga"にしようという提案もあるけど。
#blobはWG1ではbyteだけです。なのでendianを気にする必要はない。
#(current-jiffy) の唐突感が半端じゃないｗ
#time周りは個人的には微妙だなぁと思ってる。
#そうですね。何でこんなことに。
#たぶん詳しい人がWGに居ないんじゃないかなぁと。。 POSIXじゃなくてPosixだし。
#transcoder に相当すうるものはないのかな。良い仕組みだと思うのだけど。
#define-record-typeは変わったというよりsrfi-9じゃないですか? 「r6rsがdisruptiveに変えた」って印象だなあ。
#そういういみではerrorとかrecordは単に戻っただけですね
#trancoderは入れると仕様がふくらむでしょう。srfiで良いのでは。r6rsのportまわりはよくできてるとおもうけれど、srfiでまずい理由も思い浮かばない
#transcoderとか国際化はWG2行きのはず
#正規表現もWG2だったかな。。
#でもなぜかSRFI-98はWG1に入った。。
#シンボルの |hoge fuga| は現状追認では。Lispの伝統ですし。ただ、CLでは |foo|bar|baz| はひとつのシンボルとして読まれるけど、そこをどうすべきかな。
#transcoder も正規表現もよくあるテキスト処理に使われるので RnRS でサポートして欲しいなと。そういう意味では Socket も（無理だけど）
#それ言い始めるとまとまりませんよ。srfiで良いじゃないですか。
#正規表現なんて、ひとつの正しい仕様に合意が取れるとは到底思えない。
#WG2の位置づけはどうなんだろうなぁ RFCとSTDの関係で良いんだろうか。
#たしかに＜正規表現。
#正規表現仕様はどこかの言語もしくは処理系の正規表現の仕様に準ずる。細かいことは気にするな。は許されないだろうしなあ。
#リテラルだけでも決めてもらえると助かるのだけど。
#そういえば R6RS の Unicode 周り（normalize とか）はやり過ぎ感があったな。
#今回(scheme base)以外のライブラリは全部オプショナルなので、unicodeの事を一切知らない処理系も一応可能。
#あれも「完全な仕様」を追い求めたせいかと＞やり過ぎ感。「こういうエッジケースはどうするの?」とか言い始めるとどんどん肥大化する。「完全に互換性のあるライブラリ書きたいじゃん」と言い出すとそうならざるを得ないんだけど。それをrnrsでやろうとするのが間違いなんじゃないかなあ。
#そういうのは仕様ありきの言語の難しさでもありますよね。本当に必要だと思うものから実装される言語とはちょっと違う。
#穴があったら誰かがsrfi書いて、それをなるべくたくさんの処理系がサポートするようにロビーすればいいんで、先回りして全部穴を塞ごうとするのは多分無理。
#srfi はもっと出したいですね。ちょっと敷居が高いけど。
#list 周りが良い感じだな。
#list-ref, list-set! 。あと帰ってきた set-car!/set-cdr!
#stringとpairは最初からmutableになった。
#ああevalもR5RS仕様に戻ったな。。
#うーmutable stringは複雑。string portではだめな、mutable stringがあると嬉しい応用って何?
#vectorやblobとの統一感。。
#個人的には string は immutable の方が好きかな。
#ECMAScriptとかもimmutable stringだったと思うから、世間的にstringがmutableなのってマイナーなのかね。。
#「統一感」は弱いと思うな。vector-carやvector-cdrが無いのは相応の理由があるわけで。
#あとは正規表現のreplaceが等長のときくらいかなぁ。。
#それってものすごく特殊ケースじゃない?
#Uppercase→lowercaseとかは比較的頻出だと思う。。
#string-map！があるわけじゃないから、基本的にmutable-stringでなければ実装が非効率な操作ってWG1の中には無いよなぁ
#case conversionも結構特殊ケースだと思う。言語限定だし。
#moshのライブラリだとirregexがmutable-stringを使ってるようだ。
#Objective-C には NSMutableString っていうのがありますね。
#irregex は pure R6RS なのは良いのだけど結局遅いので使い物にならなかったなあ。
#Gauche no
#毎回正規表現を生成すると病的に遅くなる＞irregex
#たぶん正規表現は構文が必要。。
#そういえば Gauche の copy-on-write string は初期リリース時からあったのでしょうか。それともアプリケーションの性能要求から後づけ？
#SREみたいにマクロドメインになってればいいんじゃない? (rx "....") で rxがマクロならコンパイル時に一回生成すればいい。
#Gaucheの文字列本体は最初からimmutableです。multibyte encodingを採用しようと決めた時点で、string-set!の性能は捨てました。
#なるほど。
#multibyte encodingにしたときってO(1)アクセスにしてますか？
#今はO(N)です。single byteの場合は特別扱いしてO(1)。問題が出たら補助構造をつけようと思ってますが、今までひっかかったことはない。Gauche内部では文字列をインデックスでアクセスすること自体があんまりないし。
#はじめまして。Smalltalk処理系のSqueakのStringはmutableです。商用Smalltalk処理系のVisualWorksだとimmutableですが、インスタンスのisImmutableをfalseにすると mutableに変身しちゃいます。
#それで嬉しいことってどんなことがありますか?
#文字列の構築には別にプリミティブがあるとして。
#どうなんでしょう(^^;
#Squeakの場合、単にStringがCollectionクラスの子クラスだからだと思うのですけど。
#長い文字列のうちの頭の 1 文字を消したい時とか？
#少なくともSchemeのmutable stringは長さを変えられないですよ＞1文字消す
#それはsubstringでいいような。。＞１文字けす
#あ、Schemeのsubstringはコピーするのか
#mutable stringだからコピーしなくちゃならないんですね。immutableなら本体共有できる。
#長さが変えられないと意味ないですねぇ。
##Perl の文字列は mutable だそうだ。
#そうそう、ぼくも Perl の文字列があたまにありました。
#それで十分性能が出ているのか。
#Perl は内部ではマルチバイトじゃないから、まだやりようがあるのかも。
#内部表現まで決める気ならそれでもいいんですけどね。Common Lispの文字列は要素の型に制約がある配列だから、当然mutable。それはひとつの割り切り。
#Perl だと長い文字列に対して $str =~ s/^.// みたいにして頭から 1 文字ずつ処理するとかやっても遅くならないんですが、長さ固定だとこれが出来ないですね。
#まあでも内部表現をツリーにしちゃえばmutableかつ部分共有はできるし、それほど強硬にimmutable stringを主張するつもりはない。case sensitivityと同じで、次第にmutable stringがオプショナルな感じになってきてスイッチが起きてくれるならそれが望ましいんじゃないかと思う。
Gauche > Archives > 2011/04/17