2024-05-24 23:22:33 Ukicodeの投稿 opaupafz2@fedibird.com
icon

このアカウントは、notestockで公開設定になっていません。

icon

プログラミング言語で文字列結合に「+」を使うの、数学的な加算演算子と言うより、「Fediverseは "federation" + "universe" のかばん語です」みたいな説明に使われる散文的表現由来なのでは? という感想(​:bt:​記事の根本からひっくり返しにかかるツッコミ)
とはいえ数値型と文字列型が混在するプログラムコードにおいて、表記が似すぎていてややこしいのはそれはそう
VBの & 演算子とかはその解決のひとつだけど、これはこれで他の言語だと別の意味を持つ演算子だからまたややこしい

icon

最初の行、「しらんけど」って書き忘れてた(気にするところはそこじゃない)
しかし確かに「+」を使うようになった理由は気になるっちゃ気になるわね
へたすりゃ50年とか遡ることになりそうだから、もし探すなら史学的なアプローチで探すことになるのかしら?

QT: fedibird.com/@the_kwa/11249673
[参照]

Web site image
くゎ (@the_kwa@fedibird.com)
Web site image
投稿の参照(1件) by くゎ (@the_kwa@fedibird.com)
icon

おお! WikipediaおっかけてたらAltair BASICのページの参考資料にリファレンスマニュアルあるじゃん!
その20ページ目を見てみたら、文字列結合演算子として「+」記号が登場してる!
さらに62ページには「CONVERTING BASIC PROGRAMS NOT WRITTEN FOR THE ALTAlR」と題して
> ALTAIR BASIC uses " + " for string concatenation, not " , " or " & ".
とはっきり書いてあり、他のBASIC方言では "," や "&" が使われているものがありそうなことも読み取れる。
1975年発売の製品の時点ですでにこうなってるのか……興味深い話……!

archive.org/details/bitsavers_
[参照]

Web site image
投稿の参照(1件) by くゎ (@the_kwa@fedibird.com)
icon

@opaupafz2 完全に横道ではありますが、VBの&演算子については心配ありません。
VBでの&は文字列同士のみに定義されていて、それどころか前後の型を文字列に拡大変換しようとするぐらい文字列志向の演算子です。
つまり、&を使った場合、くっつけた文字列が返るか、ダメなら型変換エラーになります。
ちなみに、VBのbit演算は「And」演算子です。「And」演算子にはBoolean演算のパターンもありますが、今ではBooleanには「AndAlso」演算子を使うのが主流ですから、気にすることはないでしょう。

……と、ここまで書いた上でアレなんですが、現在のVBには演算子のオーバーロードがあるため、演算子前後の型を完全に把握していない限り、そのコードから何が起こるかは結局確定できなかったりします(台無し)

icon

@opaupafz2 昨日ちらっと調べてた話ですと、1975年発売のALTAIR BASICが文字列結合に「+」演算子を使っていて、そのドキュメントに「, や & じゃないよ」と書いてありますから、75年時点でこの3者はそれなりに使われていたりしそうですね。
一般的な用法として単語の結合を「+」で表現するのはそれなりにありえますし、見た目のわかりやすさで「+」記号を選んだ可能性はありそうです。当時のBASICだと文字列変数は必ず$が必要だった(LET A$=B$+"ABC")ので、数値との混乱は考えにくい(パーサ的にも混乱しない)というのも後押ししてそうです。
Wikipediaベースですが、ALTAIRはホビーユーザー間でかなり普及したようですから、ALTAIRが「+」を採用したのは、「+」が一般化する過程に結構な影響があったのかもしれませんね。

icon

@Cydonia_9761 ".."パターンは初耳……! 何の言語だろう……!?

icon

@opaupafz2 おそらくJavaやらそのあたりのことを念頭においてのことだと思うのですけど、あの文字列型に合わせていく挙動、個人的にはいうほど違和感ないのですよね。
数値を起点に考えるとWhy!?!?!??!?になるのも理解できるのですが、「Stringクラスに【数値型との間での拡大変換&演算子オーバーロード】が定義されている」と考えるとめちゃくちゃ素直な挙動なのですよ。

icon

@opaupafz2 そうですねぇ、究極的には好みの問題、極端に言えばそれこそ"宗教"的な話になってくると思います。演算子オーバーロードや暗黙の型変換をどこまで認めるかのラインは難しいですよね。
もっとも、JavaScriptのほうは型変換の問題というより、変数そのものには静的な型がないし決めようがない言語仕様の限界という感じがしますが…… :blobcat_daradara:

icon

@opaupafz2 あ、はい、さんざん引っ掻き回した上で言うのもあれですが、記事に関しては承知しております……(なのでBTしたのちリンクも参照もなしに空リプしてました)

変数展開を用いて云々に関しては、もう完全にまっさらな新しい言語でも作らない限りどうしようもなくてしょうがないところですね……。理想ばかりを謳って目の前にある古いコードが動かないような処理系などなんの役にも立ちませんし……。

icon

@opaupafz2 その検査の話も、結局は互換性問題が理由でどうしようもないんですよね……。検査を厳しくしてしまえば「この目の前にある古いコード」が動かなくなりえますから。
だもんで、静的検査とトランスパイル時に解決できる問題は事前に片付けておこうというAltJSに流れるのもやむ無しですよね。難しい話です。