-generic- 総称的プログラミング -programming-

このエントリーをはてなブックマークに追加
1デフォルトの名無しさん
erasureなんてうんこ、とか。
ひとりでできるもん!
3デフォルトの名無しさん:04/03/21 00:14
ジェネティック・プログラミングぅ〜?
遺伝アルゴリズムか。北野武ウザすぎ
4デフォルトの名無しさん:04/03/21 00:18
>3 まずはアルファベットを読めるようになろう
>3 漢字もな
template
7デフォルトの名無しさん:04/03/21 01:55
>>3
なぜにビート。宏明だろ。
>>3 はかなりのアホだな。
このスレタイのセンスのなさ
>>3 << >>3
1110:04/03/21 15:01
間違った
>>1 ネタ振りすらろくにできねぇ癖に、スレ立てすんなよ

■■■■■終了■■■■■
勿体ないから関数型系の言語のGenericFunctionの実装についてうだうだ騙ってみるスレにしちゃうとか?(w
では、まず >>13 さん、どうぞ。
C++の独壇場?
16デフォルトの名無しさん:04/04/03 21:20
関数型系の言語のGenericFunctionって、CLOSの総称関数とはどういう関係?
CLOSの総称関数とOOのgenericsって、どういう関係?
17デフォルトの名無しさん:04/04/03 23:14
同じことじゃないの?
CLOSの総称関数って英語では generic function だよね。

ここでいう generics って、どっちかというと ML の parametric polymorphism に
近いんじゃないの? で、MLを使っている側からいうと何が新しいんだかよくわからな
いのだが。
18デフォルトの名無しさん:04/04/04 15:51
Java Genericsはいい感じだね
さて、俺も総称するかな。
> で、MLを使っている側からいうと何が新しいんだかよくわからないのだが。

ようやく世の中が追いついてきたということ。
次は型推論だ!

21デフォルトの名無しさん:04/04/04 20:03
MLとHaskellはどっちが強いのか教えてください
22デフォルトの名無しさん:04/04/06 01:43
>>17
そうなん?
関数型言語はよく知らないけど、Genericsっていうと、
ひとつの処理実装で、型を (゚ε゚)キニシナイ!!っていう感じだけど、
CLOSの総称関数は、引数型組み合わせごとに処理実装をシコシコ用意してやる、
って感じで、全然方向が逆のようなイメージだけど。
23デフォルトの名無しさん:04/04/06 03:31
片推論ってCでもやってるじゃん。
24デフォルトの名無しさん:04/04/07 02:37
>>17
最近のトピックとしてJavaに導入というだけで、
Generics自体が別に新しいとは誰も思ってないでしょ。
それよか、大先輩(なのか知らんけど)のMLだとGenericsはどんな感じなの?
ついでに関数型言語の勝たす異論てどのぐらいすごいの?
>>24
> ついでに関数型言語の勝たす異論てどのぐらいすごいの?

関数を定義する時に型を宣言しなくてよく、自動的に、
そのように定義できる(最も一般的な)型が与えられる。
もちろん矛盾が存在すれば検出される。
26デフォルトの名無しさん:04/04/07 13:14
>>25
それってそんなにうれしいの?
それに、意図してた型と他の型になっちゃうかもしれんじゃん。
しかし、勝手に一般的な型が与えられるってのは、Genericsっぽいな。
27デフォルトの名無しさん:04/04/07 13:31
型パラメータほしいっす。

例えば、比較関数で  public abstract int compare(<typeA> x, <typeA> y) ;
例えば、加算関数で public abstract <typeα> plus(<typeα> x, <typeα> y);

みたいな感じで、引数x と 引数y と、あと戻り値が、同じ型である事を宣言できれば。。。
何でもObjectで宣言して実装でキャスト、みたいなコテコテのコードを、
自然な感じのPolyMorphismとして扱えるやん。。。

で、Java Genericの機能はどのヘンまで北の?
JSRで議論が始まった頃は注目してたけど、
最近はJSRやJDK1.5仕様書、どころか厨房雑誌(JavaWorld)すら隅々まで読む暇もなくて、
よくわかんない。
28デフォルトの名無しさん:04/04/07 13:56
> 例えば、比較関数で  public abstract int compare(<typeA> x, <typeA> y) ;
> 例えば、加算関数で public abstract <typeα> plus(<typeα> x, <typeα> y);
なぜそれが出来ないと?
つうか、型パラメータって意味間違ってね?
2925:04/04/07 14:48
>>26
> それってそんなにうれしいの?
とてもうれしい。型宣言がいらないからね。
細かい関数を(関数の中でも)沢山つくる関数型言語では、
いちいち型宣言するのは面倒すぎる。

> それに、意図してた型と他の型になっちゃうかもしれんじゃん。
自分で明示的に宣言すればいい。

> しかし、勝手に一般的な型が与えられるってのは、Genericsっぽいな。

# Haskell で、add x y = x + y
# と定義すると、 add :: Num a => a -> a -> a という型があたえられる。
# "Num a => "というのは、+オペレータを持つtype class Num に 型aが
# 属している、という意味。type classはMLにはない。
# add :: Int -> Int -> Int などとつけくわえれば適用される型を制限できる。
>>27-28
それは型パラメータじゃなくて、type classではないかと。

型パラメータというのは、
data List a = Cons a (List a) | Empty
というときのaのこと。
Cons True (Cons False Empty) :: List Bool
Cons 1 (Cons 2 Empty) :: List Int
などのように任意の型毎のリストがつくれるようになる。

head (Cons a _) = a
と定義すれば、これは型推論により、List a -> a という型が与えられ、
 List Bool にも List Int にも作用できるものになる。
31:04/04/07 15:17
それはHaskellでの「型パラメータ」なのでは?
Genericsでの「型パラメータ」は、hoge<T>の<T>とか自体では?
。。。あ、同じか?
なるほど、これが関数型でのGenericsか?(ホントか?)
あ、いや、これはただのhoge<T>ではなくhoge<T extends U>が相当するのではないか?
だって、MLにはないんだよね?
32:04/04/07 15:39
あ、いや継承関係なんてないからhoge<T>でいいのか。失礼。
しかし、MLにないっちゅうのはどういう事よ?
>>31
>>17  
> ここでいう generics って、どっちかというと ML の parametric polymorphism に
の続きかと思っていた。

C++のテンプレートはadhoc overloadingがあるから、
テンプレートになるべき型を推論することはできないね。
パラメータとしての型が指定されてから、コンパイルできたりできなかったり
する。duck typingになってるってことなのかな。
34:04/04/07 15:55
ああ、>>27でみんな同じ型ってところに着目したのね。
たぶん彼はそういう意図はないと思う。

というかそろそろ厨には訳若めでふ。この辺から勉強してきまふ。
http://www.tabee.com/private/lab/types/type22/node5.html
http://216.239.57.104/search?q=cache:E7Y5J8QeIAQJ:web.yl.is.s.u-tokyo.ac.jp/~ganat/memo/+parametric+polymorphism%E3%80%80ad+hoc&hl=ja&lr=lang_ja&ie=UTF-8
35デフォルトの名無しさん:04/04/07 15:58
つうか、Genericsってなんのメリットがあんの?
コンテナで中身の型が保証できるだけじゃねぇの?ショボ!
>>32
int hoge<T>(T)の定義で例えばf, g, ..という関数を利用するとして、
そのf,g ..がいくつかの特定の型にしか適用できないものであることがあるよね。
Listのheadは本当にgenericでどんなaに対するList aにでも適用できたけれど。

その場合、hogeの型は、あえていえば、
「なんだかわからないがfという名前の、これこれという
型の整合性を満たす、関数が適用でき、さらにgという...な型(T)をとって、
intを返す関数」になる。

それはそれで便利なんだけど、
これではあらかじめhogeをコンパイルしておくことが難しいし、
型推論したら
hoge :: T -> int, where T can be argument of functions f, g, ..
    f has type T -> double, g has ...
というえらいことになってしまう:-)
そこでHaskellでは
そのfやgが属するべきtype classをあらかじめ指定しておいて、
そのtype classに属する型であることを推論できるようにしてある。

