トップページ⇒tech
981コメント333KB

【数学者】Haskellはクソ言語【オナニー】

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2005/09/30(金) 01:34:05
C/C++＞＞＞＞(越えられない壁)＞＞＞Haskell
0232デフォルトの名無しさん2006/06/30(金) 12:27:10
ああ、言いたいことは分かったよ。

IOモナドは副作用を陽に扱わない。
Haskellは、副作用を表現するIOモナドを純粋関数的に「繋いで」、mainとして定義するスタイル。
繋いだアクションが逐次実行されることで、実行形式は副作用を伴うプログラムとして動作する。
一方、unsafePerformIO はIOモナドとは違い、Haskellの遅延評価のステップの途中で
本当に「副作用的に」評価される(純粋関数の枠を壊している)。
それを言いたいのは分かった。

>・>>210は「Haskellに副作用が無い」という前提で話している。
>　だから少なくともこの文脈ではHaskellのIOを副作用と呼ぶのは不適切。
どうしてその前提が読み取れるのか分からんけど。
というか明らかに IOモナドを副作用を扱うモナドでそ。unsafePerformIOと区別したいのは分かったが。
Haskellで副作用を表現できることはもはや常識なわけで、
「Haskellは副作用を(表面上)追い出した為にIOモナドというややこしい形でしか扱えない。しかし副作用は効率的なプログラムを扱う上で必要悪だよな。もっと簡単にならんのか？」
という風に読んだ。
0233とおりすがり2006/06/30(金) 22:38:41
・形式的にはHaskellのソースコードの中に副作用を伴う要素は無いものとみなせる。

・副作用をいわば「ランタイム側に追い出す」ための仕組みがIOモナド。
　そういう意味でIOは副作用を扱っているといえる。

（・でも本当に副作用を持つ禁断の関数も実はある。）

ってことでFA?

状態機械の仕様をフローチャート的にではなく構成的に
定義できるのってキモチイイな
do構文使ってると普通の逐次処理言語とあまり変わらないけど。
まあ気分の問題で。
0234デフォルトの名無しさん2006/06/30(金) 23:03:53
>do構文使ってると普通の逐次処理言語とあまり変わらないけど。
そう。というかlet文も考えようによっては逐次型っぽい。

for文やwhile文がなくて、オブジェクトのアップデートができない事を除けば、
手続き型言語も関数型言語もそんなに変わらない。
更にHaskellは純粋関数的なので順序を気にしなくていいんだけどね。
0235とおりすがり１2006/06/30(金) 23:52:32
fib = 1:1:zipWith (+) fib (tail fib)
= 1:1:2:3:5:8:12 ....

これはおなじみHaskell版フィボナッチ数列
遅延評価の例として一度はお目にかかるという。

これはリストのある要素の値を
遅延評価を利用して
同じリストの手前の要素から構成しているのがミソ。

#解説は「フィボナッチ Haskell」 でググるといっぱいでてくるので略
0236とおりすがり２2006/06/30(金) 23:55:06
で話かわってmain関数の値の話。

これって要するに最終的には

main = (IO a) >>= (IO b) >>= (IO c) >>= (IO d) ......

というふうに(IO x)を>>=でつないだ数珠繋がりに簡約されるわけで。

(IO x)中にはキー入力とか、画面出力とか、メモリの上書きとか
逐次処理言語の命令コードやサブルーチンのようなものが詰まってる。

>>232とかで言ってるアクションてやつ
ちなみに(return x)で作った(IO x)はNOP（何もしない）が入ってるとみなす。
0237とおりすがり３2006/06/30(金) 23:59:14
>>236のミソは
ループや分岐に相当する(IO x)は無いってこと。

なぜそれでこまらないのかというと、

フィボナッチ数列のときに
ある要素を決定するのにそれより前の要素の値を利用したように

条件分岐で次の処理として(IO y)を繋げようか(IO z)を繋げようか決めるのに
それより前の(IO x)の値をみて決める事ができるから。
あるいはそこで打ち切ってプログラムを終了してもいい。

つまり、Haskellで副作用のあるプログラムを書くってことは

