次世代言語Part8[Haskell Rust Kotlin TypeScript]

**デフォルトの名無しさん** · 2017/12/01(金) 23:08:21.45

スレタイ以外の言語もok

前スレ
次世代言語Part7[Go Rust Swift Kotlin TypeScript]
http://mevius.5ch.net/test/read.cgi/tech/1508403098/

**デフォルトの名無しさん** · 2018/01/20(土) 23:10:12.11

>>678
俺は最近書いてないぞ。
つまらんからな。

**デフォルトの名無しさん** · 2018/01/21(日) 00:17:54.03

パターンマッチで変数にバインドするところとかあれってどう還元できんですかね？

**デフォルトの名無しさん** · 2018/01/21(日) 01:01:46.61

・頭文字が大文字ならコンストラクタ (引数0個以上)
・そうでなければ変数 (引数なし)
少なくともこの仕様を守れば動的言語でもパターンマッチできるよ

**デフォルトの名無しさん** · 2018/01/21(日) 01:02:49.35

難しく考える必要はない
タプルは関連する複数の値をまとめて扱ってるだけ
レコードはタプルに型名というラベル値が付いただけ
型によるパターンマッチはその型名で条件分岐してるだけ
変数へのバインドはタプルの特定の要素の値にに別名を付けただけ

**デフォルトの名無しさん** · 2018/01/21(日) 01:37:10.13

つまり・・・どういうことだってばよ？

**デフォルトの名無しさん** · 2018/01/21(日) 06:13:50.88

>>682
動的言語どうこうではなく、オブジェクト指向の情報隠蔽とパターンマッチの相性が悪い。
アクセス制御をかいくぐってデータ構造にマッチさせるぐらいなら
オブジェクトを受け取ってからメソッド叩いたり条件分岐したほうがマシ。

**デフォルトの名無しさん** · 2018/01/21(日) 10:42:33.20

>>690
SuccessとFailをパターンマイッチングするんじゃなくて
class Success implements Resultと
class Fail implements Resultみたいにしろ
ってこと？

**デフォルトの名無しさん** · 2018/01/21(日) 11:06:54.37

本物のオブジェクト指向はTrueクラスとFalseクラスを使う
Bool &True::ifTrue(Block f) {f(); return this;}
Bool &True::ifFalse(Block f) {return this;}
Bool &False::ifTrue(Block f) {return this;}
Bool &False::ifFalse(Block f) {f(); return this;}

**デフォルトの名無しさん** · 2018/01/21(日) 11:22:08.22

こういうときオブジェクト指向ってアホの自慰っぽいなと思う

**デフォルトの名無しさん** · 2018/01/21(日) 12:05:31.75

全てのif文を消し去るのです

**デフォルトの名無しさん** · 2018/01/21(日) 13:37:58.84

その次の世代はtemplateを使いvirtualを消し去る
だからifが復活

**デフォルトの名無しさん** · 2018/01/21(日) 14:30:35.35

>>695
はいサイクリングマチカル複雑度増加

**デフォルトの名無しさん** · 2018/01/21(日) 23:54:04.18

多次元配列と第一級関数をサポートしている静的言語ってなんかあったっけ？

**デフォルトの名無しさん** · 2018/01/22(月) 00:18:19.80

**デフォルトの名無しさん** · 2018/01/22(月) 00:18:46.23

サポートするの定義が曖昧すぎる。

**デフォルトの名無しさん** · 2018/01/22(月) 00:28:37.30

そうかC#があったか。ありがとナス��

**デフォルトの名無しさん** · 2018/01/24(水) 05:54:32.12

>>697
それサポートしてない言語って何があるの？

**デフォルトの名無しさん** · 2018/01/24(水) 10:06:55.58

>>701
多次元配列サポートしてる言語なんて他にはFortran, R, Python, Julia, Racketくらいしか思いつかない
第一級関数は最近増えて来てるけどFortranみたいな古い言語はだいたいサポートしてない

**デフォルトの名無しさん** · 2018/01/24(水) 10:13:41.67

>>702
多次元配列サポートすると何の役に立つの？

**デフォルトの名無しさん** · 2018/01/24(水) 10:30:59.45

>>703
行列計算とか、その他数値的な解析がめちゃくちゃ書きやすくなる。
いわゆる数値解析や流行りの機械学習からゲーム開発まで、くまなくアルゴリズムが書きやすくなるぜ

**デフォルトの名無しさん** · 2018/01/24(水) 10:44:28.83

