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

**デフォルトの名無しさん** · 2019/09/08(日) 19:16:25.58

**デフォルトの名無しさん** · 2023/07/09(日) 22:25:24.69

>>209
typeとletで普通に見分けつかん？
英語の本あれば十分なのでは…というか英語でダメならこれを機会に英語勉強しろ
翻訳するのもあり

**デフォルトの名無しさん** · 2023/07/13(木) 00:01:20.07

F#のベストプラクティスがよく分かってないからあれなんだけど
moduleはC#でいうところのstatic classみたいなもんっていうの読んであれ？って
ユーティリティクラスは良くないとか言われるけどあんまstatic classにいいイメージ無くて
F#だと全然そんなことないの？ガンガンmoduleに色々突っ込んじゃえみたいな感じ？

>>210
注文した

>>211
いやtypeとletはそりゃ区別つくけど。関数だろうと変数だろうと条件分岐だろうと全部letじゃない
あとまぁpythonもそうだけどインデントで分けるのほんと分かりにくくて。カッコが無いときつい
英語割りと得意な方だけど勉強するときはやっぱり日本語のほうが頭に入る

**デフォルトの名無しさん** · 2023/07/25(火) 20:56:40.72

判別共用体がよくわかりません。例えば
type Shape =
| Rectangle
| Circle
| Prism
みたいな例だと最初いやお前らどこから出てきた。そんな型ないだろと思って
んじゃenumみたいに0から番号振ってるのかと思ったらそうじゃないって言うし
それでいきなりlet x = Rectangleみたいな使い方が出来るなんて言われてもうちんぷんかんぷん。それでxの型はShapeだっていうし
RectangleだのCircleだのは識別子って言うらしいけどこいつら一体なんなんですかね。英語サイトなんかだとコンストラクタだと思えばいいよみたいなこと書いてたけど
そもそもクラス定義なのにこの内のどれかってどういうことなんですかね。例えばlet y = Circleみたいにやったときxとyの違いってなんでしょう？（参照するアドレスの話ではない）
暗黙的にprivate int typeみたいなのが生成されて番号振られてるとかなら分かるんですが

今日一日ずーっとあれこれサイト巡ってchatgptとかにもお伺い立ててそれでも全然理解できませんでした
大体どの本も最初でさらっと流してるけどどうしてみんな理解できるんですか？自分の理解力の低さに悲しくなってきました

**デフォルトの名無しさん** · 2023/07/26(水) 20:16:10.29

>>213
オブジェクト指向でのクラス・サブクラス関係のようなものと考えればいいんじゃないか?
RectangleクラスやCircleクラスのインスタンスはShapeとして扱える、みたいな話の関数型の考え方での表現方法

**デフォルトの名無しさん** · 2023/07/26(水) 22:00:01.17

自分は理解に困ったことなかったんで新しい知見だけど
背景知識でどう書き換えられるかを調べてみたらどうだろう。
その感じだとC#とかJavaとかのオブジェクト志向言語は使えるんでしょ
～言語で書いてみる、とかでググってみたらどうかな

番号振られてるのとコンストラクタ（≒クラス）で識別できるのはあまり変わらない気がするけども

**デフォルトの名無しさん** · 2023/07/26(水) 22:10:22.50

xとyの違いは値の違いだと思うよ
どちらもShapeクラスのインスタンス
C#で書くなら、Shapeクラスがpublic static readonly Shape Circle = new Shape(ShapeId.Circle)ってなやつを持ってれば、だいたい同じになりそうじゃん？
これならprivate int ShapeIdで区別してるって考えられるけど。

CircleとRectangleの区別のために、実際にどう実装されてるか気にしなくてもいいと思うけどね

**デフォルトの名無しさん** · 2023/07/27(木) 20:58:49.84

>>213
> そもそもクラス定義なのにこの内のどれかってどういうことなんですかね。

どういうことっていうか、そもそもクラス定義じゃないので。

無理やりオブジェクト指向に当てはめるとすると、
null許容型みたいに複数の選択肢を与える型とレコード型を融合させたものと考えたらいいんじゃないですかね。
ただ例え話にも限界が有るし、素直に頭を関数型言語にシフトさせた方がいいと思います。

**デフォルトの名無しさん** · 2023/07/27(木) 23:01:28.28

>>213
その例だとRectangle、Circle、Prismは中身がないから
単なる番号と考えることもできるだろうけど
中身がある場合はそうもいかないでしょ
learn.microsoft.com/ja-jp/dotnet/fsharp/language-reference/discriminated-unions

