演算子の優先順位

今更綺麗にひっかかったけど、Erlangは演算子の優先順位が他と違う。
例えばPython、

>>> 1 << 2 & 4
4

あるいはRuby、

irb(main):001:0> 1<<2 & 4
=> 4

またはC、

% cat op.c
#include <stdio.h>

int main(){
  printf("%d\n",1<<2&4);
}
% gcc op.c
% ./a.out
4

これらの（メジャーと思われる）言語では、&の結合度が<<より低いため、

(1<<2) & 4
↓
4 & 4
↓
4

と解釈される。
それに対してErlangでは、band、andはビットシフトより優先されるので、

1> 1 bsl 2 band 4.
1

つまり、

1 bsl (2 band 4)
↓
1 bsl 0
↓
1

と解釈されているらしい。

他にも、

>>> True or False == False
True

のようなPythonの式を、Erlangで同じように書くと、

> true or false == false.
false

結果が違う。
これも、論理演算子（※andalsoとorelseは除く）の結合度が比較演算子のそれより高く、

(true or false) == false
↓
true == false
↓
false

と解釈されるために起こるようだ。

結局のところ「括弧で範囲を明示するのは（特にErlangでは）大事」という話なんだけど、Erlangの他からの乖離は面白い。
何か深い意味があるんだろうか・・・

R13B03

またリリースに気がついてなかった…
毎度ながら面倒なのでMacPorts待ち。

goo.glをいじってみる

日記書くネタもないし、なんか面白そうだったので、http:request/4の練習をかねて。
最初のうちは元ソースを読んでましたが、最終的にPython版の丸写し。*1
色々*2酷い事になっていますが、気にしてはいけません。

使い方：

1> c(googl).
{ok,googl}
2> inets:start().
ok
3> googl:get_short_url("http://d.hatena.ne.jp/zubenalt/").
"http://goo.gl/SsZe"
4> 

書いてる現在、ちゃんと動いてる・・・はず。

以下はソース。

*1:id:LaclefYoshiさんありがとうございます、というか勝手に使ってすみませんm(__)m

*2:urlencode/2が勘だったり、http:request/4の引数が適当だったり

というわけで、gccを無理矢理ビルド（しようとして失敗）

色々弄ってみたが、結局のところgcc-coreのビルド中にldがrelocation overflowを5,000個ほど吐いて死ぬ。
一応同じような環境で成功した例があるんだけど、コンパイラが違うからかなぁ…appleのgccが使えるかを確かめてみるべきか…。
と思って検索かけたらなんか色々見つけた。
一部関係あるのか微妙な気もするが、最後のgmane.comp.lang.ada.macosxの投稿とはエラーメッセージがほとんど同じなので多分同じ問題だろう。
で、debain-gccのスレッドによると「ldが古くてダメだから、binutils 2.20のにしてね（はぁと」という事らしい。
でも（当然というか）ELFの話っぽいし、OSXのldはAppleのだから関係ない気もするんだけど…
…とりあえず眠くて読み込めないので明日考えよう。

というか報告した人はどうやってビルド成功したんだろう…

Tagged recordのメンバにUnbounded_Wide_Wide_Stringを含めるとコンパイルできない

~/ada% cat test.adb
with Ada.Strings.Wide_Wide_Unbounded;
procedure Test is
   type Test_Type is tagged record
      A:Ada.Strings.Wide_Wide_Unbounded.Unbounded_Wide_Wide_String;
   end record;
begin
   null;
end Test;
~/ada% gnatmake test.adb
gcc -c test.adb
test.adb:3:09: run-time configuration error
gnatmake: "test.adb" compilation error
~/ada% 

Unbounded_Wide_String、Unbounded_Stringでは通る一方、Unbounded_Wide_Wide_Stringだけは通らない。
コンパイラにオプション渡さなきゃいけないのか、GNATが古いからか、Mac自体が古いからか…
恐らくメモリまわりだろうと想像*1はできるけど、全く理解していないのでよく分からない。
いずれにしても、対応しないと先に進めない…

*1:というか妄想

Parameterized Module

いいかげんに同じことを公式で検索かけるのも嫌なので。結局日記を検索することになる気もするけど
e.g.:

-module(pm_ex, [X,Y]).
-compile(export_all).

foo(Bar)->
    Bar*Y+X.

使い方は、

1> c("pm_ex.erl").
2> M=pm_ex:new(2,3).
{pm_ex,2,3}
3> M:foo(4).
14

2の結果を見ても分かるとおり、pm_ex:new(X,Y)={pm_ex,X,Y}なので、

4> M2={pm_ex,3,4}.
{pm_ex,3,4}
5> M2:foo(5).
23
6> {pm_ex,2,3}:foo(4).
14

なんてことができたり。
まぁ今後も使えるのかは知りませんが。

R13B01に違和感を覚える

と思ったら、なんの事はない、今までだったら"R13B-1"だったのが、"R13B01"になってるからだった。
これ、メンテリリースが10越えたら、例えば"R13B13"になるのかな？
やっぱりハイフンあった方がいいんじゃないだろうか…。