phf: ben_vulpes: i think best way to answer that question is to read a lot of existing code from different backgrounds (pre-2000s code, famous people code, etc.). my rule of thumb is that you use optional if ~at call site~ it's still obvious what the argument means. otherwise you promote it to keywoard. (run "foo" `("-p" "bar")) makes sense, but (run "foo" `("-p" "bar") stream) you start guessing. is it input stream? is it output stream?

phf: not enough reverb. i always thought baliset being a 70s instrument, considering that they had those portable source of energy in their shields, would be a kind of guitar moog

phf: deep purple covers on a loop?

phf: you have a set of (incomplete and adhoc, but there) crypto operations. they speak their own language. they can succeed, they can fail, but none of that has to do with "external programs". that's a different set of operations that deals with unix etc. that speaks its own language

phf: no, that's no the issue, it's more like a complexity along arbitrary lines

phf: but your bad-signature is an external-program-error, so the whole things is a swiss chese

phf: well, more important whose reporting the failure. if you want to pass through to the user the fact that there's a shell call out somewhere and it has all kinds of mechanisms. but verify should probably speak for itself in its own terms.

phf: it's an "overkill" for a "unix script", because you throw all that data out anyway soon after constructing it. but in a lisp instance, when you already have all that data in the ~correct form~ you can start writing a dozen of different functions to analyze it, without getting bogged down on format trivia all over the place

phf: so instead of doing subseqs you can just (pathname-path ...), you check for "false" by a simple null check, you check for hash equality with eql or =

phf: fwiw btcbase parses path component into a pathname, and the hash is (member nil bignum)

phf: the main folly are the unixisms all over the place. lisp works with a clear read/eval/print cycle. read means that you want to take outside input and convert it into a concrete data structure. so you shouldn't have a hash with strings in it. things like (string= "false" (gethash 'hash c)) should not happen so far down the call chain. your ~reader~ should convert the input data into a format that's easy to work with. the check could've

phf: http://btcbase.org/patches/hashes_and_errors#L118 you don't really want to do this. you're subseq'ing there to strip the a/ b/ but that's not at all a guarantee! i have a vpatch with `diff -ib -ruN /Users/pf/cmucl20d-build/src/hemlock/abbrev.lisp src/abbrev.lisp` in it for example. at the very least you want to abstract it away into its own function. that would correctly operate on a hashed-path datastructure. ☟︎☟︎

phf: also in the same handler-bind you're losing a branch. if there's an error, but it's not "BAD signature", then the whole verify silently succeeds. you probably want to (error c) in the else branch to rethrow whatever ☟︎

phf: there's not much discipline on unix with stderr/stdout. particularly gpg seems cavalier with it. so i wouldn't even bother with error/output separation. i'd make it always return a single value, string that's combined stdout/stderr, and fail when status code is not equal to zero. maybe add a key argument, that splits them if need be, but only once there's need. ☟︎☟︎☟︎

phf: also as a rule you don't really want to let string output streams escape their scope. they don't have standard type (one cmucl it's lisp::string-output-stream for example), so you can't test for it, and for all intents and purposes they act as incomplete builders: you can't do anything with them except get their value, so why not get value there and then? ☟︎

phf: that run is a bit weird

phf: i for one am looking for to a gattaca future, where i have to hire a standin for myself. to run amazon echo and nest and facebook and all the other things like that so that there aren't any irregularities

phf: kind of like cat-v, from recent memory, was a fledgling tmsr at one point: mp died, asciilifeform's left elsewhere, maggots still there

phf: most of the things seem to have sane core, which you can dig for for a long time, but it's there, and the reason is that ~doing anything at all~ is so much effort, everything that's done is a byproduct of some human being constructively spending energy at one time in one place.

phf: it's called v8, which is a case of talented programmers working for fuhrer