|| について (Re: フレーム非対応のブラウザについて (|| について)

[OOTANI TAKASHI]

"M.Wada" <m-w...@japan.com> writes:
>> var b = document.documentElement ? document.documentElement : document.body;
>> でもそりゃ長いし同じことだから
>> var b = document.documentElement || document.body;
>> と書くようにしてます。

> Logical Operaterは必ずBooleanを返す系統の言語育ちで、
> JavaScriptはNetscape2.2の頃のJavaScript 1.1ベースの知識だったので
> ちょっと驚きました。
> でも、便利ですね。

C 等から入ると、そうでしょうね。私はCより先にLISPを知ったので
(当時日本語のCの本が無かった)、C の && || が 0 か 1 しか返さないのは
違和感があり不便に思いました。まあ、変数に型のある言語なので両辺の型が
違う場合とかを考えるとしょうがないのかもしれません。
新しい言語はあまり知らないのですが、Boolean 以外の値に && || が使える言語で
結果に Boolean しか返さない言語って C類 の他にメジャーな範囲では何があります？
(Cの場合Booleanじゃないという突っ込みはしないでください)

かなり前になりますが、fj のどこかで、
(1) && || 演算子は、左辺の値によって右辺が評価されたりされなかったり
するのが演算子の意味として本質的である
(2) && || 演算子は、論理演算処理が本質的であり、右辺が評価されたり
されなかったりは、最適化/高速化のために過ぎない
という議論をした覚えがあります。
私は(1)の立場。
andthen orelse というふうに(1)であることがよくわかる演算子の言語もありましたね。
ADAだっけ?

Followup-To: fj.comp.lang.misc にしました。
--
tksotn

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

tks...@anet.ne.jpさん:

> C 等から入ると、そうでしょうね。私はCより先にLISPを知ったので
> (当時日本語のCの本が無かった)、

日本語のLispの本はあった? 黒川Lisp? なんかなつかしいですね。

> C の && || が 0 か 1 しか返さないのは違和感があり不便に思いま
> した。まあ、変数に型のある言語なので両辺の型が違う場合とかを考

> えるとしょうがないのかもしれません。

式全体の型が決められないと困りますからね。

> 新しい言語はあまり知らないのですが、Boolean 以外の値に && ||
> が使える言語で結果に Boolean しか返さない言語って C類 の他にメ
> ジャーな範囲では何があります？

強い型の言語はそうなんじゃないかな～。よく知らない。

> かなり前になりますが、fj のどこかで、
> (1) && || 演算子は、左辺の値によって右辺が評価されたりされなかったり
> するのが演算子の意味として本質的である
> (2) && || 演算子は、論理演算処理が本質的であり、右辺が評価されたり
> されなかったりは、最適化/高速化のために過ぎない
> という議論をした覚えがあります。
> 私は(1)の立場。

私は「&&と||は演算子ではなく制御構造である」てな文を読んでカル
チャーショックでした。ずいぶん昔でしたが。

> andthen orelse というふうに(1)であることがよくわかる演算子の言
> 語もありましたね。ADAだっけ?

ですね。これもちょっと長くていまいち。

ちなみにCLUは「cand」と「cor」でした。 久野

[Shinji KONO]

河野真治 @ 琉球大学情報工学です。

In article <c38343$1u...@utogw.gssm.otsuka.tsukuba.ac.jp>, ku...@gssm.otsuka.tsukuba.ac.jp writes

> 私は「&&と||は演算子ではなく制御構造である」てな文を読んでカル
> チャーショックでした。ずいぶん昔でしたが。

Perl だと or と and があって、演算子の優先順位なんかも調整されて
制御構造向きになってます。

> > C の && || が 0 か 1 しか返さないのは違和感があり不便に思いま
> > した。まあ、変数に型のある言語なので両辺の型が違う場合とかを考
> > えるとしょうがないのかもしれません。

そういう用途だと ?: の三項演算子があるから。まぁ、型変換でき
るならOkだし、できなきゃエラー出せばいいし。

でも、必ずBooleanに変換してから && の処理にいくわけだから、
違う型を返したいんだったら、なんか工夫がいると思うな。

ただ、predication を持つCPUが増えていくことを考えると、if 文
みたいな制御構造じゃなくて、値を持つ式の方がいいかも知れない。
そういう変換はコンパイラでやれっていう意見もあるんだろうけど、
僕は明示できる方がいいな。

> ですね。これもちょっと長くていまいち。

ML もいろいろ持ってますね。

---
Shinji KONO @ Information Engineering, University of the Ryukyus
河野真治 @ 琉球大学工学部情報工学科

[IIJIMA Hiromitsu]

いいじまです。

> かなり前になりますが、fj のどこかで、
> (1) && || 演算子は、左辺の値によって右辺が評価されたりされなかったり
> するのが演算子の意味として本質的である
> (2) && || 演算子は、論理演算処理が本質的であり、右辺が評価されたり
> されなかったりは、最適化/高速化のために過ぎない
> という議論をした覚えがあります。
> 私は(1)の立場。

私も同意です。
if (pszHogeHoge!=NULL && strlen(pszHogeHoge)>5 )
みたいな式が出てくるとその差が顕著ですよね。

========================================================================
飯嶋 浩光 / でるもんた・いいじま http://www.ht.sakura.ne.jp/~delmonta/
IIJIMA Hiromitsu, aka Delmonta mailto:delm...@ht.sakura.ne.jp

[MAEDA Atusi]

OOTANI TAKASHI <tks...@anet.ne.jp> writes:

> 新しい言語はあまり知らないのですが、Boolean 以外の値に && || が使える言語で
> 結果に Boolean しか返さない言語って C類 の他にメジャーな範囲では何があります？
> (Cの場合Booleanじゃないという突っ込みはしないでください)

&&, || のような短絡評価をする演算子、というのがそもそも(Lisp以外の)古
い言語には少ないのではないでしょうか。「副作用と値の両方を使う式」が前
提の仕様なので、関数型言語やAlgolなどの「きれいな」言語にはありえない
でしょうし。

論理積、論理和という意味だと、論理型以外を受け付けるのがそもそもおかし
な感じなので、強い型の言語では少ないでしょうね。Algol/Pascal系も
Javaも関数型言語も「論理型と論理型から論理型を返す演算子」ですよね。

> かなり前になりますが、fj のどこかで、
> (1) && || 演算子は、左辺の値によって右辺が評価されたりされなかったり
> するのが演算子の意味として本質的である
> (2) && || 演算子は、論理演算処理が本質的であり、右辺が評価されたり
> されなかったりは、最適化/高速化のために過ぎない
> という議論をした覚えがあります。
> 私は(1)の立場。
> andthen orelse というふうに(1)であることがよくわかる演算子の言語もありましたね。
> ADAだっけ?

Ada の短絡評価演算子は and then, or else と2トークンですね。短絡評価し
ない(左右どちらを先に評価するとも決まっていない)andとorも別にあります。

(1)と(2)は、別の概念なので両方用意したということでしょう。いかにもAda
らしいですね。

前田敦司

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

maeda...@ialab.is.tsukuba.ac.jpさん:

> &&, || のような短絡評価をする演算子、というのがそもそも(Lisp以外の)古
> い言語には少ないのではないでしょうか。「副作用と値の両方を使う式」が前
> 提の仕様なので、関数型言語やAlgolなどの「きれいな」言語にはありえない
> でしょうし。

学生時代、Fortranの論理演算子(.AND. とか .OR. とかのこと)は両
側を評価しなくてもよい)と学んだので。短絡評価は保証されてはいな
いがコンパイラのコードとして許容されているというか。

