カリー化と部分適用の違いについては、過去のエントリ カリー化 != 部分適用 で既に述べており、決着もついているので改めて書きません。 カリー化 != 部分適用のエントリを書いたのは2009年12月です。もう3年以上前の話になります。ですが、JavaScript界隈などをみると、未だにカリー化と部分適用の違いについての誤解は残っているようです。一方で、静的型付き言語界隈でそのような誤解をほとんどみかけません。カリー化が関数の「型」を変換する操作(関数)であるために、動的型付き言語にのみ慣れ親しんでいると、両者の違いがわかりにくいのかもしれません。 ある技術用語が指すものを誤解する事自体は仕方ないことですし、責めるものではありません。また、用語が指すものは時代を経ると変わっていくものだという主張もあるでしょう。ただ、カリー化という用語の定義は明確に定義されており、数十年もの歴史があります。こ
最近、ネット上でカリー化に関する記事を読んでいると、特にGroovy界隈でカリー化に関して誤解がまかり通っているようなので(特に実用的なGroovy: カレー化クロージャーによるファンクショナル・プログラミングはひどい。そもそも、Groovyの標準ライブラリ自体がカリー化を行うための関数ではないものにcurryとか付けてるから仕方無いのかもしれんが)、一言言っておく。 カリー化というのは、Groovyで言うと、 def add = {x, y -> x + y} のように、xとyという複数の引数を取って値を返す関数を def add = {x -> {y -> x + y}} //間違ってパースできないコードになっていたので修正(12/17) のように、一つの引数xをとって、「yを引数にとって値を返す関数」を値として返すような関数に変換すること、あるいは最初からそのように表現することを言う
http://www.well-typed.com/blog/90/ foldlに関するこの記事(英文)が面白かったので、勝手翻訳しました。 foldlなんとかなるといいですね。 foldlを直す foldl 関数は壊れている。壊れているとみんなが知っている。 四半世紀近く壊れたままだ。ついにこれを修正する時が来た! 今日、私はPrelude.foldlをData.List.foldl'として知られる実装で再定義することを提案する。 foldlは壊れている! 既にご存知だとは思うが、念のため… Haskellerが必ずfoldlではなく、foldrやfoldl'を使うように勧めてくることにお気づきだろうか? 例えばReal World Haskellでは次のように言っている。 `foldl`のサンクの挙動のため、実アプリではこの関数を使わないようにするのが望ましい。 特に問題がない場合でも
… in an uncontrolled study, in which I reflect on my personal experience, I feel like I’m less productive. Therefore, you will be less productive as well, QED. Well, I think I can safely tick the ‘science’ check box. In this lengthy post, I’ll share my thoughts and opinions on Scala, and moving to it for day-to-day coding. Using a cavalcade of flawed data; logical fallacies; biased opinion; startl
Programming in Standard ML '97: An On-line Tutorial Stephen Gilmore Laboratory for Foundations of Computer Science The University of Edinburgh September 1997 (Revised June 1998, Apr 2000, Jan 2003, March 2004) Standard ML is a programming language which combines the elegance of functional programming with the effectiveness of imperative programming. This tutorial introduces important concepts in t
この記事では、私がオブジェクト指向のどこを愛しどこを素晴らしいと感じていて、そのうえでなぜオブジェクト指向を使うことを避けているのかを書き留めておきます。関数型言語使いの方で、「オブジェクト指向の何がいいのかわからない」「オブジェクト指向難しすぎ・複雑すぎ」とおっしゃる方にぜひ読んでいただきたいと思っています。また、「オブジェクト指向言語完璧に理解したわ」と思っている方にも読んでいただきたく思います。 なお、ここでのオブジェクト指向の定義は、「各言語でオブジェクト指向と呼ばれているものすべて」とします。JavaやScalaやJavaScriptやSmalltalkやRubyやCommon LispやOCamlがオブジェクト指向と呼んでいるものすべての総称です。もっとまともな定義が知りたい方は以下の記事がおすすめです。 オブジェクト指向の概念の発明者は誰ですか?(改訂版) - Smallta
プログラミング言語 Scala このWikiの目的は? Scalaのマニュアルの日本語訳を作成する。首尾よく日本語訳が完成したら、www.scala-lang.orgに置いてもらうように頼むつもり。--> 完成したのを連絡したのだけど、全然本家サイトに置いて貰えない...。 →置いてあるようです。Translations of the Scala Manuals ScalaのTipsなどの情報をまとめる。 使い方 普通に自由にWikiとして自由に編集して下さい。spam投稿で荒れたりするまでは、自由に編集出来る様にしておきます。 ご意見や不具合などありましたら管理人([email protected])までご連絡下さい。 もう何冊も日本語でのScala解説本が出たので管理人は和訳プロジェクトを放置状態です。このサイトの翻訳文を管理者がPDF化の作業は実施しませんのでご了承下さい。 チュート
All Elixir code runs inside lightweight threads of execution (called processes) that are isolated and exchange information via messages: current_process = self() # Spawn an Elixir process (not an operating system one!) spawn_link(fn -> send(current_process, {:msg, "hello world"}) end) # Block until the message is received receive do {:msg, contents} -> IO.puts(contents) end Due to their lightweigh
The Pure Programming Language http://pure-lang.sourceforge.net/ Pure is a functional programming language based on term rewriting. It has a modern syntax featuring curried function applications, lexical closures and equational definitions with pattern matching, and thus is somewhat similar to languages of the Haskell and ML variety. But Pure is also a very dynamic and reflective language, and is m
Robert Fischer claims Scala is not a functional language. But if you go by his post then Erlang isn't either. ModulesFischer says In OCaml, we define a function like this:let f x = x + 1;;In Scala, though, we define the function somewhat differently:object SomeHolderObject { val f(x:int):int = { x + 1 } } Now some Erlang -module(SomeHolderModule). -export([f/1]). f(X) -> X + 1. Erlang requires a f
Having now worked a fair amount with Scala, I can now unequivocally make this assertion: Scala is not a functional programming language. It is a statically typed object oriented language with closures. So, I’d appreciate it if people would stop the bogus sales pitch. To understand the distinction, take a look at this surprisingly interesting troll from Jon Harrop on the Scala mailing list. In that
Inspirations & experiments, mainly about denotative/functional programming in Haskell There is a lot of confusion about the meaning of “functional” and “declarative” as descriptions of programming languages and paradigms. For instance, Haskell is sometimes advertised as a “purely functional programming language” and other times as “the world’s finest imperative programming language”. I added some
Inspirations & experiments, mainly about denotative/functional programming in Haskell There has been a scurry of reaction on twitter and reddit to Robert Fischer’s post saying that Scala is Not a Functional Programming Language. James Iry responded by saying that analogous reasoning leads to the conclusion that Erlang is Not Functional My first inclination was to suggest that Haskell, as commonly
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く