Haskellにも同様のものがあるし
www.letitride.jp/entry/2020/05/05/092738
Scalaにも同様のものがある
zenn.dev/mossan_hoshi/articles/20230417_scala

ScalaではF#のinterfaceのようなものであるtraitと
こうした目的のための特別なclass定義 case classがあり
CircleやRectangleの定義でShapeを継承している >>214

**デフォルトの名無しさん** · 2023/07/27(木) 23:41:44.86

>>217
あれちょっと衝撃的だったんですけどクラス定義ですよね？typeだし

**デフォルトの名無しさん** · 2023/07/28(金) 00:31:33.37

あーちょっと思いついて判別共用体をDLLにしてC#で呼び出して定義に移動したらC#で判別共用体がどう解釈されるかは分かりました
sealed class Shape の中にstatic class Tagsが定義されてint Rectangle = 0, int Circle = 1みたいに番号振られてますね。考え方としては間違ってなかったのかな……

**デフォルトの名無しさん** · 2023/07/31(月) 19:11:32.66

returnが無いの本当にきついと思うんですけど慣れますか
最後まで関数読んでもそもそも何を返しているのかさえ分からないのが日常茶飯事なんですけど
if condition then xxx, true else...みたいなのがあっては？true？なんじゃこの構文と思って散々検索した後にxxxとtrueのタプルを返してるとchatgpt先生に教えてもらったときは無理だろってなりました

**デフォルトの名無しさん** · 2023/07/31(月) 19:38:50.32

書かれているとおりのものが返るだけなのにreturnがあるはず(あるべき)という
思い込みのせいで分からなくなってるわけで、returnがあるはず(あるべき)という
思い込みはいつか消えますかと問われても、人によるだろと答えるしかないな

**デフォルトの名無しさん** · 2023/08/03(木) 19:15:32.83

確かにオブジェクト指向とは違う表現が多いだろうけど、それ以上に面白いと思うけどなあ
特にCopilotとの相性が良すぎる

**デフォルトの名無しさん** · 2023/11/18(土) 22:09:32.82

コンピュテーション式まじでわかんねぇ……
let!とかdo!とか解説をいくら読んでも理解できん。デバッグでステップごとにやってるとlet!の次の行実行しないでいきなり波括弧終わったりするのなんでや

**デフォルトの名無しさん** · 2023/11/19(日) 02:44:53.10

コンピュテーション式の名前をはじめて知った初心者だけどステップインで実行したら1行ずつ動いて、
この記事のコメントで書いてるイメージのコールバックの動きが実感できた
ttps://zenn.dev/zecl/articles/a330820e9277cf#option%E3%83%A2%E3%83%8A%E3%83%89%E3%81%AE%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%86%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E5%BC%8F

中身がコールバックだからかデバッガが上手いこと判断してくれないんかな。

**デフォルトの名無しさん** · 2023/11/22(水) 23:34:53.49

コンピュテーション式まじで難しい
大体公式のhttps://learn.microsoft.com/ja-jp/dotnet/fsharp/language-reference/computation-expressionsこれはなんだ。理解できる人間が存在するのか
記事とか読んでてもこういう風に自動的に変換できるんだよ簡単だねみたいな書き方してるけど変換先がもうわけわからん
これを頭の中で想像できない人間は書けないのか

**デフォルトの名無しさん** · 2023/11/23(木) 12:25:10.81

いろんなものを1つのシンプルな手法で表現できる仕組みなので、公式の説明にあるように抽象化された難しい概念なのでは
シンプルというのが簡単ではなくて、難しいというのは数学とかはよくあるよね

公式ではうそや矛盾する喩えを出さないように説明するから、
一面を単純化して喩えてるような、複数の外部の記事を自分の中で抽象化することで理解が進むんじゃないかな

**デフォルトの名無しさん** · 2023/11/24(金) 14:49:40.02

直ぐに仕組みを理解しなくても良いんでは？
仕組みを理解しなくてもある程度は使えるでしょ。
難しく考えすぎな気がする。

関数と変数と条件分岐が全部letだって、評価して何かしら結果が得られるものって思えば、全部同じでも困らないし。

**デフォルトの名無しさん** · 2023/11/26(日) 08:28:05.33

俺もそのマイクロソフトのサイトだけではさっぱり理解不能だと思う

コンピュテーション式はhaskellのdo記法を真似たものだから
わからなかったらそっちを勉強するのがいいかもしれない
bindの型をみて、bindがチェーンにする様子がイメージできたら
なぜ展開するとああいういかつい式になるのかが理解できてくるよ

**デフォルトの名無しさん** · 2023/11/28(火) 00:02:10.45

