Re: wip-namespace review

[Ludovic Courtès]

Hello Andy,

Andy Wingo <address@hidden> writes:

> Thanks for the review. Some more background:

Thanks for filling in the dots!  That’s allowed me to understand the
transitions much better.

> On Sat 24 Apr 2010 18:55, address@hidden (Ludovic Courtès) writes:
>
>> Regarding the single module/variable name space, I was convinced that it
>> was annoyingly constraining module names; however, as illustrated at
>> <http://thread.gmane.org/gmane.lisp.guile.devel/10166> that constraint
>> has vanished somehow, making it less of a problem IMO.
>
> It still does constrain module names, but only if you have a local
> variable of the same name. If I even do (define bar ...) in my '(foo)
> module, I can't define a '(foo bar) module. This is undocumented, leads
> to poorly-understood errors, and is just wrong ;-)

I agree.

[...]

> Beyond that, I don't want to merge in r6rs support that has hacks around
> the module system (cf recent thread about (rnrs) and (rnrs
> syntax-case)). The version comparison code is already complicated enough
> as it is; I would rather not maintain hacks in the future.

Agreed (though it’s still unclear to me why the example referred above
doesn’t expose the problem while (rnrs syntax-case) does.)

[...]

> So, we've gotten rid of %app, but old code will still work if
> --enable-deprecated is used.

[...]

> Then eventually we add a submodules array to modules themselves, switch
> module-ref-submodule to use that, and voila separated namespaces, with
> back-compat in deprecated.scm.

Nice that you found a way to maintain backward compatibility.

[...]

>> There also needs to be the C counterpart:
>>
>>   #define scm_module_index_import_public_interface 9
>>
>>   #define SCM_MODULE_PUBLIC_INTERFACE(module) \
>>     SCM_PACK (SCM_STRUCT_DATA (module)
>>     [scm_module_index_public_interface])
>>
>> and change ‘scm_module_public_interface ()’ to use that instead of
>> ‘scm_call_1 (...)’.
>
> This won't work in general, because in the case in which you have
> deprecated code enabled, you still need to go through the Scheme
> function (overridden by ice-9 deprecated).

Indeed, I had overlooked that.

> Regarding the indices, only a subset of module's fields currently have
> record indices and accessors defined. Given that these would be new C
> interfaces, I would prefer to avoid defining them unless there were a
> need.

Yes, sounds reasonable (in general, I’m inclined to reduce the new C API
to the bare minimum.)

>> Finally there needs to be ‘scm_set_module_public_interface_x ()’ as
>> discussed at <http://thread.gmane.org/gmane.lisp.guile.devel/10136>.
>
> I'm not sure; Lilypond seems to be using this interface as:
>
>       mod = scm_call_0 (maker);
>       scm_module_define (mod, ly_symbol2scm ("%module-public-interface"),
>                          mod);
>
> Which is a verbose (and somewhat incorrect) way to say, "export
> everything in this module". Perhaps, given that this would be a new
> interface, we should just provide a more appropriate interface --
> module-export-all! or something.

Right.  TeXmacs had a similar use case IIRC.

Could you reply to the thread above and see how they like it?  :-)

Thanks for the detailed explanations, and again sorry that I didn’t find
out on my own!

Ludo’.