フィボナッチ数列を定義するように
コマンド列を定義しているようなもの
0238とおりすがり４2006/07/01(土) 00:03:08
とまあ
そういう風にオイラは理解したわけです。
0239デフォルトの名無しさん2006/07/01(土) 06:11:52
合ってると思うっす。
0240デフォルトの名無しさん2006/07/01(土) 06:30:18
>>232
>どうしてその前提が読み取れるのか分からんけど。

>「Haskellは副作用を(表面上)追い出した為にIOモナドというややこしい形でしか扱えない。しかし副作用は効率的なプログラムを扱う上で必要悪だよな。もっと簡単にならんのか？」
>という風に読んだ。

そう読めるのに気付かなかった。

入出力のことを副作用と呼んでるようだが、副作用とは式の簡約の過程で入出力を行うことであって、
入出力そのもののことではないだろ。
それとも、「副作用」という言葉をそういう意味で使うことを支持する典拠があったりするのか？

多くの言語では、入出力を扱う唯一の方法が副作用なわけで、入出力と副作用を混同してもさして問題はないだろうが、
そうでない言語(たとえばHaskellやClean)の話をするときはちゃんと区別して話したほうが良いと思う。

>というか明らかに IOモナドを副作用を扱うモナドでそ。
>>231に書いたように「副作用なしで」IOを扱うためのモナド、とするのが普通だと思う。
How to declare an imperativeから引用
>This section relates the monad approach to input-output to four other widely used
>approaches: synchronised streams, as used in earlier versions of Haskell; continua-
>tions, as used in Hope; linear types, as used in Clean; and side effects, as used in
>SML.
0241デフォルトの名無しさん2006/07/01(土) 08:52:27
手続き型言語の代入でも、裏で全メモリの値を渡してると考えれば副作用ではないな
0242デフォルトの名無しさん2006/07/02(日) 00:07:46
>そうでない言語(たとえばHaskellやClean)の話をするときはちゃんと区別して話したほうが良いと思う。
なるほど、完全に同意しましたです。すまない。

更に How to declare an imperative の文がとてもわかりやすい。ありがとう。
入出力、といえば副作用と思っていたけど、同期ストリームもそうだよな。
自分ではhGetContentsくらいしか使わないけど。
linear typeで入出力ができるのもCleanのマニュアルの序章で分かる(world as value)。
しかし。。。continuationでどうやって入出力するのか??


>それとも、「副作用」という言葉をそういう意味で使うことを支持する典拠があったりするのか？
あなたが言うように、副作用と入出力を混同していた。典拠はない。
02432422006/07/02(日) 00:15:21
誤解を招くと悪いので少し書くと、hGetContents自体の型は Handle -> IO StringなのでIOモナド。

ただ、hGetContentsから得たStringは遅延評価の度にファイルやネットワークデバイスから読み出される。
(データがなければブロックする)
この「遅延読みString」を処理する部分は旧来のストリーム・プログラミングっぽい（よね？
0244デフォルトの名無しさん2006/07/06(木) 22:15:48
C言語だと言語仕様として再帰は32回までしか保証しない(だっけ)とかだから、
再帰による33回目の関数呼び出しとそうでない呼び出しで意味が大きく変わってくる。
0245デフォルトの名無しさん2006/07/06(木) 23:06:29
>>244
うそつけ。Cの仕様書にそんなこと書いてないぞ。
0246デフォルトの名無しさん2006/07/07(金) 04:38:43
何かそういう類いのあった気がするよ。
for のネストの回数とか意外なものに、
最低保証回数が仕様として決められている。
0247デフォルトの名無しさん2006/07/07(金) 06:46:28
つ[5.2.4 Environmental limits]
だが、再帰回数はない。
0248デフォルトの名無しさん2006/07/07(金) 08:25:32
そうなのか。
0249デフォルトの名無しさん2006/07/07(金) 08:32:38
>>244
少し考えれば、再帰を32回まで完全保証する事が不可能だって分かるだろ。
0250デフォルトの名無しさん2006/07/08(土) 09:19:47
へ？不可能なの？スタックさえ確保しておけばいいんじゃねーの？
0251デフォルトの名無しさん2006/07/08(土) 09:22:30
>>249
ああ、確かにそうだな。
0252デフォルトの名無しさん2006/07/09(日) 01:07:02
>>250
ローカル変数がスタックに取得される仕様だと
消費されるスタックの量が予測できないだろ。

