VoQn さんはインスタンス qiitadon.com のユーザーです。アカウントさえ持っていればフォローしたり会話したりできます。 もしお持ちでないなら こちら からサインアップできます。

あっダメ、つかまった

今から会場向かう

CUD、ちゃんとやろうな

過去に簡単なレキシカルスコープの環境フレームを実装したことあったはずなんだけど、そのソースコードどこやったか忘れた……

バグじゃなくてインシデントとしてラベル付けするのは一応意味も効果もあって、手を入れるべきところはソースコードなのかドキュメントなのか仕様なのかってちゃんと焦点を探すところから始められるように習慣つく。「バグ」呼ばわりすると現象の再現ばかり意識にとられちゃう

自分が管理するBTSとかタスク管理表、基本 bug ってラベル付けないで incident にしてる。ライブラリやフレームワークの、つまりコード書く人間ですらユーザーとしてすぐ「バグ?」って不可解な現象をすぐバグとして報告してしまうこと多し

feature は装置における機能を指すので、多分ハードウェア屋の語彙が転じて ソフトウェアの「機能」にもそう言われるようになった

内々でNoteの方にあのへんのコラム書きたがる方々を誘導したらいいんじゃないすかね(Note、なんかそういう方面のプログラマの書き手の方向が多めなのであっちで技術的な事書く気になれず)

ファンミ登録した(なお最近まったく投稿していない模様)

VoQn さんがブースト

Qiita/Qiitadon ファンミーティング #1 やります! ( @yyano さんが提案してくださいました 😉 )

Qiitaって最近どうよ?とか、こんな機能欲しい、とか、飲みながら話せたらいいなーぐらいのゆるい会の予定です。

日時: 2/27 火曜日 19:30 ~
場所: 弊Increments社オフィス(渋谷)or 近隣のHUBで調整中
人数: MAX15人ぐらいで。

申し込みフォーム代わりに一応イベントを作ったので「参加してやるぜー!」って方は以下からチケットをぽちっとしてください(無料)

peatix.com/event/352768/view

予定が近いことからも分かる通りですが、初回は来れる人で集まってゆるりとやろうかなと。3月にもまた企画しようと思います!

可能な限りバックトラックしない上に厳格に型を固定させたパーサーを書くの、見事に「16進数浮動小数点小数リテラル」で諦めざるを得なかった(他の8進数や2進数と合わせて任意倍精度のintもuintもfloatもdoubleもflonumも含めた巨大なレキサーが生まれてしまう…)

こうするとパースする時は parseExpr :: Parser (Expr' Location) になるし、型推論させる時は infer :: TypeEnv -> (Expr' Location) -> (Expr' TypeInfo) みたいな表現になる

うーん、これだったら、インタプリタ実行の時のメタ情報が多岐に及ぶケースを見越して

type Expr = Located Expr'

data Expr’ a
= Int Int
-- ...
| List [Expr a]
-- ...
| With a (Expr a)

pureAst: Expr a -> Expr a
pureAst (With _ expr) = pureAst expr
pureAst (List elems) = List $ pureAst <$> elems
pureAst atomic = atomic

ってやってしまって、構文木の型の方にメタを仕込めるコンストラクタ増やして純な木を取り出せるユーティリティを付属で提供する方が筋がいい気がしてしまう

Elm の方はそういうアプローチだったはずなので見にいったら

type Expr = Located Expr_

data Expr_ =
-- ...
| List [Expr]
-- ...

としてあって、結局メタ情報を包んだ型を構成子にすることで解決していた。

抽象構文木とそのメタ情報の管理切り離したかったので

data Ast = AstInt Int | AstBool | AstList [Ast]

data Location = Location String Int Int

data Located l a = WithLocation l a

type Expr = Located Location Ast

とやってみたけれど、これ Ast.List [Ast] をパースした時にそれぞれの Location が喪失されちゃうじゃんって気づいた

is が付いてるから isAbleToSubmit の方か。(英語的には canSubmit でいいじゃん感あるけど、プログラミングにおける boolean への命名って is プレフィックスで統一してないと誤解する人おるけん)

isEnableSubmit ? isAbleToSubmit ?

1e5 って書いてあるリテラルってIntegerとしてパースできるべきなのか、 _e サフィックスがついたわけだから 浮動小数点数として一元化させるのがよいのか悩む