サポートてのは、数値計算でよく使う引数が2の関数と、そういう関数とと中置演算子との間の糖衣構文が標準でオーバーロード気味に存在するってことですかね？

**702** · 2018/01/24(水) 10:59:06.24

>>704
Racket挙げてるし中置演算子は重要度低いけど、よく使う関数はチューニングされたものを置いておいて欲しいな

Numpyだって標準ライブラリじゃないし、最悪標準ライブラリじゃなくてもいいけど、「数値計算するなら常識的に考えてこれ」という一つに定まっていてほしいな。
あるライブラリはEigenに依存しているが他のあるライブラリはublasに依存してるみたいなのはやめて欲しい

**702** · 2018/01/24(水) 10:59:37.34

間違えた。
安価は>>705で

**デフォルトの名無しさん** · 2018/01/24(水) 11:04:32.91

>>702
良かった。言語として普通にあるもんだと思ってたから
無いことを想像したこともなかった。

**デフォルトの名無しさん** · 2018/01/24(水) 11:09:12.83

第一級関数のことかな？
多次元配列はレアだよ

**デフォルトの名無しさん** · 2018/01/24(水) 11:24:52.80

Pythonは多次元インデックスをオーバーロードできるけど組み込みの多次元配列は無い
PythonレベルのサポートでいいならKotlinも同等だね

**デフォルトの名無しさん** · 2018/01/24(水) 11:58:57.43

そういえばExcel方眼紙もある意味二次元をサポートしてるな
Excelの異常な人気の原因はそこか

**デフォルトの名無しさん** · 2018/01/24(水) 19:16:29.18

義務教育に向けて親もプログラミングやっときたい、どれが良い？
Pythonとかよく目にするけど、と聞かれた。

どう答える？

**デフォルトの名無しさん** · 2018/01/24(水) 19:30:37.89

相手が挙げて来た言語のメリットを適当に言ってそのまま勧めれば良い
親が教えるためにやる言語なんて何でも良いし、違いがわかる頃には子供は卒業してる
選ぶのも面倒くさい

**デフォルトの名無しさん** · 2018/01/24(水) 19:50:08.15

>>712
まずはExcelのVLOOKUPを使いこなせるようになれ
次はVBAをやれ
でいいよ
教える側が何の役に立つのか分からないまま人に教えるなんて全く何の意味もない

**デフォルトの名無しさん** · 2018/01/24(水) 20:27:01.77

>>712
教育ママに特定の言語やらせて認識を固定させんな、むしろ子供に害悪だろ
数学パズルでもやらせとけ

**デフォルトの名無しさん** · 2018/01/24(水) 20:29:15.40

子供にはScratchをやらせることになるらしいから、親もScratchをやればいいじゃん

◆QZaw55cn4c · 2018/01/24(水) 20:39:13.05

>>712
やはり再帰的思考が勘所かと考えていますので、scheme をお勧めしようかと思っています

**デフォルトの名無しさん** · 2018/01/25(木) 01:24:29.68

>>712
Haskel
関数型を理解できないバカはプログラミングする資格も意味もなし
保守困難なウンコをひり出すだけのゴミは消えろ

と伝えてくれ

**デフォルトの名無しさん** · 2018/01/25(木) 02:32:13.16

>>718
Haskellの綴りも正しく書けない池沼は文章を書く資格も意味もなし
無意味なウンコをひり出すだけのゴミは消えろ

**デフォルトの名無しさん** · 2018/01/25(木) 12:45:10.82

>>711
excelは関数型言語だ、と言う人々も居るくらいだからな(笑)

**デフォルトの名無しさん** · 2018/01/25(木) 14:09:07.50

Excelはビジュアルリアクティブプログラミング環境と言えばまあ間違ってはないんだけど
二次元配列以外の構造の扱いが難しすぎて、学習用にしてしまうと
他のデータ構造を学ぶ機会がないまま何でも二次元配列に落としこむ悪癖がついてしまいそうで

**デフォルトの名無しさん** · 2018/01/25(木) 14:31:25.81

>>721
人間が無理なく扱えるデータは二次元の表が限界なんだよ
考えてみろ
お前がよく使う構造体やクラスのリストや辞書は実質二次元の表だろ
オブジェクト指向では直接深く階層掘ったアクセスは嫌われるだろ？
なんだかんだ格好いい理屈を付けても、結局人間にはExcelのデータ構造が馴染むんだよ

**デフォルトの名無しさん** · 2018/01/25(木) 14:38:39.64

