【.NET】F#について語れ2【OCAML】

**デフォルトの名無しさん** · 2011/05/01(日) 02:46:49.52

MSResearchから出てきた.NETで使える関数型言語のひとつF#
OCAMLの流れを汲むこの言語、いろいろと面白そうなことができそう。
そろそろ日本語の情報が充実してきそうなこの言語について、幅広く語れ。

http://www.fsharp.net/

前スレ
【.NET】F#について語れ【OCAML】
http://hibari.2ch.net/test/read.cgi/tech/1186030985/

関連スレなどは >>2-

**デフォルトの名無しさん** · 2019/03/23(土) 00:41:02.20

関数型言語が流行るときは果たして来るのかな？

2010年くらいまでは、cpuとgpuがまもなく統合されて、命令的でなく、宣言的にかける関数型言語でかくことでプログラムの並列化が自動的になされる時代が来るとかいう謳い文句をよく耳にした。

でも現実は関数型言語で並列プログラミングをしている人は少なくて、directx12とかvulkanの登場に象徴されるように、並列化したければ、寧ろもっと命令的でstate machineを操作するようなスタイルが主流になってしまった。

**デフォルトの名無しさん** · 2019/03/23(土) 00:54:03.50

いやDirectX とか引き合いに出されても、それが普通の並列のケースかいったらちがくね？

**デフォルトの名無しさん** · 2019/03/23(土) 00:54:13.93

コンピュテーション式を使って、async{}の内部では文を特別に解釈することで、簡単に非同期処理をすることができるというのはF#の優れた点だと思う。
けれど、AsyncなんかはC#とか色々な言語に取り込まれつつある。

折角頑張って本を読んで、F#を使ってはみたが、クラスを作らなくてよい、代数的演算ができるようになったC#という程度の使い方しかできない。

コンピュテーション式は俺には使いこなせる気がしない。プログラミング言語を使うことそれ自体が目的みたいな人なら使えるかもしれないが。このスレッドをざっと見てみたけれど、殆どのF#でコンピュテーション式とかそういう機能使う人いないんじゃないかな。

**デフォルトの名無しさん** · 2019/03/23(土) 00:59:32.27

結局俺が言いたいのは、2010年くらいまでによく聞いた関数型言語の宣伝文句は大げさ過ぎだったということだ。

**デフォルトの名無しさん** · 2019/03/23(土) 01:06:26.22

>>949
普通のケースではないけれど、当時はゲームエンジンの制作者までもが関数型言語に期待しているような記事があったんだよ。ゲームにまでも関数型言語か！これは関数型言語をやらざるを得ないな！って思ったことを覚えている。
https://game.watch.impress.co.jp/docs/20080911/epic.htm

**デフォルトの名無しさん** · 2019/03/23(土) 01:21:43.24

よく分からないんだが、自分が使いこなせない？のかよく分からなかったという理由で誰も使ってないと思うのはなんなの？
WEBでもReactとかまさに関数型の考えでできてるしElmはピュアだし、いろんな言語に関数型の要素取り入れられてる
シェーダーとかまさに関数だし、ゆにていのECSとかオブジェクト指向で色々効率悪かったから値の配列を元に処理するぜって話だし、Rx系もいろんなところに移植されてる。
むしろ色んなところで関数型の考えで応用されてると思うけど。

**デフォルトの名無しさん** · 2019/03/23(土) 01:30:39.33

デザパタとかほとんど不要になったしな

**デフォルトの名無しさん** · 2019/03/23(土) 04:56:56.13

>>948
・ユーザーは同じ操作をすれば同じ結果が返ってくるソフトを求めてる(ある種の参照透明性のあるソフトを求めてると言える)

・しかし手続き型言語は参照透明性が保たれない。

この時点で論理矛盾は有るんだけど、流行らないでしょうね。。。ー>関数型言語

**デフォルトの名無しさん** · 2019/03/23(土) 05:05:32.95