ローカル変数と配列の最大数×配列サイズの制限？から再帰の
最大数を決めてもあまり意味があるとも思えない。

ローカル変数をスタックに取らないといけない決まりも無いけど
ほとんどの実装で受け入れられないモノを標準仕様を
するわけにはいかなかったんだろう。

ってスレ違いごめん
0253デフォルトの名無しさん2006/07/09(日) 20:45:30
ローカル変数のスタック上のサイズは固定でしょ。言語にもよるけどCやC++ならそう。
そんなことも分からんやつしか居ないの？
0254デフォルトの名無しさん2006/07/09(日) 21:39:50
もっと優しく言ってくれ
0255デフォルトの名無しさん2006/07/09(日) 21:49:20
おれにはツンデレでお願い
0256デフォルトの名無しさん2006/07/09(日) 22:30:35
し、Cの言語仕様にスタックなんて概念は規定されてないんだからねっ！
0257デフォルトの名無しさん2006/07/09(日) 22:34:52
>>244-256
スレ違いの議論はこの辺で終了して下さい
0258デフォルトの名無しさん2006/07/10(月) 00:31:31
>>253
だからその固定の変数を最大いくつ宣言できるか判らないでしょ
0259デフォルトの名無しさん2006/07/10(月) 02:01:36
さらにC99だとスタック上の配列のサイズは実行時に決定できる。
すれ違いなのでこの辺までにしとこう。
0260デフォルトの名無しさん2006/07/10(月) 06:35:50
>>259
>>256
0261デフォルトの名無しさん2006/07/10(月) 12:53:18
>>259
偉そうに大嘘で締めないように。無能はしゃしゃり出ちゃいやん。

ま、スレ違いだからやめとくか。
0262デフォルトの名無しさん2006/07/10(月) 13:38:02
ここは一応 Haskell 本スレじゃないから、
少々脱線した所でどうでもいい気もするけどね。
0263デフォルトの名無しさん2006/07/10(月) 13:52:49
少々なら良いけど3日も続くとね…。
面白い話でもないしw
0264デフォルトの名無しさん2006/07/10(月) 22:01:26
>>260
細かいな。記憶クラスが auto の配列って言えばいいのか？

>>261
C99のマニュアル読んでね。
0265デフォルトの名無しさん2006/07/10(月) 22:17:04
げ。知らなかった。
int a[hoge()];
なんてやっても動くじゃん。
いままで関数内で捨てちゃう配列にmalloc使っていたのは無駄だったのか。

HaskellとRubyばっかり使っていたせいで、Cはメモリ管理がめんどくさい言語
だとばかり思っててちゃんと調べてなかった。
0266デフォルトの名無しさん2006/07/10(月) 22:31:16
C99 じゃないと無理だけどな。
0267デフォルトの名無しさん2006/07/10(月) 22:34:35
Cは99なのにHaskellはまだ98なのかー
0268デフォルトの名無しさん2006/07/10(月) 22:46:53
>>264
しかしそう言い直した途端にスタックの話じゃなくなる罠。

いつまでもひきずってもつまらんので、Haskellの豆知識でも。

