"Theorems for free!"とParametricityとJVMとCLRのジェネリクスの実装の違いの関係 - xuwei-k's blog
という題だけ思いついて、中身を書ける気がしないので、誰か書いて欲しい(他力本願) だいぶ自信がないのですが "Theorems for free!"で言っている、Parametricityについて、超大雑把に自分の今の時点の理解を言葉にしてみると「型パラメータによって関数の性質が変わらない*1」ということ(?) CLR*2のジェネリクスで型パラメータが保存されると、その性質を破ることが容易になる(?)ので、そういう論拠で「JVMがtype erasureなのは正しい」などと関数型なScalaの人達がたまに主張している(?) という話にもっていけるのでは？と思ったのですが、これ以上なにか書くほどの知識を持ち合わせていないので そもそもParametricityの理解から違ってそうだよ だいたい話の方向性合ってるよ JVMとCLRとParametricityの関係について、実はすでに書いてある
Scalaz の NaturalTransformation - xuwei-k's blog
以下のやりとりなどをして、なんとなく書きたくなったので解説してみます。 @gakuzzzz implicitついてないし、型クラスのインスタンスではなく、「高階レベルの関数」ですね。Id型使いたいだけなら、それ使っていいと思います(なにに使うのか・・・？) 2013-09-11 16:07:49 via web to @gakuzzzz ↑昨日。 ↓こっちは別のやりとり .@nagise @yuroyoro 値が多相になれないというかHaskellのforallが直接表現できないので、Haskell版のこれ URL をScalaで書くとこんなに長く、とか URL 2013-09-12 19:29:14 via web to @nagise まず問題です、scala.util.Try[A]をscala.Either[Throwable, A] に変換するメソッドは、どのように書けるでしょうか
関数を扱えるだけでは、モナドを表現するには不十分過ぎる - xuwei-k's blog
つまりなぜかいきなり高階型の話です。 これ 関数を扱えることはどのようにプログラミング言語の能力をあげるか に対する便乗というかツッコミとして。 つい先日もある人がこんなこと https://twitter.com/koropicot/status/365014333413011457 を言っていて*1、「ですよねー」と勝手に納得していたりしましたが。 つまりScalazでよくみるような高階型 trait Monad[F[_]] extends Applicative[F] { implicit val listMonad = new Monad[List]{ がないと、モナドとして抽象化や共通化ができない、という話です。*2 高階型についてはたとえばこれ (もりそば)Scalaによる高階型変数 - Higher-kind Generics とか読んでください。 関数がオブジェクトとして扱
( Javaには存在しなくて ) ScalaとC#には存在する言語機能 - xuwei-k's blog
いわゆる静的型付けでオブジェクト指向な言語という点からみれば、ScalaもC#もJavaも似ている点があるわけですが、その中でJavaにはなくてしかしC# と Scala である程度共通するものを書きだしてみた。別に「この結果 = Javaがダメ」とかすぐに結論づけたいわけじゃなく、自分の頭の中整理してみたかっただけです。この3つを選んだのも自分がある程度使った経験があるというだけに過ぎません。ちなみにここで言ってるJavaはJava6で、C# は4.0で、Scalaは2.8以降です。あと「似ている機能」があるだけで細かいところ色々違いますが、そこは自分の基準でなんとなく「似ている」と感じたものと書いているだけなのであしからず(´・ω・｀) 型推論( C# はローカル変数のみだけど ) http://ufcpp.net/study/csharp/sp3_var.html いわゆるラムダ式っ
Javaの10個のBad Partsのほとんどはscalaだと解決されちゃうんだぜ - xuwei-k's blog
ネタ元 業務系のJavaプログラマーが知っておくべき10個のBad Partsとその対策 結論から先に言うと、3と10以外は結構直接的にscalaで解決できるというか、javaに比べてscalaの方が便利だとおもいます。*1 あと、元ネタのblogの人はgroovy詳しいみたいですが・・・ groovyとscala比べるとgroovyの方が手軽で便利だったり、scalaのほうが型安全だったり*2いろいろあるかもしれませんが、groovyあまり詳しくないので、その辺の言及というか、比較はやめておきます。*3 1.標準APIのチェック例外が扱いにくい チェック例外ってなにそれおいしいの?(・ω・) java Field field; try { field = getClass().getField("testField"); Object value = field.get(this); }
scalaの、配列に対する統一的な扱いについて - xuwei-k's blog
C言語だと、配列ってなくてはならない存在で、入門書でも比較的最初の方に出てきますよね？それはいいとして、言語の誕生や影響うけた順として、 C => C++ => Java みたいなことがよく言われるじゃないですか？そして、C++でもJavaでも、C言語*1の配列の構文を、よくも悪くも受け継いでますよね？ なんか、出だしからまとまってなくて何が言いたいか意味不明ですが、scalaはその配列の構文受け継いでないよって話。 なんで受け継いでないか？それが具体的にどういうことか？を説明していきます。 これ以降基本的にJavaの例をだして、Javaと比較して説明します。 配列の特殊な構文を挙げてみると、以下のような4点でしょうか？ 1.初期化が簡単にできる。 2.型名の書き方が特殊 int[] intArray = {10,20,30,40,50}; // 中括弧つかう・・・ // "int[]"
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