>>952
覚えてますよー。
恐らく並列用のライブラリ充実で手続き型言語で良いやってなったんでしょうね。
シングルスレッドは手続き型言語優位ですし、並列ライブラリ揃えばパフォーマンスは手続き型言語に軍配上がりますから。

**デフォルトの名無しさん** · 2019/03/23(土) 05:11:15.99

ちなみにHaskellは純粋関数型言語という事で並列に向くのではと思われましたが、純粋さの為に遅延評価だったのが災いしてます。
(遅延評価が並列動作を徹底的に邪魔をする)

実用的には金融系で採用されたOCamlのように純粋でない関数型言語の方が並列に向いているようです。
(並列プログラミングでよく名前の上がるErlangも純粋じゃないですよね)

**デフォルトの名無しさん** · 2019/03/23(土) 11:44:18.54

遅延評価と純粋性がごっちゃになっておる

**デフォルトの名無しさん** · 2019/03/23(土) 12:37:37.78

俺純粋なんだけど、あの子は振り向いてくれない

みたいなもんか

**デフォルトの名無しさん** · 2019/03/23(土) 12:43:08.27

>>959
純粋男子はモテないからな
ジェントルよりワイルドに
ワイルドよりデンジャラスよ

**デフォルトの名無しさん** · 2019/03/23(土) 14:19:44.65

Haskellが遅延デフォなのは副作用を外に持ってた関係？
その辺よく知らんけど純粋と遅延は一体じゃないでしょ
関数型はパフォーマンスではそりゃゴリゴリメモリ書き換えるやつの方が速いかも知れんが、そりゃメンテ性とか色々一切無視したあまりにも乱暴な議論じゃねーの。

重ねていうけどいろんな言語に関数型の概念は染み渡ってて、それで関数型が流行らないとか言われてもむしろすでに乗っ取られてはしませんかって感じしかしないわ。

そもそも関数型も手続き型も各々得手不得手あるんだからどっちが勝った負けたの話じゃない

**デフォルトの名無しさん** · 2019/03/24(日) 22:48:09.05

質問です。２重ループ内で関数Fを呼び出して処理をしようとしているのですが、これをreduceなどを使って簡潔に表現する方法はありますか？

for i in seq1 do
for j in seq 2 do
F(i,j)

**デフォルトの名無しさん** · 2019/03/24(日) 22:56:58.91

先ほどの訂正:
seq1は２次元のコレクションでseq1の各要素を引数にしてとある関数Fを呼び出すということをやりたい。

for i in seq1 do
for j in seq1.[i] do
F(seq1.[i].[j])

**デフォルトの名無しさん** · 2019/03/25(月) 01:12:57.65

Haskellしか知らんけど、関数型言語である以上似たようなものがあるはずなので。。。