この表はよく見返して、型に合わせてパズルするよ。
https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/computation-expressions#creating-a-new-type-of-computation-expression

コンピュテーション式がなぜ必要なのかとか、どう置き換えればいいのかはここを読むといいかも
https://fsharpforfunandprofit.com/posts/computation-expressions-intro/

**デフォルトの名無しさん** · 2023/12/06(水) 04:53:42.99

ｒわｒ

**デフォルトの名無しさん** · 2023/12/09(土) 12:18:29.76

Haskellとかもそうだけどシンタックスシュガーの元の構文は複雑すぎるので
元の構文までしっかり理解して書けるようにするべきなのか？
というのは意見分かれるだろうな
使い方だけ覚えれば手続き言語のように使えるわけだし

**デフォルトの名無しさん** · 2023/12/15(金) 20:18:00.56

https://qiita.com/262144/items/01a3023612116180278e

**デフォルトの名無しさん** · 2024/02/18(日) 11:50:06.93

F#使ってる人殆といなくて悲しい

**デフォルトの名無しさん** · 2024/02/18(日) 13:02:53.69

どこのサイトで情報収集してる？

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

f#の書き方Copilotに質問したらあっさり解決した
geminiは全然駄目だねコンパイル通らなかった

**デフォルトの名無しさん** · 2024/03/17(日) 01:51:00.22

既に三か月もF#の記事がない公式ブログかな
https://devblogs.microsoft.com/dotnet/tag/f/

最近ずっとAIとクラウドの話しかされてない

**デフォルトの名無しさん** · 2024/03/17(日) 01:52:34.69

公式ブログかissue
ブログはもはやAIとクラウドの話しかしてない・・・

**デフォルトの名無しさん** · 2024/03/17(日) 11:23:11.60

コミュニティベースで頑張るよって言ってるし、あまり書くこともないのかも？

**デフォルトの名無しさん** · 2024/06/25(火) 19:17:22.19

F#はどの分野でよく使われてるんだろう？
web？データサイエンス？

**デフォルトの名無しさん** · 2024/09/15(日) 13:50:02.80

F#は良い言語だと思うけど、
C#やTypeScriptにくらべてマイクロソフトの愛情不足だよな

**デフォルトの名無しさん** · 2025/01/18(土) 16:10:54.77

ScalaとF#の両方触ったことある人いる？
もしいれば、個人的な感想で良いのでどちらが好みか聞いてみたい

**デフォルトの名無しさん** · 2025/01/19(日) 09:31:11.83

自分はScalaはちょびっとしか触ってないけど、前のScalaはScala固有の部分と、Javaを引き継いでる部分と2つにわかれてて綺麗じゃないなって感じを受けた
その点F#はC#とかVBのより型が便利なバージョンって感じでこちらのほうが好み

**デフォルトの名無しさん** · 2025/01/19(日) 10:51:52.69

OCaml.NETと呼べる存在ならともかく実際はそこまで互換性ないし、どうせ.NET独自言語ならC#でいいからなあ

**デフォルトの名無しさん** · 2025/01/21(火) 20:29:20.50

scalaはオブジェクト指向側に軸足あるような雰囲気だけど
それにしてはよく頑張って関数型に手を伸ばしてる感じ

F#は生まれ持っての関数型ではあるけど
世間に転がってるF#のコード見ると
そんなに関数型にたしなんでる人のコードじゃないのも多々見る
関数合成よりパイプラインを使ってるようなというか
JavaのStreami APIみたいに、メソッドチェーンみたいにして満足してる人々を多々見る

**デフォルトの名無しさん** · 2025/01/21(火) 21:14:20.24

パイプラインはF#らしいコードって印象
HaskellもData.Functionに(&)が定義されてて、F#のバナナブラケットみたいな使い方が出来る

**デフォルトの名無しさん** · 2025/01/22(水) 14:27:10.61

むしろこれからどんどんストリーム的なプログラミングが多くなるんじゃないか
Algebra Effectsで厄介なところはhandlerに閉じ込められそうだし
それはBackusのFP的になるってことだよね

**デフォルトの名無しさん** · 2025/01/22(水) 14:43:36.01

F#は利用者が少な過ぎんじゃないかな
処理系やライブラリにバグがあると手こずるよ
でもF#駄目でもOCamlに行けるというのはメリットかも

**デフォルトの名無しさん** · 2025/07/04(金) 15:27:24.17

OCaml、C#, VB.NET→F#
と遍歴してきたけど
Ocaml.Netという造語？は誠にその通りだと思いますわ