>>722
再帰的 or 多相な構造どうすんのよ、ってのはまあExcelの用途では滅多にないとしても
単純に三次元配列が欲しい時もあるし
Sheet増やしだすと急に面倒くさくなるんだよなあ

**デフォルトの名無しさん** · 2018/01/25(木) 14:41:15.02

>>723
再帰なんか同じ表の行番号を持たせるだけだろ

**デフォルトの名無しさん** · 2018/01/25(木) 17:16:48.70

３次元以上を汎用に使おうとするとSQLみたいだったり tensor flow だったり
かなりめんどくさいインターフェイスになるのはしゃーない。

**デフォルトの名無しさん** · 2018/01/25(木) 17:55:47.33

まぁ、Haskellで作られたものより、Excelで作られたモノのほうが多いしな(笑)
純関数型(笑)

**デフォルトの名無しさん** · 2018/01/25(木) 20:01:29.48

>>719
このようなtypoを防ぐためにも強い型付けが必要なんだよ

◆QZaw55cn4c · 2018/01/25(木) 22:05:59.50

>>727
変数宣言（型宣言ではない）だけでいいと思うが、それだけでもいいから、事前チェックを可能にしてほしいなあ
python のバイトコンパイル機能は変数名をチェックしてくれるのでしょうか？

**デフォルトの名無しさん** · 2018/01/25(木) 22:42:04.62

flake8を使えば

**デフォルトの名無しさん** · 2018/01/26(金) 01:29:50.06

headerをincludeしてチェックする言語は簡単だけど
コンパイル済みのライブラリの中身を見て名前をチェックする言語は大変そうだ
コンパイル後も情報を全部残しておかないといけない

**デフォルトの名無しさん** · 2018/01/26(金) 16:21:27.98

変数宣言を省略できる機能(スペルミスが検出できない)と、型付けは別だよね？
昔のFortranやBASICは変数はいきなり使っていいけど名前で型が決まる静的型だったし

**デフォルトの名無しさん** · 2018/01/26(金) 16:36:58.42

宣言がない変数は、省略ではなく他のファイルで宣言している可能性がある
そのファイルをincludeするか、全てのファイルを検索する必要がある

**デフォルトの名無しさん** · 2018/01/27(土) 13:04:44.52

レベル下がったなぁ

**デフォルトの名無しさん** · 2018/01/27(土) 14:31:34.34

下がってから言っても遅いな
レベル高かった頃に、なにこれ高いって評価できる奴が勝つ

**デフォルトの名無しさん** · 2018/01/27(土) 14:40:54.49

まぁ、その時から無駄なつっかかりしかできない奴ばっかだったし仕方ないんだろうな。
今更option explicitじみた話に戻るとは。

**デフォルトの名無しさん** · 2018/01/27(土) 22:13:06.80

>>734
天井Lみたいなこと言うな

**デフォルトの名無しさん** · 2018/01/28(日) 15:51:11.09

自分で書いたコードが三ヵ月後に読めないっていうやつは素人
プロは三ヵ月後の記憶喪失を織り込んでる

**デフォルトの名無しさん** · 2018/01/28(日) 23:40:40.83

保守受注独占するために汚くするんやぞ

**デフォルトの名無しさん** · 2018/01/29(月) 22:16:09.55

そういう足を引っ張る人には保守受注の代わりに
ベーシックインカムをあげたらいいんじゃないかと言われている
足を引っ張る悪人より善良な怠け者の方がいい

**デフォルトの名無しさん** · 2018/01/30(火) 01:45:49.07

しょーもない理想論はいらんねん
こっちはきっちり世間様に仕事回してんねんで
頭の悪いガキは黙っとき

**デフォルトの名無しさん** · 2018/01/30(火) 01:47:45.52

ソースがきれい　→　オタクの自己満足
ソースがきたない　→　工数取れて残業代も出る、みんなニッコリ

これが現実やで

**デフォルトの名無しさん** · 2018/01/30(火) 10:52:36.78

そんなことしてるから他国の技術に駆逐されるんだよ。。

**デフォルトの名無しさん** · 2018/01/30(火) 14:43:26.40

その理屈だと、まるで必要もない次世代言語で書くやつみたいだな。
汚いソース書くやつは。

**デフォルトの名無しさん** · 2018/01/31(水) 23:31:38.87

次世代言語で書くだけならいいんだよ
故意に汚くするとはいってないから、改善する可能性がある
故意とただの偶然とでは罪の重さが違う

**デフォルトの名無しさん** · 2018/02/01(木) 08:43:21.74