1・main =print $ [map f (lst!!y) | y <- [0..length lst - 1]

lst = [[1,2,3],[4,5,6]]

f = (+1)

2・main =print $ map (map f) lst

lst = [[1,2,3],[4,5,6]]

f = (+1)

**デフォルトの名無しさん** · 2019/03/25(月) 08:28:31.79

>>963
seq1|>Seq.collect id|>Seq.iter F
のことでいいのかの？

**デフォルトの名無しさん** · 2019/03/25(月) 08:35:51.05

let f = printfn "%d"
let l = [[1;2;3]; [4;5;6]]
let kk = List.collect id l |> List.map f

**デフォルトの名無しさん** · 2019/03/25(月) 08:36:41.76

かぶったすまん
iterの方がええね

**デフォルトの名無しさん** · 2019/03/25(月) 13:16:59.54

いやmapしたいのだったらそっちで正解かと

**昨日質問したものです** · 2019/03/25(月) 22:24:43.80

>>964
Haskellなのでよくわからない部分もありますが、
map f (lst!!y)が1つ目のforループの代わりになって
(lst!!y) | y <- [0..length lst - 1]が2つ目のループの代わりになる感じだと理解しました。

>>965
Seq.collect idを使って2次元を1次元に並べ直すんですね。

ありがとうございました。関数型言語は難しいです。
私には、forループの方が分かり易く思えてしまうのですが、皆さんは副作用のない場面ではforよりcollectとかmapを使う感じですか？

**デフォルトの名無しさん** · 2019/03/25(月) 22:50:11.46

気分かなー
上からパイプライン演算子で繋がってない時はiterの代わりにfor使うことも

**デフォルトの名無しさん** · 2019/03/25(月) 23:12:16.99

>>969
うい。
Haskellのlst!!yは普通の言語のlst[y]に置き換えてくれれば。

リスト内包表記でも作れそうだと作ってみましたが、
普段インデックスなんて意識しなかったから、ちょっと悩みました。

最初、こう書いてみたら2次元から1次元になったので違うな。。。と。
(全部に適用するのは同じですが、リスト(配列)の構造(次元)が違ってしまう)

[f (lst!!y!!x) | x <- [0..(length.head) lst - 1], y <- [0..length lst - 1]]

結局map (map f) lstが一番簡潔でしたが。

**デフォルトの名無しさん** · 2019/03/25(月) 23:18:05.28

F#良く知らないけど内包表記で
[ for xs in xss do
for x in xs -> f(x)]
みたく書けないん？

**デフォルトの名無しさん** · 2019/03/25(月) 23:33:50.20

>>970
変に関数型にこだわるより簡潔に書ける方を使うということですね。

**デフォルトの名無しさん** · 2019/03/25(月) 23:44:59.82

>>971
lst!!y!!xでコレクションの形を表してxやyに対しての操作を記述しているってことですか？
このような記述はＦ＃でできるのかな。。。

>>972
質問の仕方が曖昧だったかな。リストを生成するのでなくて、コレクションの各要素に対して関数を適用して副作用を得るのが目的。で、それをforみたいなループを使わずに書けないかという質問でした。

**デフォルトの名無しさん** · 2019/03/25(月) 23:55:50.61

>>974
あんまり難しく考えなくて良いですよ＾＾;
リスト内包表記でxとyの全ての組み合わせが小さい順で出るので、それをインデックスに使ってるだけです。
F#にもあると思いますよ。

1次元になって良いなら、

(map f.concat) lst

が簡潔でしょう。

>>965-966 のcollect id がちょうどconcatと同じ事してます。

**デフォルトの名無しさん** · 2019/03/25(月) 23:57:10.44

>>974
オペレーター書けば出来るとおも

**デフォルトの名無しさん** · 2019/04/05(金) 14:57:42.01

Microsoft makes F# 4.6 and F# tools for Visual Studio 2019 generally available

**デフォルトの名無しさん** · 2019/06/18(火) 06:24:44.70

プログラム板にキチガイ降臨中！botに一晩も反応する異常さ
一般人(学校恩師)に殺害予告をしているのでスレ建て通報してください。
https://mevius.5ch.net/test/read.cgi/tech/1559872586/

142 名前：a4 ◆700L1Efzuv 投稿日：2019/06/18(火) 05:29:55 ID://qVkzO
>>141
名古屋の人な　俺ね、君の問題を大橋先生と混ぜないことにする。つまりね、
片桐孝洋のことをボコろうと思う。普通に顎の骨を折る。これくらいで警察来るか？
一般市民とかさ、普通にさ、俺らの秘密なんだけどさ、日本人なんて復活ねーから。

**デフォルトの名無しさん** · 2019/07/09(火) 22:26:17.25

F#の公式リファレンス
たとえばList.splitAtが
左側のメニューにはあるけど一覧表のほうには無かったり
色々不備がある、コアライブラリの漏れの無い完全なリファレンスってどうやったら得られる？

https://msdn.microsoft.com/visualfsharpdocs/conceptual/collections.list-module-[fsharp]

**デフォルトの名無しさん** · 2019/07/09(火) 23:29:34.93

ソースみたほうが早いやろ

**デフォルトの名無しさん** · 2019/07/10(水) 07:48:30.66

>>979
インテリセンス？

**デフォルトの名無しさん** · 2019/07/10(水) 10:27:08.20

バージョンアップされたり
パッチ出るたびに
毎回ソース見直すのか
ご苦労さん

**デフォルトの名無しさん** · 2019/07/10(水) 14:49:37.18

>>982
公式ドキュメントの漏れや不備がないか心配って言ってるんだからそれしかないだろう
バージョンアップの度にソース見直すとかってのはお前が勝手に言いだしてることだから俺には意味がわからん

**デフォルトの名無しさん** · 2019/07/13(土) 03:11:40.87

>>979
公式リファレンスがいろいろ不備があって不便、でよかった
どうやって得られるとか変に前向きな姿勢見せたからこのありさま
スキ見せたらあかんで！

**デフォルトの名無しさん** · 2019/07/13(土) 05:05:29.01

スレたて以降８年もたってるのに全然流行ってる気配ないぞ

**デフォルトの名無しさん** · 2019/07/13(土) 08:18:43.51

まあはやってはないしな実際
C#なんかより遥かにマシなんだけどね

**デフォルトの名無しさん** · 2019/08/05(月) 22:08:11.43

ましって何が？

**デフォルトの名無しさん** · 2019/08/06(火) 00:15:19.73

言語としてまし

**デフォルトの名無しさん** · 2019/08/17(土) 16:38:45.86

んじゃ、言語ましましで

**デフォルトの名無しさん** · 2019/08/19(月) 08:46:52.63

C#とF#で「F#のほうがマシ」と言われる理由が分からん。
C#とF#が違う点って「書き方」だけだよね（どちらもCLIに落とされたら同じ）。
書き方で「マシ」「マシじゃないない」の議論するってもはや言語関係ないじゃん。

**デフォルトの名無しさん** · 2019/08/19(月) 10:40:41.65

インライン強制あたりはC#では実現できないILの産み方するんでは？
あとは単位つけれるアレとか。コンパイル時後は消えるけど、書き方の問題だけではなくて実際にコンパイルエラーを起こしてくれる賢い機能だと思うけど。
あとなんだろ。スタックに変数確保がとても楽とかかな。最近やっとc#でも出来るようになったけど、まだまだ不便よね。

**デフォルトの名無しさん** · 2019/08/19(月) 23:18:21.85

>>990
言語が違うからマシな書き方が出来るんだが…

>>991
スタックにおくってなんの話だっけ？

**デフォルトの名無しさん** · 2019/08/20(火) 11:42:16.19

>C#とF#が違う点って「書き方」だけだよね（どちらもCLIに落とされたら同じ）。

機械語になったら同じ(少なくとも同じCPUで実行してれば)だから
PHP の方が Ruby よりましだな

**デフォルトの名無しさん** · 2019/08/20(火) 12:38:36.66

>>992
キャプチャされないlet mutableはスタック上に確保される

**デフォルトの名無しさん** · 2019/08/20(火) 13:38:14.98

>>994
それは値型参照型問わず？

**デフォルトの名無しさん** · 2019/08/20(火) 13:47:24.56

わず

**デフォルトの名無しさん** · 2019/08/20(火) 15:50:26.07

>>996
その辺書かれてるドキュメントとかある？
ローカルでレコードやユニオンをただ値に束縛してるやつとかもそうなんか？

**デフォルトの名無しさん** · 2019/08/23(金) 12:59:41.19

>>990
でもC#の代替及びすみ分け、でしかF#の生きる道はないし
それで生き残れているだろう

**デフォルトの名無しさん** · 2019/08/23(金) 15:07:25.79

次スレ無しでOK

**デフォルトの名無しさん** · 2019/08/24(土) 05:21:57.38

Slot
🎴👻👻
🎰💣🌸
🌸🍒🎰
(LA: 0.90, 0.83, 0.75)

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 3037日 2時間 35分 8秒