例えば
class FG a where
    f :: a -> Double
    g :: a -> Int
とあると、
hoge x = floor (f x) + g x 
の型は、hoge :: FG a => a -> Int と推論される。
38デフォルトの名無しさん:04/04/07 16:20
> そのf,g ..がいくつかの特定の型にしか適用できないものであることがあるよね。
> Listのheadは本当にgenericでどんなaに対するList aにでも適用できたけれど。
そういう型を特定する目的がある場合は、 <T extends U> でつね。(ホントか?)

型推論であれば、f,gからTとして取り得る型が決まりそうだけど。
なるほど、FGがUですな。
継承(subtyping)と任意にtype classを使えるところが違いか?
ん?おなじ?
>>39
> 継承(subtyping)と任意にtype classを使えるところが違いか?
そうだね。
継承関係に無い無関係な(定義済でもOK)型を自由にいつでも
そのtype classに追加することができる。

> 型推論であれば、f,gからTとして取り得る型が決まりそうだけど。
# ちょっと意味がわからないけれど、こういうことだろうか。
プログラムが単一のもので、他から利用されること無く、
全部書き上がっている場合は、全ての型とf, gをチェックすれば、
取りうる型の集合かを知ることができる。
でもそのプログラムにデータ構造や関数をつけくわえてしまえば
その集合は変わってしまい得る。
したがってバイナリのライブラリにはできないし、どこか変更がある度に
コンパイラはソース全体を読んでhogeを使用している部分を
再コンパイルする必要がでてくる。
エラーメッセージもわけ分からなくなるし。
ああ、f,gの型は確定可能という前提ですた。そんな前提なら元々型推論自体いらん罠。鬱氏。

ただ、
> そのf,g ..がいくつかの特定の型にしか適用できないものであることがあるよね。
を束ねる型って、実際、継承親しかないんじゃないのかな。
> 継承親しかないんじゃ
継承親と同じ意味になるって意味でつ。
type classと継承は、実用上同じ意味かなと。後から定義できるかどうかを除けば。
4326:04/04/08 03:35
>>30,>>37
結局、
「型パラメータ」という用語は、Haskelでは構成型の型推論等で使う用語で、
 >>26の例は 関数の型的制約だから、type class と呼ぶべきだ、
という事なのでしょうか?

関数型言語スレッドにありがちな事ですが、議論が微妙すぎて、
単に教科書のおさらいをしてるだけなのか、
(Genericや型推論という)テーマを新たに定義しなおそうとしているのか、
よくわかんないっす
44デフォルトの名無しさん:04/04/08 03:39
>>34
最初の方のリンク、米澤県の輪講っすか?
「Type Systems and Programming Languages」ってどの本だろう?
日本のアマゾンで探しても、みつかんねぇや。これかな?
  http://www.amazon.co.jp/exec/obidos/ASIN/047194128X/
4544:04/04/08 03:48
>>34の輪講本の件、
本家 amazon.com でも探してみたけど、そゆータイトルの本見つかんないっす。
・"Object-Oriented Type Systems" by by Jens Palsberg, Michael I. Schwartzbach (Contributor) $65.95
これかな。

