- 【Delphi】Embarcaderoオッチャ その30【C++ﾋﾞﾙﾀﾞ】
233 ：デフォルトの名無しさん[]：2015/01/29(木) 19:42:25.64 ID:+AdaLcLW - AppleがPascalを独自に拡張してLisa Pascalを実装（1982）
HejlsbergとWirthがLisa上でObject Pascalを策定する（1985）
AppleがObject Pascalの拡張をLisa Pascalに組み込んで実装（1986）
直後にBorlandがほぼ同様の拡張をMac Turbo Pascalに組み込んで実装(1986)
|
- 【Delphi】Embarcaderoオッチャ その30【C++ﾋﾞﾙﾀﾞ】
234 ：デフォルトの名無しさん[]：2015/01/29(木) 19:49:02.26 ID:+AdaLcLW - Borlandとは無関係にApple（でHejlsberg）がObject Pascalを実装したのは事実。
ほぼ同様の拡張をBorlandが後追いでTurbo Pascalに実装し、これがDelphiへ。
>>230は半分正しい。
AppleはBorlandと無関係に独自拡張し、Borlandがそれに全力で追随しただけ。
LisaでBorlandのTurbo PascalとそのObject Pascal拡張を利用できたのも事実。
|
- 【Delphi】Embarcaderoオッチャ その30【C++ﾋﾞﾙﾀﾞ】
235 ：デフォルトの名無しさん[]：2015/01/29(木) 20:17:40.78 ID:+AdaLcLW - あ、HejlsbergがそもそもTurbo Pascalのオーサーだったことを書き落とした。
他方で、HejlsbergがBorlandに移籍したのはあくまで1989年になってからだ。
Hejlsberg本人の会社だったPolyDataがAppleのPascal実装とBorlandのPascal実装の
両方の背後にいたからこんなことになってるんだな。
|
- 関数型プログラミング言語Haskell Part27＿©2ch.net
337 ：デフォルトの名無しさん[]：2015/01/29(木) 21:28:27.17 ID:+AdaLcLW - >>336
Identity Law : pure id <*> v = v
が満たされないから。お前さんの提案する定義だと
pure id <*> [1,2,3] =1
になっちまうだろ。
|
- 関数型プログラミング言語Haskell Part27＿©2ch.net
338 ：デフォルトの名無しさん[]：2015/01/29(木) 21:37:09.02 ID:+AdaLcLW - あ、書き間違えてる。
pure id <*> [1,2,3] == [1]
になっちまうだろ、だ。
Identity Lawがわかりにくいなら、
そもそもpure f <*> は fmap f と等価なので、
fmap id [1,2,3] == [1,2,3]
である以上、
pure id <*> [1,2,3] == [1,2,3]
でなければならん、と考えてくれ。
|
- 【Delphi】Embarcaderoオッチャ その30【C++ﾋﾞﾙﾀﾞ】
238 ：デフォルトの名無しさん[]：2015/01/29(木) 21:41:39.77 ID:+AdaLcLW - >>236
>無関係、ってどっちも Wirth の Object PASCAL 拡張なんだけど
実は微妙に違う。なので、
http://www.pascal-central.com/ppl/chapter5.html
の表でもWirthのOP拡張とBorlandのOP拡張が区別されてる。
|
- 関数型プログラミング言語Haskell Part27＿©2ch.net
341 ：デフォルトの名無しさん[]：2015/01/29(木) 21:51:44.46 ID:+AdaLcLW - >>340
ApplicativeがFunctorである以上、ほかにどうしろと？
つうか、Applicative Lawsを満たすようにApplicativeを実装しようね、
つうのはMonadはMonad Lawsを満たすように実装しようね、
というのと同じ性質のお約束なので、破りたきゃ破れるが、
Functorとしての振る舞いと整合性が取れないそんな糞みたいな型を
作られても使いようがない、というだけのこと。
Applicative Lawsが成立するところにApplicativeそのものの有用性があるんだからな。
|
- 関数型プログラミング言語Haskell Part27＿©2ch.net
343 ：デフォルトの名無しさん[]：2015/01/29(木) 22:22:06.70 ID:+AdaLcLW - >>342
気に入る答えとは思えんが、Monadとの整合性から出てくる。
fmap を入れ子で適用した結果の
[[f 1, f 2, f 3], [g 1, g 2, g 3], [h 1, h 2, h 3] ]
に対してjoin（これはリストモナドではconcatのことだ）を適用した
結果と同じにならなければならんので。
|
- 関数型プログラミング言語Haskell Part27＿©2ch.net
344 ：デフォルトの名無しさん[]：2015/01/29(木) 22:33:00.11 ID:+AdaLcLW - あー、というか、お前さんの提案もpureを工夫すればApplicativeには一応できるんだ。
pure a = repeat a と定義すれば、お前さんの提案の<*>でも
pure f <*>と fmap fとを等価にできる。
ただ、それはMonadにするのが困難なだけ。
|
- 関数型プログラミング言語Haskell Part27＿©2ch.net
347 ：デフォルトの名無しさん[]：2015/01/29(木) 22:43:16.27 ID:+AdaLcLW - >>342
というわけで、Preludeでのリストモナドと整合的な
Applicativeとしての振る舞いは[f 1, f 2, f 3, g 1, g 2,...]なやつの方だ。
お前さんの提案しているzip風の振る舞いは工夫すればApplicativeにはできる。
それをMonadにしようとすると無限リストに関するなんかのMonadにはできるかもしれんが（確信はない）、
Preludeにあるようなリストモナドとは別の挙動をするMonadになるはず。
なので、お前さんのzip風のやつは標準的なリストモナドに対応するApplicativeの振る舞いではないのは確か。
だがしかし、うむ、お前さんの直観は意外に正しかった気がする。
|