#リストの動機ってなんだろう。
#リストの動機？
#@cut-sea なぜリストが欲しい？
#要素のひとつ(head)と残り(tail)に分離できて、先頭に要素を付加できる(:)、という構造があると要素の集合を扱う計算が何でもできていいよね、ってことで、それをリストって呼んでるだけじゃなくて?
#つまり、Haskellでは繰り返しのようなものもリストを使うけど、なにゆえリストなのか？ってことかな？
#そう。集合というだけならSetでもMapでもArrayでもよいわけで。
#リストがどこか特別扱いされている理由ね？
#そう。
#無限長の幻想が維持できるならArrayでもいいかも
#Setって順序ありましたっけ？
#ない
#リストは集合だけど、順序ありますね
#そう
#これはfoldr (.) id みたいなことをする場合には
#いや、関係ないか
#いやいや関係あるよね
#順序があって、無限であって
#あと
#再帰的な構造ってのはミソかも
#再帰は他ものOKそうだけど
#自然数と構造が同じだから？
#その見解はなかったけど
#自然数に似てるから？
#そうなのかなぁ
#ちょっと自信ないけど
#リストの自然な導入を考えてる
#初めての人のためのLISPのスタンスとしてはどんな構造もリストで表現できるよん！でしたけど、こいつは型に制限がないという点が結構重要なんですよねー
#Haskellではリストはデータ構造のひとつにすぎない
#にもかかわらず、かなり重要なbuild-in type
#あと、RWH読書会でも前回出てきて、kazuさんのブログでもかかれてた余再帰の話
#ふむ。
#あの辺もリストがHaskellにおいて自然で無理のない構造だってのを支持してそう
#それが自然だとおもうのはなぜだろう？
#なんででしょうね
#自然数って「自然」？
#難しいー
#Haskellでは[]という記法は組込で
#その時点で特別扱いしちゃってるから錯覚してるだけかもしれない
#なので、SetやMapと比較するなら
#data List a = ...で比較して
#という比較とか差を調べてみるってのはどうでしょ
#Array は可変長でないから、無限長の幻想を維持しようとすると高くつくと思いますが。（もちろん、「関数プログラミング」のように Array を木で実装しても良いけれど、そうすると今度は参照コストが……）
#data List a = Nil | Cons a (List a)
#data Nat = Zero | Succ Nat
#SetとListではどっちがより抽象的なんだろう？
#Setに順序を導入したらListになるの？
#要素の重複を表現する必要がある
#それとも
#Listの要素のOrdが全て同じ場合がSet？
#???
#ちがうと思う。> cut-sea
#というかどういう意味 > Listの要素のOrdが全て同じ場合がSet？
#いや、すまん。
#気にしないで
#扱いたいものが「集合」ではなく、「並び」だから？
#扱いたいものはその時々で違うから
#どちらかと言えば表現力にかかっているような
#「並び」が扱えるなら「集合」として扱える(解釈できる)よねみたいな
#「並び」の方がプリミティブ？
#概念として。
#初めての人のためのLISPを昔読んだときに、なんとなくだけど逐次・分岐・閉包(繰り返し)を表現できる構造なんだーって思ったことがある。
#正しい解釈かどうかは知らないけど。
#違うかLISPの構造を読んだときだっけ？ちょっと記憶曖昧。
#難しい話で私にはわからない＞プリミティブ
#IEだとchaton重いな。firefoxだと楽チンだ。誰かがIEはjavascript遅いって言ってたけどそうなのかな。
#いや、集合の方がプリミティブっぽい気がする。
#並びの方がより複雑な構造が入ってきているんじゃないかな。順序という。
#プリミティブというのはちょっと適切でない表現かも。
#集合に順序を導入したら並びになるのがやっぱり分かりやすそう
#集合と並びはべつものという感覚があるんだけど。そうではない？
#リストの「並び」の方が、重複不可能な「集合」よりもデータ構造としては単純ですね（そしてその分計算コストが下がる）
#私も別だとは思うけど、どっちかがどっちかのスーパークラス的なものって気がしてる
#並びの方が構造が簡単なの？＞shelarcy
#集合って重複不可能？
#データ構造実装としてはそういう階層を考えられなくはないけど
#集合は同じ要素が2つあることを表現しない。
#重複不可能だっていうことは「集合」は常に Eq a制約があるのね？
#そうか。
#じゃあどっちがどっちかのスーパークラスっていうより
#重複不可能な集合にしてしまうと、挿入操作の度に重複しているかどうかをいちいち調べないといけませんよ。なので、データ構造の実装としては集合の方が複雑になりますね。
#typeclassopediaで出てきたPointedみたく、まだ知らないクラスがあって、それと微妙に親戚関係にあるのかもしれないな。
#つまり重複も許すような「ものの集まり」
#それに順序構造をいれたら「並び」
#「ものの集まり」に重複不可の構造を入れたら「集合」
#(ひとりごと)タイムラグとLTの重複(chaton_haskellをフォローしているので)がなければTwitterでしゃべるほうがいいのかもなぁ
#そうなりますね。まあ、（Map の lookup 関数みたいに）挿入操作の方の制約にしておいても良いのですが。
#であれば、それぞれ全く別物というnobsunの考えでよさげ
#じゃあなぜ「ものの集まり」でもなく「集合」でもなく「並び」＝「リスト」なのか？
#というとやっぱり順序が重要だから？
#集合は抽象されすぎているから？
#でもさ、集合演算ってむしろドメイン特化な気がする
#そうかも。
#抽象化の度合いは別方向向いてるから、あまりどっちがより抽象的とは判断つかないけど
#つまり、違う種類の制約が噛んでいるようなので＞別方向
#計算機でなにをさせたいかという問題か？
#「要素の順序」ってのが「制御フローの順序」に対応可能なんじゃないだろうか
#順序がないとそれが表現できない。
#みたいな。
#先の方まで考えればそうだけど、もっと単純なものじゃなかろうか。
#いや、ダメか。
#自然数を最初にあつかえるのと同じような理由？
#集合を{}で書くとして、{(1, action),(2, action),(3, action)}という風に要素自体が相対的に順序を決定できるようにすれば済む話か。パフォーマンスが置いておけば。
#自然数を最初にあつかえるって？
#通常プログラミング言語では自然数をあつかえるよね
#整数？
#あれなんかちがう気がしてきた。
#自然数ってようするにカウントするためのもの？
#うーん。自然数は「生成」するものってイメージがあるなー
#その次、その次、その次・・・・
#だとすると、すごくプリミティブな感じがする。なにかをカウントするという応用はいかにも計算機にさせたい仕事だよね。
#nobsunが今書いたように「カウント」は「応用」なので、もっと根源的なものがあるんじゃないかしらん。
#実際[1..]はリストの一利用方法に過ぎない。
#[pred, then, else]も利用方法ですし。
#loop = 1:loopも一利用法ですし。
#やっぱり逐次・分岐・閉包が表現できる構造ってのが私にとってはリストを特別扱いするポイントの様な気がします。
#ちがうか。分岐はやっぱり微妙だな。
#上のはリストを扱う方に分岐の能力があるね。すまぬ。
#それに型もダメだし。
#そうなんだけど、その使い方がプリミティブなんじゃないかなぁ。と思うわけです。
#カウンタとして使う使い方が？
#そう。結局同じことを言っている気はするんだけど。。。
#数値計算という分野をのぞけば、計算機の使い道の最初はカウントではないかと。
#どうなんでしょう
#少なくともシンプルな応用は考えやすい → 計算の応用として原初的 ということにならないかしらん？
#Haskellのリストって実装の縛りはどのくらいあるのかな?
#縛りというと？
#Listだとリストに対するインデックスアクセスはO(n)、ベクタならO(1)っていうのがほぼ前提になってるけど、Haskellでリストが実は内部ではツリーでした、とかコンパイラがオプティマイズかけまくってシーケンシャルなアクセスしかされないから実はベクタで実現しちゃいました、とかあるのかなと。
#s/List/Lisp/
#API ？
#どのくらい抽象化されてるかってこと。Clojureでおもしろいなと思ったのは、シーケンスライブラリが「first, rest, consをもつデータ型」の上に構築されてて、このプロトコルを持ついろんなデータ型について共通の操作が出来るんだけど、Haskellくらい抽象度が高いと「リスト」というのがそもそも「head, tail, (:)」に応える何かって程度の意味しかなくて、実装上では実は色々な表現があったりするなんてことはないのかなあと。
#そしたら「並び」を表現する最低のプロトコルが「head, tail, (:)」であって、中身はどうなっててもいいからそれをリストと呼ぼうってことなのかなとか思ったんで。
#いろいろな実装が実際にあるかどうかはよくわからないですが
head, tail, (:), [] があればよいというのは確かです。
#あれ？(:)と[]だけでよいか。
#パターンマッチで分解するなら(:)と[]だけでいいですね。
#でも操作を考えるならheadとtailがあるってのが前提になるんじゃ?
#データ構造は結局データ構成子がAPIなので
#GHC が提供しているものではなくて外部のライブラリですが、最低のプロトコル上に抽象化されたものを提供するようなリストの実装は存在しますね。http://bit.ly/7Y2dKC #そうか、そういう考え方もあるか＞コンストラクタがAPI
#headとtailもパターンマッチで定義されているので
##あら、そのリンクはvisitedになってた>shelarcy。中身は覚えてなかったけど頭の中にひっかかってたのかもしれん。
#データ構成子とパターンマッチはHaskellではとても重要な役割をしています。三途の川の渡し
#てことは、ゼロ元と「それにひとつ要素をくっつける」コンストラクタがあれば「並び」の表現には充分ってことかな
#data X a = X0 | X a (X a)
#そうです。
#で多分それが「並び」を表現するもっとも単純な方法
#これはどのくらい抽象的なもんなんだろう。例えば自然数もよく似た感じで定義できそうだけど(「要素」を使わないだけで)、やっぱり「要素」があることがリストにとって本質なんだろか。それともリストの存在意義というのはもっと根源的な、こういう帰納的定義の最も単純な形態ってとこにあるんだろか。
#要素がいらないなら data X = X0 | X X でいいのか。ってことはこれはやっぱり別のものかいな。
#data Nat = Zero | Succ Nat
#自然数はカウントするだけ、リストは「並び」ということは、並んでいるものがある。つまり要素。
#元の問いに戻るけど、そしたらリストの動機ってのは最も単純な並びの表現ってことでいいのじゃないかしらん。そういう問いではなかった?
#そうですね。まさにそういう問い。
#自然数が「自然」であるなら、並びをあらわすリストも構造としては同じなので「自然」だ。
#hi
#hallo from germany
#www.bestefm.de | turkish radio
#hi
#この結論は、プログラマの感覚に整合するのだろか
#wher are you from nobsun?
#japan
#wat time ist it in japan
#15pm
#んーまてよ。型変数が入ってくると、再帰のやり形にバリエーションが出てくると思うんだけど
#data A = A0 | A A
data B a = B0 | B a (B a)
data B' a = B0' | B' (B' a) a
data B'' a = B0'' | B'' (B'' a) (B'' a)
#oooo... we haven mornigs 07:11 h
#BとB'は表記法のみの違いだから同じとしても、B''よりBの方が「自然」という根拠はあるんかいな。
#hi asker, I'm in Hawaii. It's 8pm here.
#hi shiro...ok.
#B'' はあきらかに再帰が分岐しているのでその意味では複雑ですよね。
#it`s here twitter chat?
#nah. it's a web-based chat system, and the log is fed to twitter. btw, the topic of this room is about the programming language Haskell.
#Traversable という意味では同じですが、深さ優先、幅優先の2種類あるという意味でB''は複雑。でも複雑だから自然じゃないということはいえるかな。
#Ok I have a message from the twitter module, I am left clicked landed here, I'm online radio holder make new page at the page had twitter module
#shiro, it is summer or winter in Hawaii, but as far as I know is always summer in Hawaii
#hawaii's in northern hemisphere, so it's winter.
#although it hardly goes below 20C. and in the daytime, the sun is still very hot.
#acha..OK
#(you can still swim in the daytime. night is chilly.)
#>nobsun そうか。コンストラクタの引数は別に2つでなくてもいいんだし、上のBの例はあんまり意味ないなあ。
#ooo how good we have winter here and -1 celsius, here is sick too many pork gripe
#in hawaii, a chilly day means you need socks.
#OK...they are on the main island or in a small island?
#asker, it's pleasure for me to chat with you, but this room is dedicated to the topic related to Haskell. Would you mind if we move the room to http://practical-scheme.net/chaton/chaton/ ? It's a test room and not bound to a specific topic. #ok shrio, I click link landed in the space!
#「並び」のシンプルな応用としては文字列かな。
#文字列扱いたい → ええ娘いまっせだんな。リストいいまんねん。
#自然数にしろ、リストにしろ、共通点があります
#それは、0 と [], Succ と Cons です (Snoc でもいいけど)
#そして、"recursively defined algebraic data" というキーワードが重要です
#くわしくは on demand 出版で買える "Algebra of Programming", Bird de Moor を取り寄せて読もう
#古くて、具体例が Miranda なところが残念で、Haskell 98 ならいいのに、といつも思うが、それ以外は非常に素晴らしい
#あと、on demand 出版だから値段が高いが、そこはなんとかして
#それをよむと、自然数やリストに対する「操作」(+, ++ など)が、foldable になっていることがわかる
#ずーっと、抽象化すると、「free algebra」というところまでいきますが、そうするともう数学の世界で、プログラミングからは遠ざかってしまう
#と、recursively defined algebraic data の話はここまで
#プログラムはFoldableだ！あれっなんかちがう？
#一方、Set (Bag) のような道具も、プログラマには必要で、というのは世界は recursive ではないから
#pure <-> stateful のような直交構造があるように、recursive <-> non recursive な直交構造もある
#ふむ
#functional programming では、「もの」が recursive かどうかを見極めると、fold ですっきり
#これは、stateful な構造がみえたときに IORef でなく monadic にするのとにています
#なんでもかんでも monadic (うそ) なんでもかんでも recursive (うそ)
#ここもうすこし掻いて > stateful な構造がみえたときに IORef でなく monadic にするのとにています
#nobsun 相手に書くけど、monadic なら f >>= g <<= h とか書くの好きでしょ、do 構文使う代わりに
#うん。
#fact 0 = 1
fact n = n * fact (n-1)
#っていうのは、自然数を recursive data として見極められていないひとが書くコード
#(fact に負の数を入れて定義することもできなくはないけど、そこは横においておきましょう)
#Freshman
#自然数を recursive data としてみると (Miranda => Haskell に翻訳中...)
#Miranda(R)のままでもOK
#うぐう、あたまがまわってない
#いや、本から引用するとなると、いろいろ準備がひつようで、しまったと思っているところ、なう
#ざっくりでゆるしてもらえるなら
#fact = undefined . fold undefined
#と、point-free で書けるんだけど、undefined おおすぎですみません
#もちろん、ざっくりでないと解らないとおもう。たしかどこかに件の本あったはずだな
#1つめのudefinedと2つめのundefinedは同じ？
#Pointless (ahem) “Points-free” Haskell programmer
#(studied at Oxford)
#fac = foldr (*) 1 . enumFromTo 1
##(くだんの本は、Oxford 大学の先生が書いています)
#この場合、enumFromTo 1 n を「1..nまで順番に数を生成する
#」と操作的に考えたら負けで、
#さすが shiro さん、洞察力が鋭い
#n回再帰している「何か」と考えるってことでしょうか。
#(+) = fold ..., (*) = fold ..., (foldl か foldr か、はたまた foldl' かはおいといて)
#ううむ。
#fold が「母
#となるのです、途中改行はいった
#リストも木も森もみーんな「きほんてき？」な関数が fold を母にもつ、なぜなら recursive algebraic data だから
#あと、すみません、コードは Miranda じゃなくて Gofer でした（くだんの本
#ただ、当然、可読性はさがりますよね、こういう書き方すると(勉強した人としてない人で)
#だから、あまり取り上げられない話題なんだとおもう
#コンパイラの最適化のひとが知ってればいい知識なのかもしれない
##ずーっと昔に、「何でもかんでもfoldまで分解して最適化しちゃおう」みたいな論文を読んだ記憶があります
#こういう抽象は抽象した後だけを見ると解りにくいけど、通常の世界でも無意識におこなっていることなのかもしれん。という気がする。うまい例を示せないけど。
#HOP のメンバーとして、"The Higher-order fold Functions" をマスターしてください (とかいう
#むむ。
#Foldableなものは順序があるってことでOK?
#FoldableはあくまでもFoldableということじゃ。
#手元で:iとかできないのですがFoldableを:iとかすると？
#*Main> :m +Data.Foldable
*Main Data.Foldable> :i Foldable
class Foldable t where
fold :: (Data.Monoid.Monoid m) => t m -> m
foldMap :: (Data.Monoid.Monoid m) => (a -> m) -> t a -> m
Data.Foldable.foldr :: (a -> b -> b) -> b -> t a -> b
Data.Foldable.foldl :: (a -> b -> a) -> a -> t b -> a
Data.Foldable.foldr1 :: (a -> a -> a) -> t a -> a
Data.Foldable.foldl1 :: (a -> a -> a) -> t a -> a
-- Defined in Data.Foldable
instance Foldable Maybe -- Defined in Data.Foldable
instance Foldable [] -- Defined in Data.Foldable
#39
#あら、制約にMonoidが出てきてる
#そらそうでしょうという感じ？
#でも t a がリストなら[] aに相当すると思うけどtには何か構造的に順序があるべしみたいな制約はないのかな。
#いや、Monoidはまだわからんので。
#そらそうとも納得いかんとも言えん
#ああ、逆かー。[]はFoldable。
#順序があるなしじゃなくFoldableか否か。
#class Monoid a where
mempty :: a
mappend :: a -> a -> a
mconcat :: [a] -> a
-- Defined in Data.Monoid
instance (Monoid a) => Monoid (Dual a) -- Defined in Data.Monoid
instance Monoid (Endo a) -- Defined in Data.Monoid
instance Monoid All -- Defined in Data.Monoid
instance Monoid Any -- Defined in Data.Monoid
instance (Num a) => Monoid (Sum a) -- Defined in Data.Monoid
instance (Num a) => Monoid (Product a) -- Defined in Data.Monoid
instance (Monoid a) => Monoid (Maybe a) -- Defined in Data.Monoid
instance Monoid (First a) -- Defined in Data.Monoid
instance Monoid [a] -- Defined in Data.Monoid
instance (Monoid b) => Monoid (a -> b) -- Defined in Data.Monoid
instance Monoid () -- Defined in Data.Monoid
instance (Monoid a, Monoid b) => Monoid (a, b)
-- Defined in Data.Monoid
instance (Monoid a, Monoid b, Monoid c) => Monoid (a, b, c)
-- Defined in Data.Monoid
instance (Monoid a, Monoid b, Monoid c, Monoid d) =>
Monoid (a, b, c, d)
-- Defined in Data.Monoid
instance (Monoid a, Monoid b, Monoid c, Monoid d, Monoid e) =>
Monoid (a, b, c, d, e)
-- Defined in Data.Monoid
instance Monoid Ordering -- Defined in Data.Monoid
instance Monoid (Last a) -- Defined in Data.Monoid#Monoidってのはなんとなく”閉じてる”って感じだな
#単位元も。
#第3回 HIMA は 12/13 19:00-22:00 に決定していいですか？
#12/13というと日曜日？圏論勉強会の後飲んでる頃だ。
#あらら。
#では、12/13の午前中というのはありかしらん。いかがですか？参加予定の方。
#12/13 は僕は大学で自主ゼミです
#ログが残るならあとで読むでもいいけど
#あらら。
#12/12土 の午前中というのはどうかしらん。
#圏論勉強会の12/13も仮決めで確定ではないので変更できるか相談してみます。
#前回 Google Wave のはなしがでてきたけど、本当に Google Wave でやりますか？
#closed になってしまうのが、すこし残念な気がしているのだけれど、付箋機能はおもしろい
#closed にしないためには、事前アナウンスして、Haskell に興味のありそうな、まっとう人を Google Wave に invite しなければならない(のが、ちとめんど
#なので、Google Wave でやるのなら、Google Group にまず「HIMA グループ」をつくるのがベターだとおもいます
#すでに「HIMA人『ばるばる』による集い」なる Google Group がある、興味深い…
##こんにちは! I am a headhunter based in London. I focus on functional programmers for the finance sector, banks, hedge funds, prop trading houses etc. I'm not sure if this is acceptable topic but I just wanted to let this group know I am currently looking for oustanding Haskell programmers to join an established team at a major Investment Bank. The role is based out of Singapore.
I work with many of the major Investment Banks and would be happy to discuss potential openings. Please feel free to email me on jwood@kaizenpartnership.co.uk
James Wood
#HIMA 3 は臨時にchatonを立ててやろうと思っています。
#jameswood: wow
#jameswood: wish you are not spam, please
#nobsun: chaton 了解。それがいいアイデアとおもいます。
#chaton-twitter ボットが ban されないといいな
#chaton-twitterボットはあるほうがいいですか？ そちらはやめておこうかと思ってますが。。。
#やめる⇒やめるべき
#(HIMA3 について)
#やめるておくというは、ブリッジを用意しないという意味です。とくに禁止するわけではないです。
#ぼくのかきかたがわるかった。twitter bridge いらないです：HIMA3
#了解。
#オフトピかもしれませんが: 英語をどういうふうにして練習していますか(いましたか)? 僕は haskell-cafe を読んだり http://www.picturesforsadchildren.com/ を模写したりしています。読むのは比較的なれてきたかなーと自己評価していますが書くのが全然駄目です... #オフトピではないとおもいます。現状、Haskell と GHC の先端の情報は英語でないと手に入らないわけですから
#そして、とうぶんの間 GHC が主にヨーロッパ勢で開発されつづけるからには、英語は Haskell プログラマとして必須とおもいます
#結論：日本でも Haskell 処理系つくろうよ！（ちがう
#で、僕は高校のとき英語が最低クラスでしたが、大学の端末室で寝泊りするようになってからは、ひたすら man と nethack spoiler を読みました
#読むのは辞書片手にひけばいいので、あと英語の文法とイディオムさえ覚えれば、書く、話すのふたつよりは簡単だという印象です
#英語を書けるようになったのは、IRC の英語チャンネルを数ヶ月 ROM ってからなんとかなりました、あと、自分でつくったプログラムのマニュアルを英語だけ準備するとか
#話せるようになったのは、師匠のおかげです。その発音では通じない、だめだめだめの連続。
#一番難しいのは、English native speaker が話すのを、聞き取ることだとおもいます。これは、僕もまだ達成できていません
##Ph.D comics に出てくる単語は、使わないほうがいいと思いますが。。。そういう意味では悪い紹介だったか
#なるほでぃうす、、、#haskell を ROM ってた時期もあったんですが人間 <-> lambdabot のやりとりしか読んでなかったな... Haskell のイディオムはいろいろ覚えたけど
#使わない方がいい言葉っていうのはどうやって知るんですか?
##haskell-beginner のほうがいいと、Shelarcy さんから聞きました。ぼくはその存在を知らなかった
##haskell-beginner そういうのもあるのか
#online English-English dictionary 引けばわかります
#beginners だったかも
#そうか、英英辞典を見ればいいのか
#書くときは、そうだな、まず言いたいことを書いて、"I mean, ..." とか "In other words, ..." と別の言葉で書くと、「あ、こいつ、こいつなりに頑張ってるんだな」と、いった雰囲気が
##相手に伝わります
#抽象的なことを書きたかったら、まず書いて、"For example, ..." と書くとか
##"Well, honestly, I can't say what ..." とか言っても、同情してもらえるかもしれないです
#人間同士ですから、感情を引き出すのがいいと思います
#shelarcy さん、いつもありがとう
#逆の立場に立てば、「日本のみんな、こんにちは？わたし。わかりません？ monad むずかしい」とかで、十分通じますよね
#ほえー...。ikegami さん、そのあたりのこと Blog か何かにまとめたりする予定はありませんか?
#どういたしまして。
#需要は結構あると思うのですが...
#うーん、王道はないとおもうんですよね。結局、根気をどこまでだすかは、人によって違いますので
#それに、かならず炎上する話ですから、英語の習得法は
#確かにそうですね。どこまで英語の能力が必要かは人によって異なります。
#Dan とか「訳されてから読め」とか、すでに言っていて、もうそういう人相手にしたくない
#「まとめてほしいなー」といったのは習得法ではなくて「相手の感情を引き出すイディオム」のほうのことだったんですが、それでも炎上は懸念されますか?
#書き方をうまくすれば、それはいい考えだとおもう
#ブログにするまえに、英語わかる人複数あつめて、まとめたい内容ですね、査読してほしい
###9 steps っていっても、これ、ひとつひとつが重いな…
#ここまでやれば完璧です、たしかに... : 9 steps
#geek 相手の気軽な会話だったら、ここまではいらない
#記憶をたどると、高林哲さんが上手にまとめてらしたのを見たような
##これはでも、個別論でしたね、一般論ではない
#高林さんのやつ、いいですね。このぐらいのスコープだといろいろ書きやすいのかも。
#クリスマスプレゼントとして、書いてみようという気にはなりました
#結城浩さんが協力してくださるとうれしいかも
#「英語圏にいる人に、話しかける勇気と、第一歩」を 7 steps で
#いったん、相手から好印象の返事が返ってくれば、あとはもう、そのひとたち同士でぎくしゃくしながらも、うまくやっていけることを信じる
#ぼーっと期待してます > 池上サンタ
#ああnethack-spoiler私も読んだ。読みたいという強い動機が重要ですかね。
#英語での伝え方興味あります。期待していますに1
#hello
#I apologise if my last message is regarded as spam. I thought you might be interested as because this is a Haskell chat. Sorry about that!
#jameswood: To be honest with you, I misunderstood that you may be spammer. I was too strict!
#jameswood: Please speak about Haskell in English here freely. You are right that here is a Haskell chat.
##このスピードに耐えられれば、中級者
#彼自身は、かなりゆっくり喋っているつもりのはず
#く、くそう、むずい
haskell-ja > Archives > 2009/11/26