次世代言語13 Go Rust Swift Kotlin TypeScript

[過去ﾛｸﾞ] 次世代言語13 Go Rust Swift Kotlin TypeScript (1002ﾚｽ)
上下前次 1-新

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索歴削→次ｽﾚ栞削→次ｽﾚ過去ﾛｸﾞﾒﾆｭｰ

264: 2018/09/01(土)08:01 ID:FRKhXQkv(1) AAS
>>260
文法が複雑になるし、等値比較の扱いをどうするかが難しい
a = f
これC系の優先順位に倣うと (a = f) が自然だろうけど、たぶんこの式を書いた人の期待していた結果ではないだろう

265(3): 2018/09/01(土)10:17 ID:y+HuzDXi(1/3) AAS
数学では a = f はガイジが書いたとしか思えない

266: 2018/09/01(土)10:18 ID:/xY33kfI(1) AAS
でも個人開発じゃなかったらガイジも書くから

267(2): 2018/09/01(土)10:31 ID:8XWt4TWp(1/8) AAS
>>265
そんなに出てこなかろうが書けなきゃ一貫性に欠ける
a < b <= c の形に限るんなら a in (b..c] の方が美しいわ

268(1): 2018/09/01(土)10:56 ID:y+HuzDXi(2/3) AAS
>>267
あんまり出てこないって言っただけで、>>265の二つめは出来た方が良いと思うよ。三つめガイジだけど
で、>>261に挙げられた言語は出来ないの？出来るんじゃね？

269(1): 267 2018/09/01(土)11:13 ID:8XWt4TWp(2/8) AAS
>>268
その上で、範囲チェックにしか使えないんなら範囲チェックに特化した表記の方が望ましいという意見なんだけど、言ってる意味わかる？
表記上は一般的に広く使えそうに見えて実は特定の限定的なパターンしか認めないってのは典型的なダメ言語だよ

270: 2018/09/01(土)11:16 ID:33FbYz6y(1/2) AAS
「数学では〜」っていう言い方見ると悲しくなる
高校数学やそれに毛の生えたようなとこしか触ってないのに
それをもって「数学では〜」などと笑止千万

これは>>265にあてつけたんじゃなくて
昔からずーっと思ってたこと

271: 2018/09/01(土)11:19 ID:4l6T8pEq(1/5) AAS
まさかMaybeが出来ない初心者なんていませんよね

foo p x y = if p y x then Just x else Nothing
bar m p = maybe False p m

(a <= b && b < c && c == d)
== ((Just a >>= foo (<=) b >>= foo (<) c) `bar` (==d))

272: 2018/09/01(土)11:19 ID:y+HuzDXi(3/3) AAS
>>269
いや、だからキモいしガイジしか書かないけど、書けた方が良いって言ってんじゃん
で？>>261の言語は書けるんじゃないの？

273(1): 2018/09/01(土)11:27 ID:pVUyxPYl(1) AAS
数学でも a 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 c は合法だった
多分 a 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 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
全然違う

上下前次 1-新書関写板覧索設栞歴

あと 709 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ

ぬこの手ぬこTOP 0.011s