CLC-INTERCALコンパイラ「sick」の嫌らしい仕様!勝手に壊れるな!ビルドする際にどうやったら壊れなくなるんだよ!
結論:コンパイルする度に*000 (意味不明の文字列)と出るのであればコンパイル時に--charser=ASCIIなどで文字コードを指定しよう。
⚠️⚠️コードゴルフ上、未発表の短縮手法があります!!!
TermuxでCLC-INTERCAL 1.-94.-2のソースコードのtarballをDebianパッケージ配布所から入手。これをビルドしたら正常に動いたので、そのまま使えた。
だがしかし、
$ cat >shoulddieonemptyline.clci
DO,1<-#99
DOCOMEFROM#9
DOWRITEIN,1
DO,2<-,1SUB#1
(9)DOREADOUT,1
$ sick shoulddieonemptyline.clci
$ ./shoulddieonemptyline.io <shoulddieonemptyline.clci
*000 D!,1<-#99
D!C!(EFR!(#9
D!WRITEI+,1
D!,2<-,1SUB#1
(9)D!READ!UT,1
$ sick shoulddieonemptyline.clci
$ ./shoulddieonemptyline.io <shoulddieonemptyline.clci
*000 KNZMFABBR KAKFSIWKFABR KQWDHSDCNZR KNWMFNZLY
BD KWSE KYHNZR
$ sick shoulddieonemptyline.clci
$ ./shoulddieonemptyline.io <shoulddieonemptyline.clci
*000 KNZMFABBR KAKFSIWKFABR KQWDHSDCNZR KNWMFNZLY
BD KWSE KYHNZR
$ sick shoulddieonemptyline.clci
$ ./shoulddieonemptyline.io <shoulddieonemptyline.clci
DO,1<-#99
DOCOMEFROM#9
DOWRITEIN,1
DO,2<-,1SUB#1
(9)DOREADOUT,1
*280 Invalid array: Subscript out of range
$
うわ。無茶苦茶なことを吐き出しやがって。一度は正しいプログラムとしてコンパイルするくせに、たまにソースコードを改変しやがってはKNZMFAABなんとかとまで出しやがって。
私は数回のコンパイルと実行を通じてはじめて理解したのです、本当のCLC-INTERCAL 1.-94.-2は、コンパイル時にランダムで壊れるのが仕様だということを。
今まで私はそんなものとは無縁でした。全てコードゴルフ界隈、パッケージ作成界隈、ならびにオンライン環境提供者界隈の尽力により、そんなものとは無縁となるように修正がされていたためでした。
それでは、ソースコードからビルドした方はどうすればいいのでしょうか?そうです、--bug=0 --ubug=0をコンパイラオプションとして使いましょう。
バグとはおさらば!これを書いて筆を置くつもりでしたけど、助けてください。実は--bug=0 --ubug=0では、解決に至っていませんでした。
コンパイルの結果、数回は同じ結果となってしまいます。どうしてですか。ソースコードのどこがそんな意地悪なことをするのですか。ふぇぇ…。😢コードゴルフ民もいるんですよ?わかりますか、我々競技者の気持ち?どうせ日本語なんか読まないでしょうし、CLC-INTERCALをつくったこと自体お忘れでしょうけど。開発者様の反論と生存確認はコメント、この記事のご紹介、新バージョンの発表、あるいはこれらの組み合わせや類似行為にて受け付けます。
開発者の意地悪。ユーザ主体主義があまりにも大きすぎる。しかもウェブサイトも消えてどっかにとんずら。まぢイミフ。パッケージ開発者への虐待。
ということで、また来週(?)お目にかかりましょう。ありがとうございました。INTERCALはマゾヒストをさらにマゾヒストにさせるプログラミング言語だと思います。
追記(2022-07-17 0:04 UTC+9頃)
もしかして文字コードの指定をしてくれ、だったりする?
A. 本当だ!--charset=ASCIIでコンパイルしたらちゃんとしたプログラムとして認識してくれるじゃないか!他の文字コードの場合も別のものを使えばよさげだね。試さないけど。文字コード推測機能の故障にすぎないんだ!なーんだ、そういうことだったんだね。
CLC-INTERCAL開発者にキスを。😘😘😘
この記事が気に入ったらサポートをしてみませんか?