12/05/06 19:43:30.18
言語はなんでもいいので具体例をプリーズ。
676:デフォルトの名無しさん
12/05/06 20:31:27.12
pushとかpullなんて名前は知らないけどこんな感じなんじゃね？
サンプルはJava。上がきっとpushで下がpull
URLﾘﾝｸ(www.akirakoyasu.net)
List<B> blist = new ArrayList<B>(alist.size());
for (A a : alist) {
blist.add(new B(a));
}
Guavaを使う場合は次のように書きます。
List<B> blist = Lists.transform(alist, new Function<A, B>(){
@Override
public B apply(A a) {
return new B(a);
}
});
677:デフォルトの名無しさん
12/05/06 20:34:08.65
いまさらだけど、>>671の
pullとpushの言葉の使い方逆じゃね？
678:デフォルトの名無しさん
12/05/06 20:43:49.33
>>677
放置したほうがいい人だと思うがどうか?
"Push-Pull Functional Reactive Programming"風に、
pull: demand driven
push: data driven
ってことでいいかと。
679:デフォルトの名無しさん
12/05/06 20:45:09.00
言葉のままに捉えればよいんじゃない？
pullは引く。
result = hoge( piyo( huga() ) );
pushは押す。
huga( result );
piyo( result );
hoge( result );
680:デフォルトの名無しさん
12/05/06 20:59:16.39
>>678
遅延評価はdemand drivenだから、671は合ってるだろ
681:デフォルトの名無しさん
12/05/06 21:05:42.54
一箇所だけ取り上げてそんな事言われても困りますよ。
682:デフォルトの名無しさん
12/05/06 21:16:14.00
>>677は0箇所ですよ
0箇所よりも1箇所の方がいいんじゃないか
683:デフォルトの名無しさん
12/05/06 21:18:45.89
pullとかpushって>>671が作った言葉だろ？
手続きタイプと、コールバックタイプとかでいいんじゃね？
684:デフォルトの名無しさん
12/05/06 21:23:25.41
なんだ、オレオレ用語かよ
685:デフォルトの名無しさん
12/05/06 21:44:18.93
>>682
まあそりゃそうだねw
push/pullは、上に上げたようにFRPでも取り上げられてるし、
他にはWebアプリフレームワークとかXML系APIとか、
いろいろなところでAPIデザインの選択肢として語られてる。
大げさに騒ぐような概念じゃないけど。
686:デフォルトの名無しさん
12/05/06 21:51:58.49
URLﾘﾝｸ(ja.wikipedia.org)繊維強化プラスチック
繊維強化プラスチック（せんいきょうかプラスチック、Fiber Reinforced Plastics、FRP）は、
ガラス繊維などの繊維をプラスチックの中に入れて強度を向上させた複合材料のこと。
単に FRP と書いて、ガラス繊維強化プラスチックを指すことも多いが、
ガラス繊維であることを明示したい場合は GFRP または
GRP (Glass fiber reinforced plastics, Glass-reinforced plastics) と書かれる。
687:デフォルトの名無しさん
12/05/06 22:02:41.17
URL貼れってか
URLﾘﾝｸ(conal.net)
688:デフォルトの名無しさん
12/05/06 22:14:04.87
でも、FRP自体は明らかに関係ない概念だよね？
pullとpushの概念引っ張ってくるためだとしても。
それに、Getter/SetterをPull or Pushに分類しようとするのは
独自解釈が過ぎるでしょ
689:デフォルトの名無しさん
12/05/06 22:15:07.62
なんだF#用語か。URLﾘﾝｸ(pro.art55.jp)
690:デフォルトの名無しさん
12/05/06 22:19:52.64
>>671 はオレオレ定義すぎ。
>>676 の下がpush。上はシラネ。
だろ。普通にpull/pushを考えるなら。
691:デフォルトの名無しさん
12/05/06 22:23:38.07
>>688
> でも、FRP自体は明らかに関係ない概念だよね？
ちょっと難しい例でごめんね。
692:デフォルトの名無しさん
12/05/06 22:28:26.04
>>691
難しい例もなにも、普通にFRP関係ない例しかでてないぞ。
関係あるんなら関係ある例になるコードをださんと。
693:デフォルトの名無しさん
12/05/06 23:30:20.47
>>688
つまり、まず質問をして、独自ではない回答が出るまで待っていればいいんですかね
関数型言語がgetterの使用を制限しない理由は何でしょうか
694:デフォルトの名無しさん
12/05/07 06:32:00.39
関数型ってパターンマッチとか、再帰とか、モナドとか、そんな程度のものなの？
もっとすごい秘密兵器があるんじゃないかなぁと期待しているんだけど、イマイチ見えてきません。
型クラスのメリットは、クラスを使った不完全な抽象データ型オブジェクト指向より
定式化され優れているとわかるとしても、両者は必ずしも背反するものではないですよね？
参照透明性にしても抽象度やモジュラリティは上げられる反面、直感的でない回りくどい処理や
そのための記述を強いられたりする局面も少なからずあるし、そうしたやり難さと引き換えに
関数型でゴリ押しするメリットってどこら辺にあるのでしょうか？
695:デフォルトの名無しさん
12/05/07 09:50:54.31
高階プログラミングではないかと昨夜から今朝にかけて思った。
いわゆるメタプログラミングや自己反映計算を実現する方法として、
自己書き換え→テンプレやマクロ→...というように発展してきて、
関数合成とかでプログラミングをするようになった、というか。
696:デフォルトの名無しさん
12/05/07 10:34:09.89
関数合成はメタプログラミングに入りますか？
697:デフォルトの名無しさん
12/05/07 11:00:16.79
>>694
代入を制限する関数型が、get/setの両方を制限するオブジェクト指向よりも回りくどい
と言われるのは何故ですか？
698:デフォルトの名無しさん
12/05/07 11:08:18.79
Smalltalkが普及しなかったようにHaskellは普及しない
699:デフォルトの名無しさん
12/05/07 11:19:44.93
「get/setの両方を制限」のところがよくわからないので具体的にお願いします。
あとなんでその「get/setの両方を制限」が関数型の再代入制限に対応すると
思われたのでしょうか？
700:デフォルトの名無しさん
12/05/07 11:50:13.94
こうかいかんすう
701:デフォルトの名無しさん
12/05/07 12:01:35.13
高階関数って関数オブジェクトがファーストクラスなら
どうということなく使えますよね。それでもやっぱり
関数型の秘密兵器なんでしょうか？
カリー化が自動だったり関数合成演算子が組み込みなのは嬉しいけど、
OOPLであっても関数オブジェクトがそうであればいいだけって気もしますし、
ポイントフリースタイルで書こうとしてパズルみたいになるのも
何だか本末転倒な感も否めません。
702:デフォルトの名無しさん
12/05/07 12:15:37.81
OOPLでもできるって
頑固なOOPLのスタイルを変えさせることができるなら凄い兵器だ
703:デフォルトの名無しさん
12/05/07 12:35:48.84
頑固なOOPLのスタイルってどんなの？
704:デフォルトの名無しさん
12/05/07 12:54:07.33
>>701
別に秘密兵器でも何でもなく、関数型の思想のうち
手続き型でも適用出来そうな部分は既に受け入れられてるってことさ
705:デフォルトの名無しさん
12/05/07 15:35:46.86
>>694
「ゴリ押しする」ってのは、あなたの心の問題じゃないの？
706:デフォルトの名無しさん
12/05/07 15:47:21.06
関数型の主力は副作用が無いこと
手続き型の主力は副作用が有ること
OOPは副作用の局所化を目指すもの
異論は認める
707:デフォルトの名無しさん
12/05/07 17:50:02.95
副作用があるのはsetterだけ
getterの局所化には副作用以外の目的があるだろう
708:デフォルトの名無しさん
12/05/07 18:08:27.94
そうかしら？
709:デフォルトの名無しさん
12/05/07 18:09:54.21
>>707
一体いつからgetterに副作用が無いと錯覚していた？
getで内部キャッシュを生成,保持しても良く
副作用は外から分からずとも、仕様(期待)通り動作すればいい
710:デフォルトの名無しさん
12/05/07 18:47:24.86
しかし実際にはオブジェクトが他のオブジェクトの参照を握ってたりして、
一回のメソッド呼び出しがどんどんたらい回しされてって。
特にオブジェクト指向では多態のためにメソッドのシグネチャを固定化するから、
オブジェクトが他のオブジェクトの参照を握る傾向は強い。
つまり、オブジェクト指向で副作用の局所化はされないし、元々狙っても無い。
オブジェクト指向はオブジェクトに関するコードや変数の依存関係を纏めたってだけ。
これを手続き型で実行すれば、処理がオブジェクトを跨いであちこちに飛び回る。
このとき、副作用は局所化されない。
副作用の局所化するためには、処理がオブジェクトを跨がないように
する必要がある。
しかし、それはオブジェクト指向とは関係無く、手続き型一般における、設計のテクニックだ。
711:デフォルトの名無しさん
12/05/07 19:01:14.42
・シグネチャを固定化 → 他のオブジェクトの参照を握る
・副作用の局所化するため → 跨がないように
この辺前後の関連がよく分からないので詳しくお願いします
712:デフォルトの名無しさん
12/05/07 19:09:28.48
どう言えばよいんだろうね。
オブジェクト指向はオブジェクト単位で色々纏めるが、これらは変数やコードといった、
静的な要素を分類したに過ぎない。
言い換えれば、「ソースコード」をオブジェクト単位で分類したに過ぎない。
一方で副作用はソースコード上には現れない。
実行時に「処理」にくっ付いて現れる。
だから、副作用を局所化するためには、処理の流れそのものを
局所化する必要があって、これは手続き型一般の設計の問題で、
OOだからどうこうという話ではない。
OOはあくまでソースコードをオブジェクト単位で局所化するだけで、
それ以上は助けてくれない。
713:デフォルトの名無しさん
12/05/07 19:26:38.69
>>709
それはgetterを作って良いし副作用が有って良いという意見だな
そういう自由な考え方が定着すれば、OOに反対する人はいなくなると思う
714:デフォルトの名無しさん
12/05/07 19:29:05.25
そんでついでに言うと、
オブジェクト指向は処理の流れに関して凄く無頓着な一面がある。
というのも、仮想関数だ多態だといってな。
そんで、むしろソースコードみたいな静的なものは怖くねーよ、
こんなの綺麗に分類するより、
処理の流れとその副作用の方がよほど怖えーよ、そっち整理しろよ、
って考え方もあって、OOは使いどころが難しく、2chなんかで議論もこじれる。
だから皆だんだん嫌になってきて、
処理の流れそのものを気にしなくて良い関数型に白羽の矢が立ったってわけ。
715:デフォルトの名無しさん
12/05/07 19:48:12.05
俺にとっての副作用を局所化というのは
「この変数を触るのはこの処理だけ」といった
スコープを小さくしたり責任範囲の壁を作ったりすることなんだけど
>>712にとっての副作用の局所化というのは
何かのメソッド呼んだときに変化するN個のオブジェクトのN個の変数とか
その辺りに言及してるのかな？
メソッドの中で自身(A)が持ってる別のオブジェクト(B)のメソッドを呼んだとして
そこから先でファイルアクセスが発生しようと
それはBの範疇なのでAの中での局所化には関係無い
というスタンスかな、俺はね
>処理の流れに関して凄く無頓着
そうかもね
他のオブジェクトは外面(インターフェイスと仕様)しか見ないので
処理の内容は「あとは任せた」って感じだし
716:デフォルトの名無しさん
12/05/07 20:17:37.37
>>715
これは物凄く悪い例なんだけど、
AがBのメソッドを呼び出して、
そのメソッドの中でBがAのメソッドを呼び出したら、
カプセル化は壊れるんだよね。
そんな設計はするな、と言われそうだが、
これが結構良くあるんよ。
親が子の参照を持ってて、子も親への参照を持ってるとか。
717:デフォルトの名無しさん
12/05/07 20:22:02.86
循環参照は注意だが、カプセル化は別に崩れてなくね？
718:デフォルトの名無しさん
12/05/07 20:22:28.51
カプセル化は言葉が悪かった。
整合性だね。
719:デフォルトの名無しさん
12/05/07 20:40:40.96
AがcallするならBはreturnすればいいのに、なぜかBもcallしようとするんだな
なぜreturnを避ける設計をしてしまうのか
720:デフォルトの名無しさん
12/05/07 20:46:15.19
>719 てめぇ、CPSさんDisってんのか?
721:デフォルトの名無しさん
12/05/07 20:49:59.90
>>716
>これが結構良くあるんよ。
わかる・・・
イベントハンドラとかのインターフェイスの実体として子に自身を渡すとか
木構造で高速化のためAが別のA(親)を持つとかは許容出来るけど
一つずつ順にコンパイル出来ないような定義レベルでの循環参照は俺も嫌い
722:デフォルトの名無しさん
12/05/07 21:04:21.69
>>720
末尾呼出しなら問題なさそうだ
問題は、Aのメソッドの途中でAが参照されること
723:デフォルトの名無しさん
12/05/07 21:18:02.26
>>718
言葉が悪いんじゃない。関係ないんだよ。
724:デフォルトの名無しさん
12/05/07 21:29:27.23
>>722
ACTORさん(以下略
725:デフォルトの名無しさん
12/05/11 20:23:27.60
それぞれのオブジェクトがメッセージを投げ合い、
その結果でたらめな順序で副作用が起こっても問題が無い
仮に問題あっても例外投げときゃ無問題
そういうイイカゲンなシステム開発にオブジェクト指向は最適
726:デフォルトの名無しさん
12/05/11 21:46:23.18
さすがにそこまでいい加減なシステムは品質を確保できないだろ。バカにし過ぎ。
「そのように組むことができる」ことと「実際にそうする」は別問題。
Haskellでも副作用が発生する処理と、そうでない処理をごちゃ混ぜにすることは可能は可能だし。
727:デフォルトの名無しさん
12/05/12 18:57:50.97
ここの人らなら詳しそうだから教えてくれ。
0 :: Integer
0 = 0
みたいな感じで、数値を関数化できる言語ってないの？
0関数にラムダ与えたら、ラムダの実行を無視して、
0以外の数値関数にラムダ与えたらラムダを実行するようにしたい
728:デフォルトの名無しさん
12/05/12 19:03:59.81
は？
関数なら 'a -> 'b みたいな型を持ってるはずだけど。
Integer という型は整数の型であって、関数じゃないよ。
729:デフォルトの名無しさん
12/05/12 19:09:46.34
別にそこの式は、数値を関数化したいって例であって
関数を返すとかとは関係ないよ
730:デフォルトの名無しさん
12/05/12 19:21:16.56
「数値を関数化」ってのが、たとえば「文字列を虚数化」みたいに意味不明。
むしろ、
> 0関数にラムダ与えたら、ラムダの実行を無視して、
> 0以外の数値関数にラムダ与えたらラムダを実行するようにしたい
こっちをソースコードで表現できたら、少しはなんとかなるかもしれない。
731:デフォルトの名無しさん
12/05/12 19:41:40.45
あ゛？チャーチ数ディスってんのかメーン
732:デフォルトの名無しさん
12/05/12 23:05:55.96
>>727
「0」というシンボルと、何らかの関数を結び付けたいということ？
関数型ならそもそも、既に何かに結び付けられてるシンボルに
別の値を結び付けるのは再代入そのものだろうし
手続き型関数型問わず、特定リテラルの意味だけを変更するのはちとマズくないかな
733:デフォルトの名無しさん
12/05/12 23:10:21.88
common lispに変数としての値と関数としての値を区別するということなのか
734:デフォルトの名無しさん
12/05/12 23:11:42.30
ごめん、脱字した。
common lisp（のよう）に変数としての値と関数としての値を区別するということなのか
735:デフォルトの名無しさん
12/05/13 00:06:48.19
>>732
Smalltalkなら実現してたべ
value := 0.
value message.
こんな感じで、数値にメッセージを送ると、
数値に紐付いたメソッドを呼ぶ事ができた。
1にメッセージを送れば、1のメソッド。
2にメッセージを送れば、2のメソッドみたいにね。
736:デフォルトの名無しさん
12/05/13 01:07:22.66
本のお題がどういうものだが今一歩ピンとこないが、
チャーチ数を計算する型なしラムダ式処理系なら結構転がってる。
数値や真理値は短形表示できるが。
737:デフォルトの名無しさん
12/05/13 02:06:34.64
>>735
何が言いたいのか分からん
value message と function value は語順が違うだけじゃね？
738:デフォルトの名無しさん
12/05/13 02:12:38.75
>>737
Smalltalkが解らないとなるとlispなら解るかい
(0 arg) 0関数を実行
(1 arg) 1関数を実行
別バージョン
( (lambda ( x arg ) ( x arg ) ) 0 arg ) 0関数を実行
( (lambda ( x arg ) ( x arg ) ) 1 arg ) 1関数を実行
739:デフォルトの名無しさん
12/05/13 02:36:28.73
>>738
なるほど分かった
0や1といったリテラルに関数を割り当てたいってことだね
どっちかというと関数型 vs. オブジェクト指向じゃなくて
静的型 vs. 動的型になりそうな気配
740:デフォルトの名無しさん
12/05/13 02:40:45.66
ところで>>727のいう「ラムダ」の引数は何？
それは何時渡すの？
741:デフォルトの名無しさん
12/05/13 02:44:08.62
>>740
値が関数だって事の説明用だから引数はなんでもいいんですが
742:デフォルトの名無しさん
12/05/13 02:49:18.06
>>741
意味論的には関数型言語の値は「ゼロ引数関数」という関数
743:デフォルトの名無しさん
12/05/13 08:04:27.03
いずれにしろ 0 :: Integer では、関数になってないから
744:デフォルトの名無しさん
12/05/13 10:20:35.18
OO信者の俺ですら数値クラスにメソッド追加するような
コードは勘弁して頂きたい
オープンクラスではしゃぐのは初心者時代で終わらせてほしい
745:デフォルトの名無しさん
12/05/13 11:09:32.18
>>735>>738
シングルディスパッチでは第一引数を特別扱いしてるだけで
x.foo y z と foo x y z に本質的な差は無い
シングルディスパッチ脳には理解出来ないかもしれんけど
746:デフォルトの名無しさん
12/05/13 11:16:35.94
難しい問題だね。
func( o1, o2 )
こういった関数は後からいくらでも追加できるけど、
o1.func( o2 )
との本質的な違いはスコープだけだからな。
多態出来る出来ないの違いは有るけど、それは言語上の制約ってだけだからね。
クラスの外のスコープにいくらでも関数が定義できるのに、
クラスの中のスコープにメソッドを追加することは出来ません、
って制約に一体どれほどの意味があるかって言われると、ねぇ。
特に動的言語では。
747:デフォルトの名無しさん
12/05/13 11:37:40.06
あんたの恣意的な分類で「本質」とか「言語上の制約ってだけ」とか言われても
わかりませんわ。
748:デフォルトの名無しさん
12/05/13 12:25:07.97
別に恣意的ではないと思うけど。
本来、どこのスコープに何を追加しようが勝手なものなんじゃないの？
静的言語では実行効率の理由で制限がかかってくるのも分かるけどさ。
749:デフォルトの名無しさん
12/05/13 12:32:53.64
Haskellでやっつけ
お題の真意が掴めてないので、たぶん条件を満たしてない
URLﾘﾝｸ(ideone.com)
750:デフォルトの名無しさん
12/05/13 12:39:04.98
0がどうのこうのの話は、まだ続いてたの？
0と1は同じ型だろうから、同じ関数にディスパッチされるのが当たり前だしさ。
751:デフォルトの名無しさん
12/05/13 15:59:42.13
>>742
そういう形式化もあるという程度の話。
752:デフォルトの名無しさん
12/05/13 18:30:14.35
このスレには時代遅れのSmalltalkを使ってる
奇特な人が居るから質問するんだけど、
あのIDEモドキを立ち上げずにプログラム実行する方法無いの？
それと動的型付けで実行が遅いから、せめてボトルネックだけでも
C/C++で書いて実行できないとトイプログラムでしか
使いモノにならないと思うけど、簡単にC/C++のライブラリとリンクできるの？
753:デフォルトの名無しさん
12/05/13 19:25:11.00
たとえばVisualWorksやPharoといったSmalltalk処理系には
headlessといって、サーバーなどの用途に使う目的でIDE抜きで起動したり、
その際に指定した.stファイルを読み込んだり実行できる機能があります。
またGNU Smalltalkのように、標準入出力から使うことに特化して開発された
特殊な処理系もあるのでこういう処理系を最初から選ぶのもよいでしょう。
ただIDE抜きの使い方は他の言語と同様の使い方ができるというメリットがあると反面、
Smalltalkの独自の機能や優位性をかなりスポイルする使い方ということにもなるので
他の言語が選択できる状況であるならば、よほどSmalltalkを使い慣れた人でもなければ
そこまでしてSmalltalkを使うメリットはあまりないような気もします。
GNU SmalltalkやAmber Smalltalkといった特殊なSmalltalk処理系を使っての
Smalltalk入門があまり推奨されないのも同様の理由です。
SmalltalkからC/C++で書いた関数をコールするにはいくつか方法がありますが、
たとえば、商用のSmalltalkであるVisualWorksにはDLL and C Connectという方法が使えます。
URLﾘﾝｸ(www.cincomsmalltalk.com)
PharoやSqueakではVMプラグインを書いてバイトコードを拡張したり、FFIが使えます。
URLﾘﾝｸ(wiki.squeak.org)
URLﾘﾝｸ(wiki.squeak.org)
754:デフォルトの名無しさん
12/05/13 19:48:37.96
727です。
なぜかOOの話がでてますが関数型の話でOOは関係ありません。
OOPLでも同じ表現ができるというだけです。
で、本題ですが、最終的な目的としては下のようなラムダ演算ができる言語は
存在しないのかという話です。
( 0 (lambda () "true" ) ) 0関数はlambdaを評価せず、nilを返す
( 1 (lambda () "true" ) ) 1関数はlambdaを評価し"true"を返す
( 2 (lambda () "true" ) ) 1関数はlambdaを評価し"true"を返す
( (- 1 1 ) (lambda () "true" ) ) 0関数を評価する事になるのでlambda
755:727
12/05/13 19:54:33.33
間違えて途中で書き込んでしまいました。すみません。
( 0 (lambda () "true" ) ) 0関数はlambdaを評価せず、nilを返す
( 1 (lambda () "true" ) ) 1関数はlambdaを評価し"true"を返す
( 2 (lambda () "true" ) ) 1関数はlambdaを評価し"true"を返す
( (- 1 1 ) (lambda () "true" ) ) 0関数を評価する事になるのでlambdaを評価しない
( (+ 1 1 ) (lambda () "true" ) ) 2関数を評価する事になるのでlambdaを評価しない
数値を関数化できないかというのは、数値を評価したとき、このような
振る舞いをするように数値を定義できなる言語は無いかという事でした。
尤も、言語レベルで最初から数値をチャーチ数と同じように評価できるなら
新たに関数として数値を再定義できる必要は無いんですが。
756:デフォルトの名無しさん
12/05/13 20:00:39.51
>>752
時代遅れってアホか、通信・製造・金融・保険・政府。
お前がしらんだけで第一線で新規開発されとるわ。
国内企業なら、東洋ビジネスエンジニアリングとかが導入してんだぞ。
757:デフォルトの名無しさん
12/05/13 20:17:42.17
F#でやってみた。
拡張メソッド定義してるだけなので、実質「Execute(0, fun () -> printnf "zero")」と同じ
type System.Int32 with
member x.Execute func = match x with 0 -> () | n -> func()
> (0).Execute (fun () -> printfn "zero");;
val it : unit = ()
> (1).Execute (fun () -> printfn "one");;
one
val it : unit = ()
> (1 - 1).Execute (fun () -> printfn "zero");;
val it : unit = ()
758:デフォルトの名無しさん
12/05/13 20:19:29.56
>>755
Integer と () -> Bool は違う型なので、
同じ数値（関数）の型が文脈に応じて変化する言語でなければ不可能。
759:727
12/05/13 20:19:44.31
むちゃくちゃになっていたので直します。何度もすいません。
( 0 (lambda () "true" ) ) 0関数はlambdaを評価せず、nilを返す
( 1 (lambda () "true" ) ) 1関数はlambdaを評価し"true"を返す
( 2 (lambda () "true" ) ) 2関数はlambdaを評価し"true"を返す
( (- 1 1 ) (lambda () "true" ) ) 0関数を評価する事になるのでlambdaを評価しない
( (+ 1 1 ) (lambda () "true" ) ) 2関数を評価する事になるのでlambdaを評価する
760:デフォルトの名無しさん
12/05/13 20:20:46.22
>>758
できる言語はあるかと聞いているのですが？
あとboolは関係ないですよね
761:デフォルトの名無しさん
12/05/13 20:24:09.03
>>760
じゃあ Integer と (() -> a) -> a
それはともかく、関数型とか全然関係なくって
まともな静的型なら無理って言ってるんだけど、
動的型しか使った事無い馬鹿には分からないかな？
762:デフォルトの名無しさん
12/05/13 20:25:17.06
>>761
だから、できない言語の事は聞いてなくて、出来る言語はあるかと聞いてるんですけど。
763:デフォルトの名無しさん
12/05/13 20:29:16.10
>>762
スレ違いだし問題としても糞詰まらんから
どっか行けって言ってんだけど？
764:デフォルトの名無しさん
12/05/13 20:29:54.03
何か値を返さなきゃならないみたいなので、>>757を修正
nilと値じゃなくてoption型使ってるけど
type System.Int32 with
member x.Execute func = match x with 0 -> None | n -> func() |> Some
> (0).Execute (fun () -> "zero");;
val it : string option = None
> (1).Execute (fun () -> "one");;
val it : string option = Some "one"
> (1 - 1).Execute (fun () -> 1 - 1);;
val it : int option = None
765:デフォルトの名無しさん
12/05/13 20:32:20.89
>>763
NGにしたいんでトリでも付けてもらえます？
スレ違い以前に話が通じないので
766:デフォルトの名無しさん
12/05/13 20:42:57.75
>>763
まず日本語の通じないお前がどっか行けよ
767:デフォルトの名無しさん
12/05/13 20:44:48.51
>>764
オブジェクトで出来てもあんまり嬉しくないんですが・・・
768:デフォルトの名無しさん
12/05/13 20:46:00.83
>>765>>766
型付けの問題だって理解できない自分の低能さを
日本語の問題にすり替えるなよw
769:デフォルトの名無しさん
12/05/13 20:52:46.02
>>761
「コンセントの付いている車はありますか？」
「軽トラなら無理です」
お前が言ってるのはこういう事だという自覚は有るのか？
普通は「あります」「ありません」この2択だろ
頭おかしいな
770:デフォルトの名無しさん
12/05/13 20:53:58.75
>>767
Int32はラッパークラスとかではなく、プリミティブかつオブジェクトなんだけど。
まぁそれでもダメというならどうしようもない。
771:デフォルトの名無しさん
12/05/13 20:55:35.08
>>764 のような Execute 的な関数を使うのってダメじゃね？
これアリなら難しくも何ともないじゃん
(|.) 0 _ = Nothing
(|.) x f = Just $ f ()
main = do
print $ 0 |. (\_ -> "zero")
print $ 1 |. (\_ -> "one")
print $ (1 - 1) |. (\_ -> "zero")
print $ (1 + 1) |. (\_ -> "two")
772:デフォルトの名無しさん
12/05/13 20:57:08.31
>>770
すいません。
関数と互換性をもってて欲しいんですよ。
773:デフォルトの名無しさん
12/05/13 21:06:51.99
>>771 >>772
てっきり拡張メソッド的なものを要求してるのかと思ってた。
Scalaなら暗黙型変換あるからできそうな気がする。
774:デフォルトの名無しさん
12/05/13 21:08:02.77
>>773
なるほど。Scalaですか、調べてみます。
775:デフォルトの名無しさん
12/05/13 22:46:41.69
で、Scalaなら出来たの？
776:デフォルトの名無しさん
12/05/14 00:37:38.04
マイナー言語使い共が
可読性皆無のコード書く御題で
型付けの弱さを競うスレはここですか？
時代に逆行してて笑えるwww
777:デフォルトの名無しさん
12/05/14 01:46:05.41
誰だって0と1は同じ型だと考えるのに、違った振る舞いをさせたいってのは、
何か前提がおかしいんだろうね。
元々何がしたかったのか聞ければよいんだけど、
彼にそういった振る舞いが出来るとも思えないしなぁ。
778:デフォルトの名無しさん
12/05/14 07:07:11.76
うーん。一番良く分からんのは、>>767を読むと出題者は>>764を見て
オブジェクトとしてなら「出来ている」認定してるっぽい処だな。
779:デフォルトの名無しさん
12/05/14 07:40:52.01
出題者がOOP厨だからオブジェクトには甘いだけだろ
別に不思議でもなんでもない
もちろん出題者は底なしのアホだけど