From f7ae224f3e2530bb4b05166b6013f8a42432086e Mon Sep 17 00:00:00 2001 From: nsfisis Date: Mon, 20 Mar 2023 22:03:50 +0900 Subject: feat(nuldoc): rename simpara to para See also: https://tdg.docbook.org/tdg/sdocbook/5.1/para.html --- .../cpp-you-can-use-keywords-in-attributes.xml | 68 +++++------ .../2021-10-02/python-unbound-local-error.xml | 36 +++--- .../ruby-detect-running-implementation.xml | 44 ++++---- .../2021-10-02/ruby-then-keyword-and-case-in.xml | 80 ++++++------- .../rust-where-are-primitive-types-from.xml | 84 +++++++------- ...ce-between-autocmd-bufwrite-and-bufwritepre.xml | 68 +++++------ .../vim-swap-order-of-selected-lines.xml | 124 ++++++++++----------- 7 files changed, 252 insertions(+), 252 deletions(-) (limited to 'content/posts/2021-10-02') diff --git a/content/posts/2021-10-02/cpp-you-can-use-keywords-in-attributes.xml b/content/posts/2021-10-02/cpp-you-can-use-keywords-in-attributes.xml index 7f5fc66..3dbb8ff 100644 --- a/content/posts/2021-10-02/cpp-you-can-use-keywords-in-attributes.xml +++ b/content/posts/2021-10-02/cpp-you-can-use-keywords-in-attributes.xml @@ -16,16 +16,16 @@ - + この記事は Qiita から移植してきたものです。 元 URL: https://qiita.com/nsfisis/items/94090937bcf860cfa93b - - + +
- - + + タイトル落ち。まずはこのコードを見て欲しい。 - + @@ -50,24 +50,24 @@ ]]>
- + コンパイラのバージョン $ clang++ –version Apple clang version 11.0.0 (clang-1100.0.33.8) Target: x86_64-apple-darwin19.6.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin - - + + コンパイルコマンド (C17指定) $ clang –std=c++17 hoge.cpp - +
- + この記事から得られるものはこれ以上ないので以下は蛇足になる。 - - + + 別件で cppreference.com の identifier のページ を読んでいた時、次の文が目に止まった。 - +
@@ -81,53 +81,53 @@
- + キーワードでも属性として指定する場合は非キーワードとして使えるらしい。 実際にやってみる。 - - + + 同サイトの keywords のページ から一覧を拝借し、上のコードが出来上がった (C++17 においてキーワードでないものなど、一部省いている)。 大量の警告 (unknown attribute `〇〇' ignored) がコンパイラから出力されるが、コンパイルできる。 - - + + 上のコードでは [[using]] をコメントアウトしているが、これは using キーワードのみ属性構文の中で意味を持つからであり、このコメントアウトを外すとコンパイルに失敗する。 - + - + C++17 の仕様も見てみる (正確には標準化前のドラフト)。 - - + + 引用元: https://timsong-cpp.github.io/cppwp/n4659/dcl.attr#grammar-4 - +
- + If a keyword or an alternative token that satisfies the syntactic requirements of an identifier is contained in an attribute-token, it is considered an identifier. - +
- + 「identifier の構文上の要件を満たすキーワードまたは代替トークンが attribute-token に含まれている場合、identifier とみなされる」とある。どうやら間違いないようだ。 - - + + ところで、代替トークン (alternative token) とは and (&) や bitor (|) などのことだが、identifier の構文上の要件を満たさないような代替トークンなどあるのか？ 疑問に思って調べたところ、代替トークンという語にはダイグラフも含まれるらしい (参考: 同ドラフト) - + <% → { %> → } @@ -136,11 +136,11 @@ %: → # %:%: → ## - + 「identifier の構文上の要件を満たさないような代替トークン」はこれらが当てはまると思われる。 - - + + 調べた感想: 字句解析器か構文解析器が辛そう - + diff --git a/content/posts/2021-10-02/python-unbound-local-error.xml b/content/posts/2021-10-02/python-unbound-local-error.xml index 7cf9b1a..bb44a47 100644 --- a/content/posts/2021-10-02/python-unbound-local-error.xml +++ b/content/posts/2021-10-02/python-unbound-local-error.xml @@ -16,19 +16,19 @@ - + この記事は Qiita から移植してきたものです。 元 URL: https://qiita.com/nsfisis/items/5d733703afcb35bbf399 - - + +
- - + + 本記事は Python 3.7.6 の動作結果を元にして書かれている。 - - + + Python でクロージャを作ろうと、次のようなコードを書いた。 - + - + 関数 g から 関数 f のスコープ内で定義された変数 x を参照し、それに 1 を足そうとしている。 これを実行すると x += 1 の箇所でエラーが発生する。 - +
- + UnboundLocalError: local variable `x' referenced before assignment - +
- + local変数 x が代入前に参照された、とある。これは、f の x を参照するのではなく、新しく別の変数を g 内に作ってしまっているため。 前述のコードを宣言と代入を便宜上分けて書き直すと次のようになる。var を変数宣言のための構文として擬似的に利用している。 - + - + 当初の意図を表現するには、次のように書けばよい。 - + - + (*) のように、nonlocal を追加する。これにより一つ外側のスコープ (g の一つ外側 = f) で定義されている x を探しに行くようになる。 - + diff --git a/content/posts/2021-10-02/ruby-detect-running-implementation.xml b/content/posts/2021-10-02/ruby-detect-running-implementation.xml index 18548c2..9b59202 100644 --- a/content/posts/2021-10-02/ruby-detect-running-implementation.xml +++ b/content/posts/2021-10-02/ruby-detect-running-implementation.xml @@ -15,29 +15,29 @@ - + この記事は Qiita から移植してきたものです。 元 URL: https://qiita.com/nsfisis/items/74d7ffeeebc51b20d791 - - + +
- - + + Ruby という言語には複数の実装があるが、それらをスクリプト上からどのようにして programmatically に見分ければよいだろうか。 - - + + Object クラスに定義されている RUBY_ENGINE という定数がこの用途に使える。 - - + + 参考: Object::RUBY_ENGINE - - + + 上記ページの例から引用する: - + - + それぞれの処理系がどのような値を返すかだが、stack overflow に良い質問と回答があった。 - - + + What values for RUBY_ENGINE correspond to which Ruby implementations? より引用: - +
@@ -100,20 +100,20 @@
- + なお、この質問・回答は 2014年になされたものであり、値は変わっている可能性がある。MRI (aka CRuby) については執筆時現在 (2020/12/8) も 'ruby' が返ってくることを確認済み。 - - + + この表にない主要な処理系として、https://mruby.org[mruby] は 'mruby' を返す。 - - + + mruby 該当部分のソース より引用: - + - + この記事は Qiita から移植してきたものです。 元 URL: https://qiita.com/nsfisis/items/787a8cf888a304497223 - - + +
- +
TL; DR - + case - in によるパターンマッチング構文でも、case - when と同じように then が使える (場合によっては使う必要がある)。 - +
<literal>then</literal> とは - + 使われることは稀だが、Ruby では then がキーワードになっている。次のように使う: - + - + このキーワードが現れうる場所はいくつかあり、if、unless、rescue、case 構文がそれに当たる。 上記のように、何か条件を書いた後 then を置き、式がそこで終了していることを示すマーカーとして機能する。 - +
なぜ普段は書かなくてもよいのか - + 普通 Ruby のコードで then を書くことはない。なぜか。次のコードを実行してみるとわかる。 - + - + 次のような構文エラーが出力される。 - + - + 二つ目のメッセージは無視して一つ目を読むと、then か ; か改行が来るはずのところ変数だかメソッドだかが現れたことによりエラーとなっているようだ。 - - + + ポイントは改行が then (や ;) の代わりとなることである。true の後に改行を入れてみる。 - + - + 無事 Hello, World! と出力されるようになった。 - +
なぜ <literal>then</literal> や <literal>;</literal> や改行が必要か - + なぜ then や ; や改行 (以下 「then 等」) が必要なのだろうか。次の例を見てほしい: - + - + then も ; も改行もないのでエラーになるが、これは条件式がどこまで続いているのかわからないためだ。 この例は二通りに解釈できる。 - + - + then 等はこの曖昧性を排除するためにあり、条件式は if から then 等までの間にある、ということを明確にする。 C系の if 後に来る (/) や、Python の :、Rust/Go/Swift などの { も同じ役割を持つ。 - - + + Ruby の場合、プログラマーが書きやすいよう改行でもって then が代用できるので、ほとんどの場合 then は必要ない。 - +
<literal>case</literal> - <literal>in</literal> における <literal>then</literal> - + ようやく本題にたどり着いた。来る Ruby 3.0 では case と in キーワードを使ったパターンマッチングの構文が入る予定である。この構文でもパターン部との区切りとして then 等が必要になる。 (現在の) Ruby には formal な形式での文法仕様は存在しないので、yacc の定義ファイルを参照した (yacc の説明は省略)。 - - + + https://github.com/ruby/ruby/blob/221ca0f8281d39f0dfdfe13b2448875384bbf735/parse.y#L3961-L3986 - + - + 簡略版: - + - + ここで、keyword_in は文字通り in、p_top_expr はいわゆるパターン、then は then キーワードのことではなく、この記事で then 等と呼んでいるもの、つまり then キーワード、;、改行のいずれかである。 - - + + これにより、case - when による従来の構文と同じように、then 等をパターンの後ろに挿入すればよいことがわかった。つまり次の3通りのいずれかになる: - + - + ところで、p_top_expr には if による guard clause が書けるので、その場合は if - then と似たような見た目になる。 - + - + この記事は Qiita から移植してきたものです。 元 URL: https://qiita.com/nsfisis/items/9a429432258bbcd6c565 - - + +
- +
前置き - + Rust において、プリミティブ型の名前は予約語でない。したがって、次のコードは合法である。 - + - + では、普段単に bool と書いたとき、この bool は一体どこから来ているのか。rustc のソースを追ってみた。 - +
- + 前提知識: 一般的なコンパイラの構造、用語。rustc そのものの知識は不要 (というよりも筆者自身がよく知らない) - +
調査 - + 調査に使用したソース (調査時点での最新 master) - - + + https://github.com/rust-lang/rust/tree/511ed9f2356af365ad8affe046b3dd33f7ac3c98 - - + + どのようにして調べるか。rustc の構造には詳しくないため、すぐに当たりをつけるのは難しい。 - - + + 大雑把な構造としては、compiler フォルダ以下に rustc_* という名前のクレートが数十個入っている。これがどうやら rustc コマンドの実装部のようだ。 - - + + rustc はセルフホストされている (= rustc 自身が Rust で書かれている) ので、bool や char などで適当に検索をかけてもノイズが多すぎて話にならない。 しかし、お誂え向きなことに i128/u128 というコンパイラ自身が使うことがなさそうな型が存在するのでこれを使って git grep してみる。 - + - + 165 程度であれば探すことができそうだ。今回は、クレート名を見ておおよその当たりをつけた。 - + - + rustc_resolve というのはいかにも名前解決を担いそうなクレート名である。該当箇所を見てみる。 - + - + これは初めに列挙したプリミティブ型の一覧と一致している。doc comment にも、 - +
- + All other types are defined somewhere and possibly imported, but the primitive ones need special handling, since they have no place of origin. - +
- + とある。次はこの struct の使用箇所を追う。追うと言っても使われている箇所は次の一箇所しかない。なお説明に不要な箇所は大きく削っている。 - + - + 関数名や doc comment が示している通り、この関数は識別子 (identifier, ident) を現在のレキシカルスコープ内で解決 (resolve) する。 if ns == TypeNS のブロック内では、primitive_type_table (上記の PrimitiveTypeTable::new() で作られた変数) に含まれている識別子 (bool、i32 など) かどうか判定し、そうであればそれに紐づけられたプリミティブ型を返している。 - - + + なお、ns は「名前空間」を示す変数である。Rust における名前空間はC言語におけるそれとほとんど同じで、今探している名前が関数名/変数名なのか型なのかマクロなのかを区別している。この if は、プリミティブ型に解決されるのは型を探しているときだけだ、と言っている。 - - + + 重要なのは、これが resolve_ident_in_lexical_scope() の最後に書かれている点である。つまり、最初に挙げたプリミティブ型の識別子は、「名前解決の最終段階で」、「他に同名の型が見つかっていなければ」プリミティブ型として解決される。 - - + + 動作がわかったところで、例として次のコードを考える。 - + - + ここで main() の bool は struct bool として解決される。なぜなら、プリミティブ型の判定をする前に bool という名前の別の型が見つかるからだ。 - +
まとめ - + Rust のプリミティブ型は予約語ではない。名前解決の最終段階で特別扱いされ、他に同名の型が見つかっていなければ対応するプリミティブ型に解決される。 - +
diff --git a/content/posts/2021-10-02/vim-difference-between-autocmd-bufwrite-and-bufwritepre.xml b/content/posts/2021-10-02/vim-difference-between-autocmd-bufwrite-and-bufwritepre.xml index 4e3f187..7e0dd2e 100644 --- a/content/posts/2021-10-02/vim-difference-between-autocmd-bufwrite-and-bufwritepre.xml +++ b/content/posts/2021-10-02/vim-difference-between-autocmd-bufwrite-and-bufwritepre.xml @@ -15,69 +15,69 @@ - + この記事は Qiita から移植してきたものです。 元 URL: https://qiita.com/nsfisis/items/79ab4db8564032de0b25 - - + +
- +
TL; DR - + 違いはない。ただのエイリアス。 - +
調査記録 - + Vim の autocmd events には似通った名前のものがいくつかある。大抵は :help に説明があるが、この記事のタイトルにある2つを含めた以下のイベントには、その違いについて説明がない。 - + BufRead/BufReadPost BufWrite/BufWritePre BufAdd/BufCreate - + このうち、BufAdd/BufCreate に関しては、:help BufCreate に - +
- + The BufCreate event is for historic reasons. - +
- + とあり、おそらくは BufAdd のエイリアスであろうということがわかる。他の2組も同様ではないかと予想されるが、確認のため vim と neovim のソースコードを調査した。 - +
- + ソースコードへのリンク vim (調査時点での master branch) neovim (上に同じ) - +
vim のソースコード - + 以下は、autocmd events の名前と内部で使われている整数値とのマッピングを定義している箇所である。見ての通り、上でエイリアスではないかと述べた3組には、それぞれ同じ内部値が使われている。 - - + + https://github.com/vim/vim/blob/8e6be34338f13a6a625f19bcef82019c9adc65f2/src/autocmd.c#L85-L86 - + - + https://github.com/vim/vim/blob/8e6be34338f13a6a625f19bcef82019c9adc65f2/src/autocmd.c#L95-L97 - + - + https://github.com/vim/vim/blob/8e6be34338f13a6a625f19bcef82019c9adc65f2/src/autocmd.c#L103-L105 - +
neovim のソースコード - + neovim の場合でも同様のマッピングが定義されているが、こちらの場合は Lua で書かれている。以下にある通り、はっきり aliases と書かれている。 - - + + https://github.com/neovim/neovim/blob/71d4f5851f068eeb432af34850dddda8cc1c71e3/src/nvim/auevents.lua#L119-L124 - + - + ところで、上では取り上げなかった FileEncoding だが、これは :help FileEncoding にしっかりと書いてある。 - +
まとめ - + 記事タイトルについて言えば、どちらも変わらないので好きな方を使えばよい。あえて言えば、次のようになるだろう。 - + BufAdd/BufCreate @@ -159,10 +159,10 @@ - + ところでこの調査で知ったのだが、BufRead と BufWrite は上にある通り発火するタイミングが「後」と「前」で対称性がない。可能なら Pre/Post 付きのものを使った方が分かりやすいだろう。 - +
diff --git a/content/posts/2021-10-02/vim-swap-order-of-selected-lines.xml b/content/posts/2021-10-02/vim-swap-order-of-selected-lines.xml index f919301..cf1013a 100644 --- a/content/posts/2021-10-02/vim-swap-order-of-selected-lines.xml +++ b/content/posts/2021-10-02/vim-swap-order-of-selected-lines.xml @@ -15,13 +15,13 @@ - + この記事は Qiita から移植してきたものです。 元 URL: https://qiita.com/nsfisis/items/4fefb361d9a693803520 - - + +
- +
TL; DR @@ -36,69 +36,69 @@
バージョン情報 - + :version の一部 - +
- + VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Jan 26 2020 11:30:30) macOS version Included patches: 1-148 Huge version without GUI. - +
よく紹介されている手法
<literal>tac</literal> / <literal>tail</literal> - + tac や tail -r などの外部コマンドを ! を使って呼び出し、置き換える。 - +
- + :h v_! - +
- + tac コマンドや tail の -r オプションは環境によって利用できないことがあり、複数の環境を行き来する場合に採用しづらい - +
<literal>:g/^/m0</literal> - + こちらは外部コマンドに頼らず、Vim の機能のみを使う。g は :global コマンドの、m は :move コマンドの略 - - + + :global コマンドは :[range]global/{pattern}/[command] のように使い、[range] で指定された範囲の行のうち、{pattern} で指定された検索パターンにマッチする行に対して、順番に [command] で指定された Ex コマンドを呼び出す。 - +
- + :h :global - +
- + :move コマンドは [range]:move {address} のように使い、[range] で指定された範囲の行を {address} で指定された位置に移動させる。 - +
- + :h :move - +
- + :g/^/m0 のように組み合わせると、「すべての行を1行ずつ 0行目(1行目の上)に動かす」という動きをする。これは確かに行の入れ替えになっている。 - - + + なお、:g/^/m0 は全ての行を入れ替えるが、:N,Mg/^/mN-1 とすることで N行目から M行目を処理範囲とするよう拡張できる。手でこれを入力するわけにはいかないので、次のようなコマンドを用意する。 - + ,g/^/m-1 ]]> - + これは望みの動作をするが、実際に実行してみると全行がハイライトされてしまう。次節で詳細を述べる。 - +
<literal>:g/^/m0</literal> の問題点 - + :global コマンドは各行に対してマッチングを行う際、現在の検索パターンを上書きしてしまう。^ は行の先頭にマッチするため、結果として全ての行がハイライトされてしまう。'hlsearch' オプションを無効にしている場合その限りではないが、その場合でも直前の検索パターンが失われてしまうと n コマンドなどの際に不便である。 - +
- + :h @/ - +
解決策
- + [2020/9/28追記] より簡潔な方法を見つけたので次節に追記した - +
- + 前述した :Reverse コマンドの定義を少し変えて、次のようにする: - + reverse_lines(, ) ]]> - + 実行しているコマンドが変わったわけではないが、関数呼び出しを経由するようにした。これだけで前述の問題が解決する。 - - + + この理由は、ユーザー定義関数を実行する際は検索パターンが一度保存され、実行が終了したあと復元されるため。結果として検索パターンが ^ で上書きされることがなくなる。 - - + + Vim のヘルプから該当箇所を引用する (強調は筆者による)。 - +
- + :h autocmd-searchpat - - + + Autocommands do not change the current search patterns. Vim saves the current search patterns before executing autocommands then restores them after the autocommands finish. This means that autocommands do not affect the strings highlighted with the `hlsearch' option. - +
- + これは autocommand の実行に関しての記述だが、これと同じことがユーザー定義関数の実行時にも適用される。このことは :nohlsearch のヘルプにある。同じく該当箇所を引用する (強調は筆者による)。 - +
- + :h :nohlsearch - - + + (略) This command doesn’t work in an autocommand, because the highlighting state is saved and restored when executing autocommands |autocmd-searchpat|. Same thing for when invoking a user function. - +
- + この仕様により、:g/^/m0 の呼び出しをユーザー定義関数に切り出すことで上述の問題を解決できる。 - +
解決策 (改訂版)
- + [2020/9/28追記] より簡潔な方法を見つけたため追記する - +
,g/^/m-1 ]]> - + まさにこのための Exコマンド、:keeppatterns が存在する。:keeppatterns {command} のように使い、読んで字の如く、後ろに続く Exコマンドを「現在の検索パターンを保ったまま」実行する。はるかに分かりやすく意図を表現できる。 - +
- + :h :keeppatterns - +
-- cgit v1.2.3-70-g09d2