[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: wip-namespace review
Re: wip-namespace review
Sun, 25 Apr 2010 19:37:06 +0200
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
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 ;-)
> 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)
>> 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
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"),
> 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!