Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider a shorter name for _macro_ #257

Open
gilch opened this issue Jul 14, 2024 · 3 comments
Open

Consider a shorter name for _macro_ #257

gilch opened this issue Jul 14, 2024 · 3 comments
Labels
design Notes and ruminations that might lead somewhere

Comments

@gilch
Copy link
Owner

gilch commented Jul 14, 2024

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)
  • ! or QzBANG_
    • (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 Consider munging - as QzH_ instead of Qz_ #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) Prepends hissp.._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 of hebi.basic.._macro_., which could have something similar added.

@gilch
Copy link
Owner Author

gilch commented Jul 14, 2024

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.

@gilch
Copy link
Owner Author

gilch commented Jul 17, 2024

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.

@gilch gilch added the design Notes and ruminations that might lead somewhere label Jul 19, 2024
@gilch
Copy link
Owner Author

gilch commented Sep 28, 2024

I'm considering a rename to _meta_, since I'm not calling tags "reader macros" anymore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design Notes and ruminations that might lead somewhere
Projects
None yet
Development

No branches or pull requests

1 participant