> (1)と(2)は、別の概念なので両方用意したということでしょう。いかにもAda
> らしいですね。

…Cだって | と || とか両方ありますよね(ちょっと違うけど) 久野

[MAEDA Atusi]

ku...@gssm.otsuka.tsukuba.ac.jp writes:

> 学生時代、Fortranの論理演算子(.AND. とか .OR. とかのこと)は両
> 側を評価しなくてもよい)と学んだので。短絡評価は保証されてはいな
> いがコンパイラのコードとして許容されているというか。

中田育男先生の「コンパイラ」(産業図書)に、詳しい解説がありましたね。

言語仕様としては、
(1)必ず短絡評価する
(2)短絡評価するかもしれないし、しないかもしれない(副作用を使ったら誤り)
(3)短絡評価しない(コンパイラは、副作用がない時に限り短絡評価してよい)
の3とおりでしょうか。副作用のない言語だと意味のない区別ですけど。
Fortranは(2)ですか。Pascalは(3)ですね。

> > (1)と(2)は、別の概念なので両方用意したということでしょう。いかにもAda
> > らしいですね。
>
> …Cだって | と || とか両方ありますよね(ちょっと違うけど) 久野

値域がだいぶ違いますが、両辺が0か1ならたしかに…

MS BASICのAND, OR, NOTはCでいうと&, |, ~でしたね。だから「真」は&HFFFF
だった。
前田敦司