故意にその言語で書いてる以上、もう偶然でもなんでもないだろ。

ちゃんとその言語のメリット、デメリット含めて布教してから使うべきだと思うが。

**デフォルトの名無しさん** · 2018/02/01(木) 11:05:23.20

ちゃんとする可能性があるならいい
その可能性をわざと排除するなら悪質
最初からそう言ってるんだろ

**デフォルトの名無しさん** · 2018/02/01(木) 13:10:20.37

まあ大体がカスな開発体制に問題があるところに
新しい言語なら問題解決できる！
とかめちゃくちゃな広告が出回って導入、失敗っつークソパターンがここ20,30年の間繰り返されてるわけだからな。

**デフォルトの名無しさん** · 2018/02/01(木) 15:37:35.21

Elm はどう？
ここ見てたら興味出てきた
https://nulab-inc.com/ja/blog/typetalk/elm-introduction-tutorial/

**デフォルトの名無しさん** · 2018/02/03(土) 02:04:53.95

JSに依存するのはいいがGHCがな
もしもF#がGHCに依存していたら面倒臭いじゃないか

**デフォルトの名無しさん** · 2018/02/12(月) 17:15:27.49

http://arison.jp/wordpress/wp-content/project_comedy_l.gif

**デフォルトの名無しさん** · 2018/02/12(月) 17:16:33.56

http://i.imgur.com/WlyRTkz.jpg

**デフォルトの名無しさん** · 2018/02/14(水) 20:27:03.68

ASM.net

**デフォルトの名無しさん** · 2018/02/15(木) 23:40:47.93

clojure やれよ？

**デフォルトの名無しさん** · 2018/02/16(金) 00:35:29.80

気の科学　★朝は気合いで起きる★　雑学

https://youtu.be/E6lvPide0JA

**デフォルトの名無しさん** · 2018/02/18(日) 01:30:59.56

>751
これ初めて見た

**デフォルトの名無しさん** · 2018/02/18(日) 15:38:35.68

なんかTypeScriptのジェネリクスがどんどん変態じみてきたんだけど、ジェネリクスってこういうもんなの？
これならgoに乗んなくていいなぁ

**デフォルトの名無しさん** · 2018/02/18(日) 15:51:20.83

>>756
欲求は際限なく広がって、そしてゴミの塊みたいな仕様になるもんだ。
ずっと前からTypeScriptは手段と目的をどっかで履き違えたと言ってたが、最近シャレになってない。

Goの割り切りは納得に値するよ。あったら便利なのは認めるけど。
Cppのtemplateみたいに、それだけでチューリング完全になってしまう前に、最初から入れない、やるならgenerateで別立てで勝手にやれと言う割り切りしたのは英断だと思う。

**デフォルトの名無しさん** · 2018/02/18(日) 17:25:12.30

>>757
ジェネリクス関連のエラーメッセージは本当に意味がわかんないよね。
ユーザー視点ではimmutable.jsとかでも補完が効くのは便利になっていいんだけど、
いざ型関連エラーが出た時にエラーメッセージから原因を予測するのが困難なんだよね。

rustもあんな感じなの？
正直TypeScriptはエラーメッセージをわかりやすくする方向に軌道修正頼んます。

**デフォルトの名無しさん** · 2018/02/18(日) 18:16:19.28

>>758
変性注釈とか、やりたいことはわかるし、なぜ必要かもわかるが、一方でjsとどんどん乖離していって、jsのプロジェクトと繋げるときに結局any使うことになったり、グダグダも良いところだと思う。
TSだけでもの作るんなら、良いと思うが、そうなるとJavaScriptにコンパイルできる必要もなく、逆に早くwasmなんかに対応しろとか、ネイティブにTSの良いところを保ったまま実行できる環境出せとか、色々文句が言いたいけど、
全部ほったらかしにされてるからな。
ずーっと言語の改良してる。

**デフォルトの名無しさん** · 2018/02/18(日) 18:37:05.69

一方的にjsのライブラリを使用する分には問題ないだろうし、その資産にただ乗りできることこそ
jsとの相互運用性を維持する理由だろう。
言語仕様としては奇麗だけどライブラリが揃わなくて実用性がいまいち、みたいになるよりは。

**デフォルトの名無しさん** · 2018/02/18(日) 19:25:55.39

>>760
jsのライブラリ側が自由な感じのライブラリだと定義ファイルが無茶苦茶ややこしいものになったりするし、なかなか微妙だけどな。
ライブラリが揃わなくてイマイチ、は確かに無いか。ほとんどタダ乗り出来るからなぁ。

