はじめに 私は現在、Salesforceで使われているSOQLというクエリ言語のオープンソースとしての再実装に取り組んでいます。 以前はTypeScriptで実装を行いましたが、直近ではGoによりパーサーを書き直し、実行エンジンの再作成をしています。 Goによるクエリパーサーが主要なクエリへの対応を完了したので、クエリをER図として可視化するツールを作ってみました。 ツールで使用したもの フロントエンドはVanilla JavaScriptで作っています。 ER図のレンダリングにはMermaidを使用しました。本当はPlantUMLの方が好きなのですが、クライアントだけで何とかしたいのでMermaidを選びました。 SOQLのパーサーははじめに記載した通り、自作のものを使用しています。 パーサーはパーサーコンビネーターとして構築されており、パーサーライブラリも自作のものを使用しています。

本ドキュメントでは、Go言語向けのパーサー・コンビネーター・ライブラリ「takenoco」について解説します。 パーサー・コンビネーターとは、小さなパーサー(構文解析器)の関数を組み合わせて目的のパーサーを構築する、パーサーの構成方法です。 プログラミング言語の「高階関数」という仕組みによって比較的容易に実現することができます。 takenoco は、文字列、または、任意の型のスライスをパースし、AST (abstract syntax tree; 抽象構文木) に変換するための基盤と、汎用的な小さなパーサー群、生成規則によるASTの変換機能を提供します。 takenoco のパッケージ takenoco は以下のパッケージによって構成されます。 base/: 型、パーサー基盤および、文字列/任意の型のスライス 共通の汎用的なパーサー群を提供します。 string/: 文字列の汎用的なパー

はじめに Goの自作パーサーコンビネーターライブラリ「takenoco」を使って、トイ言語を作ったり、まだ公開していないプロジェクトでパーサーを作ったりしているのですが、自分も活用できる実用的なサンプルを作ろうと思い、JSON・TOMLパーサーの作成を思いつきました。 完成したのがこちら「go-loose-json-parser」です。 ※作り始めたとき、JSONパーサーだけのサンプルにしようかと思っていたので、リポジトリ名にはTOMLが入っていません😖 Live demoはこちら ※wasmで動いています Goには既に有名なTOMLパーサー(1),(2)もあるので、作成する必然性は無いのですが、車輪の再発明は楽しいですね。また、プロジェクトの依存関係が自家製なのは精神衛生上、大変良いです。 コンセプト まず、最初に作り始めたJSONパーサーについて、パーサーライブラリの特性も考え、ゴリ

前回、 Go の学習を始めた際のまとめを記事として書きましたが、Makefileの作成は後回しにしていました。 Go のプロジェクトでは殆どの場合、 Makefile によりビルドを記述しています。Makefileは GNU Make 用のルールを記述したファイルで、 マルチプラットフォーム で利用することができます。 Makefile 完成版 今回、 Go 用のマルチプラットフォーム (Windows-cmd.exe, Windows-PowerShell, Windows-Git-Bash, Linux(ChromeOS-Crostini(Debian), WSL(Ubuntu), 他)) で動作する Makefile を作ってみました (GNU Make は Chocolatey の非 MinGW 版 4.3 を使用しました)。 Docker の scratch イメージで動作するよ

最近、 Go の学習を始めました。入門書や 公式のチュートリアル を終えてもなかなか解らないことをまとめてみました。 1. パッケージ作成・パッケージ管理 1. a. ディレクトリ構成は非公式ながら標準と目されるものがある(らしい) Standard Go Project Layout /cmd にmainのアプリケーションのソースを置きます。 /pkg にライブラリのソースを置きます。 /src にソースを置いてはいけません。 なお、このディレクトリ構成は go コマンド(go build 等)がデフォルトで認識するディレクトリ (/src , /pkg , /bin) とは全く異なるので注意が必要です。 2021-05-24 追記 このレイアウトは殆ど普及していないとのこと。また、リポジトリ名が「標準」を名乗るのは誤解を招くとのissueも挙がっています。 個人的な意見として、ライブラ