[過去ﾛｸﾞ] 次世代言語13 Go Rust Swift Kotlin TypeScript (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
273(1): 2018/09/01(土)11:27 ID:pVUyxPYl(1) AAS
数学でも a < b > c みたいな書き方はしないし
許してる言語もないだろ
274: 2018/09/01(土)11:37 ID:8XWt4TWp(3/8) AAS
>>273
それが文法上許されないことを説明する一貫性のある理由がない
<と<=を特別扱いみたいな一貫性の欠片もないガイジ仕様にするくらいなら要らない、という設計判断は十分にありうる
275: 2018/09/01(土)11:47 ID:4l6T8pEq(2/5) AAS
必要か不要かを判断するコストは実際にはものすごく高い
簡単に作れるかどうかで判断してたくさん自由に作ってどれかひとつ成功すればいい
276: 2018/09/01(土)11:52 ID:VcQ5WdQC(1) AAS
Juliaだと a < b > c は合法だった
多分 a < b && b > c を計算してるっぽい
しかし文法的に一貫性があるのはわかるのだが
これが書けてしまうのはやはり気持ち悪いな
この手のでRangeで書きにくいやつだと、
行列の上三角成分だけ舐めるときに
1 <= i < j <= n
とか書けるとちょっとだけ嬉しい
277: 2018/09/01(土)12:00 ID:bn2L0QEe(1) AAS
a < f(b) < c
fは何回呼ばれるべきか
278: 2018/09/01(土)12:11 ID:xDnWzldj(1) AAS
理想的にfが純粋関数でbの値がconstで1回だけ評価が素直だと思うが
279: 2018/09/01(土)12:11 ID:Lo8welT8(1/5) AAS
pythonの場合、 a < b という式の型がboolなのに (a < b) < c ができてしまうというのが
非常に分かりにくいね。なんというか、むりやり捻じ込んだ感。
280(3): 2018/09/01(土)12:14 ID:+BAvd4bn(1) AAS
a < b < c
と
b > a and b < c
どっちがわかりやすいか？
281(2): 2018/09/01(土)12:36 ID:rtR930fJ(1/2) AAS
なんで
a < b and b < c
じゃないの？
282: 2018/09/01(土)12:53 ID:7zNJuyPV(1/2) AAS
センス
283: 2018/09/01(土)13:05 ID:8oBLXasx(1) AAS
>>280
1=1<2だったらどうすんの？
284: 2018/09/01(土)13:19 ID:vTDtzWWE(1) AAS
>>280
コンパイラは大抵
b > a and b < c
のがわかりやすいと判断している。
285(1): 2018/09/01(土)18:37 ID:/wwW4VSs(1/14) AAS
だれかがいってるように
ﾏｼﾞで頭悪い。。。
aho = a < b ← 結果はﾌﾞｰﾘｱﾝ
baka = aho < c ← ﾌﾞｰﾘｱﾝを大きさで比較してる
< は普通2項演算子で予約されてるからな
3項演算子みたいに使ってない記号を組み合わせるならまだ理解できる
286(2): 2018/09/01(土)18:51 ID:TMvFd8Nd(1) AAS
>>281
その書き方だと 0 < x < 100 が
0 < x and x<100になるからセンス悪いと思った
x > 0 and x <100
xが0より大きく100より小さいにマッチするような記法がない
287: 2018/09/01(土)19:03 ID:7zNJuyPV(2/2) AAS
ワロた
288(1): 2018/09/01(土)19:34 ID:+4zR3ral(1) AAS
半角の人はいい加減に自分が馬鹿なことを認めてほしい。
289(2): 2018/09/01(土)19:34 ID:8XWt4TWp(4/8) AAS
>>285
ineqop ::= ('<' | '<=' | '>' | '>=')
ineqexpr ::= shiftexpr { ineqop shiftexpr }
みたいに定義すりゃいいだけだろ
290(1): 2018/09/01(土)19:47 ID:/wwW4VSs(2/14) AAS
なにも解決してない
構文規則と演算の規則は
なんの関係もないからな
知恵遅れは構文規則でかければ
自動的に演算規則ができて
なんでも演算できると思ってるらしい
構文規則と解釈が分離できてない
ｺﾚが低学歴知恵遅れの限界
ﾎﾝﾄな気の毒なぐらい頭悪い
291(1): 2018/09/01(土)19:51 ID:8XWt4TWp(5/8) AAS
>>290
任意個数のオペランドを持ったノードとして左から順に評価すればいいだけだぞ
CやJSのカンマ演算子なんかと一緒
292: 2018/09/01(土)19:52 ID:/wwW4VSs(3/14) AAS
a < bは
普通にﾌﾞｰﾘｱﾝ返す演算子だからな
普通にﾌﾞｰﾘｱﾝ返すのが正しい演算だ
293: 2018/09/01(土)19:53 ID:/wwW4VSs(4/14) AAS
aho ? baka1 : baka2
全然違う
294: 2018/09/01(土)19:56 ID:4l6T8pEq(3/5) AAS
a < b の値は最初はintだったのをboolに変えたんなら次はMaybeに変えてもいいぞ
295: 291 2018/09/01(土)19:56 ID:8XWt4TWp(6/8) AAS
カンマ演算子と一緒は間違いだな、撤回する
例えば配列リテラル式と一緒だと考えればいい
あれは任意個数のオペランドを引数にとって全体として配列型を返す演算子であると解釈できる
296: 2018/09/01(土)19:57 ID:/wwW4VSs(5/14) AAS
非ｾﾞﾛを非ｾﾞﾛでないかを
真偽にしても別に問題はない
297: 2018/09/01(土)20:00 ID:/wwW4VSs(6/14) AAS
真偽値をどういう値にするかどうかなんか関係ないからな
式の評価で真偽判定を行わないという解釈の問題になるからな
298: 2018/09/01(土)20:01 ID:/wwW4VSs(7/14) AAS
とりあえず低学歴知恵遅れは
とてつもなくｵﾂﾑに問題があるのが
このｽﾚみててもよく分かる
適切な問題の分離のしかたが分かってない
299: 2018/09/01(土)20:03 ID:8XWt4TWp(7/8) AAS
アホだなあ
演算記号が単独で式を構成しなければならないなんて決まりはない
全体で式を構成すると考えれば何の問題もない
300(4): 2018/09/01(土)20:06 ID:/wwW4VSs(8/14) AAS
a < b < c
まず a < b を評価して
その評価結果を
(a < b) < c
で評価するという決まりだからな
ｺﾚが正しい解釈になる
それ以外は不適切な解釈
301: 2018/09/01(土)20:07 ID:Lo8welT8(2/5) AAS
Iconという言語だとこれが、a < b という式は成功した場合の値がbになるから a < b < c が
自然に実現できるんだよな。
302(1): 2018/09/01(土)20:13 ID:8XWt4TWp(8/8) AAS
>>300
じゃあ関数呼び出し式 (f)(a, b) はどう解釈する?
君のいう正しい解釈のように ((f)(a))(b) と解釈する言語も実際に存在するけど、あまり一般的ではないよね
上下前次1-新書関写板覧索設栞歴
あと 700 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.010s