Lisp Scheme Part40 [転載禁止]©2ch.net
レス数が900を超えています。1000を超えると表示できなくなるよ。
スマリヤンって関西っぽい響きがあるよね。
スマリやん？ｗｗｗ >>839
あれはチューリングマシンじゃなくてコンビネータ >>840
ああっ昔駄洒落自動生成機を作ろうとした黒歴史を思い出した すまん。初心者です。教えてください。
仮に学校の比較？などを扱うプログラムを作ろうとしていて、schoolという1つの学校の情報をまとめたクラスを作るとします。
そのクラスの中に、以下のような学生の情報をまとめたテーブルの情報をぶち込みたいとして、どのようにこれらのテーブルをschoolクラス内に保存するのがいいですか。
名前 整理番号 性別 2ちゃんねら 馬鹿 橋本環奈好き 年齢
taro 0 #\M t t nil 16
hanako 1 #\F nil t t 16
nagisa 2 #\L nil nil t 18
hoge
piyo
foobar
...
学校によって人数は若干違いますが、基本的にテーブルの大きさはそれほど大きくないとします。
それぞれの要素を頻繁に検索・参照する必要があります。
僕が思いつくのは、
・schoolのstudentsというスロットに、1人のデータの1つのリスト・構造体・クラスにして、そのリストとして保存。
・ハッシュテーブルをつかって、下記のような形で保存。
2CHP ((NAGISA NIL) (HANAKO NIL) (TARO T))
BAKAP ((NAGISA T) (HANAKO T) (TARO T))
ぐらいなのですが、このうちどれがおすすめとか、これら以外にもっと便利な方法などありましたら教えてください。
よろしくお願いいたします。 作ったハッシュテーブルをschoolのstudentsスロットにぶち込むと言うことです。
あと、nagisaさんは馬鹿ではありません。失礼しました。
こーいうクラスとかの設計の基本と言うか定石ってどうやって勉強したらええの？ 何が良くて何が悪いかなんてやってみなきゃわからんよ。
まず動くものを作ってから出来が悪いと思ったところを直していったらいい。
LISP の良さってそういうとこだろ。 studentクラスの定義がまず先かな
あとstudentsはキーを何にするかが問題
多分名前なんだろうけど、他の項目でも取り出したいときはハッシュテーブルだと面倒だから単に配列でも良いと思うがな >>843
そもそもクラスは初心者向きじゃないし
Lispのような関数型言語では無理に使わなくても別にいい
多用したいならオブジェクト指向言語を使えばいい オブジェクトシステムを積極的に使うべきかどうかは確かに場合によるし使わなくても割といけるが、
関数型とオブジェクト指向は直行する概念で、関数型であるからオブジェクトシステムの価値が低いというわけじゃない。 CLOSは初心者に分かりにくい
Lisp自体もそうだけどさらに分かりにくい CLOSみたいなんじゃなくてもっと言語仕様に密着したオブジェクトシステムがあればと思う
例えばコンスセルはcarとcdrをメンバーに持つクラスみたいな
Gaucheってそうなってんだっけ？ オブジェクト志向うんぬんの空気読まずにカキコ
>>844
>こーいうクラスとかの設計の基本と言うか定石ってどうやって勉強したらええの？
LISPというよりも、どちらかというとデータベース設計が主題になるね
もし手早くSchemeで小規模なデータベースを実装したいのであれば、
SLIBと呼ばれるよく知られたライブラリに含まれている
データベースを使うのが最短だと思う
・The SLIB Portable Scheme Library
http://people.csail.mit.edu/jaffer/SLIB
日本語では、以下の書籍で文献データベースを主題として丁寧に解説されている
・入門Scheme
- Schcme入門からXツールキットを使ったリレーショナルデータベースプログラムまで
https://www.amazon.co.jp/dp/4879669547
もしLISP(による実装)を離れて一般的なデータベース設計そのものを勉強するなら、
たとえば定番の入門書(教科書)である以下の書籍の前半を読む
・リレーショナルデータベース入門―データモデル・SQL・管理システム・NoSQL
https://www.amazon.co.jp/dp/4781913903
もしLISPプログラミングに自信があり、その上で広義のデータベースとして
「LISPによる知識表現プログラミング」を習得したいのなら、
遠回りになるけどSICP本の「４.4章 論理プログラミング」への挑戦を勧める
>>849
どうだろうなぁ。 初心者っていうか人によるんじゃね。
俺は JavaScript のプロトタイプベースのクソさに辟易した (実利があるのはわかってはいる) けど、
Gauche の (CLOS 風の) オブジェクトシステムにはそんなに忌避感ないし。 みなさん、アドバイス・参考書の紹介などありがとうございます。
いろいろ自分で試してみて、どれがいいか決めようと思います。
とりあえずの方針としては、school-baseみたいなクラスの下に、studentsクラスを作って
そこにテーブル属性ごとにスロットを作って、alist形式でぶち込むことにしました。
キーの設定やら検索の便宜やら考えた結果、alistが一番手軽そうだと言うことで。
BAKAP ((taro.t) (hanako) (nagisa.t) ... )
みたいな感じで。学生を単位にデータを作ると扱いづらそうなので。 オブジェクト指向的には
学生ごとにインスタンスを生成して
各属性はインスタンスのスロットに入れるのが自然な実装だろう
属性が動的に変わるなら
そこをalist/plistにするか
プロトタイプ思考のOOPSを使うといい 本屋に行ったらLittle Proverの和訳が出ててびっくりした またkaizenさんが和歌でレビュー書いてるのかと思った 教えてください。
cxmlで150mbぐらいのファイルをparseしようとしたら、
メモリのリミット来てるでーって怒られてダメでした。
巨大ファイルの扱い方教えてください。 saxとかklacksってのを使えば良いのか。
どうやっても空白を拾ってしまう。何でだ。
いろいろ頭痛い。 >>856
これか。字が小さいんだよなぁ。
ttps://www.amazon.co.jp/dp/4908686025 >>860
空白はそのままに認識するのが XML の規約じゃなかったっけ。
空白を除去したいかどうかはアプリケーション側の裁量。
よく使われるライブラリなら何かオプションを持ってたりすることはあるかもしれんけど。 これがLispだ！は教科書っぽくていいな
これと実践あたりを順を追って読んでみようと思う
それからSICPにいこうかな
竹内初めてのとかLand of Lispみたいなノリの本こそLispらしいのだろうが、ついていけないと嫌いになる^^;
LittleはCPSからいきなり難しくなるし、その前も背景知識ないと消化不足になる
Yコンビネータも一応流れはつかめても、自分みたいな頭良くない初学者にはあの試行錯誤から何かを掴むのは難しい
Lispは表面的な軽さと話してることが乖離している書籍が多いし、独学者にはキツイ
これらが、同時並行的にあーなるほど、となると悟ったという事になるのかな？ >>863
＞LittleはCPSからいきなり難しくなるし、その前も背景知識ないと消化不足になる
おっと、いつのまにか little schemer の読み込みが途絶えてしまっていた、今日から馬力をかけて、ぜひ読みきろう！ CPSも紙に書いてトレースすることはできるんだけど
見た目が難しいのにご利益があまり感じられないのは俺の頭が悪いからかな？ >>865
Scheme の意味論的には重要なのは確か。
そういう理屈はどうでもいいやってのなら知らなくてもいいかもしれぬ。 >>866
それはどうしたら学べますか？
プログラム意味論とか読めばいいの？ >>867
うーん、俺も理屈をきちんと学んだわけじゃなくて CPS 変換を通して理解したんだけど、
CPS 変換しても何もつかめなかったのならどうすればいいんだろう……。
CPS は継続の理解の助けになるんだよ。
入門書で CPS 変換を取り上げるのは継続を理解させるため。
CPS 変換すること自体が普段のプログラミングですごく役に立つってわけではない。
継続ってのは call/cc で取り出せるやつってだけじゃなくて、
Scheme のプログラムでは常に背後にある。
Scheme に限らずどんな言語にも、 C にだってある。
call/cc は背後にあるのを表に引きずり出す仕組みなんだ。
だから背後でやってるやつを明示的にやったらどないや？ っていうのが CPS なの。
そんだけ。 CPS変換はCLとかelispでジェネレータの実装に使われてるよね >>868
> CPS は継続の理解の助けになるんだよ。
その通り
> CPS 変換すること自体が普段のプログラミングですごく役に立つってわけではない。
まあ普通のプログラミングではCPS変換なんて必要ないわな
> 継続ってのは call/cc で取り出せるやつってだけじゃなくて、
> Scheme のプログラムでは常に背後にある。
> Scheme に限らずどんな言語にも、 C にだってある。
上の３行はもちろん間違っていないんだけれども補足しておくと、
Cなどの通常のgoto文（やCのbreak文等のような制限されたgoto文）とか例外処理を有する命令型プログラミング言語の意味論（正確には表示的意味論）を語る上でこそ継続が不可欠になる
Schemeからcall/ccを除けば（call/ccやそれを含むライブラリ手続きの類を一切使わない範囲でしかSchemeを利用しない人は）継続を使わない意味論で考えても何も問題ない
例えば、命令型言語でも制御構文としてif文とwhile文しかない（goto文やbreak文等のジャンプは含まない）言語…しばしば「While言語」とか呼んで手続き型言語の表示的意味論の
説明用としてに最初に取り上げられるミニチュア言語（一応、万能ね）…の意味を与えるだけなら継続は必要ない
そういう単純な（いわゆる「構造的」な）制御フローしか許さない言語では、個々の文（命令）の意味は状態から状態への写像（つまり文の表すものは一つの状態変換関数）として考えれば済む
goto文や例外処理のような構文に関して制御の流れが（文の構文構造について）構造帰納的でなくなる制御フローを生み出してしまうものを含んだ言語の意味論を考えようとすると継続が不可欠になる
もはや、個々の文を状態変換関数（そして個々の式を状態の集合から値の集合への一つの関数）として考えるような直感的に分かり易い意味の与え方は通用しない
表示的意味論の生みの親のStracheyが、compositionalつまり大雑把には構造帰納的に意味を与える表示的意味論において構造帰納的でない制御フローを生み出すgoto文の意味を
如何に与えるかで悩んだ末に発明した概念こそが正に継続なんだ
（因みに日本語の表示的意味論の教科書でやや古いものは“continuation”の訳語として「継続」でなく「接続」という言葉を使っている場合があるが両者は全く同じ） 何時からこんな長文のレスが出来るようになったのかと >>865
簡単なスタックマシンにコンパイルしてみてはどうか? >>872
継続がない言語からね
CSPありとなしで比較して CPSは必ずしも再帰で使う必要はないということでいいのかな
リトルのCPSが消化不良なのは前の章までの理解が足りてないってことか 再帰の際に、例えば階乗計算で終端条件から戻ってきて
1*2*3*.......*(n-2)*(n-1)*nと掛けられるものも継続ですか？ >>877
再帰はなくても
関数からのreturn実行が
継続の適用そのものです C ではアドレスが継続だと思えばだいたい合ってる。
環境が保存されないから Scheme より限定的だけども。
C だと実引数と一緒にリターンアドレスもプッシュするじゃん？
それと同じように Scheme でも戻ってくる継続を暗黙に渡してるんだよ。
Scheme の call/cc は gcc 拡張の __builtin_return_address みたいなもん。 >>877はあってますか？
終端から戻ってきた値が、入れ子の外側、つまり継続に渡されて
さらに外側の継続に渡されて
継続がなくなったら値がプリントされる
というイメージなんだけど Cで継続を保存しようとしたら、setjmpで保存してるもの(全レジスタの状態)とスタックの内容のコピーだろ(場合によってはかなりのサイズになるが) >>884
setjmp/longjmp は、スタックポインタは保存してもスタックの内容のコピーはしない、だからネストの浅いところから深いところにジャンプできない >>885
ん？だからsetjmpの内容とスタックの内容をコピーすると思いっきり書いたつもりだったが… C++ coroutinesだとスタック全コピーも実装の有力な候補だな というか、おととし最後に聞いたときには>>884の言う通りでほぼ決まりみたいな話だった
C/C++では何と、スタックの中を書き換えることができるのだ！ Smalltalkならスタックフレームもオブジェクト Smalltalkって業務で使ってるとこあるのかな
LISP系よりはありそうなんだが ヨーロッパや南米での事例が多いとか
https://medium.com/@newapplesho/今時-2017-のsmalltalkの始めかた-93c044820e1b
日本にも地味に仕事あるらしいけど守秘義務で見えにくい
スーパーの古いレジ（POSシステム）で使われているのを見かけたのはNEC系のこれか？
http://tech.nikkeibp.co.jp/it/members/NT/JIREI/20011220/1/
比較的最近の話題はLispばりにスタートアップに活用されたこと
http://web.archive.org/web/20171111102557/https://thepedia.co/article/1068/ >>890
> Smalltalkって業務で使ってるとこあるのかな
> LISP系よりはありそうなんだが
少なくともアメリカでは実アプリをSmalltalkで作ってるケースはほとんどないんじゃないと思うが
プロトタイプをSmalltalkでちゃっちゃと作ってしまい動作確認をするってのはアメリカでも昔からさほど珍しくないそうだが
ちなみにCommon Lispはアメリカでは以前から実用アプリの記述言語としてそれなりの頻度で使われてるよ >>893
Scheme 用語で言う「環境」のことな。
それを含まないから限定的と説明しているわけ。 >>894
Cではと限定してんだから、普通にsetjmpと言ってほしいんだが…
IP(インストラクションポインタ)だけを指して限定的な継続言われても逆に分かりにくいと思うが 環境をあえて使わない継続の応用はあっても
環境を含むことができない機構を（「限定的」と断ったとしても）継続だと言い張るのはオカシイよ 別に「限定継続/delimited continuation」ってものもあるしな
話がややこしくなるだけで理解の助けにならない Racket で escape continuation って言ってるやつと近いかな。 schemeをjsに変換してreactやるとかelectronでGUIアプリ作るとかいう話ない？ scheme->jsの変換は簡単そうだね
継続使ってなければ そもそもJSにトランスパイルできる
まともなscheme処理系が無いだろう 実践Common Lispで覚えた
formatも同じく ocamlでさえjavascriptにコンパイル出来るというのにschemeも頑張ろうや Scheme -> Clojure -> javascript の順番に変換するなら、
Clojure -> javascript はすでに自動変換だし、
Scheme -> Clojure も define -> def 等、機械的な置き換えである程度出来るから、
単純なプログラムを変換することは出来るけど、それほど需要がないから無いんじゃないの。 つうかemscriptenで幾つかの実装が動いてるよね
ただそれだけで emscripten で C言語 -> javascript に変換が可能だから、Chicken で Scheme -> C言語 に変換すれば、
Scheme -> C言語 -> javascript が実行できるハズか。うまく通らないコードもあるだろうけど。 >>908
そんなチキンなやり方が許されるとでも？ >>908 ＞Chicken
>>909 ＞チキン
日本語でおｋ ところで「ブラウザでCLを動的にJSにトランスパイル可能なライブラリ」って聞いたら何が思い浮かびます？ 質問です！
動的スコープってスタックに積み上げるだけで実現できるじゃないですか
静的スコープってどうやって実装すればいいんですか？ヒント下さい コンパイル (意味解析) 時にスタックを使えばいいんじゃないのかな。 >>917
なるほど、意味解析時にスコープの構造をスタックで再現しといて
eval時に該当するスタックを参照できればいいってことですよね。
なんだか、ソースマップみたいですね。ひとつひとつのAtomに該当するスコープの参照を持たせるとなると、なんか重くなりそうですね Have you ever read The Little Schemer? => #t
Have you ever read The Seasoned Schemer? => #t
Have you ever read The Reasoned Schemer? => #t
Have you ever read The Little Prover? => #t
Have you ever read The Little Typer? => #f
What's The Little Typer? => Pie language book. David Thrane Christiansen のやっている Idris や Pie language といえば、
依存型 (dependent type) を使用した Type-Driven Development かな。
定理証明系の次の話題としては順当なところ。 依存型についてのテキストはこれまでにこういうのが出てるよ。
Edwin Brady "Type-Driven Development with Idris"
Adam Chlipala "Certified Programming with Dependent Types"
Aaron Stump "Verified Functional Programming in Agda"
Edwin Brady と David Thrane Christiansen は協力して Idris を作ったひとで、
今回、Christiansen が Racket 上で Pie language を実装したみたい。
Pie languageの実装を理解させる本が出ることで Type-Driven Development の
低レベルでの詳細が明快になると期待できる感じかな。 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
VU7Z1 ちょっと聞きたいんですけど
JSONをS式で書いたらどんな書き方になると思いますか？
(users . (
((Name . John)
(Age . 25))
((Name . Mike)
(Age . 24))
))
みたいな感じですか？ 素直に連想配列にした方が良いのか、それだと巨大なデータの時にアクセス効率が悪いからハッシュテーブルやdefstructした方が良いのかとか、一筋縄では行かないだろう Expat みたいな方式で、オブジェクトの構築はユーザまかせにするってのもひとつの案かな。
まあ、 JSON が必要な場面は設定ファイルとかウェブ API の類とかだと思うので、
極端に巨大な JSON を仮定する必要はあまりないと思うが……。 JSONをS式で書くといっても、いろいろやり方はあるよね。
Pie language みたいにDSLを使って、Name型、Age型、users型を定義すれば、
型推論、Type-Driven Development を導入できる。 PIE には、元々「インド・ヨーロッパ祖語」(Proto-Indo-European language) という意味があるらしい。
そこから転じて Type-Driven Development の祖語たれかし云々。
Pie言語のような Type-Driven Development と J-Bob(ACL2) の定理証明器の組み合わせによって、
新しいプログラミング・サイクルがもたらされる。
[1] 型を定義する（自動的に型チェックもされる）だけで、
[2] Type-Driven Development 環境が型定義から実行可能なプログラムの雛形を生成してくれる。
[3] プログラムの雛形に実装部分を書き加える。
[4] 書き加えた実装部分の数学的正しさを定理証明器でチェックする。
こんな感じで開発するだけでプログラムの正しさが保証付きで出来上がる。もちろんOOPでもOK。
将来、ほとんどの言語がこういう機能を持つと思われる。 荒っぽく言うと、英文作成時にtypo checkerとgrammar checkerを併用すると、
正しい英文が簡単に書けてしまう。そのプログラミング言語版みたいなものかと。 既存の XML や Json のデータからスキーマを構築するやつはどっかで見たことある。 >>934
JSONスキーマつかってvalidationするやり方は、テスト駆動開発だからミスリード。 初心者なんだけど、qiitaでlispの勉強ブログやるのどう思う？
ブログとか自分の趣味ではないんだけど、勉強はかどるかと思って。 >>936
いいと思うよ。
ただ、 Qiita はブログホスティングサービスではなく、
「知識を共有する」ということをコンセプトにしたサイトだから、
やったことを箇条書きにするだけとかコードが貼っているだけみたいなのではなく、
自分に続く人に参考になるような書き方を心がけてね。 数行のコードをコンパイルしてみた
chickenでとても小さいバイナリが生成されて満足したあと
Racketが生成するバイナリの大きさに驚いた
そしてSBCLでやってみたらさらに5倍以上も大きくてビックリだわ
それぞれに理由があるのは分かるけど 実行ファイルのサイズがでかくても役に立つアプリだったらいいんじゃないの
役に立たないアプリだからサイズが小さくないとまずいって話かな レス数が900を超えています。1000を超えると表示できなくなるよ。
