ブックマーク / zenn.dev/mod_poppo (11)

  • インターフェースと型クラスの違いを考える

    この記事では、JavaライクなインターフェースとHaskellライクな型クラスを比較します。どちらも、複数の異なる型を統一的に扱うための仕組みです。 インターフェース インターフェースはご存知の方も多いと思いますが、コード例を載せておきます。 // インターフェースの定義 interface Greetable { String greet(); } // 実装の例1 class Hello implements Greetable { String message; Hello(String m) { this.message = m; } public String greet() { return "Hello " + message + "!"; } } // 実装の例2 class Goodbye implements Greetable { public String gree

    インターフェースと型クラスの違いを考える
    toshikish
    toshikish 2024/02/24
  • JSONの小ネタと、JSONに対する拡張

    JSONは最も普及したデータ形式の一つでしょう。JSONの仕様はECMA-404やRFC 8259として標準化されています。 ECMA-404 - Ecma International RFC 8259 - The JavaScript Object Notation (JSON) Data Interchange Format 細かいネタ 文字コード RFC 8259では、外部と交換するJSONテキストはUTF-8でエンコードされなければならないということになっています。BOMは禁止です。昔のRFCではUTF-16やUTF-32も許容されていました。 ただし、キーや文字列の中身としては単独のサロゲート(例:"\uD800")は禁止されていません。JSONのキーや文字列はUnicodeスカラー値の列とは限らないのです。 UTF-8を前提とする実装にとっては、単独のサロゲート(不正なUTF-

    JSONの小ネタと、JSONに対する拡張
    toshikish
    toshikish 2024/01/22
  • unsafePerformIOではじめる愉快なHaskellプログラミング

    Haskellは「入出力のためにIOモナドを使う必要があるので難しい」というイメージを持たれがちです[要出典]。この記事ではそのイメージに異を唱えることを目指します。すなわち、モナドを使わずに入出力を含むプログラミングをやってみます。 と言っても、Haskell標準の入出力関数には IO 型がついていることに変わりはありません。ですが、 unsafePerformIO という魔法の関数を使うと、IO 型を外して値を取り出すことができるのです。この記事ではこれを最大限活用します。 module System.IO.Unsafe where -- 魔法の関数 unsafePerformIO :: IO a -> a

    unsafePerformIOではじめる愉快なHaskellプログラミング
    toshikish
    toshikish 2023/10/05
  • x86-64機械語入門

    この記事はx86-64の機械語を書けるようになるためのガイドとなることを目指します。読者はアセンブリー言語について既にある程度知っていることを想定します。 情報源 x86-64の機械語のオフィシャルなガイドはIntelのSoftware Developer ManualまたはAMDAMD64 Architecture Programmer's Manualです。 Intel SDM: Intel® 64 and IA-32 Architectures Software Developer Manuals AMD64 Architecture Programmer's Manual, Volumes 1-5 このほか、Cから呼び出される関数を定義したり、Cの関数を呼び出すためには、呼び出し規約の知識も必要です。使用される呼び出し規約はOSに依存し、Unix系では主にSystem V ABI

    x86-64機械語入門
    toshikish
    toshikish 2023/09/18
  • Haskellプロジェクトのベストプラクティス

    Haskellプロジェクトの「良い習慣」と考えられるやつをまとめてみます。あくまで私の個人的な意見です。 プロジェクト固有のPrelude Prelude に相当するモジュールをプロジェクト独自に持っておくと便利ではないか、という話をします。代替Preludeの話ではありません。 プロジェクト固有のPreludeがあると便利な理由 理由の一つは、標準 Prelude の変化です。直近では次のような変化がありました: GHC 9.4: ~ 型演算子が追加(これまでは構文だった) GHC 9.6: liftA2 が追加 GHC 9.10(見込み): foldl' が追加 もっと昔に遡ると、Semigroup((<>)) が増えるやつなどがありました。 この帰結として、 新しいGHCで名前の衝突が起きやすくなる 新しいGHCで「冗長なインポート」の警告が出やすくなる ことが言えます。これらの問題

    Haskellプロジェクトのベストプラクティス
    toshikish
    toshikish 2023/08/08
  • C言語の符号付き整数はモジュラー演算ではない

    C言語の符号付き整数の足し算、引き算、掛け算は「2^nを法とするモジュラー演算である」と説明されることがありますが、これは間違いです。正しい説明は、「C言語の符号付き整数のオーバーフローは未定義動作である」となります。 この違いが観測できる例を2つ紹介します。 まず、単項マイナスについて。以下のプログラムを考えます: #include <limits.h> #include <stdbool.h> #include <stdio.h> bool f(int x) { return x == -x; } int main() { printf("%s\n", f(INT_MIN) ? "true" : "false"); } int 型の単項マイナスが2^nを法とするモジュラー計算で行われるのであれば、f が true を返す x は 0 と INT_MIN の2つのはずです。ですが、実際に

    C言語の符号付き整数はモジュラー演算ではない
    toshikish
    toshikish 2023/03/06
  • 新しくプログラミング言語を作る際に数値型をどうするべきか

    この記事は、新しくプログラミング言語を設計する際に数値型をどうするべきかについて、私の持論をまとめたものです。 数の体系 JavaScript(BigInt以前)やLua(〜5.2)などは唯一の数値型が浮動小数点数型で、整数も実数も同じ「number」型で表現します。ミニマルな言語を作るのならそういう設計もアリかもしれませんが、ネイティブコンパイルも視野に入る実用的な言語を作るなら整数と実数を一緒くたにする設計はやめた方が良いと思います。 特に、JavaScriptにコンパイルする言語を作るからと言って、数値型の設計まで真似る必要はありません。 整数を浮動小数点数で表現すると、思わぬ性能低下の要因になったりします。最近(2023年2月)、次のツイートが話題になりました: これは正のゼロと負のゼロが値として区別され、正のゼロは内部的に整数扱いされるのに対し負のゼロはそうではないことによるもの

    新しくプログラミング言語を作る際に数値型をどうするべきか
    toshikish
    toshikish 2023/03/01
  • 浮動小数点数オタクがAtCoder Beginner Contest 284のD問題をガチで解説してみる

    こんにちは、浮動小数点数オタクのmod_poppoです。 昨日開催されたABC284のD問題でsqrtがどうのこうのという声がツイッターで観測されたので、ガチで考察してみます。 問題文(引用) まず最初に問題文を引用しておきます。 AtCoder Beginner Contest 284 | D - Happy New Year 2023 問題文 正整数Nが与えられます。Nは、2つの相異なる素数p, qを用いてN=p^2qと表せることがわかっています。 p, qを求めてください。 T個のテストケースが与えられるので、それぞれについて答えを求めてください。 制約 入力は全て整数 1\le T\le 10 1\le N\le 9\times 10^{18} Nは、2つの相異なる素数p, qを用いてN=p^2qと表せる 2023が7\times 17^2と素因数分解できることにちなんだ問題のよう

    浮動小数点数オタクがAtCoder Beginner Contest 284のD問題をガチで解説してみる
    toshikish
    toshikish 2023/01/09
  • Haskellの環境構築2023

    この記事はHaskell Advent Calendar 2022の1日目の記事です。 この記事では、2022年12月時点のHaskellの環境構築手順を紹介します。2023年になっても通用するといいなあ。 対象とする環境 対象とする環境は以下の通りです: Unix系 macOS (Intel / Apple Silicon) Linux (x86_64 / aarch64) WSL2を含む(WSL1は不具合があった気がするので避けてください) Windows (x64) Arm系CPU搭載のコンピューターを使っている場合は、別途LLVMが必要になる場合があります。以下に当てはまる場合は、「補遺:LLVMバックエンドを使う」も読んでください: 64ビットArm(Apple Silicon Macや、Raspberry Pi OSの64ビット版など)で、GHC 9.0またはそれ以前のバージョ

    Haskellの環境構築2023
    toshikish
    toshikish 2022/12/01
  • 次期C標準 (C23) の内容が固まったらしい

    C23については最近のC言語と、次期C標準(C23)でも軽く紹介しました。 今回、C23入りする内容が大体固まったようなので改めて紹介します。 この記事を書いている時点での最新の公開されたWorking Draftは N2912 N3047 N3054 N3096です。ただし、C2y向けの最初のドラフトN3220もあり、そちらの方が実際の内容に近いかもしれません。 内容については会議参加者の投稿も参考にしています: https://twitter.com/rcs/status/1550526425211584512 C23 now finalized! : C_Programming というわけで、C23に入る主な機能はこちらです: C23に入る主な機能 POSIXの機能の取り込み: strdup, strndup, memccpy, gmtime_r, localtime_r C++の機

    次期C標準 (C23) の内容が固まったらしい
    toshikish
    toshikish 2022/07/25
  • Haskellでの型レベルプログラミング

    Haskellでの型レベルプログラミングの解説書です。

    Haskellでの型レベルプログラミング
    toshikish
    toshikish 2022/03/17
  • 1