[OOTANI TAKASHI]

OOTANI です。

ku...@gssm.otsuka.tsukuba.ac.jp writes:
> 久野です。
> tks...@anet.ne.jpさん:
>> C 等から入ると、そうでしょうね。私はCより先にLISPを知ったので
>> (当時日本語のCの本が無かった)、
>
> 日本語のLispの本はあった? 黒川Lisp? なんかなつかしいですね。

はい。「黒リスプの本」と呼んでました。あと、中西先生のM式中心の
青っぽい装丁の「青リスプ」がありました(改訂版ではさすがにS式中心になった)。
もう少しすると、ウィンストンの緑の装丁の「緑リスプ」、日本コンピュータ協会の
赤っぽい装丁の「赤リスプ」(これは厚いので読んでない)等が出ました。

>> 新しい言語はあまり知らないのですが、Boolean 以外の値に && ||
>> が使える言語で結果に Boolean しか返さない言語って C類 の他にメ
>> ジャーな範囲では何があります？
>
> 強い型の言語はそうなんじゃないかな～。よく知らない。

強い型の言語だと、そもそも && || 相当が無かったり、あっても Boolen型しか
書けなかったりするんではないかと思ってます。

> 私は「&&と||は演算子ではなく制御構造である」てな文を読んでカル
> チャーショックでした。ずいぶん昔でしたが。

sh では制御構造としてそこそこ使います。あと、perl の ～ or die はよく見ます。
C では単に論理演算子として使うことも多いですね。
if (c==' ' || c=='\t') とか。これを if (c==' ' | c=='\t') と書く人は
少ないでしょうけど、| はビット演算子という意識があるせいでしょうか？
それとも効率化の意味でしょうかね。コンパイラの最適化によっては
どちらが速いかわからないかもしれませんが(同じになるのかな？)。

飯嶋さんの書かれてた、

> if (pszHogeHoge!=NULL && strlen(pszHogeHoge)>5 )

も 本質は strlen を使いたいんだけど、事前に前提条件を確認するという感じで
制御構造か？というと微妙なところでしょうか？ガートとか言うのかな？
--
tksotn

[Junn Ohta]

fj.comp.lang.miscの記事<uu10nz...@anet.ne.jp>で
tks...@anet.ne.jpさんは書きました。

> if (c==' ' || c=='\t') とか。これを if (c==' ' | c=='\t') と書く人は
> 少ないでしょうけど、| はビット演算子という意識があるせいでしょうか？

0や1以外の値を返す関数やマクロの結果を真偽値として
使いたいときには、|はともかく&は使えないですよね。

たとえば
strcmp(p, "charlie") & strcmp(p, "lucy")
はpが"charlie"でも"lucy"でもないのに偽になることが
あると。

あと
isascii(ch) & isdigit(ch)
なんてのもまずそう。

