-
Notifications
You must be signed in to change notification settings - Fork 4
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
[enh] Re-exporting macros from another module #11
Comments
One thing I've thought about since I posted this is that having seen Racket, what Python is missing is a separation of the concepts of In Python there's just There's the magic list For me, having this capability in one form or another is starting to become important, as Perhaps, as you said in email, just an import statement can't solve this. Maybe the This would require some added complexity in the logic that imports macro definitions (it would have to perform some form of lookup), but maybe it's doable? If this issue is not relevant for what you currently need from MacroPy yourself, I might take a look at some point if I find the time - I'll keep you updated. |
star imports are frequently discouraged in python, they are used
Frankly, I've still to understand why can't you split such a module in
Maybe, but maybe, if you are trying to replace an entire language with
As of now it's not relevant (yet). While I understand it general |
Star-imports, exactly, that's what I meant by Python "almost getting it right". The About splitting, in this particular case it's so far purely a maintainability consideration. Also, I want the import statements at the use site to be as brief as reasonable. The name of the library aside, a I suppose it's possible to refactor it that way. I think I'll try that, thanks for the suggestion! I'm not sure if I'm trying to replace a language with another, or just extend an existing one. With macros, I'm not even sure if "programming language" is a well-defined concept. Is Python plus I suppose what I really want is a building material, like Lisp, so I can replace repetitive patterns with syntactic abstractions, and borrow such abstractions from other languages when I see one that could simplify my code. Whatever the language is, it should run Python libraries, not have a separate namespace for functions and data (so no Hy), and I really wouldn't mind if the code mostly looked like Python. ;) If the re-export feature is not relevant for you, don't worry - we both know how open-source development works :) |
Thanks for the refactor suggestion, it was excellent! It solved the issue for me. Thinking back, I suppose the problem was that I was thinking of all code as one kind of thing - whether it be regular functions or macros. (I mean, aside from the obvious difference of AST transformation vs. regular run-time computation and all the consequences of that.) I think one possible way to resolve this issue would be to mention in the noob tutorial, that the way to keep things composable (and maintainable) is to manually separate the syntax transformers (regular functions processsing ASTs) from the macro interface, because macros cannot currently be re-exported (whereas for regular functions there are no such limitations). Therefore, to provide the macro interface in one central module even when the implementation is split into several modules, ... A downside is that from unpythonic.dynscope import dyn, make_dynvar
def nogensym(*args, **kwargs):
raise RuntimeError("No gen_sym function set")
make_dynvar(gen_sym=nogensym)
@macros.expr
def mymac(tree, gen_sym, **kw):
with dyn.let(gen_sym=gen_sym):
return _mymacimpl(tree) # or "return (yield from _mymacimpl(tree))" if needed ...and presto, no spam in the call signatures. It's then available as |
To improve both maintainability and ease of use of macro libraries, it would be useful if a macro-definition module could re-export macros defined in another macro-definition module.
This would allow the macro library maintainer to structure the source tree logically, and then just re-export all macros from the library's
__init__.py
(just like it is possible to do for functions in pure Python).This would allow the users of the library to just
from somelibrary import macros, ...
, without caring about in which particular submodule of the library each of the macros is defined.There are probably some pitfalls I'm not seeing here; thoughts?
The text was updated successfully, but these errors were encountered: