Booについて語るスレ【CLI】

1 ：10/05/12 〜 最終レス ：11/10/22

Booは.NET Framework/Mono上で動作する
Pythonライクな静的型付け言語です。
公式
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

2 ：

http://blog-imgs-40.fc2.com/t/s/u/tsuba3555/41gsqAdAmmL.jpg

3 ：

http://blog.livedoor.jp/boo_takagi/

4 ：

名前がダサいので日本では流行らない

5 ：

下手に拡張すると汚くなる。
元のpythonがきれいなので余計汚く見える。

6 ：

まあ、マクロ機能による構文の拡張は自前のニーズにとどめておいて、
フレームワークやライブラリ自体は公式サポートの範囲で構築した方がいいだろうね。

7 ：

>>1
boooooooooo!!!!!!!!!!!

8 ：

>>1
boooooooooo!!!!!!!!!!! , too!!!!!!!!!!!!!!!!!!!!!!!!!!!!

9 ：

C#に対する利点：
・単独ファイルでのプログラムが比較的書きやすい（Pythonとほぼ同レベル）
・List[]、Hash{}、array()のリテラルが記述しやすい
IronPythonに対する利点：
・起動・実行速度が速い（それはもう、ベンチで比べたら１０倍以上……）
・コンパイル時に単純な記述ミスを修正しやすい（静的型付け言語全体の利点）
全体的な利点：
・マクロ機能(動作確認はしたがまだ役に立ててはいない)
C#に対する欠点：
・ジェネレータの実行中にyieldで中断されず、最後まで実行されてしまう？
　（for文(≒foreach）中にbreakはかけられるけど実行中の状態を保存できない？）
・Visual Studioが持つ様々な開発支援機能が受けられない
　（UIデザイナー、DataSource、アプリケーション設定ファイル、etc...）
IronPythonに対する欠点：
・モジュールロード時の動的な処理などは基本的にできない
　（module(namespace)の自由度はC#と同程度なのであまり期待しないこと）
・[]/{}/()の中身がジェネリック型を指定しないとみんなobjectになってしまう
・Pythonとは結局全く互換性がないのでPythonライブラリは使用できないと思え
全般的な欠点：
・記事が非常に探しにくい（Booじゃほとんど全く引っかからん）

10 ：

名前は検索性を前提にすべきだってことを
未だに分かってないのかと思う

11 ：

＞＞１０
Boo!, bobobobob,, bb, boooooooooooooo!!!!!
bobobbbbbbb!!!

12 ：

豚言語

13 ：

もしかして>>9だけで終了かこのスレｗ

14 ：

F#と比べてほしかったな

15 ：

C# 4.0の登場でBooの特徴も無意味になった。

16 ：

>>15
C# 4.0は再頒布パッケージも小さいしね。
これだけで3.5以下の機能がどれだけ使えるのかはやや疑問だけど。

17 ：

単体で頑張るというよりは
他のCLIのコードと組み合わせられるのが最大の利点だと思う。
俺はDSLsInBooに書いてあるとおりに
C#から呼ぶスクリプト書くのに使ってみてるよ。

18 ：

地味にコンパイラ、インタプリタ、標準ライブラリ全込みで
1.45MBと容量が小さいのがいいね。
C#だけだと動的にスクリプトを動かすということができないから、
単純に文字列で書いた計算式を計算したいといった用途でも使える。
もちろんDLR系でも同じことがいえるわけだけど、
.NET 3.5以前の環境ならランタイムが10MBコースになる。

19 ：

週1ペースが確定してきたな。
結局このスレにいる人たちはBooのどこに魅かれた？
自分が惹かれたのは
1. コンパイラマクロ
2. オプションとしてのダックタイピング
3. クロージャ
マクロと型推論がなければ
このタイミングでIronRubyに行ってたと思う。

20 ：

>>19
＞コンパイラマクロ
まあ便利なことは便利だが、コード量が若干節約できることで
Booとして「できることが増える」わけではないので、ちょっと微妙。
まあmatch〜case構文マクロは常用するかも。
＞ダックタイピング
全く使わん。object型を素で使うのと比べて利点は？
＞クロージャー
積極的に使っていきたいが、コンパイラが通らない構文がある。
（ハッシュの要素として定義できない）
ラムダ式的なインラインクロージャーの構文があるが、これは式しか定義できないのでちと不便。
（複数文を書くときはセミコロンで区切る）

21 ：

>20
＞コンパイラマクロ
新たなライブラリ作成の武器として使っていきたい（と思ってる）。
コーディング規約や設計のテンプレートを実現する形で
洗練させられれば強力な武器になると思う。
quasi quotation（[| ... |]の表記のおかげで相当敷居低いしね。
＃これ日本語訳誰か知らない？
＞ダックタイピング
俺もコンパイルするコード内で使ってみたことはない。
特に静的型付け＋型推論のあるBooでは
1. インタプリタ形式での使用
2. 実行時に生成・評価したいコードの記述（ex: AI記述、設定ファイル）。
3. アプリケーションのスクリプティング環境構築
といったところにピンポイントで使うという位置づけになると思う。
俺は3で使ってみてる。
公式にある「COM連携(duck)」「XMLパーサー, Jsonパーサー(IQuackFoo)」
Ayande氏の「Binsor」あたりのコードサンプルを
実際に見てもらった方がいいと思う。
静的型付けに慣れた人は
言語仕様ガチガチのコードを書くことにストレスを感じないようなので
言葉だけでは平行線になることが多い。

22 ：

長いので分割。スマン。
＞クロージャー
構文は俺も不満が多い。
#そもそもpythonのlambdaでなくrubyのblock形式というところから疑問。
＞ラムダ式的なインラインクロージャーの構文があるが、これは式しか定義できないのでちと不便。
俺は逆だなあ。複数文はdef()なりdo()なりで書ければいい。
インライン形式が簡潔でない方がはるかに不満。
具体的には型宣言とreturn文が冗長に過ぎる。
C# : x => (x + 1)
Boo : {x as int| return x + 1}
どちらが light なのかわからない。
lambda x: x + 1 みたいにしてほしい。

23 ：

>19
＞quasi quotation（[| ... |]
macroの定義は書いてみたことあるが、そんなのもあるのか。後で調べてみる。
＞ダックタイピング
ま、COM向けだよな……。
＞2. 実行時に生成・評価したいコードの記述（ex: AI記述、設定ファイル）。
そんなものはコンパイルしてしまった方がいい。かっこ書きの中の話ね。
とはいえ、スクリプト的なものも確かにある。大規模に動かした場合はどうなるんだろうね。
以前1.5MBのスクリプトを自作のコンパイラを通してIronPythonに変換してDLLにコンパイルしたら
50MBにもなってしまって全く実用にならなかったよ。
初期化処理が重くなく、実行速度で問題なく、
使用メモリがふくれあがっても実行中に開放できるようなら問題なしだね。
＞静的型付けに慣れた人は
＞言語仕様ガチガチのコードを書くことにストレスを感じないようなので
＞言葉だけでは平行線になることが多い。
んなこたぁねえよ。PythonからBooにコードを移植したんだが、
名前付き引数やデフォルト引数がサポートしてなくて非常に難儀した。
せめてデフォルト引数くらい実装してくれよなと。

24 ：

>>20
＞俺は逆だなあ。複数文は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

25 ：

＞quasi quotation
名前を知らないだけじゃない？
macro foo(id as ReferenceExpression):
. yield [|
. class $(id)(IBar):
. pass
. |]
の[| |]部分の記法のことだよ。
本当に毎回 new ClassDefinition() とかやってるのなら
マクロを敬遠しても仕方ないが。
＞そんなものはコンパイルしてしまった方がいい。かっこ書きの中の話ね。
自分としてはスクリプト的なものの例としてあげたつもりだった。申し訳ない。
＞初期化処理が重くなく、実行速度で問題なく、
＞使用メモリがふくれあがっても実行中に開放できるようなら問題なしだね。
実行時にコンパイルするなら、Booの静的コンパイル時≒C#レベルの速度はあるはずだよね。
ベンチしたことはないが。
「DSLsInBoo」の12章はスケーリングがテーマで
まさしくStartup time と Memory について取り上げている。
内容の大半は常識的な話だが、作者は15,000個のスクリプトを相手にした経験があるらしい。
ただし。彼のメインフィールドはWeb＋DBのアプリのようだから
高度にリアルタイム性の要求されるアプリなら事前コンパイルに頼る他ないかもしれない。

26 ：

＞書けないんだよ。Hashのインライン構文の中だと……。
ハッシュ＋複数行クロージャーをインラインで書くことの重要性はいまだに理解できないが
仮にブレースとコロンの多義性ゆえの問題なら
言語仕様の不具合だよね。
だとしたらやっぱり、クロージャ記法をPython式にしてほしいな。
（ハッシュリテラルをruby式にする方法もあるが）
＞書ける。
returnなくてもよかったのか。知らなかった。ありがとう。
でも依然、代入先が定まっているにも関わらず型宣言はいるんだよね。
強力な型推論と簡潔な記法を謳いながら
こうした部分でC#にすら劣るというのは俺は瑕だと思う。

27 ：

＞実行時にコンパイルするなら、Booの静的コンパイル時≒C#レベルの速度はあるはずだよね。
CLIはモジュールのロード時に全てのクラスとメソッドの
厳密な型チェックを行うので、ロードの処理が全体的に重いんだ。
これがDLRになったら致命的。
C処理系(cpython/cruby)用の大きめなライブラリをロードすると
スタック食い尽くして落ちちゃったりすることもある。
＞ハッシュ＋複数行クロージャーをインラインで書くことの重要性
GUIのハンドラをメソッド・クロージャとして実装した上でハッシュに登録して再利用可能にする。
これを外部化（XMLファイルだったりハッシュテーブル）したデータを介してスキンと結び合わせる。
この時の照合用のハッシュとして記述している。
クロージャのインライン構文を併用するとカリー化などを使ってメソッドの数を節約できる。

28 ：

プログラムがでかくなってきたらだんだんビルドが遅くなってきた。
現在380kbでビルドに約4秒。
ま、IronPythonのビルドに比べたらずっと早いんだけどね。
C#に比べると遅いよなー

29 ：

BooのInteractiveInterpreterだが、
どうも動的に生成されるプログラムコードを.NET Frameworkの管理上から削除する方法がなく、
事実上のメモリリークが発生するようだ。
数十回程度の呼び出しなら実用範囲内だが、
何千回も呼び出すようだとやばいっぽいね。

30 ：

1ヶ月以上レスなしか……。
俺は日常じゃ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"

31 ：

前半。インデント消えたらすまない。
class 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
|]