**デフォルトの名無しさん** · 2018/02/18(日) 22:15:41.08

>>761
せめて関数のオーバーロード定義みたいなことが出来ればコードが整理しやすくなると思うんだよね。

つまり
export function h(name, attributes /*, ...rest*/) {
// 省略
return typeof name === "function"
? name(attributes || {}, children)
: {
nodeName: name,
attributes: attributes || {},
children: children,
key: attributes && attributes.key
}
}
ってあった時に
export function h(name: string, attributes:obj /*, ...rest*/) {}
export function h(nextFunc: (attributes:obj)=>void, attributes:obj /*, ...rest*/) {}
みたく出来れば型定義自体も綺麗にできる気がする。
でも今のTypeScriptってこれできんよね。

**デフォルトの名無しさん** · 2018/02/18(日) 22:19:58.51

あと詳しい人に聞きたいんだけどやっぱりジェネリクス一つとっても
言語によって全然仕様が違うのかね？

だとしたらGoはコードジェネレートと組み合わせも考慮したちょうどいい便利さの
ジェネリクスというのも考えていて実装を見送ってるのかも。

でもGoにはそれ以前にnull安全を実装してほしい気がするが。
レシーバがnullの可能性があったりnull周りに罠があるんだよねGoは

**デフォルトの名無しさん** · 2018/02/18(日) 22:47:38.32

>>762
オーバーロードってまさにそんな感じでできた気がするが。

**デフォルトの名無しさん** · 2018/02/18(日) 23:30:02.62

ジェネリクスは途中から入れるようなもんじゃないと思うがね
型自体はフラットな構造で、階層構造はHaskellみたいに型の境界（型クラス）として作ると綺麗にまとまりやすい
型≒クラスで、型自体に階層構造を作ってるような言語だと、ジェネリクスの使い方が面倒よ
Javaの<T extends ClassFoo>とかＣ#のin/outとかは元の型システムに合わせて入れないといけない面倒な部分

TSの元々の型システムはよく知らないけど、ダックタイピングできるならジェネリクス入れる必要がないし、
クラスがあったり型に階層構造があるなら面倒なのはしょうがない

**デフォルトの名無しさん** · 2018/02/18(日) 23:45:12.91

むしろJavaScriptさんが悔い改めるべきではないか？

**デフォルトの名無しさん** · 2018/02/18(日) 23:52:24.01

Goでレシーバがnilになれるのは案外便利だぞ。
あれは罠ではない。

型や型クラスに階層構造持つのはいつでも便利なわけではないと言うか、結局コンパイラ都合を押し付けられてるだけな気がするけどな。
その辺、後出しジャンケンできるGoのinterfaceの方が楽な事が多い。

**デフォルトの名無しさん** · 2018/02/19(月) 00:07:59.55

ジェネリクスは、コード上別の箇所に出現する型Aと型Bが同一であることを明示することにより、型情報の損失を避けるために使うんだよ
ダックタイピングは関係ない
C++やHaskellをやってる人は>>765みたいに混同しがちだけど、JavaやC#だと多態とGenericsをわりとはっきり区別する文化がある
TypeScriptのGenericsも同様に、型の同一性を示すマーカーとしての性格が強いね

**デフォルトの名無しさん** · 2018/02/19(月) 01:32:35.15

「型が同一である」の定義がわからない
犬型と猫型は異なるともいえるし同じ動物型ともいえる
この辺の仕様を捨ててからジェネリクスを追加するのが基本

もし両方入れてゴミ言語ができたら
捨てられないのが原因ともいえるし追加したのが原因ともいえる

**デフォルトの名無しさん** · 2018/02/19(月) 01:40:02.40

それに対して型の制限を型でなくしたのがHaskellの型クラスやRustのtraitだし、型を分解する事で非同一性を示すのが多くの言語にあるパターンマッチじゃないの

**デフォルトの名無しさん** · 2018/02/19(月) 07:49:12.96

型階層のある言語でアドホックに型クラスをやりたいなら別途Comparableみたいなインスタンスを受け取るようにするだけだろ
ジェネリクスと区別するっていうのは端的にはそういうことで、実際に引数として明確に分かれることになる
JavaやC#, TSだと型引数に制約を付けることで中途半端に似たことができてしまうのが微妙に直行してなくてダサいけど、それは基本的にあまり使われない機能

**771** · 2018/02/19(月) 07:54:42.45