いずれにせよ、さすが米澤県っすね。マニア心をくすぐる渋い輪講テーマだ(w
今度、その本注文しよっと
46デフォルトの名無しさん:04/04/08 06:38
>>34の最初の方のリンク ("Type Systems and Programming Languages" 輪講)
 23.2 Varieties of Polymorphism
  Parametric Polymorphism: 前節と本節のメイン。
    型チェックではとりあえず「generic な」型を当てておいて、必要に応じて具体的な型で考えるタイプ。
    Polymorphic なコードはプログラムテキスト上は同じ見かけになる。

    最も強力なのは本節の impredicative (or first-class) polymorphism だが、
    実用上広く使われるのは let-polymorphism である。

  Ad-hoc Polymorphism: 型ごとに違ったコードを書くタイプ。
    最も広く使われているものに overloading、それを一般化した multi-method dispatch 等がある。
    intensional polymorphis や typecase のように、実行時に型情報を利用できる強力な機構もある。
    OOP 界で polymorphism というときには ad-hoc polymorphism の一種である
    subtype polymorphism を指すことが多い。

>>38-42
簡単に言うと、「Genericで型推論!」つう事は、
・OOで subtype polymorphismは普及したから、次は
・Genericで Parametric Polymorphismしようよ、
って話でOK?

(10年前からそりゃわかってるさ、わかってるけどOO屋が頭固いから・・・)
>>44-45
http://www.amazon.com/exec/obidos/tg/detail/-/0262162091/102-2455043-2214555?vi=glance
これでしょ?
ソース:http://web.yl.is.s.u-tokyo.ac.jp/~kohei/rinkou/types/
(ってまあ、厨の漏れにはさっぱりちんぷんかんぷんな訳だが)

48デフォルトの名無しさん:04/04/10 17:07
Generic Program'mistの漏れは、
モニータスピカーも、フィンランドのGenelecにしますたが、何か?
generic programming がなんなのか未だによく分からないんだけど、
Ruby の module みたいなのは generic programming って言うの?
>>46
関数型言語の方でもGeneric Programmingは最新のテーマだよ…。
Parametric Polymorphismなんつー30年前のネタとは違う。
G'Caml とか Generic Haskell とか調べてみれ。
ケンブリッジの人たちが、MSRケンブリッジに大量に。
http://research.microsoft.com/projects/clrgen/
52デフォルトの名無しさん:04/04/11 15:21
>>50
ふ〜ん、そうなんだぁ〜。
CommonLispコンパイラーやC++ STL近辺で
Parametric Polymorphismと関連して
総称型とかGenericとか普通に言ってたから、
両者の境界が見えなかったあるよ〜。

で。Parametric PolymorphismとGeneric Programmingの境界はナニですか?
あと、Genericのびぶりおぐらふぃぃキボンヌ
PolymorphismとGenericsは、深い関係がある気がするけど、
どういう関係なんでしょうか。
54デフォルトの名無しさん:04/04/11 15:30
つ〜か。
関数や変数の型付けが弱いLispでは、consセル以外の型なんて外付けだから、昔からGenericだけど、
型をきちんと扱う関数型言語では、型付けと総称型って、ムチとアメみたいな関係があって、
ムチの有効性を維持しながら如何にアメを提供するか、つう議論の決着がなかなかつかないのかな。

そ〜ゆ〜話題は、なんかSMの女王様向けの話題っすね。
漏れは、ムチよりもムチムチが好みだ・・・。
と、無恥な男がなんか世迷い言を申しておりますが。
>>52-53ってどうなんでしょうね?
>>52
Parametric Polymorphismを使えば、「list of intの全要素に関数を
適用する関数」も「list of stringの全要素に関数を適用する関数」
も「list of hogehogeの全要素に関数を適用する関数」も一個の定義で
書けた。OK。万歳だ。(MLとかHaskellのmap関数)

Generic Programmingなら、「list of hogehogeの全要素に関数を
適用する関数」も「tree of fugafugaの全要素に関数を適用する
関数」も「array of piyopiyoの全要素に関数を適用する関数」も
一個の定義で書ける。いえーい。(GenericHaskellのpmap、C++のfor_each…)

とか、あくまで一例だけどな。
http://web.comlab.ox.ac.uk/oucl/research/areas/ap/topics.html#GP

C++ STLやJavaはオブジェクト指向とかカプセル化を前提にしたGenericsなんで
実体は要するにParametricPolyとAdhocPolyを巧妙に混ぜて使ってる
だけにならざるを得ないんだけど、概念としては、そーゆーこと。
57デフォルトの名無しさん:04/04/11 16:26
Parametric Polymorphismと、Generic Programmingの違いぃー?
場の量子論をメズスコピックと言い直し、最近はナノテクノロジーと呼ぶのと一緒じゃないのかな?
研究の焦点や目的は、微妙に変化してるけど、扱ってる対象はおんなじ、みたいなw
58デフォルトの名無しさん:04/04/11 16:31
>>56
Javaだと、Iterator interfaceっす
リストなんかのparametric polymorphismでgenericだというのはトリビアルなわけで、
どれだけのことをGenericにできるかというのが課題なのだと思う。

Generic tree traversal についての最近のpaper(Haskell).
Scrap Your Bilerplate: 
A Practical Design Pattern for Generic Programming
http://www.cs.vu.nl/boilerplate/
Visitor patternとの比較なんかもしてるしreferenceをたどるのも面白いかも。

個人的には"Derivable type classes (2000)"での、
「全ては式である」(by mathematica)的な(data typeの構造について帰納法)
方法に期待していたけれど開発中止っぽい:-(
JavaのIteratorだと、回すことは出来ても、肝心の関数適用が。。。
で、型に関係なく適用できる関数ってなにができるの?
それとも、回すこと自体がGenerics?
61デフォルトの名無しさん:04/04/11 16:53
>>59
お、ようやくコアな話題、かな。

OOとかデザパタっつうのも、形を変えた(一般向けの)型システムに関する議論なわけで、
漏れはOO専門家ぁ?みたいなのに身をやつして、そのあたりを(暇な時に)追っかけてますがw
 (構成型の要素の型をパラメータとした)実装継承=パラメトリック多態性
 (Javaインターフェースの実装のような)型継承 =総称多態性
ってなマッピングするだけだけどw

最近はOOがほぼ定着し(OOPが定着しただけだという話もちらほら)、
かつては関数型言語の話題だった総称型を扱う型システムも、OOのボキャブラリで語れるようになって、
なかなか便利な状況になって参りますたね。

最後の行、「全ては式である」つうのは、何の話でしょうか?
全てのオブジェクトは、関数型言語の部分計算キャッシュに過ぎないIという信念を持って
OOしてる漏れには、なんか気になるフレーズですた。
>>60
> JavaのIteratorだと、回すことは出来ても、肝心の関数適用が。。。
が、なんなの?関数適用の構文が変わるとは思えないんだが。

> で、型に関係なく適用できる関数ってなにができるの?
特定の型にだけなんらかの操作をするとかね。
>>59のペーパーでは複数のデータ型からなるTreeをトラバースして
特定の型に対してのみ変更を加えるといった問題を考えている。

> それとも、回すこと自体がGenerics?
それもGenerics。
63デフォルトの名無しさん:04/04/11 17:03
>>62
 >>60の方向を追求すると、
  eval機構とか、高階関数とか、リフレクション、てな方向に逝って議論が発散するヨーカン。
 その話題は、一番最初に決めちまうと身動きが取れなくなる、
 一番最後に決まれば良いんだよ、といってみるテスト
>>61
> 最後の行、「全ては式である」つうのは、何の話でしょうか?

Mathematicaでは、全てのもの(関数、データ型等)が
"Head[a, b, c, ...]"という、リストにタグがついたような形をしていて、
それは「式」といわれる。そして、Map, Apply, First, Rest, .. といったような
いわゆるリスト操作的な関数が全ての「式」に適用できる。
構造を操作する関数が完全にGenericになっている。
Mathematicaはdynamic typingだけどね。

Derivable Type Classes というのは、data typeを
どれも同じタグ(コンストラクタ)+引数みたいな形であつかえるようにする話。

> 全てのオブジェクトは、関数型言語の部分計算キャッシュに過ぎないIという信念を持って
> OOしてる漏れには、なんか気になるフレーズですた。

…わからないです。
>>62>>63
なるほど。Thx。
関数適用についてはGenericsではペーパーの議論レベルって事ね。
OOでは、Genericよりも手堅くSubTypingでGoと。
そうかんがえると、Iteratorもコンテナの枠組みだし、
>>35はあながち間違いじゃないということ?
66デフォルトの名無しさん:04/04/11 17:23
>>64
さんくす。

こっちの信念の話は、ややこしいから横置いとくとしてぇ〜(苦笑

あ、やっぱWolframたんの数式処理システムのお話っすか。(数学者が何か言ったんだと思ったw
う〜ん、そーゆー考え方、漏れにとってもある種原点の体験っす。
できれば、やさぁ〜しく教えて下さると助かりまっす。
#2chだと、シム板のMAXIMAスレが多少関係あるのかなぁ。。。
>>65
> 関数適用についてはGenericsではペーパーの議論レベルって事ね。
GHCに実装されてるよ。

>>66
Mathematicaはこれとか
http://documents.wolfram.com/v5/TheMathematicaBook/PrinciplesOfMathematica/Expressions/2.1.1.html

>>64では"Head[a, b, c, ...]"でなく"Tag[a, b, c, ...]"
と書くべきだったな。

Derivable Type Classは、例えばこういうリストを
> data Data a = A a (AA a) (AAA a) | B a | C | D
((a * ((AA a) * (AAA a))) + (a + (1 + 1)))
のような直積と直和と考えて帰納的に操作するって感じ。
ペーパーは
http://research.microsoft.com/~simonpj/Papers/derive.htm
GHCに実装されてるってのは、
>特定の型にだけなんらかの操作をするとかね。
でしょうか。
Genericsの関数適用ってのは、出来る奴にだけする?
それって訳解るんでしょうかね。人間がコーディングするという前提で。
OOのSubTyping+AdHocならすっきりですが。
69デフォルトの名無しさん:04/04/11 19:44
>>68
私はGHCの例を出された方とは違うのですが、
正直>>68さんのおっしゃっておられる事は、
Genericとは違う範疇の問題だと感じられます。

全ての型に対するGenericな操作、などというものは、
Lispのevalとか、OOのObjectクラスにしか通用しない話であり、
今更議論しても得る所は少ないのではないでしょうか?
むしろ、>>68は C++のTemplate以上の物は理解できないので要りません、
と言っているだけのような気がするテスト。
いや、むしろ>>68さんは、C++のTemplate以上の物は触ったことがないので、想像もできません、
と白旗あげてるだけのような気がするデバッグ。
72デフォルトの名無しさん:04/04/11 20:01
>>67
どもども、これから、読ませて頂きます。
即レスは、、、ちょいとムズイっぽいです。

あと、オブジェクト指向言語の上で、数式と型のお話を実装しようとした試み(symbolicC++)の本が、
自宅のコンソール下に放置しっぱなしで、こっちも数年振りに目を通しとこうかなw
73白旗:04/04/11 20:15
全ての型じゃないGenericsの操作は、OOのSubTyping+AdHocじゃなくても、
訳解るやり方なの?厨なので想像つかないや、ってレスです。
>>69トン楠です。
74:04/04/11 20:51
こんばんわ、ボンベルタ橘です。

◆新着情報◆. ★2004年4月8日★ UV対策をアップいたしました。
★2004年4月5日★ ジーンズニュースをアップいたしました。 ★2004
年3月30日★ リップリップのオススメをアップいたしました
JavaのInterfaceは、subtypingとは違う、と言ってみる結合テスト。
76デフォルトの名無しさん:04/04/11 20:57
>>75
そうは言っても、Javaのinterfaceは、ad-hockそのものだろ、と言ってみる手戻り発生。
77デフォルトの名無しさん:04/04/11 20:59
そしたらJavaのgenericは、実装コードを持つinterfaceとか、多重継承可能な抽象クラス、みたいなもんだろうか?
というQA票を発送するテスト。
関係ないが最近CMでジェネリック医薬品って言葉をよく聞くようになったな。
なんにでも聞く薬かと思ってしまう(笑)
JavaのTigerのGenericsは、erasure方式でコンパイラが
型パラメタのキャストをいれるもの、と外した回答で工数浪費。

「A Comparative Study of Language Support for Generic Programming」
という題の論文がちょっと前に SIGPLAN に出てた。以下の言語を幾つかの視
点から比べてた。

C++
Standard ML
Haskell
Eiffel
Generic Java
Generic C#

論文曰く、結局 Haskell が一番良さげなんだそーだ。その次は Standard ML ね。
> 全てのオブジェクトは、関数型言語の部分計算キャッシュに過ぎないIという信念を持って
> OOしてる漏れには、なんか気になるフレーズですた。
そういうのを手続き指向という。
オブジェクト指向の世界観は、もっとステートフルで順序的で、
拡張性・互換性のためなら副作用大歓迎という文化。
82デフォルトの名無しさん:04/04/13 22:34
>>81
おにぃさん、今、研究機関の研究テーマの流行りは、
Statelessな関数型言語(ML,Haskel,Clean,etc.)で確立した型システムの扱いを、
Javaを始めとするオブジェクト指向言語の型システム(クラス)へと適用/拡張することなんですよ。
83デフォルトの名無しさん:04/04/13 22:38
そして、オブジェクトを関数言語の部分計算と見ることで、
関数言語の型システムで、オブジェクト指向の型システム(クラス)を説明できるようになり、
最終的には、オブジェクト指向言語の型システム(クラス)について、フォーマルな取り扱いがしやすくなるんでわ?
つうのが、漏れの信念です。

でも、こーゆーのって、米澤県とかMSRあたりのキラ星研究者がやってるテーマな気がする。。。
>>82
その「研究機関の研究テーマ」ってのは何だ?(w
85デフォルトの名無しさん:04/04/13 23:16
オレオレ
>>85
おまえが研究機関か!
あれほど裏の空き地で野球を(ry
87デフォルトの名無しさん:04/04/13 23:18
つか、素人向けに現在のトレンドを説明したつもりなんだけど、
なんで一々絡んでくるの?だから素人は嫌いだ。
ニヤニヤ
89デフォルトの名無しさん:04/04/13 23:36
話の本筋ではなく、重箱の隅をつついて、
相手に丁寧な説明を要求しちまうような、
礼儀知らずで無作法な厨房って多いよな。
俺はそういう厨房が、大嫌いだ。

今も、大岡山近くの事務所(誰だよ番頭は?)から、
その手の厨房が俺の席前に出張ってきていて、
対応に困ってる。

こっちの言うこと全然聞かねぇで反論ばっかりだし(口癖は聞いて下さいよ〜)し、
メールで返事しろつっても、非難するような口調で一々口頭で質問してくるし、
忙しいから出来るか出来ねぇかまず答えろつっても、じくじく質問してきやがって、
挙句の果て、ここまで説明すりゃーどんな厨房でも出来るだろ、っつう説明をし終えると、
今度は「そんなことやっても意味がないです」ブチッ

てめぇの趣味聞いてんじゃねぇんだよ、仕事だからやれよ。
自分で方法も思いつかず、忙しい人様の時間を浪費して質問してくるなら、
さっさと実装しろよ。方法を人に聞いて、自分勝手に結論出して意味がねぇって、おまえ何様?
ふつ〜、そ〜ゆ〜無作法な奴って、卒業研究か博士課程でゴリゴリ削られて丸くなるもんなんだけど、
その程度の訓練もできてないヤシが、なんで大口叩くの?40も近くなって。お子様ですか?

と、ゆーような、アフォに心乱される日々を送る、2004年春の夜。

結論はCleanのGenericマンセー
ってこったな。
いまこのスレでなにが話されているか、
俺にもわかるように教えてください。
(・∀・) ニヤニヤ
>>89
君ももうちょっと大人になればいいのに。
94デフォルトの名無しさん:04/04/14 12:46
プロマネ業務経験者の立場から言わせてもらうと、
・虚偽の報告をする奴
・分担作業者間のすり合わせをのらりくらり逃げる奴
・ぷろぱの指示聞けない外注さん
は、居なくていいか、と。
俺がこんなこと言わにゃならんとはな〜、世も末だなこりゃw
老婆心ながらアドバイスしとくと。
・報告やすり合わせの場で、あんま反論ばっかりすると、
 プロジェクトが荒れるから、もうちょっと反論の方法を考えた方が良いよ。
 口頭でつじつまの合わない逃げを打つと、ボロクソに叩かれるのが道理。
 それでも自分に理があると思うなら、冷静にメールで事実を伝えてはどうよ。
 CCで自分と相手の上司にもCC打つのは基本動作。
 ようするに、口頭でツマラン喧嘩する暇があったら、自分も相手も逃げ場のない方法で
 きちんとした誠実な議論をして呉れっつう事。それが、正しい問題解決の方法だよん。

95デフォルトの名無しさん:04/04/14 12:54
・自分の指示系統の外のぷろぱに、全部責任押し付ける、
 不合理外注も(゚д゚)イラネ、ペッ
外注に、真実を報告する価値を認められない、
独善的終了済プロ真似の愚痴はこちらで http://life4.2ch.net/yume/
97デフォルトの名無しさん:04/04/15 00:18
>>96
いみ、ふめいですぅ〜☆
98デフォルトの名無しさん:04/04/24 17:03
で?
土曜日の晩 17:00にageたスレが、未だにスレ位置34か。

この板の過疎っぷりも、ひどいな。
ここ数年、気違いが荒らしまくってるのを放置した結果が、このザマか。
なんていうか、「関数型言語」に反応して荒らしてる奴が約2名いるな・・・
>>84を軽く流せない>>82もかなり低能な気が…
102デフォルトの名無しさん:04/05/07 01:16
相手の話の本筋をまるっきり無視して、
興味本位に重箱の隅をつついた質問を繰り返す、
そんな厨房が、私は大嫌いだ。

呆れ返った相手が、同情心で莫迦っ丁寧な説明をしてくれるのを見て、
「そんな幼稚な事は判り切ってるよ、アフォ」とか、
「アフォを煽って、うまく情報を聞き出したぞ」とか
「知的でクールな駆け引きをして情報を入手した」とか
ゆーよーな態度を取る厨房が、死ぬほど嫌いだ。

おまえら、ヴァカでアフォで格下だから、そんな態度が許されるんだぞ。
おまえらが、おまえらより格下にそんな態度とったら、アフォ扱いされるんだぞ。
そんな態度とる奴は、
「私はヴァカなガキなんで、丁寧にものを尋ねるマナーすらありません」
って首から看板ぶら下げて歩いてるくらい、みっともないんだぞ。

ただし、ヴァカでアフォでガキなおまぃらは、ヴァカでアフォでガキだから、
そーゆー未熟な態度しかとれない事はわかってる。遠慮なく、ヴァカでアフォでガキな態度でもがく事を特別許す。
だけど、とってもウザいから、とにかく早く成長しろ。おながいします。
103にゃーご:04/05/07 03:17
春だね。発情期だね。
>>102
どこを縦読み?
106厨でーす:04/05/29 16:41
下寝りっくぷろぐらみんぐって、
単にみんなObject型(型継承木のルート)で扱うのと、なんが違うの?(型間違いのチェックを除いて)

「どうだ、これが下寝りっくぷろぐらみんぐだ」!見たいな
サンプルコードない?
そんなことしたら、Object型が闇鍋になってしまうじゃない。
手に入りやすいところでtype_traits辺り読んでみてね。
108厨でーす:04/05/29 23:49
>>107
とんくすこ。それって、
http://www.boost.org/libs/type_traits/ の Example code のこと?
++読めないけど読んでみますた。
げねりっくって、コンテナ系に強いっていうか、
なんでも(?)コンテナベースで書くのが流儀なの?
コンテナを発想の中心に据えてコードを書くのかな?それって一般的に可能なの?
(Type Trait自体はリフレクションでいいかなとか思っちゃうけど(速度がメリットな訳じゃないよね?))
C++で最初に追求した人がcontainerでやったから
containerで一番発達しています。

traitsっていうくらいで、
型システムをうまく使った脱闇鍋ぶりをみてね。
とどのつまり、Generic Programmingのメリットとは、
型の気持ちよさが維持できる、ということですかい?

全部Objectで書いて気にならない剛の者、あるいは
静的型がない言語では別段うれしくはない?
111デフォルトの名無しさん:04/05/30 04:10
意味不明なリファレンスの書き方をするのが、最近の流儀なの?

学がない人の知ったかぶりって、やーねぇ
112デフォルトの名無しさん:04/05/30 04:27
type_traits:
 C++ STL方面(Boosts C++ Library ?)で
 Template引き数の型特性情報(voidとかpointerとか)
 をランタイム情報として持たせる
って話か。いかにもC++って感じだね。

>>30近辺で型パラメータ(仮引数)だtype class(実引数)だ、って言ってる話の派生ね。
で、>>107-108は一体何を言ってるの?
113デフォルトの名無しさん:04/05/30 04:28
>>110
おれもあんまわかってないけど、それは違うと思われ。
http://www.mamezou.com/tec/Tips/jsgl/

Genericsってのは、*事実上*、汎用的なコンテナと汎用的なイテレータで
汎用的にごにょごにょするのをいうのではないかと。
そういう意味で、Javaではもともと可能な訳で、
J2SE5.0で追加の、erasureによる「Generics」はホントはgenericsではなくて、
気持ちよさの味付けに過ぎない、とか言ってみるテスト。
114デフォルトの名無しさん:04/05/30 04:30
>>30-31>>107-108だろ。
つまんない知ったかぶりで話を脱線させる特性が共通してるYO
115デフォルトの名無しさん:04/05/30 04:34
>>110,>>113
 あの〜w
 まめぞの記事リファレンスに出すくらいなら、
 もっと皆に分かりやすく説明したらどうだろね。

 >>110が主観的すぎて第三者に意味不明、
 それにレスする>>113はもっと意味不明。

 要するに、Java Genericは普通のGenericじゃねぇよ、と知ったかしたいのですね :-)
>>113
どーでもいーや。あんたの発言。
夜中にいみふめな即レスつける厨はすっこんでろ、と。
117デフォルトの名無しさん:04/05/30 04:41
賢くて造詣が深くていらっしゃるようですので、意味不明なんていわないで、
突っ込みどころをきちんと突っ込んでくれれば話は進むのですが。
119デフォルトの名無しさん:04/05/30 10:36
>>118
それもGenericProgramingなの?
メンヘラー1が発生しますた。
場所は>>114=>>115=>>116です。
 OKで終了
 キャンセルでデバッグ
[OK] [キャンセル]
「とどのつまり、Generic Programmingのメリットとは、
 型の気持ちよさが維持できる、ということですかい?

 全部Objectで書いて気にならない剛の者、あるいは
 静的型がない言語では別段うれしくはない? 」

ってのは、生半可な厨房に言える言葉ではないな。
究極の厨房、至高のDQS、とにかく視野が狭すぎ。
C++ばっかやんないで、スクリプト系言語やプロトタイピングベースのOO
にでも手を出して、視野を広めてきなさい、ってこった。
究極でも歯垢でも何でもいいから、具体的な突っ込みを書けよ。
しかし、プロトタイピングベースのOOってのは初めて聞いたな。
123デフォルトの名無しさん:04/05/31 07:10
厨房に突っ込んだら捕まるからいやん
124デフォルトの名無しさん:04/06/02 00:51
> Genericsってのは、*事実上*、汎用的なコンテナと汎用的なイテレータで
> 汎用的にごにょごにょするのをいうのではないかと。

Genericsって、用途というか適用範囲は限られてるんだね。
OOみたいなもっと一般的な考え方かと思ってた。
C++なんかのgenerics程度でわかったような気になってるやつは
関数型言語の「多相型」についてもっと勉強した方がいいよ。
126デフォルトの名無しさん:04/06/02 03:11
> 関数型言語の「多相型」

それって、コンテナとイテレータ(イテレーション)でごにょごにょとは
全然違って、Genericsを一般的な技法にしてくれるもの?
>>126
> それって、コンテナとイテレータ(イテレーション)でごにょごにょとは

C++だって、そうじゃない。

話っぷりがアホっぽくて、相手したくないから、
"Modern C++ Designe"でも読んでくれ。
128デフォルトの名無しさん:04/06/02 19:22
>>127
アホはおめーだろwww.co.jp
>>126
コンテナもイテレーションも関係ない。
一言でいうと、ストローのようなもの
ストロー??(@_@)??
その心は?
ちゅーっ
133デフォルトの名無しさん:04/06/14 02:56
虎のGenericsって↓とかってどうなんのよ?
とくにEndUserだけあとでコンパイルしたら。

public class Holder<T> {
T value_;
public Holder(T t) { value_ = t; }
public T value(T t) { return value_; }
}

public class IntegerHolderUser {
void method( Holder<Integer> holder ){....;}
}

public class EndUser {
void hoge(IntegerHolderUser iu){
....;
iu.method(new Holder<String>("Unko"));//★
....;
}
}
>>133
試しもせずに聞く奴はウンコ。
> EndUser.java:3: method(Holder<java.lang.Integer>) (IntegerHolderUser 内) を (Hol
> der<java.lang.String>) に適用できません
> iu.method(new Holder<String>("String"));
> ^
> エラー 1 個
135ウンコ:04/06/15 02:56
とんくすこ。
クラスファイルは今までと変わらなくて、
実体はみんな只のObject(か制約してるinterface)+ キャスト、ってのはガセか?
これって、classファイルにしっかり特殊化したパラメタの型データが埋め込まれてるって事だよな?
>>135
そーゆーのが知りたきゃ、横着しないでちゃんと仕様読めよ。

http://java.sun.com/developer/earlyAccess/adding_generics/
でダウンロードできる adding_generics-2_4-ea.zip 内にある文書とか、
http://www.jcp.org/en/jsr/detail?id=202 とか。
>>134みてトライしたが、TypeList書けね。書けんの?
138デフォルトの名無しさん:04/07/04 16:05
>>121
このおっさん何言ってんだ?あふぉ?
Genericプログラミングは、型についてGenericなプログラミングなんだから、
「」が言ってることはあってるだろ。
当たり前すぎるからいってると思われ。


140デフォルトの名無しさん:04/09/23 03:41:52
Tiger preFCSリリース記念age。
141デフォルトの名無しさん:04/12/18 01:54:57
だれもやってないの?
142デフォルトの名無しさん:04/12/18 01:57:31
テンプレート関連のスレが他にあるから。
143デフォルトの名無しさん:04/12/18 02:02:32
++だけかぁ。 (´・ω・`)ショボーン
144デフォルトの名無しさん:04/12/18 02:17:14
>>143
別に言語なんて何だっていいんだけどね。
145デフォルトの名無しさん:04/12/18 02:47:21
>>144
だったらこのスレ盛り上げてけろ。
146デフォルトの名無しさん:04/12/18 06:03:12
「generic」という言葉の意味を考えると、コンテナ+アルゴリズムだけではなく、
ストリームもgeneric programmingじゃないんだろうか。
ファイル・標準入出力・メモリ(文字列)などを一般化して扱っているのだから。
147デフォルトの名無しさん:04/12/18 08:19:53
ちょっと研究に飽きたので書きこ。専門的には、大雑把にわけると

parametric polymorphism ≒ C++のテンプレート ≒ JavaのGenerics
generic programming == polytypic programming(呼び方が変わっただけ)

だな。

前者はMLとか大昔からあって、まあコンテナがメインだよな。
たとえば二分木を実装したいときに「整数の二分木」「浮動小数の二分木」
「文字列の二分木」とか、要素の型ごとに別々に実装するのが無駄なので、
「…の二分木」の…の部分をパラメタライズできる機構を導入したわけだ。

後者はまだ新しくて、「木にもリストにも組にもグラフにも集合にも
適用できる関数を定義」とか、もう1段上の一般化。
そこまで一般的に定義できるとうれしい関数としては、
シリアライザとかpretty printerとか=(構造等値)とか。

前者は明らかに役に立つが、後者はまだ用途が限定されてて何とも言えん
と俺は思う。
148& ◆D3ra0B2LiQ :04/12/18 08:38:49
で、parametric polymorphismというかJavaのGenericsについては
「要素の型をObjectにすればいいじゃん!」と思うかもしれんが、
そうすると取り出した要素をダウンキャストしないと
ほとんど何もできなくて、コンパイル時型チェックの有難さが
減ってしまう。実行時に「クラスが違うからダウンキャストできないよー」と
言われてしまう(かもしれない)わけだ。

もちろん、誰かが言ってたがコンパイル時型チェックのない言語だったら
そもそもparametric polymorphismなんて不要というか意味がない。

polytypic programmingも、コンパイル時型チェックのない言語なら
普通は自明に実現できるので、やはりあまり意味はない。
149デフォルトの名無しさん:04/12/18 08:40:21
あれ、名前がすげー文字化け…

たまにしか書かないので許してちょ
150デフォルトの名無しさん:04/12/18 09:08:38
全然わけわからん、そもそも>>147的な分類自体が意味不明・・・
大体、Ada83の昔から、genericは後者を明らかに志向していたし
無論AdaのGenericを手本にしたC++のtemlateも
STLなんかを見れば明らかに後者を志向している
151デフォルトの名無しさん:04/12/18 09:10:54
>>147
ちょっとちょっと
> 後者はまだ新しくて、「木にもリストにも組にもグラフにも集合にも
> 適用できる関数を定義」とか、もう1段上の一般化。
が役に立つかどうか言えないなんて、世間ずれしすぎ…
152& ◆l.EoaDddmI :04/12/18 09:27:03
>>151
じゃあそういうpolytypicな関数で役に立つ例を、できるだけ多く挙げてくれ。
153147:04/12/18 09:35:27
>>150
たとえばAdaのgenericsでもC++のテンプレートでもいいが、
木とかリストとかペアとか任意のデータ型に適用できるpretty printerを
どう書くの?
154デフォルトの名無しさん:04/12/18 09:39:52
必死だな
155147:04/12/18 09:41:33
ちなみにgeneric programmingとgenericsの区別がつかない人は

http://www.cs.uu.nl/research/projects/generic-haskell/

でも見てね。
156デフォルトの名無しさん:04/12/18 10:11:27
>>147
findとかfor_eachって、後者に入るのでしょうか?
それとも全然見当はずれなのかな。
157156:04/12/18 10:12:24
>>155
どもも。読んでみます。
158156:04/12/18 10:18:10
見当はずれの気がしてきた。
なぜなら、findやfor_eachを*作る*のはgeneric programmingだが、
*使う*のはまた別の話。
159147:04/12/18 10:42:15
あースマソなんかHaskellとか関数型言語でいうgeneric programmingと
OOでいうgeneric programmingが食い違ってるような気がしてきた。
狭義と広義っていうか。googleしてみたら半々ぐらいっぽい。
勉強になりますた。出直してきます。
160156:04/12/18 10:46:34
>>159
そんなん言わんと、専門の立場からもっといろいろ発言しておくれ。
あと、食い違った部分について軽く説明しておいてくれると、読んでる側として勉強になる。
161デフォルトの名無しさん:04/12/18 11:33:47
Java厨に言わせると、
きちんとinterfaceベースで設計すればよいだけでは?
JDK5のGenericsだってOjbectで扱う、コンテナ以外の使い道三塚欄。
162デフォルトの名無しさん:04/12/18 11:45:14
>>161
まず、まともな日本語で書け。意味が分からん。
それから、そういう次元の話はしていない。
163英語毎回追試:04/12/18 11:58:50
Java junkies say,
it is satisfied by correct desinging with 'interface'. is't it?
Generics introdused to J2SDK5.0 seems to be only useful for containers
that need hadling 'Object's.

164デフォルトの名無しさん:04/12/18 14:22:20
genericな設計にするときにUMLなんかでは書けないよね。
設計を図にしたいときってどうするの?
165デフォルトの名無しさん:04/12/18 14:35:33
総称的クラスに対しての操作を通常のクラスに対するものと同様に扱えばいいと思うけど。
166デフォルトの名無しさん:04/12/19 00:19:11
>>155
Generic Haskelは、CLOS的な総称関数をHaskelにtype safeなまま持ち込む試み。
Dynamic typingも含む。

どっちかつーと、CLOS, C++(with typeid)の後追いかな。
もちろん理論部分で頑張ってるけども。
167147:04/12/19 00:50:56
>>160
現在の自分の理解…

OOでいっているgeneric programmingは、MLとか関数型言語でいう
parametric polymorphismのことで、C++のテンプレートとか
Javaのgenericsが実現の一例。intのtreeと、floatのtreeと、
stringのtreeと…を「Xのtree」みたく、型について一般化された
型や関数を定義できる。

Haskellとか関数型言語(プログラミング言語基礎理論のコミュニティ?)でいう
generic programmingは、polytypic programmingと同義で、treeにもlistにも
pairにも適用できる関数を「定義」するための機構。>>156もいっているように、
foreachとかmapとか別々に定義して「使用」することは大抵の言語で可能だけど、
そうではなくて、まとめて定義するってことね。テクニカルにいうと、
型(intとかfloatとかstringとか)について一般的なだけでなく、
型演算子(listとかtreeとか)について一般的な定義ができる。

ついでにソフトウェア工学あたりだと、とにかく超広義に「一般的なプログラムを
書くための仕組み」を何でもgeneric programmingとか言っている人もいる。

ってな感じで合ってる?
168147:04/12/19 00:54:00
>>166
あー、C++のテンプレートはいろいろとくっついてるから、一概に
parametric polymorphismだけとはいえないのね。なるほど。

ちなみにCLOSの総称関数ってどんなの?
169147:04/12/19 01:02:07
170デフォルトの名無しさん:04/12/19 01:43:07
>>168
C++と同じくコード共有はあまり気にしない流儀。
http://www.lisp.org/HyperSpec/Body/mac_defgeneric.html

Generic Haskelは、dynamig typing使って、
コード(というか定義)共有頑張るんでしょ? (違うのかな?)
Java genericsやC#のboxing/unboxingみたいに。

structural polymorphismってのは、
C++でいうところのtraitやconceptを入れたポリモなのかな?
171デフォルトの名無しさん:04/12/19 01:43:54
>>170
> Java genericsやC#のboxing/unboxingみたいに。

auto-boxing/unboxingね。
172デフォルトの名無しさん:04/12/19 01:53:20
173デフォルトの名無しさん:04/12/21 16:03:37
マクロベースでなんとかならなかったのかなーと思って
妄想書いてみた
(define-macro (hoge . body)
 (let ((x (gensym)))
  `(let ((,x 1))
   (hage ,x (car body)) (set! ,x 2) (mage ,x ,@(cdr body)))))

#define hoge(#rest body) \
 { int #gensym x = 1; \
  hage(#unquote x, #first body); \
  #unquote x = 2; \ mage(#unquote x, #unquote_splicing #rest body); }

hoge(a,bc)

{ int g01__x = 1;
 hage(g01__x, a); g01__x = 2; mage(g01__x, b,c); }

#define_syntax for_each #var o #var proc in #var seq ; \
 { #unquote seq.type #gensym x = #unquote seq; \
  for (; #unquote x; ;#unquote x = #unquote x.next()) { \
   #unquote x.data.type #unquote o = #unquote x.data; \
   #unquote proc}}

for_each z printf("data = %a",z); in strlist;

{ string_list_t g02__x = strlist;
 for (g02__x; g02__x = g02__x.next()) {
  string_list_data_t z = g02__x.data; printf("data = %a",z); }}

やっぱ型がネックだなー
やはりC++の選択は正しかったのか。
174デフォルトの名無しさん
>>173
C++のテンプレートは構文マクロだからな。

どうでもいいがJava Genericsには日本人の貢献もでかいな。