Open gilch opened 1 month ago
Is a fully-qualified alias like in (hissp..!#prelude)
worth it to avoid a (hissp.._macro_.prelude)
if (hissp.._M.prelude)
could have worked to begin with?
The alias obscures the more direct way of doing things (which it must expand to anyway) and may encourage users of Hissp to the do extra work or reimplementing aliases for their own modules (which is not hard with macro help though), but _M
is at the cost of slightly more cryptic macro namespaces (which one would get used to fairly quickly) and at the cost of using up a short global name which the user might want for something else. Usually Python globals are more descriptive, but sometimes one-letter names are used when implementing well-known equations.
Adding an alias for hissp.macros.._macro_
to hissp.__init__
seems like the more conservative change to try first, and the fact that hissp._macro_
exists is itself precedent for such an approach, despite the aforementioned objections (and a hissp..!#
alias might be reason to remove it), but implementing it isn't trivial, because alias
itself has too many special cases (see #174). I could re-implement it in Python, but that feels like a DRY violation, and there are edge cases around kwargs to tags that I'm not sure I've tested adequately.
Looking back at options together,
hissp..prelude#:
hissp..!#prelude
(hissp.._M.prelude)
(hissp..!#prelude)
_M
looks pretty good, but it also kind of looks like a type variable, not that Hissp modules would use those, although a .py file mixing in readerless might. That's an argument for status quo.
hissp._m
seems less bad?
hissp._macro
is also an option but doesn't seem worth the bother. The trailing underscore at least suggests a hook/magic a little bit.
Given the surprising complexity of making hissp..!#
work on tags (re-implementing alias
, basically), hissp..prelude#
and hissp..alias##
seem like better options right now, though I'd consider them unstable.
I like the discoverability of the macro namespace. Having it named that is helpful. The first line of a Lissp module is almost always going to use
alias
,prelude
, or some equivalent macro, and it has to be spelled out completely, like(hissp.._macro_.prelude)
, which seems a little verbose/ugly. After that, fully qualified macro names are mostly hidden, even in the compiled output (since macros have expanded by then), however, the compiler does insert a comment with the macro name.Possible alternatives:
_macro_
(Status quo, for comparison.)(hissp.._macro_.prelude)
__macro__
Even longer. More obviously a magic hook, but such names are technically reserved for Python proper. There's a chance it could steal it one day.(hissp..__macro__.prelude)
_mac_
Not too different. Probably not worth the reduced clarity.(hissp.._mac_.prelude)
_m_
Much shorter, but still not pretty.(hissp.._m_.prelude)
_M
Some risk of collision for a name this short without the trailing underscore, although being "private" to the module with the leading underscore makes this less of a concern. Almost looks like Hungarian notation.(hissp.._M.prelude)
Qz
Omitting the trailing underscore is questionable but it looks better. Macros themselves aren't necessarily private, but their namespace shouldn't be directly imported almost ever.Qz
has precedent as being meaningful to the compiler proper, not just the reader/munger (QzMaybe_
). It is unlikely to collide with anything not from Hissp, but makes star-importing one Hissp module into another kind of broken, without the explicit__all__
. Star imports are questionable practice (and__all__
may be good practice, and may be easier with macro support), but I don't want to prohibit them. This is probably a bad idea.(hissp..Qz.prelude)
!
orQzBANG_
(hissp..!.prelude)
I think this one looks the best, but again, no leading underscore.hissp..QzBANG_.prelude:
Hebigo isn't munged, so it might look like this._!
_QzBANG_
(hissp.._!.prelude)
With the underscore.hissp.._QzBANG_.prelude:
Kind of cryptic compared to status quo, but not much worse._M
wouldn't have this problem._-
- or_Qz_
(or_QzH_
, given #256)(hissp.._-.prelude)
Not obviously better than_M
. Not as pretty as_!
, I think.hissp.._Qz_.prelude:
Not really worse than the status quo, but cryptic.hissp.._QzH_.prelude:
Maybe slightly worse, and still cryptic._M
seems best.Another option for Lissp is a reader macro. A fully qualified function can be used at read time, even if it's not in a macro namespace, but it could expand to a fully qualified macro invocation. Prettier things like
hissp..prelude#:
Only does the prelude.:
is a dummy arg to avoid the longer*=#()
.(hissp..!#prelude)
Prependshissp.._macro_.
. Like a fully qualified alias.(hissp..!#alias ! hissp._macro_)
Same.hissp..!#prelude
Prepends and invokes. Maybe less flexible.hissp..!### alias ! hissp._macro_
Same, but with more read-time args.hissp..alias## ! hissp._macro_
Only does aliases.could be possible by adding reader macro functions to
hissp.__init__
, even without changing the name of the macro namespace. Some of these variants would work in the EDN Hissps. This wouldn't help Hebigo at all (no custom reader macros), but it (currently) has!
as a built-in alias ofhebi.basic.._macro_.
, which could have something similar added.