chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] export/rename


From: Peter Bex
Subject: Re: [PATCH] export/rename
Date: Mon, 9 Oct 2023 16:17:36 +0200

On Tue, Oct 03, 2023 at 12:51:57PM +0200, felix.winkelmann@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

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]