すまんComparatorの間違いだ
補足しとくと、直行してないというのは例えば具体的には <T extends Comparable> と (T obj, Comparator<T> comparator) みたいなののことな

**デフォルトの名無しさん** · 2018/02/19(月) 09:53:32.16

>>767
便利さを教えてほしいな。
純粋なnilと型があるけど中味はnilって正直わかりづらくないかな。
reflectionのお勉強をしないと理解できない。

Goのインターフェースは後出しジャンケンってのは面白いな。パクらせてもらおう

**デフォルトの名無しさん** · 2018/02/19(月) 09:58:27.89

>>768
このへん詳しく知りたいな。
C++とかHaskellのジェネリクスってTypeScriptとかと違うの？

**デフォルトの名無しさん** · 2018/02/19(月) 12:10:56.39

>>773
それがnilでも、メソッドチェーンできる。
だから、errを伝搬するのに便利。
末尾のDoなんかで、本当の結果,errorとして取り出せば良いよ。
いちいち失敗構造体なんぞ書かんでも良い。
Nullable的に使える。

どっちかというと下回り書いてるときに便利かも。

**デフォルトの名無しさん** · 2018/02/19(月) 12:44:49.19

>>774
C++はテンプレートを使ってダックタイピングができる
Haskellはアドホック多相を使って>>772でいうcomparator引数に相当する要求をTの型制約に含められる

**デフォルトの名無しさん** · 2018/02/19(月) 14:19:03.08

>>775
なんかサンプルある？とょっとイメージがつかめない。nilでメソッドチェーンができるのはわかるけど、それがメリットになるかな？
結局nilを、返してるメソッドがエラー状態な訳で、そいつが暫定的な値を返せばメソッドチェーンはできるよね。

**デフォルトの名無しさん** · 2018/02/19(月) 15:23:40.87

ハスケルのメイビーみたいなことだろうな。

**デフォルトの名無しさん** · 2018/02/19(月) 16:10:57.83

>>777
暫定的なオブジェクトに、レシーバ書いてくの？
Hoge().Get().ReadAll().AsString()
で、毎度nilチェックとか暫定レスポンスのオブジェクト置いてたら非効率じゃん。
ToXXX以外の関数が、Hoge()の返す型やinterfaceを返せば楽じゃない？
Getに失敗したかReadAllに失敗したかが必要ならまた別だろうけど、だいたいひとからげにして問題ない事の方が多い。

**デフォルトの名無しさん** · 2018/02/19(月) 18:59:46.08

>>779
error情報を最初から諦めるってことね。
とにかく最終結果がnilだからメソッドチェーンのどっかで失敗してんだろーなー。くらいの感じなのか。

標準ライブラリでそういう実装してるのあるかな？reflect.Valueとかかな。
あれメソッドチェーンできる代わりに不正なメソッド操作するとpanicしててなかなかしんどい。

**デフォルトの名無しさん** · 2018/02/19(月) 19:03:08.21

>>780
ちょっと違うけど、protobufあたりはもう少し有意義に使ってたな。

**デフォルトの名無しさん** · 2018/02/19(月) 19:14:13.94

流れをぶった切って悪いけどTypeScriptはさすがMS。開発リソースたっぷり。という余裕を感じる。vscodeと一緒に毎週くらいの勢いでアップデート繰り返してる。

ジェネリクスの気持ち悪さもエラーメッセージがわかりやすく進化する感じで直してくれれば全然良いので頑張ってもらいたい。

**デフォルトの名無しさん** · 2018/02/19(月) 19:17:59.63

goのことは全然知らないんだが、型付きnilとやらは実行時ディスパッチしてくれて
その型のメソッドにnil引数付けてやってくるという理解でOK？

**デフォルトの名無しさん** · 2018/02/19(月) 20:22:12.51

まずメソッドではなくて、ちょっと変わった構文のの関数ぐらいに受け取ったほうが良いかも。
Foo.Bar()は
Bar(Foo)と、
Foo.Bar(a,b)
は
Bar(Foo,a,b)と同じぐらいの意味。
だからFooがnilでも(ポインタに対してのレシーバであれば)呼べる。

**デフォルトの名無しさん** · 2018/02/19(月) 23:02:26.53

やはりメソッドチェーンは何回も値 (nil) を返すのが気になる

Haskellでは
((Nothing >>= f) >>= g) >>= h
こうするとNothingのパターンマッチを3回するのに対し
Nothing >>= (\ y -> f y >>= (\ z -> g z >>= h))
これなら1回だけ