で、&が使えないので対称性を考慮して|を使うのも忌避
される、ということではないでしょうか。
--
太田純(Junn Ohta) (株)リコー/新横浜事業所
oh...@sdg.mdd.ricoh.co.jp

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

oh...@src.ricoh.co.jpさん:

> たとえば
> strcmp(p, "charlie") & strcmp(p, "lucy")
> はpが"charlie"でも"lucy"でもないのに偽になることが
> あると。

「!!」をつけるとかだめですかね。 久野

P.S. もちろんそこまでして「&」を使う気はしないので、単なるつっこ
みですが…

[Takao Ono]

小野@名古屋大学 です.

<c3b2r5$1d...@utogw.gssm.otsuka.tsukuba.ac.jp>の記事において
ku...@gssm.otsuka.tsukuba.ac.jpさんは書きました。
kuno> > たとえば
kuno> > strcmp(p, "charlie") & strcmp(p, "lucy")
kuno> > はpが"charlie"でも"lucy"でもないのに偽になることが
kuno> > あると。
kuno> 「!!」をつけるとかだめですかね。 久野
!!strcmp(p, "charlie") & !!strcmp(p, "lucy")
ですか....

言語仕様にとても驚いた感じがプログラムからにじみでているようでお
もしろいとは思いますが, あとで読む人が混乱するだけのような.

あ, 短絡評価をどうしてもさせたくないときにはつかえ... るとはやっ
ぱり思えない....
--
名古屋大学大学院 情報科学研究科 計算機数理科学専攻
小野 孝男

[Hideo Sir MaNMOS Morishita]

In article <0403181321...@flame.hirata.nuee.nagoya-u.ac.jp>,

まあ、パズルとしてはおもしろいかも知れませんが、短絡評価の禁止だけなら、
評価させてから、論理演算するのと、上記のことをするのとの比較で、デメリッ
トが見えてこない。

--
___ わしは、山吹色のかすてーらが大好きでのぅ
[[o o]] ふぉっふぉっふぉ
'J' 森下 お代官様 ＭａＮＭＯＳ 英夫＠ステラクラフト
PGP Finger = CD EA D5 A8 AD B2 FE 7D 02 74 87 52 7C B7 39 37

[Junn Ohta]

fj.comp.lang.miscの記事<m3llm0w...@nospam.maedapc.cc.tsukuba.ac.jp>で
maeda...@ialab.is.tsukuba.ac.jpさんは書きました。

> &&, || のような短絡評価をする演算子、というのがそもそも(Lisp以外の)古
> い言語には少ないのではないでしょうか。「副作用と値の両方を使う式」が前
> 提の仕様なので、関数型言語やAlgolなどの「きれいな」言語にはありえない
> でしょうし。

Algol58/60にはif式というのがありましたよね。
absval := if val < 0 then -val else val
みたいな。

もちろん関数呼び出しも書けるし、条件式の中で使えば
短絡評価にも使えるのではないかと思います。そういう
コードを実際に見たことはないのですが。

# っつーか、実用のAlgol58/60のコードを見たことがそ
# もそもなかったりするわけですが。

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

ta...@hirata.nuee.nagoya-u.ac.jpさん:

> !!strcmp(p, "charlie") & !!strcmp(p, "lucy")
> ですか....
>
> 言語仕様にとても驚いた感じがプログラムからにじみでているようでお
> もしろいとは思いますが, あとで読む人が混乱するだけのような.

じゃあたとえば

#define BOOL !!

if(BOOL strcmp(p, "charlie") & BOOL strcmp(p, "lucy")) ...

しつこい 久野

[Narita Takaoki]

成田です。

Junn Ohta wrote:

> # っつーか、実用のAlgol58/60のコードを見たことがそ
> # もそもなかったりするわけですが。

Algol-60 と言えば、Stanford Artificial Intelligence Lab.
で使われたの Stanford Artificial Intelligence Language は、
Algol-60 の派生言語だったそうですが、なぜ Algol-60 だったんでし
ょうか？

# 話のネタふりにしかなってないけれど。

