Shiro:log:2005後半

Shiro:log:2005後半


(2005/12/31 18:15:39 PST)

最近、故あって「1バイトの整数を読み、そこに示された数だけ4バイトの符号無し整数を読む」 みたいなバイナリデータを扱っているのだが、SRFI:42のeager comprehensionが 思いのほか便利。

(let* ((count (read-binary-uint8 input))
       (data  (list-ec (: n count) (read-binary-uint16 input 'big-endian))))
  ...)

(2005/12/31 12:20:46 PST)

年の瀬である。ハワイでは年に2度しかない花火解禁日のひとつであるため、 これがチャンスとばかりに人々は街が煙ですっかり覆われるまで火薬を燃やし続けるのだ。 この国にはほどほどに楽しむというたしなみはあまり無い。

去年まではまあ我慢してれば良かったのだが、今年はらむ太が居る。 寝てれば音で起きるし、起きてればびっくりして泣くし、どうやって魔の数時間を 生き延びるかが本年の課題である (許可されているのは大晦日の21時から新年の1時まで、 ただ実際は夕方から2時くらいまでやってる)。 つうかこの事態は予想できたんだからさっさと静かなホテルでも取って避難する ことを考えていればよかったんだが、例によってぼさっとしてたら、もう大晦日である。 うーん、徹夜覚悟でドライブだろうか…

(2005/12/24 18:36:31 PST)

るびま0012号で、 えとさんがhtmlを配列を使ったツリーで扱うわびさび方式 について書いているのだが、その欠点として「(文字列操作に比べて)遅くなる」 というのを挙げている。なぜだろう。

基本的にわびさび方式はSXMLなんかと同じなわけだが、SXMLで扱う場合、 データ構造の製作中はツリー同士の結合がツリーの大きさに係わらず O(1)でできるわけで、ナイーブな文字列連結のコストに対して非常に大きな ゲインだ。それに比べたら出力時の木のトラバースなんて問題にならない ように思える。なので遅くなる理由が思い付かない。

非常に単純なケースで、 バッファリング無し、フォーマッティング無しで文字列の断片を出力してく だけの処理ならツリーで扱うよりは速いだろうけれど。 エラー時の処理とか考えたら文字列で扱う場合でもどうしても一回は バッファリングが必要になると思うしなあ。

もちろん文字列の実装がスマートで内部的にツリーを使ってるなら 話は別だが。

(2005/12/08 15:55:16 PST)

Paul GrahamのY Combinatorが出資した Reddit。最初はCommon Lispで書かれていたが、 つい最近Pythonで書き直された。 作者はLispに好意的ながらも、 スイッチの理由をいくつか述べている。 当然、Lisp界では議論。 ついに「へへん、俺なんかLispでクローンを1時間で書いちゃったぜ」なんてのも。

Lispの宣伝になるサイトが減るのは残念だけれど、個人的にはPythonで動くのなら それでいいんじゃないかって思う。この件や"Ruby is acceptable Lisp" の 記事でもって、Lisp界にも簡単なフレームワークとかproduction provenな ライブラリとかもっと大きなコミュニティとか必要じゃね? という話はあって それはそれで結構なのだけれど、もし他の言語で同じ位快適に同じ位良いソフトが書けるなら Lispが別言語に置き換わっても人類全体として損はしてないよな。

本当にLispの力が必要になるアプリは、逆にうんとハイエンドであったり、 開発リソースなどの他の条件が厳しい領域だろう。80年代のハードウェア で3DCGアニメーションを作る(Lisp:Geometry)とか、あるいはもっと些細な例だけれど 限られた期間でがりがりチューンしてく場合とか (Seminar:CommonLisp:2004の「ACL7.0の新しい正規表現」補足)。 そういう領域は決して大きくはならないけれど、無くなることもない。

そこにLispのエッジがあるのなら、たとえニッチであってもそのフロンティアを 広げて行くことを怠っちゃまずいだろうと思う。他の「人気の言語」と同じことを 後追いでやるのは、意味がなくはないけれど、それだけじゃねえ。

(2005/12/06 03:51:32 PST)

Binary 2.0、 ネタをここまで昇華するノリが素晴らしい。 行きたかったなあ。

感想を見ていると、軽量言語とは対極にある世界だ、というような言及が ちらほらあった。確かに高レベル言語の重要な機能の一つはプログラマが低レベルな 世界を気にしないで済むようにすることだけれど、二つの世界は表と裏、葉っぱと根っ子、 あるいは舞台と舞台裏。客として眺めるだけなら表を見ていればいいけれど、 この世界でプログラミングを生業とするなら両者は切っても切れない関係にあるはず。 何故なら、裏を知らないとトラブルに対応できないから。

だいたい、抽象度の高い、ハイレベルなものごとというのは泥くさい現実の ある面を特定の切り口で簡略化することで成り立っている。 (そもそも、デジタル回路からしてアナログな世界を閾値でえいやと 2分することで動いてるわけだし。) その際に、簡略化が成り立つ前提ってのが必ずある。システムが 正常動作してる間はそういう前提を余裕でクリアしているんだけれど、 システムがリミットぎりぎりまで使い込まれて、 マージンが無くなった時が問題だ。 トラブルとは、抽象化の壁のほつれである。 抽象化されたハイレベルな世界でいくら強固なロジックを組み立てても、 根元がぐらついたらそのロジックはぺしゃんこだ。 それを建て直すには、少なくともほつれた抽象化の壁の一つ向こうの 世界を知ってないとどうにもならない。

もう一つ、軽量言語と低レベルな世界をスペクトルの両端に置くのに 違和感があるのは、Lispでは両者はそんなに離れていないからかも。 inner loopを最適化する時は普通にdisassembleするし (そもそもdisassembleが言語仕様に含まれている)。

(2005/12/04 01:29:22 PST)

やっぱRailsの影響ってでかいのね。

(2005/11/27 01:44:51 PST)

昨日、「降りてきてしまうもの」に対して「ヴィジョン」という言葉を使ったが、 完成形が一瞬でひらめく、というようなものだけを念頭に置いていたわけではない。 むしろ、何だかわからないもやもやしたものが来て、とにかくそれを形に しないことには居られない、というようなものを考えていた。

産みの苦しみはこっち持ち、なんである。そんな苦しいことは避けられたら 避けたいんである。でも、産まないでいる方がもっと苦しいから、仕方ないんである。 ただどっちも苦しいから、降りて来たものに気づかないふりをして 誤魔化すという誘惑もある。緩慢な精神的死を迎えるとしても、 人間、楽はしたい。 金銭的な報酬とか、功名心とか、嫉妬とかは、そういう怠惰を抜け出して 苦しみに直面するために使える便利な道具である。

金銭や名誉や嫉妬が直接の動機なのか、それとも代替物なのかは、 ちょっとした想像をしてみればわかる。金銭を求めていると思っている人は、 もし一生好きなことをして暮らせるだけの金が入ったとしたら、 周囲からの賞賛を求めていると思っている人は、無人島に一人だけで流れついたとしたら、 嫉妬に駆り立てられていると思っている人は、妬ましいその人と自分の立場が入れ替わったと したら。それでも今苦しみつつやってることをやっぱりやるだろうと思えたら、 きっと何かもっと大きなものに動かされているのだ。 (もっとも、想像するだけじゃなく本当にそうなってみないとわからないこと、 ってのはあるかもしれない。)

(2005/11/25 21:56:29 PST)

k16's note 2005/11/14

信じられないモチベーションといったら、ショスタコービッチもそうだ。 党から創作活動を制限されていたジダーノフ批判以降の約4年間、 ひたすら机の引き出しの肥やしにするために、24のプレリュードとフーガ、 弦楽四重奏第4〜5番、バイオリン協奏曲第1番といった超傑作をこっそり作り続けてたんだから。 [...] 発表することはもちろん、作っていることさえ禁じられている状況なわけで、 「オレを認めて欲しい」という欲求が一切介入しないところで高度な創作活動を続けていたところがすごい。

本当のところがどうだったかは知らないけれど、私はこのエピソードを聞いて、むしろ 「そんな状況であっても、創作を続けずにはいられなかった」と感じる。

ある種の才能は、祝福であると同時に呪いでもある。 Stephen Kingがどっかで「書かずにはいられないから書く」とか 「書かないとおかしくなってしまう」とか言ってたような気がするが、 まさにそうなのだと思う。ヴィジョンがつぎつぎに降りてきて、 創れ創れとけしかける。語弊はあるかもしれないが、 どんどん形にしてゆかないと精神的糞詰まりを起こして (精神的に)生きてゆけなくなるのではないか。 Kingは「ミューズが頭上で下痢している」(嘔吐だったかも)という 表現もどこかで書いてた気がする。 ブレヒトの「ガリレイの生涯」の14幕のガリレイも似たような境遇だ。 教会に蟄居を命じられ、細々と書き綴る"Discorsi"は書く端から 教会に取り上げられる。それでも書かずにはおれない。 それを発表して名をあげたいとか科学に貢献したいとかいう次元を離れているのだ。

困ったことに、この種のヴィジョンを得てしまう能力と、 それを形にする能力は必ずしも一致しない。しばしば両者はともに「才能」と 呼ばれて混同されるが、本来は直交する能力である。 ヴィジョンがあふれてもそれを形にするスキルが ついていかないとおかしくなる。一方、スキルがあって器用に 求められるものを形に出来るが、自分の本当に創りたいものが何か わからずに空虚な思いを抱いている人もいるだろう。 (前者は"gift"、後者は"talent" に該当するのではないか、と ふと思ったが、ちょっと調べた限りではそういったconnotationに 触れられている辞書は見当たらなかった)。

才能は獲得されるものか備わっているものかという論争はあるが、 少なくとも後者の(形にする)才能は獲得されるものだと思う。 才能があり、素晴らしい創作活動を続けている人は両方を最初から 備えていたかのように見えるかもしれない。しかしそれはむしろ、 内なるヴィジョンに子供の頃から気づいていた結果として、 自分が生きのびるために死に物狂いでスキルを獲得したのだと 言えはしないか。たとえ本人は死に物狂いだと思っていなくても、 それは生存のための無意識の行動だったのではないか。

このへんの、才能の残酷さを見事に描いているのが David Morrellの短篇 "Orange Is for Anguish, Blue for Insanity" だ。 (邦訳は「オレンジは苦悩、ブルーは狂気」---アンソロジー「ナイトフライヤー」収録)。 普通の超常現象を扱うホラーとして読んでも面白いが、 もしこれが創作の本質だと考えると、恐ろしい。

(2005/11/23 02:42:18 PST)

ねるWiki:NelDiary:2005-11-23経由で経県値。 結構行き残しているところがあるなあ。

泊りの多くは自転車のキャンプ旅行によるもの。 全県走破する前に日本を出てしまった。もうチャンスは無いだろうなあ。

(2005/11/15 12:02:39 PST)

Uuutokudaの日記2005-11-15より:

やっぱり人のコーディングスタイルとかを見るのは勉強になる。 [...] で、そこで皆さんのコードをみてみたいのである。 [...] で、あんまり複雑なのは面倒なので非常に簡単な問題。

二つのツリー(もしくはリスト)が等価であるかどうかを判定するプログラムを示せ。
(深さ優先探索したときの各葉の要素の並びが2つのツリーで等価ってこと)

たとえば、(1 (2 3) (4)) と(1 (2 (3 (4))))は等価である。

この方はさらっと書かれているが、これはsamefringe problemと呼ばれる なかなかに興味深い問題である。ナイーブな解は、ツリーの全ての要素を列挙した リスト(flattenしたもの、と言ってもよい)を作ってそれらを比べるというものだが、 もしツリーが巨大なものであり、しかもそれらが異なっていた場合、 flattenの作業の大部分が無駄になってしまう。

ところが必要最低限の空間複雑度で計算しようとすると、 「同型でないデータ構造を再帰する」というちょっと厄介な問題を解かねばならない。 コルーチンで解く方法もあるが、遅延ストリームを使うと再帰の部分が ジェネレータに隠されてわりと素直に書ける。

(use util.stream)

(define (samefringe? t1 t2)
  (define (make-gen tree)
    (stream-delay
     (cond ((null? tree) stream-null)
           ((pair? tree)
            (stream-append (make-gen (car tree)) (make-gen (cdr tree))))

           (else (stream tree)))))
  (let loop ((s1 (make-gen t1))
             (s2 (make-gen t2)))
    (or (and (stream-null? s1) (stream-null? s2))
        (and (stream-pair? s1) (stream-pair? s2)
             (equal? (stream-car s1) (stream-car s2))
             (loop (stream-cdr s1) (stream-cdr s2))))))

streamに隠された継続を陽に扱って継続渡し形式にしても良いが、 あまりわかりやすくはない。

(define (samefringe? t1 t2)
  (define (traverse g1 g2)
    (g1 (lambda (e1 end1? rest1)
          (g2 (lambda (e2 end2? rest2)
                (or (and end1? end2?)
                    (and (equal? e1 e2) (traverse rest1 rest2))))))))
  (define (end c) (c #f #t #f))
  (define (genfringe tree c rest)
    (cond ((null? tree) (rest c))
          ((pair? tree)
           (genfringe (car tree) c
                      (lambda (c) (genfringe (cdr tree) c rest))))
          (else (c tree #f rest))))
  (traverse (lambda (c) (genfringe t1 c end))
            (lambda (c) (genfringe t2 c end))))

コルーチンによるもの、継続渡しによるもの、遅延ストリームによるものは どれも本質的に同型の解になり、木の深さDに対して最悪O(D)の空間を必要とする。

(なお、良く見るsamefringe problemではコンスセルを2分木として扱う、つまり fringe (1 (2 3) 4) => (1 2 3 () 4 ()) とみなすことが多いが、 ここでは元の問題に合わせた。)

Haskellならもともとlazyだからこれでいいのかな。

data Tree a = Leaf a | Branch [Tree a]

fringe :: Tree a -> [a]
fringe (Leaf x)   = [x]
fringe (Branch x) = foldr (\x r -> fringe x ++ r) [] x

samefringe :: Eq a => Tree a -> Tree a -> Bool
samefringe x y = fringe x == fringe y

参考: Henry Baker, Iterators: Signs of Weakness in Object-Oriented Languages, ACM OOPS Messenger 4, 3 (July 1993), 18-25. http://home.pipeline.com/~hbaker1/Iterator.html

(2005/11/11 23:03:26 PST)

またc.l.sネタだが。Original Posterのちょっとしたミススペリングが ジョークツリーに発展中。

http://groups.google.com/group/comp.lang.scheme/browse_frm/thread/1af2cb0cf7adc026

(2005/11/09 21:20:25 PST) Sassy

From c.l.s

Sassy is a 32-bit x86 assembler written in Scheme, based on Henry Baker's COMFY65 Compiler.

Sassy supports the full x86 instruction set (SSE and all that), and comes with an output module for targeting ELF (we got GOT) and an API to write your own output modules.

http://home.earthlink.net/~krautj/sassy/sassy.html

アセンブラソースはS式。埋め込みScheme式があるので、 マクロアセンブラのマクロをSchemeで書けることになる。 遊びがいのありそうなソフトだ。 Gaucheでも走るらしい。

(2005/11/01 18:16:09 PST)

昨日の続き。

  1. 途中経過のdumpからGC_written_bitsが上書きされている、と思ったのは誤認であった。 テストルーチンは問題が出る前にforkしており、先にdumpが出る子プロセスの方では GC_written_bitsが正しく設定されており、後にdumpが出てた親プロセスの方で GC_written_bitsが'0'のままであった。
  2. Solarisでは、dirty bitsを読むのにprocfsを使ってる。GC初期化時に自分のプロセスIDの ファイルをオープンして、ioctl(PIOCOPENPD)でpage data fileのディスクリプタを 得て保存。その後、GCがキックされる度に(GC_initiate_gc)そこからdirty bitsの 情報をread(2)する。read(2)の度にdirty bits情報はクリアされる。
  3. 仮説。page data file descriptorが親子で共有されるということは、 もしかして片方でread(2)するとそれがもう片方に影響を与えたりしない?
  4. もひとつ。page data file descriptorは /proc/<親のprocess-id> をopenした プロセスファイルから得たものなんだが、そのまま子がそれを参照してて 子自身のpage dirty bitsが取れるんだろうか。
  5. sunのサイトにもforkが絡んだ場合のpage data fileの説明が見当たらないし、 とりあえずこのへんの疑問点をgc-listに投げてみた。

Gauche的には、今回の問題だけに関してはforkの前に強制的にgcを呼ぶようにすれば 回避できるな…

(2005/11/01 05:02:11 PST)

う〜。0.8.6リリース寸前にもたついている。

どうもメモリ絡みのやばいバグが潜んでる模様。 さんのレポートするMacOS X最新版での不具合もひょっとすると同根かも。 これまでの経過。

  1. こっちでテストできるプラットフォームのほとんどでテストは通ってるのだけれど、 SolarisでのテストがAssertion failedで落ちることが発覚。
  2. dlopenされるモジュール中のScmIdentifierであるべきオブジェクトが 全然違うオブジェクトに化けているので、gc絡みだろう
  3. root setの登録ミスをまず疑うが、値をダンプしたりScm_GCSentinelを 使ったりして調べてみると、 「root setとして登録されているアドレス範囲から参照されているにも かかわらず、GCされている」ことが発覚。gcのバグを疑い、gc/ 以下に突入。
  4. mark_rts.c, mark.c, os_dep.c と読んで、「root setに登録されているが、 ページに一度もdirty bitが立ったことがないことになっているのでmarkされていない」 ことが発覚。dirty bitはOSから得ているのに、おかしいぞ? OSのバグの可能性は低い…
  5. 「一度でもdirty bitが立ったことがある」ページはGC_written_pagesで 管理されている。このビットマップは、一度 '1' になったら決して '0' になることは ない。ところが、問題のページに該当するビットを追っていると、最初はちゃんと '1' になっているのに途中から '0' になっていることが判明。あれれ。
  6. 念のためビットマップのバックアップをstaticに確保しといて 比較するプローブを組み込んだら、今度はテストが通る。→ちうことは、 GaucheのどっかのコードがGCのデータ領域に間違って書き込んでるっちゅうことじゃん!

さすがにこの爆弾を抱えたまま出すわけにいかないので、引続き調査中。

(2005/10/05 23:50:58 PDT)

正規表現/\w/にマッチする文字の並びを得る方法

Rubyだと色々やり方があるみたい。Gaucheでは

(use srfi-14) (char-set->string #[\w])

(2005/10/04 19:23:49 PDT)

AutodeskがAliasを買収

これでMayaでMELの代わりにLispが使えるようになることは…無いだろうなぁ。

(2005/10/04 04:17:11 PDT)

毎年恒例(?)、Franz社の2日間にわたるLispセミナーが今年も開催されるそうです。

「2日間みっちり! Lispチュートリアル&Lispセミナー&Lisp事例紹介」

去年はAllegro Common Lisp 7.0の正規表現ライブラリについて 発表させてもらったんですが、今年は残念ながら行けません。 1日目のJansによる「Lispゲームプログラミング」が気になるなあ。

(2005/09/30 01:58:39 PDT)

最上の日々 9/28より:

1、関数型プログラミングは、たまたま並列性を最大に記述する方法でもある。それを利用すれば並列性の抽出は容易だ。

2、関数型のプログラムの構文木を直接実行するプロセッサがあるといい。でもそこまで行かなくとも二股同時実行コール命令を追加するだけでも効果がある。

2.について。面倒なのは呼び出しより帰って来た後の同期だから、 「二股同時コール」はそこまで含めてのことだろう。 ただ、プロセッサレベルでは非同期呼び出し命令と同期命令に分かれてた 方が使いでがあるし、そうなるんじゃないかと思う。(言語レベルでの並列 呼び出しをコンパイラが非同期呼び出し+同期命令に展開すればいい)

例えばPS2ではコードとデータを用意してDMAをキックすることでVUが (CPUと並行して)計算を進めてくれる。結果を受け取るには 確かVUから割り込みもかけられたと思うが、コンソールゲームでは 計算時間の予測がたてやすい場合も多くて、CPU側である程度他の計算を 進めてからポーリングして同期していた。

ハードウェアでマルチコアに複数のスレッドを振ってくれるような機構が 出来たなら、非同期呼び出し命令も同期命令もスレッド操作のプリミティブ として処理されることになるかな。

1.について。副作用無しの関数型プログラミングは、 それだけでは並列性の記述には不十分だ。

「AかつB」「AまたはB」というパターンには、AとBを独立して評価できる場合と Bの評価可能性がAの評価結果に依存する場合がある。 後者の例は(and (char? x) (char=? x #?a))。 逐次プログラミングでは両者の区別は不要だが、並列プログラミングでは 区別してもらわないと、前者でAとBを並列に評価する機会を失う。

これはかなり本質的な違いで、「『AまたはB』でAかBの いずれかが停止しなくても、もう一方が停止すれば答えが出る」 というセマンティクスは並行演算を前提としないと実現できない。

これらの演算は実用的には非常に重要だ。並列演算を適用したい大きな データセットを扱う問題であっても、得たい答えは入力の データセットより遥かに小さい場合が多い。 ということは多くの問題で、どこかでたくさん並列に流れてた データの流れがぐっとしぼられる点が必ず一つ以上あるということだ。 例えば「たくさんのものの中から(どれでも良いから)ひとつ条件を満たすものを選ぶ」 という操作は頻出するけれど、関数的な素直な記述:

(define (find pred set)
  (cond ((pred (car set)) (car set))
        (else  (find pred (cdr set)))))

からは並列性は抽出できない。

並列に条件判断を走らせて、どれかひとつが帰って来た時点でそれを採用し 他は捨てる、ということになれば、走っている並列演算をキャンセルする機構も 組み込みで必要になる。

(2005/09/27 05:32:48 PDT)

こちらでの演技中に、「せりふのテンポが遅い」というダメを出されることが良くあった。 自分で丁度良いペースだと感じるテンポはネイティブにとって遅いらしい。 意識して速めてOKをもらっても、気持ち的に急いでるみたいでどうも落ち着かなかった。

多分口が遅いんだろうと思い、一人で運転している時は いつもラジオを聴きながらシャドウイングに挑戦しているが、なかなか ついてゆくのは難しい。NPRのAll Things Consideredとか音楽番組など かなり聴き取り易いものでも、音に気をつけて発音しようとするとどんどん 遅れる。ついてゆこうとすると発音がでたらめになる。 ましてや地元の放送やCMは絶望的。

ふと、フレージングの問題なんではないかと気がついた。「塊」として とらえる単位が小さすぎるんではないかと。つまり、「塊」、として、 とらえる、単位が、小さすぎる、んでは、ないかと、という、具合に、認知して、 発音、してるから、どうしても、テンポが、悪くなる。 cold readingでも、ワンセンテンス全部覚えて目を離すことがなかなか出来ず 細切れになりがちだし。

フレーズを覚える位まで繰り返す練習をするのが良いのかもしれん。

(2005/08/30 05:11:37 PDT) Gaucheの起源

某所でGaucheの名前の起源について質問という程じゃないけれど 話題になっていたので、一応記しておく。いくつかの要因がたまたま 重なってついた名前にすぎず、そんなにおおげさな起源があるわけではない。

(2005/08/29 03:15:36 PDT)

天泣記2005/08/29:

ふと思ったのだが、event driven と thread の表現能力がだいたい同じだとすれば、 全部 thread なスタイルでやる GUI ライブラリというのもあり得るのだろうか。

いかにもErlangあたりがやってそう、と思ってぐぐってみた。 http://www.erlang.se/workshop/2004/ex11.pdf とか。 各ウィジェットがプロセスになっててメッセージパッシングで処理してる ように見える。

ただスタイルとしては各プロセスをオブジェクトとみなしてもあんまり変わらん ような気も。receiveで待たずにbusy loopするとか、本格的にコンカレントに 動いてるプロセスがあると差が出てくるのかも知れないけど、 触ったことがないのでよくわからない。

(2005/08/22 04:49:02 PDT)

若い女の娘を chick というのは現代の俗語かと思っていたら、 さっき読んでたシェークスピアに同じ意味で出てきたんでちょっとびっくりした。 Longmanで引くと確かに old-fashioned slang と書いてある。oldすぎる。

(2005/07/26 14:57:57 PDT)

http://reddit.com/ : Paul Grahamらの投資プログラムの支援を受けた サイトのひとつ。リンクを投稿して読者によるランキングが出来るってことかな? Apache + mod_lisp で動かしてるようだ。

(2005/07/15 11:55:20 PDT) RとL

Rの発音の前に「ウ」をつけるという のは、Rがシラブルの頭、とくに語頭にある場合はわりと有効だと思うが、 難しいのはRがそれ以外の位置にある場合である。

今読んでるStephen Kingの "The Dark Tower VI: Song of Susannah" では、 日本人観光客が Yooo take-ah pickcha, preese? Take pickcha me and my fliend? とか Solly とか喋っている。

Acting Classで注意された発音に、語尾のrがある。year, there, far, fur, cure などの 「母音+R」だ。特に文中でストレスのない場合なんか、つい曖昧に、母音をちょっと 長く発音するくらいで済ませてしまいがちなんだけど、ここに「R」があるかないかは ネイティブにとってはかなり違って聞こえるらしい。 「毎日、"ar, er, ir, or, ur" って練習するといいよ」といわれた。

なお、ハワイのピジン英語では語尾のrが落ちることが多いようで、 わざとrを落としてピジンらしさを出すことはある。 "You and me wen dea, you rememba, ya?" とか。


Last modified : 2006/01/11 07:15:58 UTC