[!REBOL3 Modules] Get help with R3's module system
if the module has a name and you rename the file, it should fail, which is probably what it does already.
in slim I also added an extension filename, in order to allow import by name to work with alternate extensions which is very usefull when you want to use the module system as a plugin mechanism for an application.
extension filename == "filename extension /refinement"
Technical reason = because one has a name and the other doesn't. I'm not dumbing it down, it really is that simple. Say you are a module, and I want to import you. It's rather straightforward, I just add your exported words to my collection (how I do that depends on what I am, but that's a story for another time). And then I can use those words, no problem. But what if I don't know whether you have been imported already? Or what if I know you have been imported by someone else, but I want to use you in particular instead of someone who just looks like you? Or what if you have data that you want to share, or resources that can't be used more than once at the same time? Or what if you want to know if a previous version of you was imported already, so you can get that guy's data or resources and take over for him? To do all of these things, you need a way for others to refer to you, a name. If you have a name, I can put you in a collection with other modules and then others can look in that collection for a module of that name and if they find one they can know that it's you. Simply having some way to find you in a crowd makes all of that stuff possible. It really is that simple.
Another trick that I can do if I have a name for you is to just put you in a box and then import you later: delayed modules. If you don't have a name, I can't find you in that box, you look just like all the other delayed modules.
It turns out that every little feature or quirk of the module system is there for a reason that is as simple as that. It's just that there are a lot of these little situations that pop up when you are writing a module system if you want to make it work properly. Especially if you want to hide a lot of that complexity from the user, to deal with the complexity in the module system itself so the programmer using it doesn't have to think about any of that. Simple on the outside requires some complexity on the inside.
Carl, how simple would it be to implement REFLECT module! 'title ? See here: http://www.curecode.org/rebol3/ticket.rsp?id=572(low priority still).
As of alpha 110, all tests of the module system pass! Time to write more tests :)
Regarding REFLECT... would store the spec in the module! object. There is room for it.
Glad to hear it!
Time to show examples of all of what it can do... and get developers using some of this good stuff.
The spec is already stored in the module object.
Or what do you mean by spec? The module header returned by SPEC-OF is stored in the module object. See here: http://www.curecode.org/rebol3/ticket.rsp?id=1586
Let's switch this discussion to where it belongs.
I was referring to my understanding that many module-related things are half-broken at the moment.
Last time this came up, you (Brian) seemed to be aware of the problems.
As it seems those issues are forgotten by now, I guess I'll have to dig them out again.
No, they were fixed in a110. We had that discussion before a110.
No, we had it post A110 and you said "whoops, last-minute errors slipped in".
I'm digging ...
That was a109. There was another las-minute error that slipped into a110, but it wasn't a module system error, it was a startup error.
There has only been one issue in the modukle system itself (aside from the possible cURL thing) that has been discovered since a110, and that is not as much a bug as it is a gotcha, and hasn't been reported yet.
(stupid typos in recent messages - bad keyboard or fingers, can't figure out which)
Ok, seems the bugs I was referring really were in A109.
At least those seem to be gone now in A110. So maybe it's time to look at this stuff again.
Yeah. We have a pretty thorough test suite for modules, and all tests pass for a110. And I checked the tests for accuracy too :)
Probably time to publish this test suite.
In any case, if A110 is deemed good, I'll certainly have another look at the module system.
Sorry for spreading FUD based on me mistaking the A109 bugs for still present in A110.
Most of a110 was dedicated to fixing those bugs, so I understand and appreciate the sentiment :)
I can get to the publishing of the test suite next week, barring unforseen stuff. This week is going to be swamped for me.
Maybe using the same name for the "isolate" option and the "/no-share" refinement would be a good idea.
I.e. either isolate for both, or no-share for both, or something else for both (like "private").
It shouldn't be a problem once we have the documentation. The /no-* options were named consistently like that by Carl for a very good reason though, to set them apart from the other options. The /no-* options can't be specified from the Needs syntax; this was a deliberate design choice, as every one of the /no-* options breaks normal module behavior in specific ways that would affect the design of the module code. As such, these needed to be exceptional cases rather than normal behavior.
If import/no-share and options: [isolate] have the same effect, using the same name seems appropriate.
If they don't, then nevermind.
I'll bring that up with Carl. He does the API design, at least the stuff that is arbitrary.
I only do the stuff that is inherent in the semantics of REBOL. And the implementing, of course.
Renaming wish submitted as #1807.
Moving this discussion what suffix to use for modules from !REBOL3 Proposals: Brian said: No, you're not really supposed to use .reb, you're supposed to change the setting to what you were going to use anyways. That's why the setting is .reb: There is no consensus on what extension to use, so the setting is set to something noone uses."
This is a distribution nightmare.
I strongly suggest that the default-suffix be changed to something practical which stands a chance of reaching consensus.
Module path searching only works with non-file! module names. I.e. import 'foo will search the system/options/module-paths for a file name %foo.reb. This search is a _very_ useful feature which we shouldn't rid ourselves of by stupid wars over which suffix to use. As a module author, I want to use a suffix which I know will make using the module easiest for my target audience. As a module distributor, I also want to make it easiest for my target audience to use the modules _and_ I need to enforce consistency within my distribution. The only one who does not really care about the suffix is the actual user. The user just wants to use third-party modules without having to homogenise their suffixes first. But the burden of choosing a sensible suffix is currently imposed on the user. This does not make much sense.
To be more precise: having a default which is actually intended _not_ to be used does not make much sense.
Having a default which _is_ intended to be used would be a strong incentive for both authors and distributors to stick with this default.
This vastly reduces friction within the wider ecosystem, making life easier for all parties involved.
I can only say that Carl set the default, but I haven't seen any published scripts by him that use it. Good point, Andreas. Too bad we can't settle on .r, because R has taken that extension in most standard tools, and OSX uses .r for something else.
.rez resource files. It's a pain.
Here's another interesting trick: Make %rebol.r a unnamed module by putting type: module in its header and not giving it it a name. This isolates the words in it in its own context instead of putting them in the user context, controls the visibility of its code, and makes it easier to free up the memory it uses because its context is thrown away afterwards. It's the perfect occasion for an unnamed module: run once, and done for effect. %rebol.r is a great place to set your preferred system/options/module-paths and system/options/default-suffix, to delay-load commonly used modules and extensions that you have checked out already, and to patch or wrap anything that you need to.
%rebol.r is run before any user code is run, even the --do and --import args. This makes it the best place to hack the module system for your own uses.