gilch

BTW, attrgetter names can have internal dots: ```python #> (-> (object) (@#__class__.__class__.__name__)) >>> # Qz_QzGT_ ... # hissp.macros..QzMaybe_.Qz_QzGT_ ... __import__('operator').attrgetter( ... '__class__.__class__.__name__')( ... object()) 'type' ``` Really leaning against `..`...

Adding `get#` as an abbreviation for `operator..itemgetter` (single-arg version only). That makes getitem work in `->`. First (car) is now `get#0`, which is really nice; implementation is the best name....

Added a tutorial on making a macro for easier slice notation. I don't know that I want to bundle this one. It works best with a helper class. It's small...

I figured out how to do it without the helper class. Added in #166. New version also added to macro tutorial.

Deleted FAQ in #158. I can still point to an older version of the docs if necessary, I just won't be maintaining it anymore. I'll probably look over it again...

If we get rid of collection atoms, #130, that frees up the `[]{}` characters for other things. We could write extras in square brackets, like `foo#[1 2 3]bar`, `foo[1 2...

`#` is now the macro for sets. But `_macro_.#` is still read as a reader macro. `_macro_.\#` works, but probably reader macro names should not be allowed to end in...

`##` should probably be a single-character reader macro. It's currently a symbol. `\##` works though.

`.` is a module handle. For the empty-named module. Which is weird. That would totally be a syntax error in a Python import statement. Empty is not a valid identifier,...

`..` is a SyntaxError. `...` is Ellipsis. Four or more is likewise a syntax error. This is related to `.` being the empty-named module. Maybe these errors should be symbols...