Lox (Crafting Interpreters)にdefer文を追加する - 井山梃子歴史館
Crafting InterpretersはRobert Nystromによるインタプリタ方式のプログラミング言語処理系の作り方の解説本である。 ハードカバー・電子書籍が発売されているほか、著者のページでWeb版が無料公開されており、自作言語界隈では人気を博している。 Crafting Interpretersでは著者が考案したLox言語のインタプリタを実装していくこととなる。本の前半部分ではAST評価器を扱い、後半部分ではバイトコードVMを用いたインタプリタを実装する。 Lox言語はシンプルとはいえ、クロージャやクラスの継承といった高度な機能も備えたオブジェクト指向スクリプト言語であり、読者は小さなインタプリタからステップ・バイ・ステップでだんだんと完全な処理系を構築していく。 Crafting Interpretersの素晴らしいところには次の点が挙げられるだろう: 平易な文章に加えて
PEG Parser Generator + Packrat Parserを実装してみた
詳しい解説はネット上に沢山存在するので割愛しますが、ご覧のようにEBNFの表現の一つに（EBNFはいくつかの表現方法があるようです。例えばこれはW3Cが定義しているものです）似ています。違いは先に述べたようにChoiceの働きが異なるのと、文法上に先読みが存在することです。 このPEGを使って四則演算を受理するシンプルなルールを書くとすると、例えばこのようになります。 # expressionからパースが始まるとする expression <- additive additive <- multitive ("+" multitive / "-" multitive)* multitive <- primary ("*" primary / "/" primary)* primary <- "(" expression ")" / number number <- digit+ digit
どうやってPureScriptに慣れたのか - oreshinyaのブログ
はじめに PureScript Advent Calendar 2017 - Qiitaの1日目の記事が埋まっていなかったので大急ぎで書くことにしました。 元々はRubyやJavaScriptなどの動的言語をメインでメシを食べているプログラミング的ゆとり世代であった私が、 少なくとも一般論としては学習が大変だと評されているPureScriptを、 (上手いか下手かは別として)普通に書けるようになった要因を記憶の限り辿ってみようと思います。 つまり、この記事は、「最初からPureScriptの勉強のためにやっていた」ということではなく、「たまたまそういう道を通ったけど、 あれがよかったのかもしれない」という回想です。 道のはじまり この道のはじまりはHaskellでした。 特に仕事で使うわけでもなく、関数型言語に興味があったわけでもなく、ただなんとなく暇を持て余していたので暇つぶしとして思い
えっ!? １時間でオリジナルのプログラミング言語の開発を構文解析から!? - Qiita
出来らあ！ 1時間で構文解析から評価器まで書けるって言ったんだよ！ プログラミング言語を作る。１時間で。 上のエントリは、Lispの『S式』みたいな式で構成されたプログラムを実行するインタプリタを作るというお話です。ストックやブックマークが結構たくさんついていて、みんな自分のオリジナルなプログラミング言語とか作ることに興味があるんだなあって思いました。 元ネタのorelangは、式をJSONのサブセットにすることでJSONパーサを流用し構文解析の手間を省いているところがキモだと思いますが、実は構文解析は案外簡単で、わざわざ避けて通るほどのものではなかったりします。また、S式の範囲に収めるとそれ以上構文の工夫は望めないので、『自分のプログラミング言語を作る』ということの面白みが薄れてしまう気もします。他にも、JSONのパーサを流用すると、構文エラーであるはずのコードまで受理されてしまうという
moonbit で json パーサーを書いてみた 感想
エアプにならないために、実際に moonbit を使ってコードを書いてみた感想を書く。 JSON Parser を書いた パッケージレジストリである https://mooncakes.io を見た限り、使いやすい json parser がなさそうなので、とりあえず自分用のをでっち上げた。 mooncakes.io に publish してあるので、 moon add mizchi/json で使える。品質が良くなくても ネームスペース付きで publish するので別に邪魔にならない気がした。 なんで作ったかというと、公式 example の cloudflare workers の example は単純なフィボナッチを計算するだけで、構造的なデータを返すことができない。 moonbit と js 間の文字列の受け渡しについては、あとで別の記事を書く。 使い方 fn main { l
コンパイラのための新しい中間表現 MLIR の論文を読む - FPGA開発日記
LLVM IRについて調べていると、最近よくMLIRという言葉を目にするようになった。MLIRは"Multi-Level Intermediate Representation"の略称であって決して"Machine Learning"ではないのだが、LLVM IRを置き換えるために開発されている新しい中間表現形式である。 LLVM IRももちろん柔軟性のある中間表現形式であるが、より柔軟かつ幅広いDSLの中間表現を受け入れるために開発されているものだ。Googleに在籍していたLLVM CreaterのChris Lattnerによって開発されたものである。ちなみにChris Lattnerは本論文が発行されたときにはすでにSiFiveに移っている。 https://arxiv.org/abs/2002.11054 この論文を読みながら、MLIRについて理解を進めていくことにしよう。 ML
LispKit Lisp処理系の実装 序 - Arantium Maestum
純粋関数型Lisp方言であるLispKit LispのインタプリタとSECD抽象機械の機械語へのコンパイラを作成する。 タネ本はHendersonの「Functional Programming - Application & Interpretation」で、この本に載っているISWIMやPASCALのコードを大体なぞるようにPythonで書いていく。（最近出た「コンパイラー原理と構造ー」でもSECDマシンへのコンパイルの話題が出ているらしいがまだ届いていないので未確認・・・） 例によって長くなるので複数の記事に分ける。 流れとしては以下のようになる： LispKit Lispの紹介 （本記事） パーサとAST インタプリタ 前編 後編 SECD抽象機械の実装 1 2 3 SECD機械語へのコンパイラ SECD抽象機械ガベージコレクション LispKit Lisp LispKit Lis
KMC Staff Blog:return 文に括弧を付ける（た）理由
2009年08月03日 return 文に括弧を付ける（た）理由 また pre K&R C の話です。 pre K&R C の時代は、return 文が取る式を () で囲むことが文法上必須でした。その時代の習慣を引きずったためか、K&R (第1版) でも return 文の後の式を括弧で囲っていたようです。（私は第2版しか所有していないので確認できないのですが。） そのため、今でも括弧を付ける人もいるようです。一方、括弧を付けると return を retuan のようにタイプミスした時に関数呼び出しとして解釈されてしまい、コンパイルエラーにならない（リンク時にはエラーになる）ために良くないと主張する人などもいるようです。いずれにせよここらへんの話は、IDE やエディタがキーワードをハイライトしてくれるようになった現在では、好みの問題の範囲と言えるでしょう。 http://www.mat
RubyにlramaがマージされてBison依存がなくなった（RubyKaigi 2023）｜TechRacho by BPS株式会社
こんにちは、hachi8833です。RubyKaigi 2023@松本に行ってまいりました。 イベント感想などは他の皆さまが続々ネット上のブログにアップしているのでそちらにおまかせするとして、今回のRubyKaigiのDay1で発表されていたlramaが気になったので手短にメモします（個人的にPEGパーサージェネレータに関心があるので）。 Lramaでリャマと読みます。LALR parser generatorのYaccやBisonの流れをくむものとして、リャマという名前にしました。LR parser generatorなのでLlama (LL)ではなくLrama (LR)と綴ります。 Ruby Parser開発日誌 (5) - Lrama LALR (1) parser generatorを実装した - かねこにっきより lramaパーサーがmasterにマージされた 発表: The f
Rustにおける「厳密な型付け」という文化 - Qiita
はじめに Rustの特徴としてはメモリ安全性やGCなしで高速といったことがよく挙げられます。それらもRustの利点ではありますが、個人的に魅力を感じる部分の一つに「厳密な型付けをする文化」があると思っています。それはあまり明文化されておらず、個人的に感じているだけなのですが、Rustを使う動機の1つになりうると思うので、ここで宣伝してみます。 ちなみにこの記事のきっかけの1つが アンサー： なぜTypeScriptの型定義に凝るのか です。これを読んでいて、「自分はRustの型付け方針が好きなんだなぁ」とあらためて気づきました。 技術的な正確性より「気持ち」多めなのでポエムということで。 「厳密な型付けをする文化」とは Rustは静的型付き言語なので、ソースコード上の様々なところで型付けが行われます。これ自体は他の静的型付き言語と同様ですが、Rustではどのような型を付けるかということにつ
clang/LLVMのお勉強 - aster_ismの工作室
最近、clang/LLVMのお勉強をしている。 が、某きつねさんの本は発売から10年以上たっているし、検索してもStackoverflowで同じ質問して解決してなかったりと、自力でお勉強するのはつらい。 どちらかと言えば、clangとかC/C++のフロントエンド回りについて知りたかったが、LLVMで自作言語を作るとかの内容は、それなりにヒットするけどclangにはみんな興味ないんですかね？ とはいえ、お勉強するには何か取っ掛かりがないとやりずらいし、どうしたものかと。 とりあえず、それなりに新しいLLVMについて書いていそうな本を探して読むことにした。 選んだのは、LLVM Techniques, Tips, and Best Practices Clang and Middle-End Libraries | Packt。ついでにPackt Publishing のサブスクリプションを契
コメントを書かない理由 | おごちゃんの雑文
コードにコメントを書かない事を責められた時の言い訳 私はコードにコメントを書かない。それは面倒だとか、ここに書いてある事情があるとかではなくて、「信念」として書かない。書くべきではないと思っているからだ。コメントを書いたら負けだとさえ思っている。これはもう20年来そうだ。 ちょっとしたメモのようなコメントは、つい書きたくなる。私は「自分のコードは他人も見る」「過去の自分は他人」と思っているので、その時の助けになるようなコメントはむしろ入れたい欲求にかられる。コメントで意思伝達しておけば楽だと思う。が、「コメントを書いたら負け」だと思っているから書かない。 例外的に書くのは、 ファイルの冒頭に書くGNUなヘッダ ヘッダファイルに書く構造体の宣言 コメントアウト くらいで(これらはむしろ積極的に書く)、その書かないっぷりは、gotoよりも少ないくらいだ。 なんでそこまでコメントを嫌うかと言えば
クリックだけでプログラムが作れる夢のプログラミング環境作った - ABAの日誌
ウソです。いやウソではないか……誇張です。 sarad p5.js demo 上のデモ開いて、左クリックでコード生成、右クリックでコード削除。運が良いと何かのグラフィックスを描くプログラムができる。あまりに何も描かないようだったら一旦右下の[Reset]を押して下さい。グラフィックスAPIはp5.js利用。 左クリックで生成されるコードはRecurrentJSを使ったLSTMで作られている。LSTMやRNNをつかった文書生成はいろんなところでやられていて、有名どころだとThe Unreasonable Effectiveness of Recurrent Neural Networksがある。この記事ではLinuxのソースコードを食わせてCのプログラムを作る例もある。ただ、自動生成でできる文やプログラムはいわゆるワードサラダで、文には意味が無いし、プログラムはコンパイルできない。 ならワー
inforno :: Scalaでスタック指向言語をサクッと実装する
Scalaにはご存知のとおり scala.util.parsing.combinator というパーサコンビネータライブラリがある。さらには scala.util.parsing.ast というのもあるわけだけど、これは激しく開発中な感じ。Scalaはバージョンがあがるとこういう開発中ライブラリはごそっと変わったりするので今はおいておく。ちなみに、2.7.1では前のパーサコンビネータは scala.util.parsing.combinatorold といういかにも使いたくない名前にされてしまった。 パーサコンビネータといえば言語処理系だ（そうか？）。というわけで scala.util.parsing.ast は置いておいて、とりあえずASTについてほとんど考える必要がない、簡単なスタック指向言語を実装してみることにする。実行はScala 2.7.1.finalで。 スタック指向言語とは
Lispはなぜ神の言語と呼ばれるのか - SEむううみんのプログラミングパラダイス
古から存在するプログラミング言語Lisp。その通り名の一つに「神の言語」というものがある。 なんという甘美な響きだろうか。この名前だけで男子中学生は全員習得することを決心するだろう。そのくらいインパクトのある名前である。文部科学省はプログラミング教育を推進するにあたって、この通り名を公式に採用することを真剣に検討されると良いと思う。 さて、「神の言語」の勉強を始めてみて驚くだろう。どのあたりが神なのかよくわからないのだ。たしかに丸括弧は多い。多いが、それと神との関連性はよくわからない。 何か土着の信仰の話なのだろうか？あなたがそう戸惑うのも無理からぬことだ。 私自身、前からこのフレーズは聞いたことがあったが、あまり理解していなかった。そこで今回改めて調べてみたので共有しようと思う。 「神の言語」の由来 そもそも、Lispは神の言語だと誰が言い出したのか？どうやら海外でそのような歌が作られた
100 Days of Codeをやってみた - Arantium Maestum
ツイッターで100 Days Of Codeというチャレンジがたまに流れていて、面白そうだったのでやってみた。今年も終わりに近づいているので今更ながら振り返ってみる。 100 Days Of Code概要 ルールは簡単： なるべく毎日１時間以上、業務外のコードを書く githubに載せる twitterで進捗をつぶやく 途中で風邪をひいて寝込んだりいわゆるライフイベントが発生したりして合計で５日ほど空いてしまったが、８月１４日にはじめて１１月２６日に終わった。 積ん読していた本をある程度消費したい、という欲求もあり、100日間基本的に本に載っているコードや演習問題、オンラインのチュートリアルなどをやって過ごした。自前のプロジェクトを立ち上げたりしなかったのですこし寂しい気もする。近いうちに自作言語に手を出したい。 やったこと（というか読んだ本） Essentials of Programm
ガベージコレクション実装したいからLISP風インタプリタ作った
ガベージコクレクションは手を動かすまでがちょっと遠い 下記の記事で書いたように、私は今ガベージコレクションに夢中です。 少し勉強して、ガベージコレクションの難しさの1つは「実装してみる」までが遠いところなのではないかと思っています。 ガベージコレクションというのは、それ単体で成り立つものではなく、基本的にはプログラミング言語の処理系と一緒に実装されるものです。したがって「ガベージコレクションに入門するぞ〜」と意気込んで理論を勉強しても、実装する対象となる適切な処理系がない、という問題に直面することになると思います。 多分、多くの人がそうなったのでは？と勝手に予想しているんですが、どうなんでしょう。 少なくとも私はそうなりました。 現実の処理系は複雑で難しい ガベージコレクションが実装されており、かつ日本語話者が関わりやすい処理系としてはまず CRuby が思いつきます。しかし CRuby
LR parser 101を完走した - ゲームリンクスの徒然なる日常
はじめに yui-knk/lr-parser-101 というRaccを使って電卓を実装しつつ、パーサージェネレーターを利用したパーサーの作り方を学ぶチュートリアルを完走した時の覚書です。 僕個人のパーサー周りの経験としては 拡張BNF記法がちょっと読み書きできる 元々parse.yに興味があり、たまにリファクタリングのパッチを投げている Rubyソースコード完全解説 や Rubyのしくみ などを読んでRubyのパーサー周りのある程度の知識はある という感じです。 なので、どちらかというと全くの初心者という感じでもないところからの覚書になります。 LR parser 101とは？ Bison Killerこと yui-knk さんが書かれた電卓を実装するチュートリアルです。 github.com Raccというパーサージェネレーターを使いつつ、パーサーの作り方を学ぶファーストステップとして非
マクロすごい。すごいマクロ。 - (define -ayalog '())
マクロすげええええええええええええええ 2013-07-17 09:21:57 via Twitter for iPhone ということで、マクロに感動した。マクロ凄い。 このブログを書くようになったきっかけである9LISPからかれこれ1年半が経ちました。 9LISP - 037 当時、Lispを勧められたとき「何が凄いんですか？」って聞いたら「ifが自分で書けるんだよ」と某@valvallowさんに言われたのを今でも覚えています。あと、valvallowさんに「LispはFortranの次に古い言語で、1958年にジョン・マッカーシーによって"発見"されたんです。ちなみに僕のお父さんも1958年生まれなので、つまり僕のお父さんはLispです！」*1って言われたのも覚えています。ついでに言うと当時の僕はFortranってなんとなく名前しか知りませんでした。むしろ、今でも名前しか知りません。
これから流行る言語 | 雑記帳
新言語にできることはまだあるかい なんとかWIMPS 最近（1ヶ月くらい前）、こんな記事が出ました： 新しいプログラミング言語が出てこない(新しく出てた言語を追記) – きしだのHatena Kotlin, TypeScript, Rust, Swift以降にみんなが話題にするような新しい言語が出てこない、それはなぜか、みたいな趣旨です。客観的に見れば「新しい言語は常に出続けている」わけですが、「みんなが話題にするような」というのが多分曲者なんでしょうね。 例え話をすると、新しい若木は常に生えてきているんだけど、大木に成長するには時間がかかるので、大木にしか興味のない人には「この8年間で新しい大木は登場していない」と判断してしまうのかもしれません。 まあ私としても、Web (HTTP) APIを書く言語とか、JSON色付け係が使う言語はもう出揃ってしまったのかもしれないという気はしなくもな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
