サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
この記事は「言語実装 Advent Calendar 2025」の3日目の記事です。 この記事は、新しくプログラミング言語を設計する際に文字列型をどうするべきかについて、私の持論をまとめたものです。 以前「新しくプログラミング言語を作る際に数値型をどうするべきか」という記事を書きましたが、この記事はそれの文字列版です。 推敲が足りずに同じことを何箇所かで繰り返している場合がありますが、冗長性だと思ってご容赦ください……。 【2025年12月4日 更新】small string optimization、スライスとGCの話を追加、Rubyの文言の修正、可変性と値セマンティクスの記述の整理など。完全な変更履歴はGitHubを見てください。 【2025年12月7日 更新】ケーススタディーにJava、D、Schemeを追加。JavaScript文字列のコードポイント単位のアクセスの記述を追加。Sw
問題提起 そこそこ有名な「自然言語にwell-definedを求めるな。」という文がある。 X (ex-Twitter) ではこの文に様々な意見がついている。 この文の形式（＝つまり文そのもの）について議論することは一定程度可能だと思う。 しかしこの文の意味する主張の妥当性についてあなたが議論しようとするとき、私はあなたが正しくこの文を解釈できているのか問いたい。 文の中には文脈(context)、違う言い方をすればその文を取り巻く環境(environment)への明示的・暗黙的な参照(reference)が散りばめられており、文章を解釈するためにはこれを正しく参照解決(dereference)してやらねばならない。 あなたはこの文が発せられた当初のコンテキストを、あるいはその出来事を記憶している人々が発するこの言葉のコンテキストを調べずにこの文の意味を断定しようとはしていないか？その状態
アジャイルソフトウェア開発手法の先駆けともいえるXP（eXtremeProgramming）の名を冠して2002年から20年以上にわたり毎年開催されているXP祭り。2023年はオンラインの講演とオンサイトでのワークショップによるハイブリッド形式で、9月30日（土）に開催が予定されています。 ▶ XP祭り2023 - xpjug.com/xp2023/ コミュニティ主体によるカンファレンス開催が国内でまだ珍しかったころにスタートし、企業によるスポンサードもほぼなく、参加費も登壇料も全て無料、セッションだけでなくスタッフも毎年公募して入れ替える素朴な運営を続けながら、和田卓人さんや平鍋健児さんといった著名なエンジニアも登壇し、ソフトウェア開発について多くの示唆を与えてきたこのイベントはどのように続いてきたのでしょうか。 世界的にもアジャイルが広まりはじめた立ち上げ当初を知る小井土亨さんと、2
結論から言うと, 名前を付けることなく再帰的な関数を定義することは可能. 特定のプログラミング言語でどうかというよりは抽象概念としての関数の再帰を名前なしに実現可能かどうかという話(名前なしに実現できるプログラミング言語は存在するかという話). 発端 id:naoyaさんがこういうツイートをしていた. 再帰を書くときに何気なく関数に名前つけたり let で束縛したりしてたけど「再帰には三項関係が必要でありその実現には記号が本質的に関わる」とあり、名前づけの行為が必然だったことが分かった。プログラミングするときの視点が変わるな— naoya (@naoya_ito)2022年8月12日 たとえば以下のように書いたときのlet fact =みたいな話. let fact = n => n <= 1 ? 1 : n * fact(n-1) ちなみに, 話は一見逸れるけど, こう書けると必然的に
それじゃあまりにも天才しかできないだろうということでニーモニックというのを持ったアセンブリ言語ができた 多分当時の人の中にあった議論は、こんなの1と0の羅列に名前つけただけだろ、なんかいいことあんの？という人たちと、まさにブレークスルーだ世界が変わるとエキサイトした人たちだろう。 色々あったが、人にも読めるソースをアセンブリ言語に変換してくれるCが出来た。 多分このときも単なるアセンブリのスーパーセットだろ？なんか意味あんのか？っていう人たちと、やばいレベルでプログラミング書きやすくなったとエキサイトする人たちに分かれたことだろう。 その後Javaが登場してオブジェクト指向が花開いた。 このときも、構造化プログラミングに毛が生えた程度のもんだろ？何が嬉しいんだ？という人と、オブジェクト指向なら何でもできる！とエキサイトした人たちで溢れかえったことだろう。Java以降のIT界隈ではもはやオ
22:22 21/11/20 ボレロ村上(村上原野)さんと constexpr のこと 去る2020年2月、縄文陶芸家にしてC++プログラマという希有な二つの顔を持つ人物がこの世を去りました。 ボレロ村上 (村上原野) 氏です。 正直なところ、陶芸家としての彼の側面については私はほとんど何も知らないに等しいです。 残された作品を見て何かを語れるほど芸術に通じているわけでもありません。 いつか機会があれば見に行こうと思っていた村上さんの作品を目にする最初の機会も、 昨年訪れた追悼展になってしまいました。 ただ、それでも私は、彼自身の登壇発表の資料 であったり、 そして何よりも縄文・陶芸に造詣の深い方々の記された幾つかの文章によって、 彼が一体何を成し遂げたのか、成し遂げようとしていたのかに触れることができています。 この夏にはクラウドファンディングで 作品集 も出版され、誰でも手にとって縄文
κeenです。今朝、エイプリルフールのネタ記事を書いたのでそのタネ明かしをします。タネとはいっても、ほぼ手書きなんですけどね。 WhitespaceはEdwin BradyとChris Morrisにより2003年4月1日に発表された言語です。 この言語自体エイプリルフールのジョークなんですね。 公式ページはあるのですが、繋がらないのでWebArchiveとかからアクセスして下さい。 特徴としては空白文字、タブ文字、改行文字だけで構成されているのでパッと見では何も書いてないようになる点があります。 いわゆるesoteric languageです。 今回の私のエイプリルフールのジョークは、Whitespaceを知らない人には「正直者にしか見えないコードですか？」、Whitespaceを知ってる人には「Whitespace！？んなもん書ける書けるわけないだろ！あ、そうか今日はエイプリルフールか
Rustの特徴のひとつは、所有権(ownership)・移動(move)・借用(borrow)の概念です。これらがコンパイル時に厳格にチェックされることにより、古くから未定義挙動でプログラマを悩ませてきたダングリングポインタなどの問題がなくなり、メモリ安全性がもたらされます。 しかし一方で、自分で多少複雑なデータ構造を定義しようとする場合にはコンパイルを通すだけでもかなりの知識・力量が要求されます。 この（不定期）連載では、Rustではじめるデータ構造とアルゴリズム と題し、プログラミングコンテストなどでよく見かける基礎的なデータ構造とアルゴリズムを、できるだけシンプルにRustで実装していきます。 &, &mut, Box, Rc, Cell, RefCell などの使い分けや、なぜそれを使う必要があるかの解説を、実例を通して行います。 第1回は、最もシンプルな木構造である 二分木 を
開発部のxgotoです。Haskellの初級・中級者向けのトピックを取り上げたいと思います。 今回は型(Type)についてです。型はHaskellの入門書でも必ず最初のほうに説明されるもので、手元の本によれば、 型とは、互いに関連する値の集合である。 ---- 『プログラミングHaskell』 Graham Hutton 著 / 山本和彦 訳 だとか、 値の世界は型と呼ばれる系統的な集まりへと分割される。 ---- 『関数プログラミング入門 Haskellで学ぶ原理と技法』 Richard Bird 著 / 山下伸夫 訳 などのように書かれています。たとえば Bool は True と False の2つの値からなる集合だし、Intは整数の集合というように、型は値の集合というふうにみることができます。それならば型などと呼ばずに集合と呼べばいいと思いますが、「異なるものには異なる名前をつけろ
※Rustのバージョンは1.33.0 (stable)を使用しています。Rustは所有権やライフタイム関連で詰まることが多い印象がありますが、私は同じくらい「型の指定方法」、特に「ジェネリクスでの型指定やトレイト境界指定」周りで詰まることが多いと感じています。 これは、Rustが特別複雑なことをしているわけではなく、網羅的なドキュメントや実例の載った解説が少ないためだと思います。最近は公式ドキュメントも充実してきましたが、それでも「これってどう書くの？」「そもそも出来るの？」という時になかなか情報が見つからないことが多々あります。（主に私の英語力が問題ということもありますが） そこで、私の理解している範囲で、詰まりやすそうな部分とその周辺をまとめたいと思います。 ※ジェネリクスやトレイトの導入部分は省略しています。the bookの該当部分に丁寧に書かれているので、そちらをお勧めします。
Rustを使っていくうちにやらないほうがいいと気づいたことを挙げていこうと思います。 少なくとも自分は『プログラミング言語Rust』を読んだだけでは以下で説明することに気づけませんでした。 v: Vec<T>を&[T]に変換するためにいちいちv.as_slice()や&v[..]と書く 解説 Vec<T>が[T]へのDerefトレイトを実装しているので、v: Vec<T>は&をつけるだけで必要に応じて&[T]に変換されます。(参照: TRPL, 1st ed, Derefによる型強制) Vecか&[T]どちらであるべきかコンパイラが判断できない文脈では、スライスがほしい場合明示的に&v[..]などと書いてやる必要がありますが、基本的には適当に&をつけるだけで問題ありません。 Vecへのイミュータブルな参照を関数の引数にする 例 解説 イミュータブルな場合、スライスとVecの違いはcapac
C++で副作用のない無限ループを書くと未定義動作になります。 「未定義動作」というのは口に出すだけでC++プログラマーを震え上がらせる力を持った言葉です。「鼻から悪魔が出てくる」という言葉で説明されるように、未定義動作を含むコードを実行した結果は何も保証することができず、バグの発見やデバッグすら困難にさせます。未定義動作下においてはコンパイラの気分によってコード片が消え、trueとfalseが同時に成立し、タイムトラベルを引き起こします1。 そのためC++ではうっかり未定義動作が埋め込まれないよう注意が払われるのが普通です。 さて、以下のC++のコードは未定義動作を引き起こします。 下の例は実際にclang/LLVMで最適化を有効にしてコンパイルするとでたらめな値を返す関数ができました。 この話をしたところ、何人かに驚かれたり異論を受け取ったりしたので、この話題について少しまとめてみました
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?C++ Advent Calendar 2018 この記事はC++ Advent Calendar 2018 15日目の記事です。 14日目: VTKライブラリ 16日目:C++のエラー処理との付き合い方 当初見積もりよりも大幅に長い記事となり、投稿したのは12/22で1週間遅刻です。すみません。 お知らせ cpprefjpにchar8_t型追加について解説を書きました。ぎゅぎゅっとコンパクトに、また査読を受けて中立的な表現で書いていますので、よければどうぞ。UTF-8エンコーディングされた文字の型としてchar8_tを追加 - c
Helping Users Find Their Own Way:Creating Modern Search Experiences
はじめに この記事では私が開発しているKaruta(カルタ)というプログラミング言語と処理系の簡単な紹介をします。 Karutaはプログラミング言語としてはGoやJavaScriptのような雰囲気になるように作っていますが、主にFPGAで動く回路を設計することを目的としています。 Karutaは https://github.com/nlsynth/karuta からソースコードを入手してビルドし、karutaコマンドを実行できる状態にすれば試せるのですが、この記事を書いてる時点では品質が微妙なので間違いなく色々なバグや珍動作に遭遇するのでご了承ください。 (Ubuntuをご利用の方は $ snap install karuta でインストールできます) (Karutaのようなプログラミング言語からの回路を生成する技術は「高位合成」と呼ばれており、興味のある方はこちらからご覧になってくださ
めでたくC++11 も出たし、さいきんはC++ AMP やC++/CX なんかの亜種も注目されてる、きょうこの頃。 そんな、いわずとしれたC++ のグルである Bjarne Stroustrup せんせい。 ビャーネとか、もっと親しみを込めてハゲなどと呼んでおけば問題は表面化しないのですが。 困ったことに、せんせいはデンマーク人なのでした。 ふだん英語を話している人たちも、先生の苗字はどう呼んだらいいか分からないのです。 日本ではWikipedia*1 が「ストロヴストルップ」「ストラウストラップ」「ストゥロウストゥループ」のカナ転写を紹介し、ちまたでは「すぽっすぽっ」「すっぽすっぽ」などのバリエーションで呼ばれています。はて、どれが正しいのでしょうか? せんせいが英語話者のために書いた FAQ*2 には 発音は北欧っ子*3じゃないと難しいかもね。いままで聞いたなかでいちばんオス
最近巷では俄に型システムについての言及が増え、型システムポエマーが増えてる気がするので自分もその時流に乗りたい。 完全にポエムだけどなんかあったら随時指摘ください。直します。 TL;DR 言いたいことはまとめると次 型システムは程度問題なのでちょうどいいところを探すべき 型は万能でも強さが正義でもない(だから未だに研究されてる) よく知りもしないくせに計算機科学を侮辱するのはやめろ 予防線 あくまでポエムですので中身はないです 私は型理論専攻で学位はとったものの研究者ではないのであまり信用しすぎないように 型システムの過去 型システムは大まかに次のような利点があるとされてきた(個人的主観) 「異常」なプログラムを検出する仕組み 静的解析による分かりやすいエラーメッセージ 型そのもののドキュメント性 IDEでのcompletionに貢献 最適化に貢献 (数学に正しく裏打ちされたsemanti
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
