Raspberry PiでAArch64なGHCを動かす - Qiita
2023年の時点で、GHCupはAArch64 Linuxに対応しています。StackはGHCup経由で入ります。詳しくは以下の記事を参照してください： Haskellの環境構築2023 最近のRaspberry Pi（3以降）のCPUのアーキテクチャは64bitのARM (AArch64)である。開発中のHaskellパッケージをAArch64でもテストできると良いので、Raspberry Piを使ってAArch64のHaskell環境を整えてみた。 環境の概要は次の通り： Raspberry Pi 3 Model B Ubuntu Server 18.04.4 LTS aarch64 Stack 2.1.3 GHC 8.8.3 記事タイトルにラズパイを銘打っているが特にラズパイ依存な部分はない（IoTめいたこともしない）ので、Linuxが動く他のAArch64環境でも同様にできると思う
GHCの型レベル自然数を理解する - Qiita
Haskellの多相型システムでは、型をパラメーターとして取る型を定義することができる。この拡張として、GHC拡張の型レベル自然数を使うと、自然数をパラメーターとしてとる型を定義することができる。 型レベル自然数を使うには、GHC拡張の DataKinds を有効にして、 GHC.TypeLits モジュール（もしくは GHC.TypeNats モジュール）をimportする。 この記事で説明するのは基本的に、GHC組み込みの Nat カインドを持つ型レベル自然数である。データ型として帰納的に定義される自然数については、比較のために紹介する程度にとどめる。 初級編 まずは、型レベル自然数の基本的な使い方を紹介する。 雰囲気を掴む 小難しい話に入る前に、GHCの型レベル自然数の雰囲気を見ておこう。 {-# LANGUAGE DataKinds #-} {-# LANGUAGE ScopedT
Haskellの文字列型：分類と特徴 - Qiita
Haskellの文字列型について Haskellの文字列型には色々あります。標準の String のほかに Text や ByteString があり、Text と ByteString はそれぞれstrictとlazyの2種類ずつあります。 Haskellを学びたての方はこれを知ると「なんでこんなに色々あるんだ？Haskellはクソなのか？」と思われるかもしれません。 ですが、それぞれの文字列型にはちゃんと存在意義があります （まあ String は標準であること以外取り柄のないクソですが……）。この記事ではそれぞれの型の特徴と使いどころを解説します。 ここで説明する対象は、主に以下の型です。 String Text 系 strict Text (textパッケージ) lazy Text (同上) ShortText （text-shortパッケージ） ByteString 系（byte
Haskellの文字列リテラルはGHCでどのようにコンパイルされるか - Qiita
Haskellの文字列とは まず、Haskell標準の文字型・文字列型が何であるかを確認しておきます。 Haskell 2010では Char 型はUnicode characterを表す、とされています。 Haskell 2010 Language Report -- 6.1.2 Characters and Strings 「文字」というのが非自明な概念であることを知っている方であればUnicode characterって具体的にはなんやねん！と言いたくなるかと思いますが、GHCにおいては Char 型はUnicodeコードポイントを表します。つまり、 0 以上 0x10FFFF 以下の整数 です。特に、サロゲートコードポイント（0xD800 以上 0xDFFF 以下）も有効な Char 型の値です。 GHC の Char 型の説明 String は Char のリストです。 これらの
ML系言語で型注釈が必要なケース - Qiita
ML系言語は型推論が得意なので基本的には型を書かなくてもコードを書けますが、状況によっては型注釈が必要になります。代表的なML系言語3つ（SML, OCaml, Haskell）について、それぞれ型注釈が必要になる（型注釈がないとコンパイルが通らない）ケースを挙げてみます。 なお、ここでは型システムのみに注目し、評価戦略はどうでもいいので、Haskellも「ML系言語」に含めています。 また、MLのモジュール／ファンクター周りは扱いません。コア言語のみを対象にします。 SML SMLで型注釈をなくすとコンパイルが通らなくなるのは、例えば以下の例です： 組み込み演算子やリテラルのアドホックなオーバーロード レコードを受け取る関数 リテラルの例： val x: IntInf.int = 12345678901234567890123; (* 型注釈を剥ぐとダメ： val x = 1234567
関数内ローカル変数に IORef を使うな - Qiita
この記事は注意喚起を目的としており、過激な表題がついている可能性があります。ご了承ください。 手続き型 Haskell と IORef Haskell には do 記法や Control.Monad の各種関数、そして IORef/STRef という、手続き型プログラミングに適した道具が揃っています。（STRef も IORef と同様なので、以下 IORef のみを扱います） これらの道具を使うと、例えば次の C プログラム int someCalculation() { int sum = 0; for (int i = 0; i <= 10000 * 10000; ++i) { sum += i % 3; } return sum; }
Haskellでフィボナッチ数列 〜Haskellで非実用的なコードを書いて悦に入るのはやめろ〜 - Qiita
-- 素朴なコード fib :: Int -> Integer fib 0 = 0 fib 1 = 1 fib n = fib (n - 2) + fib (n - 1) 数学的な定義をそのまま書き下した、Haskellらしい美しいコードですね！ ……なーんて感想を抱いた人はHaskell初心者です。計算機で動かすコードを「数学的な美しさ」で語ってどうするんですか？？？ 美しいバラにはトゲがあるように、美しいHaskellコードには罠があります。 この「素朴なコード」は非常に遅く、実用に耐えません。（この素朴なコードの出番があるとしたら「遅いコードの例」としてでしょう） 素朴なコードの問題点 例として、「素朴なコード」で fib 4 を計算してみましょう。 fib 4 = fib 2 + fib 3 = (fib 0 + fib 1) + fib 3 = (0 + fib 1) + fib
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
