タグ

ブックマーク / zenn.dev/qnighy (31)

  • WebAssembly所感

    WebAssemblyをちょっといじってみて思ったところをまとめてみます。 設計思想 WebAssembly/designに設計文書がまとまっています。特にHighLevelGoals.mdから読み取れるポイントは以下の4点です。 サンドボックス化された環境であること。 移植性があること。つまり、特定の実CPUアーキテクチャ等に依存しないこと。 少なくともC/C++の(十分に高速な)コンパイルターゲットとして機能すること。 安定した仕様を持つこと。 サンドボックスという観点からは、先行技術として以下のようなものが特筆に値します。 Webサンドボックス JavaScript および asm.js Javaアプレット Flash (ActionScript) NaCl, PNaCl Web以外のサンドボックス OSのユーザーランド、特にLinux userland これらのサンドボックスとの比

    WebAssembly所感
  • JSのデザインパターンライブラリを試作した話と、それをJSRにアップロードしたら無茶苦茶簡単で感動した話

    デザインパターンライブラリを作った JSRの話だけ読みたい人は読み飛ばしてもOKです。 JavaScriptのtry-catchはC++の影響を受けており、以下の特徴があります。 (A) throwは大域脱出的である。 (B) try-catchはブロック内の全ての例外副作用に対して一括で作用する。 (C) try-catchは文であり、値を返せない。 (D) TypeScriptにおいて、例外型は明示されない。 このうち (B), (C), (D) の問題を解決するため、RustのResultや類似のパラダイムをJSに輸入する試みがしばしば行われています。しかしこの解決手段にはいくつかの問題があり、 (E) rethrowの専用構文がないためボイラープレートが増える。 (F) 出力ストリームに対するwriteなど、戻り値を持たない副作用関数に対するエラーハンドリングが抜け落ちないようにL

    JSのデザインパターンライブラリを試作した話と、それをJSRにアップロードしたら無茶苦茶簡単で感動した話
  • Rustで単一化を書くスマートな方法を考えた

    課題 Rustでシンプルな単一化を書くことを考えます。単一化は主に型推論の実装に用いられます。 ここでは以下の方針で実装します。 一階の単一化。 変数は非負整数のidで表現し、0から順に付番する。 変数以外の項はRustのADTを使った通常の木構造で表現し、ノードの共有は行わない。 変数参照の縮約は行わない。 この方針のもと実装すると、およそ以下のようなコードになります。 #[derive(Debug, Clone)] pub struct UnifyEnv { vars: Vec<Option<Type>>, } #[derive(Debug)] pub struct UnificationFailure; #[derive(Debug, Clone, PartialEq, Eq)] pub enum Type { Var(usize), Constr { constr: u32, ar

    Rustで単一化を書くスマートな方法を考えた
    xef
    xef 2023/09/11
  • httpとhttpsの違い

    TLSの有無 言うまでもないことですが、httpsでは通信路をTLSを使って保護することが想定されています。[1][2] デフォルポート httpは80、httpsは443です。[3][4] 権威性 以降の説明に入る前に前提を確認します。稿は「httpとhttpsの違い」と題されていますが、これはURLのスキーム部分のことを指しています。URLはリソースの所在を指すものであり、通信方法はそこから二次的に決まるものです。このことを前提に置きつつ権威性について説明します。 Webにおいて、所望のリソースにアクセスする方法はひとつではありません。このような方法のうち、リソースの所有者の制御下にある(第三者による加工などが行われていないと期待される)方法で取得することを権威的アクセスと呼びます。[5] どのようなアクセス方法が権威的とみなせるかについて100%客観的で統一的な指標があるわけではな

    httpとhttpsの違い
  • enumはクローズド直和、traitはオープン直和

    稿では直和による多態性を実現する2つの機能、enumとtraitを拡張性の観点から比較します。 → Expression problem ※enumとtraitを使い分けるにあたってはパフォーマンス要件など他の条件も考慮するべきですが、記事は多態性の観点のみ説明します。 数式 — enumによる例 稿では数式をあらわすデータ型を例として扱います。enumではこのように定義されます。 #[derive(Debug)] pub enum Expr { Var(String), Add(Box<Expr>, Box<Expr>), Sub(Box<Expr>, Box<Expr>), Mul(Box<Expr>, Box<Expr>), Div(Box<Expr>, Box<Expr>), } impl Expr { pub fn eval(&self, vars: &HashMap<St

    enumはクローズド直和、traitはオープン直和
    xef
    xef 2022/09/22
  • 構文のことは忘れて、JSON, S式, XMLのデータモデルを比較する

    データをシリアライズするには、独自のフォーマットを定めるよりも、基的な定義済みの構造を組み合わせてフォーマットを作るほうが望ましい場合が多いです。 そのような仕組みとしてJSON, S式, XMLなどが存在しますが、これらは 「基的な構造」として何を選ぶか、という観点からそれぞれに個性を持っています。 記事では、具体的な構文のことは基的に忘れて、各フォーマットが採用するデータモデルの違いに焦点を絞って比較します。 JSON data JSON = Value data Value = -- Compounds Array [Value] | Object (Map String Value) -- Scalars | Null | Boolean Boolean | String String -- UCS-2 | Number IntegerOrFloat -- no NaNs

    構文のことは忘れて、JSON, S式, XMLのデータモデルを比較する
    xef
    xef 2022/08/22
  • Rustの「うわ、swapできない」を解消するパッケージを作った

    次のようなパッケージ (クレート) を作ったので解説します。 動機 Rustには所有権があるため、普通のswapパターンが動かない場合があります。これに対応するため、std::mem::swapという関数が用意されています。 let mut x = 'a'; let mut y = 'b'; std::mem::swap(&mut x, &mut y); assert_eq!((x, y), ('b', 'a'));

    Rustの「うわ、swapできない」を解消するパッケージを作った
    xef
    xef 2022/08/22
  • 2022年、Rustの未来を探る旅 (1) はじめに

    ※大風呂敷を広げてやる気だけ表明する記事です。まだ中身はない。 はじめに Rustは2009年頃に誕生し、2015年に正式リリースされたプログラミング言語です。その革新性はおよそ以下のように集約されます。 shared XOR mutable とそれに付随する発明 (所有権、ライフタイム) により、ミュータブル参照が正しく扱えるようになった (責任分界点が明確になった) こと。 上記のアイデアにより、高パフォーマンス・低フットプリントが求められるアプリケーションやOS・GC・アロケーターのない環境で動く必要のあるアプリケーションをより安全に書けるようになったこと。 プログラマーが安全に・快適にプログラムを書くための既知の優れた道具 (パッケージマネージャーなど) を計画的に取り入れ、伝統的なプログラミング言語が抱えがちな問題を広範に解決したこと。 これらの革新性から、これまでC/C++が担

    2022年、Rustの未来を探る旅 (1) はじめに
  • 32bit/64bit環境を判別するRubyコード + 解説

    注意事項 おそらくCRuby (いわゆるMRI) 限定です。3.1.2で確認しています。 環境構築が面倒だったため、実際には32bit環境でテストしていません。意図通りに動かなかったらすみません…… 以下解説 doキーワードの多重性 RubyではLRパーサージェネレーターであるBisonを使いながらも、LR(1)とは思えない高度な構文をパースさせるために、字句解析器が非常に複雑な状態管理を行っています。見た目が同じトークンでも、Bisonに渡すときには状態に応じて異なるトークンとして認識させることがあります。 doキーワードもそのような多重性をもつトークンの例で、構文解析器からは以下の5種類のトークンとしてあらわれます: 通常の識別子 foo.do ラムダ式のdo-endブロック -> do end 真のdo-endブロック f g do end 偽のdo-endブロック f do end

    32bit/64bit環境を判別するRubyコード + 解説
    xef
    xef 2022/07/26
  • Cycloneのソースリポジトリを蘇生してみる (前編)

    Cycloneとは CycloneはRustのリージョン推論の原型のひとつになった実験的なプログラミング言語です。 現在はメンテナンスされていませんが、歴史的な意義があることからCycloneのビルド環境を整備してみました。 (完結するかは未定) ソースの取得 CycloneのWebサイトは生きているので、ソースはCycloneのDownloadページから取得できます。しかしここに不穏な文言があります。 If you use gcc 4, you must get the latest version of Cyclone from SVN (see below). 最新安定版よりも新しい版があること、またgccのバージョンに依存して壊れることが読み取れます。そしてSubversionと書いてあることから嫌な予感がした人もいると思いますが、このリポジトリは既に動いていません。 というわけで

    Cycloneのソースリポジトリを蘇生してみる (前編)
  • JavaScriptでRAII (for-ofを使って)

    for-ofを用いて広義のRAIIを実現する方法を紹介し、JavaScriptでリソース管理を行うパターン3種を比較します。 タイトルはorumin氏の記事のリスペクトです。 RAIIについて RAII (リソース確保は初期化である) はC++におけるリソース管理方式を表す言葉で、デストラクタにより暗黙的にリソース解放処理を行うことでプログラマの注意力に頼らずにリソース管理を行うことができます。 C++RustのRAIIの特徴は、専用の制御構文を持たずに、変数のスコープに基づいてリソース管理が行われることです。 // C++ RAII // スコープから抜けるときに自動的に解放される std::fstream fs; fs.open("/proc/cpuinfo", std::fstream::in);

    JavaScriptでRAII (for-ofを使って)
  • Temporal Dead Zone と採用されなかった他の候補について

    Temporal Dead Zone とは ECMAScript 2015で採用された let/const のスコーピングの仕様をTemporal Dead Zoneと呼びます。 const x = "outer"; { const f = () => x; // console.log(f()); // => Error const x = "inner"; console.log(f()); // => "inner" } 4つの方式 Temporal Dead Zone という名前は、ブロックスコープ変数の挙動を決める際の4つの候補の名前に由来しているようです。 これはECMAScript 4が放棄されて間もない2008年10月のes-discussのログ[1]に言及があります。 A1. Lexical dead zone. References textually prior to

    Temporal Dead Zone と採用されなかった他の候補について
  • HTMLパーサーの設計・実装ノート (1) 字句解析

    ふと思いつきでHTMLパーサーを書いているので、どのようなことを考えながら実装したかの記録を残します。 (1) 字句解析 (2) 構文解析 おことわり 偏ったこだわりや早すぎる最適化もあるかもしれませんが、あくまで趣味で書いているものなのでご理解ください。そういったもののなかにも、他の人の発想のヒントになるものも含まれると考えています。 途中の試行錯誤のサイクルを省いて結論だけを紹介している箇所もあります。ご了承ください。 ソースコードは https://github.com/qnighy/htstream に上げていますが、現在のところ完成度はそれほど高くありません。ドキュメントもほぼありませんがご了承ください。 HTMLについて HTMLの管轄をめぐっては紆余曲折がありましたが、現在はWebブラウザベンダーを中心とする標準化団体であるWHATWGが制定するHTML StandardがH

    HTMLパーサーの設計・実装ノート (1) 字句解析
  • ジョークコマンド "dont" を作った

    (ビルド済みのバイナリや各種ディストリビューション向けのパッケージは現時点では存在しません。貢献を歓迎します!) これは何? 名前の通り、指定した処理を実行しないコマンドです。たとえば、 はfooを作成しません。 dontコマンドは必ずしも「何もしない」とは限りません。特定のパターンに対しては、ユーザーの意図を汲んで特別な処理が行われます。いくつかの例をreadmeに書いてあります。全てのパターンを知りたい人はソースコードを参照してください。 なぜこのタイミングで公開したのか エイプリルフールのネタにしようかなと思ったのですが、他のジョークの話題とい合うのもな…… と思ったので早めに公開することにしました。 実装上の工夫 基的には出落ちで終わってしまう話ですが、実装上の工夫がいくつかあるので紹介していきます。 -- の処理 コマンドはコマンドラインパーサーclapを使っており、オプシ

    ジョークコマンド "dont" を作った
    xef
    xef 2022/03/27
  • 主なNode.js独自API

    // CommonJS Modules の場合 const fs = require("fs"); const fs = require("node:fs"); // ES Modules の場合 import fs from "fs"; import fs from "node:fs"; process のように、グローバル変数としても組み込みモジュールとしても提供されているAPIもあります。 global globalThisの別名です。Webブラウザでは window と self がglobalThisの別名として定義されていますが、Node.jsには window や self はなく、かわりに global が定義されています。 Buffer ArrayBuffer, TypedArray (Uint8Arrayなど), DataView はJavaScriptの標準機能です。

    主なNode.js独自API
    xef
    xef 2022/03/04
  • JavaScriptの参照レコードとthisバインディング

    JavaScriptの仕様には「参照レコード」という概念があります。参照を意識することで、JavaScriptにおけるメソッド呼び出しの理解と左辺式の評価順序の理解を同時に深めることができます。稿ではこの「参照レコード」の動機と詳細の説明を試みます。 ※ 記事ではECMAScriptの規格で「参照レコード」と呼ばれている概念を説明します。JavaScriptのオブジェクトは参照渡しのような使い方ができますが、これは稿で説明する「参照」とは少しだけ異なります。 参照レコードの目的 JavaScriptにおける参照レコードは以下の2つの目的で存在しています。 左辺式の中間評価結果を表現するため。 メソッドのレシーバーを決定するため。 左辺式の中間評価結果とは たとえば a[f()] += 2; というコードを考えます。 function f() { console.log("f()");

    JavaScriptの参照レコードとthisバインディング
  • Native ESM + TypeScript 拡張子問題: 歯にものが挟まったようなスッキリしない書き流し

    Node.jsのNative ESM対応は夢の機能ですが、夢を詰め込みすぎたせいかCJSからの移行を難しくしているポイントが依然として存在します。そのひとつが拡張子問題で、Node.jsのNative ESMではモジュールの拡張子を明示しなければいけなくなりました。 (これはWebブラウザの挙動に近づけるための判断だと考えられます。) 特にTypeScriptと他のツール (JestやWebpack) と組み合わせて利用している状態でのNative ESM化は実質的に未解決の状態だと言えます。稿ではこの現状についてできる範囲で状況説明を試みます。 Node.jsの拡張子の扱い Node.jsはCJSとESMの2つのモジュールフォーマットをサポートしていますが、これらは単にパーサーが異なるだけではなく、実質的には「2種類の異なるモジュールシステムがFFIで繋がっている」程度には隔たりがあり

    Native ESM + TypeScript 拡張子問題: 歯にものが挟まったようなスッキリしない書き流し
  • 「Rustでやると知らないうちに詰む設計」を避けるためのTipsを集めてみる

    とりあえず、よく言われてるやつから埋めていこうと思う。 構造体にライフタイムを持たせない 構造体にライフタイムを持たせるのは「基的に」避けよ、というのが重要なのは間違いないのだけど、これをもう少し実践的な内容にしたい。ちょっと考えてみたけど、こういうのはどうだろうか。 ある関数呼び出しの中でしか絶対に使わない。returnするまでにその構造体のデータは全て破棄される。static変数に退避させることもできない。アロケーションもその関数が面倒を見る。そういう一蓮托生できる関数呼び出しに心当たりはあるか? ある→ 構造体にライフタイムを持たせてもよい。 ない→ ライフタイム禁止。 そう考えてみると、DIとかReduxとかとも通じるところがあるかもしれない。「つべこべ言ってないで全部の責務を一番外側に持っていく」という決断ができるときは構造体ライフタイムが選択肢に入る。

    「Rustでやると知らないうちに詰む設計」を避けるためのTipsを集めてみる
  • JavaScriptの演算子の優先順位と「禁止ルール」の一覧

    ただし、種別は以下の通りです。 prefix (前置演算子) …… もとの式の手前に何個でもつけられる演算子。 例: -~-~x postfix (後置演算子) …… もとの式の直後に何個でもつけられる演算子。 例: x.foo()`bar`[0] postfix once …… もとの式の直後に1個だけつけられる演算子。 例: x++ は可能だが x++-- はパースされない。 逆に ++--x はパースされるが、構文とは別のルールで禁止される。 (後述) infixL …… 中置演算子で左結合 (演算子の優先度が同じ場合は左側にあるほうが優先される) 例: 0.1 + 1.0 - 1.0 は (0.1 + 1.0) - 1.0 になる infixR …… 中置演算子で左結合 (演算子の優先度が同じ場合は右側にあるほうが優先される) 例: 2 ** 2 ** 3 は 2 ** (2 **

    JavaScriptの演算子の優先順位と「禁止ルール」の一覧
  • JavaScriptのレガシー挙動を定めたAnnex Bをひたすら読む記事

    ECMAScript Annex Bおよび関連する仕様を読みます。 おことわり 言うまでもありませんが、ここで説明されている機能は使わないようにしましょう。 筆者がJavaScriptを書き始めたのは2005年頃で、その後2010年代は実質的な空白期間でした。そのため記事に含まれる歴史的背景の説明は、2005年頃の筆者が学んだ内容に加えて、当時の資料を遡って調査した結果に基づいて記載されています。できる限り信頼性の高い情報を見つけた上で記述するよう心がけましたが、当時常識だった知識の欠落等により不正確な記述になっている部分があるかもしれません。もし誤り等があったら指摘いただけると嬉しいです。 現在のzennでは <sub></sub> や <ins></ins> は描画されていませんが、心の目で下付き文字や下線装飾に読み替えてください。 ECMAScript Annex B とは ECM

    JavaScriptのレガシー挙動を定めたAnnex Bをひたすら読む記事