fsugjp/public

F#関連についてゆるふわ会話する場所です。初心者の質問も歓迎。

callmekohei

@callmekohei

＜文字列と数値の変換について＞

おはようございます。いろいろと自分でF#をまとめてるなかで文字列と数値の変換に関して２通り？みつけましたが使い分け等ありますでしょうか？お手すきの時に教えていただくと嬉しいです。

module Test20160310 =

    let str = "33"

    printfn "%A" (System.Convert.ToInt32(str))
    printfn "%A" (System.Int32.Parse(str))

    let num = 99

    printfn "%A" (System.Convert.ToString num)
    printfn "%A" (num.ToString())

Matsushima, Kazuhiro

@Gab-km

string <=> int32 の変換であれば、細かいことは置いといて、気分で選べばいいかと思います（個人の意見です

個人的には、いずれも後者のほうが好みですね。

あと、string => int32 についてはTryParseメソッドについても確認してみてください。

callmekohei

@callmekohei

ガブさん！いつもありがとうございます(^_^)/

bleis-tift

@bleis-tift

自分はint関数とstring関数使うことが多いですね

F#の型推論はコードの順番に依存しているっぽいので(メンバーの並び順ではなく、式の順番というべきか？)、型が確定するように書くと型を書く必要なくなります

callmekohei

@callmekohei

ブレイスさん！なるほどです。順番が重要なんですね！(^_^)/

bleis-tift

@bleis-tift

あ、順序の話は @omanuke さんへのものです

メンバーの並びに関しては、F#の場合1ファイル内で完結するので、多分特に問題にはならないと思います

例えばHaskellなんかでも並び順関係ないけど推論してますしね

bleis-tift

@bleis-tift

あと、何かヒントを追加するとしても、クラスには継承もあるのであまり現実的ではない気がします。

Scalaは引数に関して推論を諦めることで解決しましたが、ML族であるF#にはその選択はないでしょうし・・・

omanuke

@omanuke

HOGE:int->unit,HOGE:str->unitを持つクラスAがあったとして、v.Hoge argという呼び出し、argの他の使われ方でどっちのオーバーロードを呼んでるかわかる、わからなければ曖昧でエラー。BもHogeを実装してたらv.OtherMethodなどの使い方でAかBか特定、できなければエラー。継承関係は継承ツリーの一番ベースになるものを選択などでいけませんかね。ソースの並び順は、別アセンブリなら全部使えるし同じアセンブリ内ならソース順を踏襲する。HM的にコンパイル時間が長くなるなどは何も考えてませんがー(´･_･`)

bleis-tift

@bleis-tift

F#の推論の仕方を考えると難しい気がします

推論できても限定的で、あまり使えない感じも

継承関係に関しては、F#の方針的に基底クラスを選ぶというのをやりそうにないです。

配列リテラル等の限られた場所で、更に受け側の型が基底クラスの場合のみ基底クラスが選ばれますが、これは「特別扱い」としており、このようなものを増やすようには思えません

omanuke

@omanuke

うーん、その辺は方針的にどうなのか分からんですが、それ置いとくと技術的にはいけますよね？

限定的はどの辺を指します？

bleis-tift

@bleis-tift

式の先頭から末尾方向に推論する特性上、ヒントが活用できる状況は限定的では？ということです

また、感覚の話で申し訳ないんですが、推論部分を複雑にしすぎると人間にとって予測しにくい推論結果(こっちは推論できるのにこっちはできないのはなぜ？というパターン)が増えそう、というのがあります

bleis-tift

@bleis-tift

当然、推論しようとしている変数のスコープ全体が使えるなら、クラスも今より推論できる部分は増えるでしょう。なぜF#の推論器がそうなってないのかはよくわかりません。

その部分、Scalaの推論器も同じなので、変に影響されてしまったのかなぁ、とか

omanuke

@omanuke

あー、F#だと型推論する箇所でこれかもーじゃなく決まるか決まらないかですかね。
確かにルール複雑だと予期してない推論とかもあり得ますかねぇ
HaskellとかだとNumっぽいかもー、いやdoubleでしたとかってなる？
いずれにしても、型を書くのがだるいのでclassできるようになるとすてきなんですけどねぇ自分的には。VOICE漁ったらsuggestありそうですね。

bleis-tift

@bleis-tift

あと、 .NETでは型をガチガチに決めないといけなくて(JVMの場合、型パラメーター部分はガチガチに決めなくていい)、その辺りも厄介な部分な気がします。

型を書くのだるいから、できる限りメソッドを直接使わず、ラップした関数を使う派(ラップする関数を用意するのが今度はだるい

omanuke

@omanuke

んーその辺でどう厄介になるかは疎くてよくわからんです…
だるいすね…
UserVoice探りましたが…何の成果も！えられませんでしたぁぁ！(´・ω・｀)
https://fslang.uservoice.com/

bleis-tift

@bleis-tift

型推論の話とはまた微妙に違いますが、高階型を自然な形でメタデータに落とせないので、Haskellのようにオーバーロードの解決ができなくてつらいなー、という話でした

高階型、欲しい

omanuke

@omanuke

type classとかの話はちらふらあがってますねーやっぱりみなほしいんやな(´・ω・｀)

pocketberserker

@pocketberserker

談話室でkekyoさんにしゃべった（？）あたりのことをメモ。
http://pocketberserker.hatenablog.com/entry/2016/03/10/195043

bleis-tift

@bleis-tift

@pocketberserker 完全に思いつきなんだけど、

type IAsync<'T> = interface end
type AZero () = interface IAsync
type Wrap<'T>(x: Async<'T>) = interface IAsync<'T>

みたいな型階層用意して、ZeroではAZero返して、RunではWrap<'T>しか受け取らない、とかやって型合わせられないですかね

pocketberserker

@pocketberserker

it cond then ceのceもAZeroを返す必要があって、それをWrapに変換するタイミングがないはずです

bleis-tift

@bleis-tift

あー、if then elseだと型を完全に一致させないといけないかー

pocketberserker

@pocketberserker

はい

bleis-tift

@bleis-tift

じゃぁ、タグをつける感じでどうだ

pocketberserker

@pocketberserker

どういうやつですかね？

bleis-tift

@bleis-tift

type FromZero = class end
type FromReturn = class end
type A<'T, 'Tag>(x: Async<'T>) = ...

こんな感じにしておいて、RunはA<'T, FromReturn>のみを受け取る

pocketberserker

@pocketberserker

あー、それは試してないですね

bleis-tift

@bleis-tift

あ、だめか

結局if then elseで死にそう

ううむ・・・

pocketberserker

@pocketberserker

あ、でもタプルと同じようなものだからおっしゃる通りif then elseでだめですね

bleis-tift

@bleis-tift

どうやってもif then elseで同じ型にしなきゃいけないから、F#の型レベルでは解決できないっぽいな

pocketberserker

@pocketberserker

昨日の記事からいろいろいじって
https://github.com/pocketberserker/ComputationExpressions/blob/452d77b7be97cbae2ed022c0273629e214223a62/src/ComputationExpressions/Async.fs#L44

bleis-tift

@bleis-tift

type Zero = class end

として、Async<Zero>をゼロ値とみなし、Run(f: unit -> Async<Zero>)をObsoleteでコンパイルエラーにとか

pocketberserker

@pocketberserker

Async.Startをラップする形で開始時にゼロ値を渡すか、Unsafeモジュールでゼロ値をUnchecked.defaultofにするとかで今は回避してます

Obsolete…なるほど、考えてもみなかったですね

Where communities thrive

People

Repo info

Activity

＜文字列と数値の変換について＞