32 ：

後半。やっぱり消えたOTL。

private 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

33 ：

Pythonに似ていて違うのが紛らわしいんだよな。
もちろん意味があるのは分かる。

34 ：

>>33
というか、６割方はそのまま移植できる。
が、４割方は違うからそこでウンウン唸ることになる。
一番違うのは名前空間とライブラリの扱い。
ここはまるっきりC#式なので。
それからlistとdictかな。要素に型がないのでひどく面倒。

35 ：

booのwiki作ろうとおもったけどいい？
とりあえずprimerのなんちゃって翻訳・入門講座だけど

36 ：

Wiki作るのに誰かの許可取る必要があるのか？

37 ：

特に訳す必要があるとは思えないが、
やりたかったらやればいいんじゃないか。
どちらかというと公式ページの記事は
言語の仕様やユーリティーの一覧と
言語を使ったテクニックの記事が
ごっちゃになってて分かりにくいところが嫌だ。

38 ：

>>35
やるならWiki付きのSCM使ってください。はかどりますよ。
>>37
たしかに。
まあ、チュートリアル程度ならページ換算で100pも無いでしょうから
どんなに遅くても一ヶ月くらいで終わるんじゃないかな。
さすがに500pとか1000pになると訳すより辞書作りながら読んだほうが早いわな。

39 ：

Boo 0.9.4でコンパイル時間が1/4になったそうじやないか

40 ：

>>39
なんと！
それはSharpDevelop再ビルドしてでも試してみないとな！

41 ：

お、なんか凄い久しぶりにバージョンアップしてるじゃん。
もう開発がストップしたのかと思ってたのに。

42 ：

age

43 ：

age

44 ：

>>9
> ・記事が非常に探しにくい（Booじゃほとんど全く引っかからん）
"Boo" "cli"
"Boo" "mono"
で検索したら結構引っかかる

45 ：

ゴミ量産機

46 ：

はい次
そんな事いってもゴミはゴミなのにね

47 ：

IronPythonがもっさりすぎて話にならないから使ってみたがなかなかよさそうだな

48 ：

>>47
数年前から使ってるから最新版に更新できなくて困ってるけど、
今からやるならBooの最新版＋.NET4.0でレガシー環境気にせずにつくるのがおすすめ。

49 ：11/10/22

Unity3Dでもサポートあるのか
公式ではJS,C#,Booと書いてあった