[#30872] segv when reentering into Fiber with callcc — sheepman <sheepman@...>

こんばんは、sheepman です。

15 messages 2007/06/01
[#30899] Re: segv when reentering into Fiber with callcc — SASADA Koichi <ko1@...> 2007/06/06

 ささだです。

[#30905] Re: segv when reentering into Fiber with callcc — "Yusuke ENDOH" <mame@...> 2007/06/06

遠藤と申します。

[#30906] Re: segv when reentering into Fiber with callcc — SASADA Koichi <ko1@...> 2007/06/06

 ささだです。

[#30929] secrand.rb — "NAKAMURA, Hiroshi" <nakahiro@...>

-----BEGIN PGP SIGNED MESSAGE-----

51 messages 2007/06/08
[#30930] Re: secrand.rb — Tanaka Akira <akr@...> 2007/06/08

In article <4669066C.2080307@sarion.co.jp>,

[#30934] Re: secrand.rb — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/06/08

-----BEGIN PGP SIGNED MESSAGE-----

[#30935] Re: secrand.rb — Tanaka Akira <akr@...> 2007/06/08

In article <46694461.4060706@sarion.co.jp>,

[#30936] Re: secrand.rb — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/06/08

-----BEGIN PGP SIGNED MESSAGE-----

[#30938] Re: secrand.rb — Tanaka Akira <akr@...> 2007/06/08

In article <46697C0B.8060402@sarion.co.jp>,

[#30939] Re: secrand.rb — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/06/08

-----BEGIN PGP SIGNED MESSAGE-----

[#30940] Re: secrand.rb — Tanaka Akira <akr@...> 2007/06/08

In article <4669DAB0.4050705@sarion.co.jp>,

[#30944] Re: secrand.rb — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/06/09

-----BEGIN PGP SIGNED MESSAGE-----

[#30945] Re: secrand.rb — Tanaka Akira <akr@...> 2007/06/09

In article <466AA73C.9030407@sarion.co.jp>,

[#30946] Re: secrand.rb — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/06/09

-----BEGIN PGP SIGNED MESSAGE-----

[#30950] Re: secrand.rb — Nobuyoshi Nakada <nobu@...> 2007/06/11

なかだです。

[#31173] Re: Random — Tanaka Akira <akr@...> 2007/07/10

In article <469253E9.9010203@sarion.co.jp>,

[#31174] Re: Random — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/07/10

-----BEGIN PGP SIGNED MESSAGE-----

[#31178] Re: Random — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/07/11

-----BEGIN PGP SIGNED MESSAGE-----

[#31179] Re: Random — Tanaka Akira <akr@...> 2007/07/11

In article <4694338C.7090303@sarion.co.jp>,

[#31183] Re: Random — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/07/11

-----BEGIN PGP SIGNED MESSAGE-----

[#30971] Linux/ia64で'ucontext_t' undeclared — akira yamada / やまだあきら <akira@...>

最近のRuby 1.9をLinux/ia64上でmakeしようとすると

16 messages 2007/06/13
[#30973] Re: Linux/ia64で'ucontext_t' undeclared — Yukihiro Matsumoto <matz@...> 2007/06/13

まつもと ゆきひろです

[#30974] Re: Linux/ia64で'ucontext_t' undeclared — akira@... 2007/06/13

Yukihiro Matsumoto さんは書きました:

[#30975] Re: Linux/ia64で'ucontext_t' undeclared — Yukihiro Matsumoto <matz@...> 2007/06/13

まつもと ゆきひろです

[ruby-dev:30884] Re: block wrapper

From: Tanaka Akira <akr@...>
Date: 2007-06-04 06:16:30 UTC
List: ruby-dev #30884
In article <E1Hv4fY-0005eN-9L@x31>,
  Yukihiro Matsumoto <matz@ruby-lang.org> writes:

> lambdaによって生成したProcの厳密化は行います。あきらめたのは、
> lambdaによって生成したとしてもyieldで呼び出したら厳密なチェッ
> クは行わないようにすることです。

なるほど。

lambda と call で扱う範囲で通常のメソッド的引数渡しのセマン
ティクスが保たれるのは、いままでまともでなかったのがまともに
なるということで、長年の問題が改善されるので嬉しいです。

その代償として、[[1,2],[3,4]].each(&lambda {|a,b| p [a,b]})
がエラーになるわけですが、Proc.new や proc は残るんでしたっ
け?

>   * lambdaでは厳密なチェック
>   * yieldはcallの別名
>
> です。今週ささだくんと直接会うのでその時いろいろ相談します。

同じなら別名はいらないんじゃないの、と私の minimalist 的側面
がささやきます。もちろん Ruby が minimalistic なデザインでは
なく、それが強い理由にならないことはわかっていますが、疑問の
きっかけにはなります。

そして、[ruby-dev:30856] にあげられている理由のうち、後者は
call でも nil.call を作ればいいので、残る理由は前者のニュア
ンスだけになります。

ニュアンスというが効果がないとはいいませんし、そういうところ
にこだわった結果が Ruby であるともいえるので反対する程ではな
いのですが、Proc#yield ってそんなにいるんですかね?

また、Proc#yield と Proc#call では call のほうが 1文字短いの
で call 側への誘導がある程度働きます。Proc#yield のニュアン
スの力がそれと拮抗していると両方から引っ張られてあまり気分が
よくならないかもしれません。

> |例えば [ruby-talk:162561] で提案し反応がなかった案をブロック
> |引数に適用すれば、(ラッパーに * じゃなくて ** を使うことにな
> |りますが) ラッパーを値の並び以外の情報をそれほど不自然でない
> |形で載せられるので呼び出し側の細工とラッパーを両立できます。
>
> あれ、私このメール見落としてました。ふーむ。

そういえば、キーワード引数の扱いは今どうなっているんですか?
-- 
[田中 哲][たなか あきら][Tanaka Akira]

In This Thread