chicken-hackers
[Top][All Lists]
Advanced

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

Re: [PATCH] export/rename


From: felix . winkelmann
Subject: Re: [PATCH] export/rename
Date: Mon, 09 Oct 2023 17:01:47 +0200

> I'd prefer if we could develop this a bit further to make the rename
> form accessible to module as well.

Sure. I personally never felt the need for rename on export and 
wanted to add this just as a base to build R7RS support on.
Bindings and aliases are so easily done in Scheme that it doesn't
seem necessary to complicate existing forms further.

> 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.

I agree. The functor is an _external_ interface, how the
implementation names stuff inside is of no concern.

> 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?

Personally I prefer a separate form, but this makes sense of course.

> 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).

Correct, that#s why I began with a separate export form.

> 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)

It's all the same. Let's keep ##core#module as it is (and perhaps "module"
itself) I wonder whether we should expend so much thought about this, to
be honest. The export/rename localizes the functionality and doesn't
require changes to existing code. The precedent of the syntax: and
interface: never was a particularly good one (we should have used separate
export forms for those right from the start), so adding funny markers or
possibly ambiguous special cases is not my favorite approach.


cheers,
felix




reply via email to

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