GHCでコンパイルされたプログラムがスタックをどのように使うかはわかりにくい。
再帰呼び出しでスタックが深くなっているようにも見えないのにオーバーフローを起こしたりする。
これは、スタックの消費が、呼び出しの深さではなく正格な関数の適用のネストの深さに比例するためだ。
例えばg x = x + 1 - 1 + 1 - ..たくさん.. - 1という関数を定義すると、呼び出しの深さは一であるにも関わらず
スタックを大量に消費する。正格な関数である(+)と(-)の適用が深くネストされているからである。
0269デフォルトの名無しさん2006/07/11(火) 09:42:39
スタックが足りなくなったら適当に評価を行って遅延してるのを減らすとか
できないの?
0270デフォルトの名無しさん2006/07/11(火) 11:27:31
>>264
嘘を拡大するためだけに前言撤回で復活しなくてよろしい。
0271デフォルトの名無しさん2006/07/11(火) 19:11:00
>>269
未評価の式はヒープに保存されているので、それ自身はスタックを消費しない。
スタックが溢れるのは式を評価しようとしたとき。
0272デフォルトの名無しさん2006/07/14(金) 00:15:50
>>271 スタックあふれた時はヒープ上にスタックを移動して計算したりできないの？
0273デフォルトの名無しさん2006/07/14(金) 01:15:45
>>272
なんで俺らがそこまでしなきゃいけないわけ？お前何か勘違いしてない？
0274デフォルトの名無しさん2006/07/14(金) 01:28:55
スタックが溢れそうなのにヒープに余裕があるなどと思ってる素人はモノ喋んな。
0275デフォルトの名無しさん2006/07/14(金) 03:16:34
・・・
0276デフォルトの名無しさん2006/07/14(金) 11:25:17
頭が良くない人ほどすぐ怒る
0277デフォルトの名無しさん2006/07/14(金) 17:56:55
>274は50年前の世界からやってきた時空の旅人
0278デフォルトの名無しさん2006/07/15(土) 19:52:26
>>277
♪ぼくらは　たびびと
　ときの　たびびと♪
0279デフォルトの名無しさん2006/07/16(日) 04:35:58
Haskellは、お利口さんに見られたいけど誰もそう見てくれない
哀れな人たちの嫉妬を一身に買って出てるよね。
0280デフォルトの名無しさん2006/07/16(日) 14:04:58
嫉妬というか、そういう奴らがすがるための言語。
知的な奴は、そういうことを考えずに自己拡張しまくりのLispを使う。
0281デフォルトの名無しさん2006/07/18(火) 13:14:51
諸君議論しているかね？
0282デフォルトの名無しさん2006/07/19(水) 01:50:46
Haskell 面白そうなので調べていたら、Clean にたどり着いた。
両方とも、ちょっとしか解ってないが、現時点ではClean の方が良さげに思える。
でも、一般的にはHaskell の方が流行ってるみたい…。
なぜなんでしょう？

Haskell の方が良い！という人の意見が聞きたいです。
0283デフォルトの名無しさん2006/07/19(水) 02:56:48
ttp://groups.google.com.au/group/comp.lang.functional/msg/c09cb40a66558a19
個人的にはCleanって閉鎖的な印象を受けるからHaskellに流れてるだけ。
どっちも元はMirandaだからCommon LispとSchemeくらいにしか違わないんじゃないの？と
ろくすっぽCleanを知らないで書いてみる。
0284デフォルトの名無しさん2006/07/19(水) 03:02:04
ま、素人はそう考えるわな。
0285デフォルトの名無しさん2006/07/19(水) 03:58:51
最新ニュース　【教育】国際数学オリンピック　中国が全員金メダルで3年連続世界1位　2位ロシア、3位韓国　日本は7位も過去最高成績
1 ：ネットナンパ師φ ★ ：2006/07/19(水) 02:23:23 ID:???0
http://news.searchina.ne.jp/disp.cgi?y=2006&d=0718&f=national_0718_002.shtml
http://imo2006.dmfa.si/results.html によると、順位は　1中国　2ロシア　3韓国
4ドイツ　5アメリカ　6ルーマニア　7日本　8イラン　9モルドバ　10台湾　11ポーランド　12イタリア
13ベトナム　14香港　15カナダ　16タイ　17ハンガリー　18スロバキア　19トルコ　20イギリス
【ニュー速＋】http://news19.2ch.net/test/read.cgi/newsplus/1153243403/

