Booについて語るスレ【CLI】
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2010/05/12(水) 11:05:35Pythonライクな静的型付け言語です。
公式
http://boo.codehaus.org/
参考
http://ja.wikipedia.org/wiki/Boo_%28%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9E%29
http://www.asahi-net.or.jp/~sy7a-ht/diary/tut_boo.html
http://www.infoq.com/jp/articles/dsl-on-the-clr
http://d.hatena.ne.jp/coma2n/20080820/1219207907
0002デフォルトの名無しさん
2010/05/12(水) 11:08:510003デフォルトの名無しさん
2010/05/12(水) 11:39:470004デフォルトの名無しさん
2010/05/12(水) 12:26:030005デフォルトの名無しさん
2010/05/12(水) 13:04:07元のpythonがきれいなので余計汚く見える。
0006デフォルトの名無しさん
2010/05/12(水) 13:49:08フレームワークやライブラリ自体は公式サポートの範囲で構築した方がいいだろうね。
0007デフォルトの名無しさん
2010/05/12(水) 19:17:25boooooooooo!!!!!!!!!!!
0008デフォルトの名無しさん
2010/05/12(水) 20:27:29boooooooooo!!!!!!!!!!! , too!!!!!!!!!!!!!!!!!!!!!!!!!!!!
0009デフォルトの名無しさん
2010/05/13(木) 02:15:44・単独ファイルでのプログラムが比較的書きやすい（Pythonとほぼ同レベル）
・List[]、Hash{}、array()のリテラルが記述しやすい
IronPythonに対する利点：
・起動・実行速度が速い（それはもう、ベンチで比べたら１０倍以上……）
・コンパイル時に単純な記述ミスを修正しやすい（静的型付け言語全体の利点）
全体的な利点：
・マクロ機能(動作確認はしたがまだ役に立ててはいない)
C#に対する欠点：
・ジェネレータの実行中にyieldで中断されず、最後まで実行されてしまう？
（for文(≒foreach）中にbreakはかけられるけど実行中の状態を保存できない？）
・Visual Studioが持つ様々な開発支援機能が受けられない
（UIデザイナー、DataSource、アプリケーション設定ファイル、etc...）
IronPythonに対する欠点：
・モジュールロード時の動的な処理などは基本的にできない
（module(namespace)の自由度はC#と同程度なのであまり期待しないこと）
・[]/{}/()の中身がジェネリック型を指定しないとみんなobjectになってしまう
・Pythonとは結局全く互換性がないのでPythonライブラリは使用できないと思え
全般的な欠点：
・記事が非常に探しにくい（Booじゃほとんど全く引っかからん）
0010デフォルトの名無しさん
2010/05/13(木) 02:17:22未だに分かってないのかと思う
0011デフォルトの名無しさん
2010/05/13(木) 17:05:22Boo!, bobobobob,, bb, boooooooooooooo!!!!!
bobobbbbbbb!!!
0012デフォルトの名無しさん
2010/05/15(土) 12:11:300013デフォルトの名無しさん
2010/05/15(土) 12:16:290014デフォルトの名無しさん
2010/05/15(土) 16:39:390015デフォルトの名無しさん
2010/05/15(土) 18:23:410016デフォルトの名無しさん
2010/05/22(土) 02:03:32C# 4.0は再頒布パッケージも小さいしね。
これだけで3.5以下の機能がどれだけ使えるのかはやや疑問だけど。
0017デフォルトの名無しさん
2010/05/22(土) 17:12:24他のCLIのコードと組み合わせられるのが最大の利点だと思う。
俺はDSLsInBooに書いてあるとおりに
C#から呼ぶスクリプト書くのに使ってみてるよ。
0018デフォルトの名無しさん
2010/05/22(土) 18:06:561.45MBと容量が小さいのがいいね。
C#だけだと動的にスクリプトを動かすということができないから、
単純に文字列で書いた計算式を計算したいといった用途でも使える。
もちろんDLR系でも同じことがいえるわけだけど、
.NET 3.5以前の環境ならランタイムが10MBコースになる。
0019デフォルトの名無しさん
2010/05/29(土) 20:00:53結局このスレにいる人たちはBooのどこに魅かれた？
自分が惹かれたのは
1. コンパイラマクロ
2. オプションとしてのダックタイピング
3. クロージャ
マクロと型推論がなければ
このタイミングでIronRubyに行ってたと思う。
0020デフォルトの名無しさん
2010/06/05(土) 22:47:32＞コンパイラマクロ
まあ便利なことは便利だが、コード量が若干節約できることで
Booとして「できることが増える」わけではないので、ちょっと微妙。
まあmatch〜case構文マクロは常用するかも。
＞ダックタイピング
全く使わん。object型を素で使うのと比べて利点は？
＞クロージャー
積極的に使っていきたいが、コンパイラが通らない構文がある。
（ハッシュの要素として定義できない）
ラムダ式的なインラインクロージャーの構文があるが、これは式しか定義できないのでちと不便。
（複数文を書くときはセミコロンで区切る）
002119
2010/06/06(日) 21:23:41＞コンパイラマクロ
新たなライブラリ作成の武器として使っていきたい（と思ってる）。
コーディング規約や設計のテンプレートを実現する形で
洗練させられれば強力な武器になると思う。
quasi quotation（[| ... |]の表記のおかげで相当敷居低いしね。
＃これ日本語訳誰か知らない？
＞ダックタイピング
俺もコンパイルするコード内で使ってみたことはない。
特に静的型付け＋型推論のあるBooでは
1. インタプリタ形式での使用
2. 実行時に生成・評価したいコードの記述（ex: AI記述、設定ファイル）。
3. アプリケーションのスクリプティング環境構築
といったところにピンポイントで使うという位置づけになると思う。
俺は3で使ってみてる。
公式にある「COM連携(duck)」「XMLパーサー, Jsonパーサー(IQuackFoo)」
Ayande氏の「Binsor」あたりのコードサンプルを
実際に見てもらった方がいいと思う。
静的型付けに慣れた人は
言語仕様ガチガチのコードを書くことにストレスを感じないようなので
言葉だけでは平行線になることが多い。
002219
2010/06/06(日) 21:24:38＞クロージャー
構文は俺も不満が多い。
#そもそもpythonのlambdaでなくrubyのblock形式というところから疑問。
＞ラムダ式的なインラインクロージャーの構文があるが、これは式しか定義できないのでちと不便。
俺は逆だなあ。複数文はdef()なりdo()なりで書ければいい。
インライン形式が簡潔でない方がはるかに不満。
具体的には型宣言とreturn文が冗長に過ぎる。
C# : x => (x + 1)
Boo : {x as int| return x + 1}
どちらが light なのかわからない。
lambda x: x + 1 みたいにしてほしい。
0023デフォルトの名無しさん
2010/06/07(月) 11:01:12＞quasi quotation（[| ... |]
macroの定義は書いてみたことあるが、そんなのもあるのか。後で調べてみる。
＞ダックタイピング
ま、COM向けだよな……。
＞2. 実行時に生成・評価したいコードの記述（ex: AI記述、設定ファイル）。
そんなものはコンパイルしてしまった方がいい。かっこ書きの中の話ね。
とはいえ、スクリプト的なものも確かにある。大規模に動かした場合はどうなるんだろうね。
以前1.5MBのスクリプトを自作のコンパイラを通してIronPythonに変換してDLLにコンパイルしたら
50MBにもなってしまって全く実用にならなかったよ。
初期化処理が重くなく、実行速度で問題なく、
使用メモリがふくれあがっても実行中に開放できるようなら問題なしだね。
＞静的型付けに慣れた人は
＞言語仕様ガチガチのコードを書くことにストレスを感じないようなので
＞言葉だけでは平行線になることが多い。
んなこたぁねえよ。PythonからBooにコードを移植したんだが、
名前付き引数やデフォルト引数がサポートしてなくて非常に難儀した。
せめてデフォルト引数くらい実装してくれよなと。
0024デフォルトの名無しさん
2010/06/07(月) 11:24:17＞俺は逆だなあ。複数文はdef()なりdo()なりで書ければいい。
書けないんだよ。Hashのインライン構文の中だと……。
＞具体的には型宣言とreturn文が冗長に過ぎる。
＞C# : x => (x + 1)
＞Boo : {x as int| return x + 1}
＞どちらが light なのかわからない。
書ける。
foo = {x as int | x + 1}
print foo(3)
=> 4
0025デフォルトの名無しさん
2010/06/07(月) 22:06:09名前を知らないだけじゃない？
macro foo(id as ReferenceExpression):
. yield [|
. class $(id)(IBar):
. pass
. |]
の[| |]部分の記法のことだよ。
本当に毎回 new ClassDefinition() とかやってるのなら
マクロを敬遠しても仕方ないが。
＞そんなものはコンパイルしてしまった方がいい。かっこ書きの中の話ね。
自分としてはスクリプト的なものの例としてあげたつもりだった。申し訳ない。
＞初期化処理が重くなく、実行速度で問題なく、
＞使用メモリがふくれあがっても実行中に開放できるようなら問題なしだね。
実行時にコンパイルするなら、Booの静的コンパイル時≒C#レベルの速度はあるはずだよね。
ベンチしたことはないが。
「DSLsInBoo」の12章はスケーリングがテーマで
まさしくStartup time と Memory について取り上げている。
内容の大半は常識的な話だが、作者は15,000個のスクリプトを相手にした経験があるらしい。
ただし。彼のメインフィールドはWeb＋DBのアプリのようだから
高度にリアルタイム性の要求されるアプリなら事前コンパイルに頼る他ないかもしれない。
0026デフォルトの名無しさん
2010/06/07(月) 22:25:57ハッシュ＋複数行クロージャーをインラインで書くことの重要性はいまだに理解できないが
仮にブレースとコロンの多義性ゆえの問題なら
言語仕様の不具合だよね。
だとしたらやっぱり、クロージャ記法をPython式にしてほしいな。
（ハッシュリテラルをruby式にする方法もあるが）
＞書ける。
returnなくてもよかったのか。知らなかった。ありがとう。
でも依然、代入先が定まっているにも関わらず型宣言はいるんだよね。
強力な型推論と簡潔な記法を謳いながら
こうした部分でC#にすら劣るというのは俺は瑕だと思う。
0027デフォルトの名無しさん
2010/06/08(火) 01:08:06CLIはモジュールのロード時に全てのクラスとメソッドの
厳密な型チェックを行うので、ロードの処理が全体的に重いんだ。
これがDLRになったら致命的。
C処理系(cpython/cruby)用の大きめなライブラリをロードすると
スタック食い尽くして落ちちゃったりすることもある。
＞ハッシュ＋複数行クロージャーをインラインで書くことの重要性
GUIのハンドラをメソッド・クロージャとして実装した上でハッシュに登録して再利用可能にする。
これを外部化（XMLファイルだったりハッシュテーブル）したデータを介してスキンと結び合わせる。
この時の照合用のハッシュとして記述している。
クロージャのインライン構文を併用するとカリー化などを使ってメソッドの数を節約できる。
0028デフォルトの名無しさん
2010/06/18(金) 13:58:20現在380kbでビルドに約4秒。
ま、IronPythonのビルドに比べたらずっと早いんだけどね。
C#に比べると遅いよなー
0029デフォルトの名無しさん
2010/06/25(金) 12:15:26どうも動的に生成されるプログラムコードを.NET Frameworkの管理上から削除する方法がなく、
事実上のメモリリークが発生するようだ。
数十回程度の呼び出しなら実用範囲内だが、
何千回も呼び出すようだとやばいっぽいね。
0030デフォルトの名無しさん
2010/08/08(日) 11:14:43俺は日常じゃC#よりも使ってるくらいなんだが（ジェネリクス以外）
Booならではってことで、前に書いたAST属性の使用例を投下してみる。
これを付けるとメンバ単位の比較とハッシュ値生成のメソッドが追加される。
※本当はIEquatable[of T]の実装もしたかったがTypeReferenceを取ってくる方法がわからなかった
[MemberwiseEquatable]
class A(IEquatable[of A]):
. _value as int
. def constructor(value as int):
. _value = value
.a1 = A(1)
.a2 = A(2)
if a1 == a2:
. print "equal"
else:
. print "not equal"
003130
2010/08/08(日) 11:16:11class MemberwiseEquatableAttribute(AbstractAstAttribute):
def Apply(target as Node):
# Cast the target to a ClassDefinition and
# start iterating over all its members.
assert target isa ClassDefinition
type as ClassDefinition = target
type.Members.Add(DefEqualsToSameType(type))
type.Members.Add(DefEqualsToObject(type))
type.Members.Add(DefGetHashCode(type))
private def DefEqualsToSameType(type as ClassDefinition) as Method:
exprs = [|self.$(x.Name) == rhs.$(x.Name)|] for x in FieldsOf(type)
foldedByAnd = Fold(BinaryOperatorType.And, BoolLiteralExpression(true), exprs)
return [|
def Equals(rhs as $(type.Name)) as bool:
return $(foldedByAnd)
|]
private def DefEqualsToObject(type as ClassDefinition):
return [|
override def Equals(obj as object) as bool:
objWithSameType = obj as $(type.Name)
if objWithSameType is not null:
return self.Equals(objWithSameType)
else:
return false
|]
003230
2010/08/08(日) 11:17:21private def DefGetHashCode(type as ClassDefinition):
exprs = [| $(x.Name).GetHashCode() |] for x in FieldsOf(type)
foldedByXor = Fold(BinaryOperatorType.ExclusiveOr, IntegerLiteralExpression(0), exprs)
return [|
override def GetHashCode() as int:
return $(foldedByXor)
|]
private static def Fold[of T(Expression), U(Expression)](op as BinaryOperatorType, initial as T, exprs as U*) as Expression:
result as Expression
result = initial
for expr in exprs:
result = BinaryExpression(op, result, expr)
return result
private static def FieldsOf(type as ClassDefinition) as Field*:
return cast(Field, x) for x in type.Members if x isa Field
0033デフォルトの名無しさん
2010/10/03(日) 11:32:02もちろん意味があるのは分かる。
0034デフォルトの名無しさん
2010/12/02(木) 06:44:50というか、６割方はそのまま移植できる。
が、４割方は違うからそこでウンウン唸ることになる。
一番違うのは名前空間とライブラリの扱い。
ここはまるっきりC#式なので。
それからlistとdictかな。要素に型がないのでひどく面倒。
0035デフォルトの名無しさん
2011/02/06(日) 19:11:23とりあえずprimerのなんちゃって翻訳・入門講座だけど
0036デフォルトの名無しさん
2011/02/06(日) 21:10:220037デフォルトの名無しさん
2011/02/07(月) 08:32:50やりたかったらやればいいんじゃないか。
どちらかというと公式ページの記事は
言語の仕様やユーリティーの一覧と
言語を使ったテクニックの記事が
ごっちゃになってて分かりにくいところが嫌だ。
0038デフォルトの名無しさん
2011/02/08(火) 16:55:11やるならWiki付きのSCM使ってください。はかどりますよ。
>>37
たしかに。
まあ、チュートリアル程度ならページ換算で100pも無いでしょうから
どんなに遅くても一ヶ月くらいで終わるんじゃないかな。
さすがに500pとか1000pになると訳すより辞書作りながら読んだほうが早いわな。
0039デフォルトの名無しさん
2011/02/08(火) 21:46:270040デフォルトの名無しさん
2011/02/08(火) 22:21:49なんと！
それはSharpDevelop再ビルドしてでも試してみないとな！
0041デフォルトの名無しさん
2011/02/09(水) 21:42:28もう開発がストップしたのかと思ってたのに。
0042デフォルトの名無しさん
2011/03/12(土) 20:39:50.940043デフォルトの名無しさん
2011/05/24(火) 22:09:59.480044デフォルトの名無しさん
2011/06/18(土) 01:42:26.05> ・記事が非常に探しにくい（Booじゃほとんど全く引っかからん）
"Boo" "cli"
"Boo" "mono"
で検索したら結構引っかかる
0045天使 ◆uL5esZLBSE
2011/07/02(土) 18:45:05.00ゴミ量産機
0046天使 ◆uL5esZLBSE
2011/07/03(日) 22:57:39.70そんな事いってもゴミはゴミなのにね
0047デフォルトの名無しさん
2011/07/05(火) 18:17:28.360048デフォルトの名無しさん
2011/07/05(火) 18:36:37.24数年前から使ってるから最新版に更新できなくて困ってるけど、
今からやるならBooの最新版＋.NET4.0でレガシー環境気にせずにつくるのがおすすめ。
0049デフォルトの名無しさん
2011/10/22(土) 20:46:26.63公式ではJS,C#,Booと書いてあった
0050デフォルトの名無しさん
2012/02/19(日) 12:58:31.65http://toro.2ch.net/test/read.cgi/tech/1329023778/
0051デフォルトの名無しさん
2012/06/13(水) 20:04:23.88■ このスレッドは過去ログ倉庫に格納されています