--
「十分間で決断し、短い理由を添えよ」
A.I.Soft, Inc. CS・品質推進課 成田隆興

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

tak...@aisoft.co.jpさん:

> Algol-60 と言えば、Stanford Artificial Intelligence Lab.
> で使われたの Stanford Artificial Intelligence Language は、
> Algol-60 の派生言語だったそうですが、なぜ Algol-60 だったんでし
> ょうか？

年代とかチェックしてないんですが、まっとうな言語(ブロック構造、
再帰のある奴)がAlgolo-60しかない時代だったからでは?

外してたらすいません 久野

[Narita Takaoki]

成田です。

Subject 変えてはみたけれど、続かんだろうなぁ。

ku...@gssm.otsuka.tsukuba.ac.jp wrote:

今までの継続調査の結果(ってほど手をかけてもいないのだけれど)でも、
SAIL がいつ開発されたか明記されたものをはずかしながら見付けられてな
いです。

んでもって、推測すると研究室のはじまりからそんなに遅れていないとする
と、遅くとも60年代半ばには着手しているだろうとして、Lisp でさえ一般
に認められている(？)誕生年は62年くらいの様ですから、確かにおっしゃる
とおりの理由なのかも。

# マイナーすぎる？やっぱりお倉入りにした方が良いかな。

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

tak...@aisoft.co.jpさん:

> んでもって、推測すると研究室のはじまりからそんなに遅れていないとする
> と、遅くとも60年代半ばには着手しているだろうとして、Lisp でさえ一般
> に認められている(？)誕生年は62年くらいの様ですから、確かにおっしゃる
> とおりの理由なのかも。

古くからあるのは確かです。名前「だけ」は聞いたことがあるという…

> # マイナーすぎる？やっぱりお倉入りにした方が良いかな。

どんな言語か知りたいんで、調査していただけると嬉しいな。 久野

[Narita Takaoki]

成田っす。

ku...@gssm.otsuka.tsukuba.ac.jp wrote:
> どんな言語か知りたいんで、調査していただけると嬉しいな。 久野

引続き継続調査していて分かったこと。私のローカルマシンで SAIL を
検索すると Jurgon にぶつかる。 犬も歩けば棒に当たるの類か？(^^;

しかたないから外で検索すると、当たりすぎ……

言語が分かりそうなものだと <http://www.xidak.com/> こんなん
見付かりました。

[YANAGAWA Kazuhisa]

In Message-Id: <c4r96f$1g79$1...@newsnnrp00.cwidc.net>
Narita Takaoki <tak...@aisoft.co.jp> writes:

> 言語が分かりそうなものだと <http://www.xidak.com/> こんなん
> 見付かりました。

The Language List で SAIL をひいて，
<http://cui.unige.ch/cgi-bin/langlist?isindex=sail&style=dl>

The Collection of Computer Science Bibliographies で見つけた論文のタイ
トルを検索してみて，
<http://liinwww.ira.uka.de/searchbib/index?query=bndllxghdjnrjhdgtlcrjchgplrkglhk&results=bibtex&mode=dup>

Stanford University Computer Science Department の Technical Reports
and Technical Notes をのぞいてみたらその TR 見っけ
<ftp://reports.stanford.edu/pub/cstr/reports/cs/tr/72/308/CS-TR-72-308.pdf>

....でもうちには PDF を見る環境が無かった，というところですがどうでしょ
う?

--
柳川和久 @ 大阪市 . 大阪府 April 5, 2004
Of two evils choose the lesser.

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

kj...@dm4lab.toさんは書きました。

> Stanford University Computer Science Department の Technical Reports
> and Technical Notes をのぞいてみたらその TR 見っけ
> <ftp://reports.stanford.edu/pub/cstr/reports/cs/tr/72/308/CS-TR-72-308.pdf>

うわー、1972年のTR。画面が狭いので明日印刷してみよう。 久野

[Narita Takaoki]

成田です。

うっへぇ～、英語読む苦しみより、文字を識別する苦しみの方が上回るとは……(^^;;;;