（以下参考情報）
インド人は、あんだけ人間いて夏季オリンピックで銅1個しか取れない劣等民族。
自慢の理系でも数学オリンピックは毎年中国が優勝。アメリカが2位。この2国が指定席で、インドなんてランク外。
http://ja.wikipedia.org/wiki/%E5%9B%BD%E9%9A%9B%E6%95%B0%E5%AD%A6%E3%82%AA%E3%83%AA%E3%83%B3%E3%83%94%E3%83%83%E3%82%AF
数学オリンピックの日本の輝かしい成績
1995年：1位-中国、2位-ルーマニア、3位-ロシア、4位－ベトナム、5位-ハンガリー
1996年：1位-ルーマニア、2位-アメリカ、3位-ハンガリー、4位-ロシア、5位-イギリス
1997年：1位-中国、2位-ハンガリー、3位-イラン、4位-ロシア、アメリカ
1998年：1位-イラン、2位-ブルガリア、3位-アメリカ、ハンガリー、5位-台湾
1999年：1位-中国・ロシア、3位-ベトナム、4位-ルーマニア、5位-ブルガリア
2000年：1位-中国、2位-ロシア、3位-アメリカ、4位-韓国、5位-ブルガリア、ベトナム
2001年：1位-中国、2位-アメリカ、ロシア、4位-ブルガリア、韓国
2002年：1位-中国、2位-ロシア、3位-アメリカ、4位-ブルガリア、5位-ベトナム
2003年：1位-ブルガリア、2位-中国、3位-アメリカ、4位-ベトナム、5位-ロシア
2004年：1位-中国、2位-アメリカ、3位-ロシア、4位-ベトナム、5位-ブルガリア
2005年：1位-中国、2位-アメリカ、3位-ロシア、4位-イラン、5位-韓国

なお参加資格は高校生までです。今すぐではなく次世代、次次世代に効いて来るものです。
それが教育の深さ、恐ろしさ。
0286デフォルトの名無しさん2006/07/19(水) 05:09:41
みなさんやっぱり頭がいいんですね。
0287デフォルトの名無しさん2006/07/19(水) 05:20:57
>>285
数学オリンピックでは中国とか凄いんだけどねえ。
なぜか欧米の方が偉大な数学者は多いよね。
インドだってラマヌジャンっていう大天才がいたし。

0288デフォルトの名無しさん2006/07/19(水) 10:28:12
だって数学オリンピックって数時間で処理できるような、簡単な問題を
いかに処理しきるかっていう官僚的作業だろ？
それでも俺には逆立しても解けないが。

ノーベル賞フィールズ賞取る様な何年もかけて倒す仕事とはスケールが違い過ぎるから

1kmレースを3速ギアでトップで駆け抜けたからといって
そのマシンが300kmレースを6･7速ギアでトップでゴールできるわけじゃない。
0289デフォルトの名無しさん2006/07/19(水) 10:57:38
>> 284
非素人の見解披露希望。
02902822006/07/20(木) 02:58:24
>>283
英語、苦手でして…。
単語を拾い読みしてみましたが、Haskell は研究用で Clean は実用言語という所でしょうか？

>>284
ぜひ、具体的意見をお聞かせ下さい。
0291デフォルトの名無しさん2006/07/20(木) 20:36:18
Cleanは実行速度速いよ
メモリも食わない
Haskellは遅い
0292デフォルトの名無しさん2006/07/21(金) 00:42:59
Cleanで
echo 'main = readFile "b.txt" >>= putStr . show . (\x->x*x*x) . read'> c.hs && echo 4 > b.txt && runghc.exe c.hs
これと同じことやってみ。
0293デフォルトの名無しさん2006/07/21(金) 09:36:40
>>288
は、数学オリンピックについて何も知らない。
0294デフォルトの名無しさん2006/07/21(金) 09:39:46
Microsoftが開発中の新しいシェル「Windows PowerShell」は、RC1版以前は
「Microsoft Command Shell（開発コード名：Monad）」という名称が付けられていた。
0295デフォルトの名無しさん2006/07/21(金) 09:48:28
英語が苦手だとHaskellやCleanの新しい機能をすぐに使えないので楽しさ半減だろうと思う。
nobsunみたいに和訳してくれる人は普通とても少ないし。
02962822006/07/22(土) 03:36:21
>>292
なる程、Haskell の利点としては
①スクリプト言語的な使い方ができる
②IOモナドだと簡潔に書ける
といった所でしょうか。

①の使い方は面白いかもしれませんね。

