On Tue, Oct 03, 2023 at 12:51:57PM +0200, felix.winkelm...@bevuta.com wrote: > Ok, I find attached a variant, both more ugly in interface and > implementation, since ##core#module and functor do not yet allow > renamings to be handled. Also, "define-interface" has no notion > of this, so "(rename: OLD NEW)" is purely applicable in "export".
I'd prefer if we could develop this a bit further to make the rename form accessible to module as well. Not sure if that would be useful in functors. I've never used them, but it seems to me that the functor's implementation is in a better position to determine whether to rename on export or not, not the functor definition itself. If you agree that it makes little sense to support it in functors, perhaps it's better to call ##sys#syntax-error when the functor definition includes renamed exports? > I prefer the first variant, but feel free to push which one you > like more. As it is, the first variant is cleaner indeed, but if we decide to support renames in the "module" form as well, I think we should go with the second variant. I had a quick look and the main obstacle seems to be that ##core#module is not very extendable, because it assumes the first two "arguments" are special, and the rest is the body (IIUC). Would it perhaps be possible to simply expand (module FOO (exps) BODY) to something like the following? (##core#module FOO (non-renamed-exps) (export (rename: name1 renamed1) ...) BODY) Perhaps a bit hand-wavey (sorry), but I think this is simpler than trying to change ##core#module. Cheers, Peter
signature.asc
Description: PGP signature