②はどうなんでしょう？
エラー処理とかを考慮したプログラムも簡潔に書けるのでしょうか？
02972822006/07/22(土) 03:38:17
>>295
今の所、基本的な事を覚えるだけで、アップアップですw
0298デフォルトの名無しさん2006/07/22(土) 05:01:32
Haskell
　関数型言語のスタンダードという役割を担うために作られた言語。
　だから、関わっている人が多いし、ライブラリも多い。

Clean
　関わっている人が少なく、ライブラリも少ない。
　異端であるがゆえに、最新の話題がCleanから出てくることはほとんどない。

という違いもある。
勉強目的ならHaskellだな。

Haskellといえばモナドだけど、Cleanでも同じようなロジックで書ける。
両者の違いは構文糖衣的な違いで、中身は似たようなもの。
Cleanで書くと、たらい回す変数を山のように書いて、文字数が2倍ぐらいになる。
Haskellはプログラムが美しい、Cleanは実行速度が速い、と言える。
0299デフォルトの名無しさん2006/07/23(日) 00:13:15
もっと最適化しろよハスクル
0300デフォルトの名無しさん2006/07/23(日) 00:15:44
カレー食いたくなった
0301デフォルトの名無しさん2006/07/23(日) 00:52:36
コンパイル時間をもっと短くしろよハスクル
0302デフォルトの名無しさん2006/07/23(日) 01:34:55
あらいぐまハスクル
03032822006/07/23(日) 02:53:12
>>298
なるほど…。
なぜ、Haskell の方が一般的なのか、解ったような気がします。
ありがとうございました。
0304デフォルトの名無しさん2006/07/30(日) 10:30:01
ヒアドキュメント無いんだったらクソ認定
0305デフォルトの名無しさん2006/07/30(日) 10:58:56
確かに欠陥だ。
次版で入らんかな。
0306デフォルトの名無しさん2006/07/31(月) 18:40:18
自己記述してるからコンパイラが低速なんだろ？
0307デフォルトの名無しさん2006/08/02(水) 17:42:50
諸君議論したまえ
0308デフォルトの名無しさん2006/08/03(木) 20:24:15
諸君怠けてはいないか？
0309デフォルトの名無しさん2006/08/04(金) 16:48:43
諸君夏休みかね
0310デフォルトの名無しさん2006/08/05(土) 13:39:27
本物のプログラマはHaskellを使う
http://itpro.nikkeibp.co.jp/article/COLUMN/20060801/244812/

記事のタイトル、センス無い
0311デフォルトの名無しさん2006/08/05(土) 15:42:44
>　最後にこの連載のタイトルの由来を紹介しておきましょう。
> 「本物のプログラマはHaskellを使う」というタイトルは
> 「本物のプログラマはFORTRANを使う」や「本物のプログラマはPascalを使わない」
> といった有名なフレーズをもじったものです。

って書いてあるじゃんか。自分が知らない読んでない理解できないからって
不当に他人を卑しめるのは止めような。
0312デフォルトの名無しさん2006/08/05(土) 16:30:56
そういうもじりが安直だって言ってんじゃないの？
0313デフォルトの名無しさん2006/08/05(土) 16:53:19
そんなに悪いとは思わないけどな…
「本物のプログラマはHaskellを使わない」のほうがしっくりくると言われればそうかもしれないが。
0314デフォルトの名無しさん2006/08/05(土) 17:45:17
「本物のプログラマはPascalを使わない」で語られる本物は、
決してHaskellなどという"軟弱な"言語なぞ使わんと思うんだが？
0315デフォルトの名無しさん2006/08/05(土) 20:09:59
310のリンク先の情報処理学会のページ、おもろいな
まだ少ししか読めてないけど
0316デフォルトの名無しさん2006/08/05(土) 20:33:27
本物のプログラマはPASCALを使わない

参考
http://ja.wikipedia.org/wiki/%E6%9C%AC%E7%89%A9%E3%81%AE%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9E%E3%83%BC%E3%81%AF%E3%83%91%E3%82%B9%E3%82%AB%E3%83%AB%E3%82%92%E4%BD%BF%E3%82%8F%E3%81%AA%E3%81%84
http://www.genpaku.org/realprogrammerj.html
0317デフォルトの名無しさん2006/08/06(日) 00:46:32
この人のサイトが痛いのは本人の趣味嗜好の問題だから放っておくとして、
一昔前のgauche-devel-jpでのshiroタンとのやりとりを見る限りコンピュータの
アーキテクチャの根本が理解できていない人としか思えなかったんだが。
まぁHaskellと戯れているうちはデータがメモリ上でどう表現されているかなんて
知らなくても生きていけるってことかな。
0318デフォルトの名無しさん2006/08/06(日) 01:08:00
ハードに近いことは良くわかってないけど何となくプログラミングできている、ってのは文系出プログラマの得意技。
0319デフォルトの名無しさん2006/08/06(日) 09:28:30
Haskellの美しさにあてられら未熟な若者だ。
優しく見守ってやれ。
0320デフォルトの名無しさん2006/08/06(日) 16:03:48
>>317
似た名前だと思っていたら、あれと同一人物なのかよ……。
0321デフォルトの名無しさん2006/08/07(月) 00:56:53
同一人物、なんだろうねぇ…。
偶然一致するようなハンドル名なのかどうか判断できないから確証はないけど。
未踏にも顔出してたと思ったけど、どんな成果だったのかな。
0322デフォルトの名無しさん2006/08/09(水) 18:27:04
何これ？ あわててブラウザを閉じたぜ。
ttp://page.freett.com/shelarcy/
0323デフォルトの名無しさん2006/08/10(木) 09:03:14
だれかヒアドキュメントの機能をcommitしてきてください。
0324デフォルトの名無しさん2006/08/10(木) 18:39:34
グラスゴウスケールって医療用語であるけど
グラスゴウハスケルと似てるね
0325デフォルトの名無しさん2006/08/11(金) 01:41:09
>>324
うわぁっ、すごぉっ、すげぇー！って、日常用語にあるけど、
グラスゴウスケールと似てるね。

0326デフォルトの名無しさん2006/08/11(金) 07:51:06
ということは
うわぁっ、すごぉっ、すげぇー！
と
グラスゴウハスケルは似てるわけか
0327デフォルトの名無しさん2006/08/16(水) 20:04:53
問１

「うわぁっ、すごぉっ、すげぇー！」を使って
長文を作りなさい
0328デフォルトの名無しさん2006/08/17(木) 05:51:34
それを見て、あるいは、変なものだ。うわぁっ、すごぉっ、すげぇー！
むやが及ん、すべてが、と思った。うわぁっ、すごぉっ、すげぇー！
不要なら、それが、それを出してきたところでもないのなのだ。うわぁっ、すごぉっ、すげぇー！
まだ比べできて、この本にもある。うわぁっ、すごぉっ、すげぇー！
すでに、人を手をするのを出している、バカな気が、この本のせいと、一歩だと思うんだ。うわぁっ、すごぉっ、すげぇー！
0001200-ROM人は、もう一つの問題になるので、ついにこれには、ホントには、下の時代にはその時のせいをつくるなものを読んでいるのも、それはそれを92020202/1創作連中所持とかの時代にもある。うわぁっ、すごぉっ、すげぇー！
あるいは物語もあった。うわぁっ、すごぉっ、すげぇー！
なお、その号のこともずっとさておきけれど、感じ。うわぁっ、すごぉっ、すげぇー！
プロットをすると、という感じ。うわぁっ、すごぉっ、すげぇー！
で、すでにシャープに、ほとんど無節操ないのかな。うわぁっ、すごぉっ、すげぇー！
短距離では、その戦時のお解釈年前の大解決冷や汗指標はほとんど開かかとかを手をもらった芸ばかり。うわぁっ、すごぉっ、すげぇー！
0329デフォルトの名無しさん2006/08/17(木) 10:12:37
ちょｗｗｗ
0330デフォルトの名無しさん2006/08/17(木) 22:03:17
>>328
日本語による近代美術だ
0331デフォルトの名無しさん2006/08/18(金) 17:06:46
解読できたらごほうびをあげるわ
■ このスレッドは過去ログ倉庫に格納されています