Comments on: Battling the Module Monster, Again

Once again the R3 module subsystem has gotten between me and the next release -- specifically the A108 release.

This has happened a couple times before on R3. Development becomes a fight... a fight between simplicity and complexity, between maintainability and chaos, between elegance and ugliness. So many operating systems and languages get it wrong. We don't want that here. Earlier prototypes worked well. They were functional, clean, and simple. Understandable.

Some of you may be saying "Carl, we don't care." Yes, I know, I've heard that before. But, (if I had a Yoda voice, I'd use it here) you will care. You just don't know it yet. That's always what a good system designer struggles with -- anticipating the future.

Anyway... I just wanted to give you an update on progress. A108 contains many fixes, and I didn't want it to be delayed much longer. However, with the split out of the system context, I want the module system to move into its final form. Also, as you know, Brian H has submitted some changes to help support delay modules, better versioning, mix-ins, etc.

I'll keep hammering away on this... and see if we can get A108 released over the next few days.

13 Comments

Comments:

-pekr- 5-Oct-2010 11:20:30	Just don't make it simpler, than simple :-) As for VID code, I told you in the past - if ppl will like to use it, enhance it, fix it, then it is OK, so i welcomed your rewrite. But module code is surely more of a guru stuff, and it needs real balance between the complexity, easy of use, and eventual loss of flexibility due to oversimplification :-) I hope you guys get it right :-)
shadwolf 5-Oct-2010 22:00:17	i'm happy you came to the conclusion that the actual way could be sharpen simplier .... for saying lets have a true thinking on what mean giving a futur to vid i was insulted badly on altme. but still there is no answers to the main question what will be vid in the near futur and what will be it's long range futur? even if people are paid for the actual task does this model will remain in time and what level of seriousness can we expect from this team. is it again a one shot attempt or do they want to make a professional level VID in the end i fear that VID become the most forked project in r3 and rebol history each and every reboler comming with his very own singular idea about how to manage it. and making in his own version what lacks in the previous attempts ...
-pekr- 6-Oct-2010 2:49:42	Shadwolf - what redo of module system has in common with VID (R3 GUI) project?
Luis. 6-Oct-2010 4:24:53	(at)shadwolf: I'd have any full version of VID for R3 over the current module work, BUT, the work being undertaken affects the upper levels. If VID were to be completed now a change on the lower levels could affect it's operation - Then there is the choie to either change the upper level or compromise the low level design, which may affect future changes. I hear your pain! I'm still waiting on news of any audio enhancements... Cheers, Luis.
Brian Hawley 6-Oct-2010 10:01:26	Shadwolf, I don't recall you expressing any particular opinion about the module system on AltME, just the GUI. Did you have any particular concerns about modules? Luis, there is no choice of GUI work vs. module work: both are being worked on right now by different people. The work that Carl and I are doing to make the core system better will give the GUI a more solid base. And the work that the others are doing on the GUI frees Carl to work on the system stuff. There is no either-or, no compromise needed. The new module system code doesn't require changes to the modules that it is meant to load, or the code they contain. The semantic model of R3's modules isn't changing, except for minor tweaks to new features that haven't been in an R3 build yet. All existing modular code should still run. What is being simplified is the code that implements the module system. The old code was working, but intimidating. It was getting too difficult to maintain. The new code does the same thing, more or less, but is more approachable. And some of the more awkward code patterns that were required in the old code may be replaced by native enhancements which were not possible before. The code needed some tweaking to work with the new system structure as well. Check the other recent blogs for the system changes that may affect existing user code or code that is being written now. The changes here to the implementation of the module system will only enhance the code to come in the future; they won't affect existing code.
Luke 7-Oct-2010 5:47:11	Couldn't resist :-) Yoda surely would have said "Care you will..."
Brian Hawley 10-Oct-2010 14:45:37	OK, having finished the new module system, I have to revise the above statement about the semantic model. There are two changes, relative to the previously revised model: Mixins now need to be explicitly marked. Set the type field to 'mixin, or 'mixin-extension for extensions. Unnamed modules are not considered to be mixins anymore. If you try to import a module without a name it will trigger an error; the name doesn't matter if you don't import the module. Mixins are now premade just like any other module. The only difference from regular modules is the importing policy. And if a mixin doesn't export anything, that difference doesn't matter at all. Both of these changes happened as a result of adding the delayed modules feature, and are for the better. Here are some other new features (relative to the released system) that made the cut in the recent revision: Delayed modules. Compressed scripts (header now required). Module hidden keyword. The module function unbinds. Module checksums don't normalize anymore, they just apply to the binary source, line endings and all. Note: This doesn't affect existing code because the old checksum model was too awkward to use, so it wasn't used. More informative errors. Hopefully this means that alpha 108 will be released soon.
Maxim Olivier-Adlhoch 12-Oct-2010 8:09:49	I REALLY like that non-named modules cannot be imported anymore. tough but good decision IMHO.
Paul personne 12-Oct-2010 9:17:48	In my view, developping modules is like developping hybride cameras (between compact and reflex). You have to develop first for experts. And after you should add automatism for usual programmer and last for non programmer. In that way you let choice to launch or not automatisms.
Brian Hawley 12-Oct-2010 15:01:11	Maxim, thanks. A lot of these changes were somewhat inevitable results of adding delayed modules; the changes those required made a lot of the rest possible. The real tough choice was the premade mixin thing. The mixins in the original system were remade every time, a trick which had interesting uses. Premade mixins only happened as a side-effect of delayed modules. However, it became too difficult to tell the difference between a delayed module and a mixin-to-be-remade at runtime, and that made me realize that the concepts were too similar as well, which would lead to programmer confusion. As it turned out, premade mixins are much more useful in practice, particularly for optionally included utility modules. And remaking mixins turned out to be so inefficient that we shouldn't be doing that kind of thing anyways. We have much better ways to accomplish the same effect. Paul, you have an excellent point there. The tricky part is to make the easy way the default. More advanced techniques can be used by more advanced programmers. As for automatisms, the main ones we have are the export and hidden keywords; those can't be disabled (without rewriting the inner code of make module!), but you can just not use them if you don't want to. We also have a system load-header function with the option to not decompress compressed scripts, which is useful if you are only interested in the header, not the rest of the script. If you want to not do the automatic tricks, it's possible.
Brian Hawley 16-Oct-2010 18:15:01	On the subject of making the easy way the default, new changes are coming. Same semantics, new syntax. First of all, the options block. Headers can now have an options field that refers to a block of words. All of the old and new header options that just took the value true, like content: true, will be replaced by words in the options block. If the word is there, the option has been chosen. The currently implemented options are: content - a reference to the binary source of the script, at the beginning of the script header, is added to a 'content field in the constructed header. Previously content: true. compress - the script has been compressed, and will be decompressed on load. Binary or script-encoded compressed data will be autodetected. unbound - the words in the script won't be bound to the user context. This option is ignored for modules and extensions. extension - is the module embedded in an extension. Previously type: 'extension. delay - just load the module, don't fully import it until import is called. isolate - make all words in a module local, initializing them from the runtime library and mixins, rather than binding non-local words to the standard library and mixins object themselves. Previously isolate: true. private - don't just import the exported words to the system, only import them into the calling module directly. This is basically the premade mixin feature mentioned above, but you don't need to set the type to anything other than 'module now. This makes script options consistent in use, and extensible. Next, checksums are now not calculated unless they will be used, and can also be used to detect unintentional corruption of all scripts, not just modules. However, the checksum no longer applies to the header, just to the decompressed source of the body. Don't worry about the calculation method for now, save handles it for you. And it will be documented.
Louis Vuitton bags outle 11-Jul-2012 22:12:36	Visit buyIf want to know where you want to buy Louis Vuitton bags outlet sale, you can use online resources Designer Louis Vuitton bags outlet sale visit descriptions of the Louis Vuitton bags and the big guy for the different costs and other accessories. You can find the online destination and Overstock Handbagcrew reduced price handbags and designer handbags. Check out other great creators of these pages that have the same quality and you will be able to see, how much to save - prices really have to pay a department store shopping at this site is much more normal. Have fun while you shop Louis Vuitton bags outlet sale!
Gucci sneakers store 16-Jul-2012 23:09:35	All Gucci sneakers store is made from superior material and crafted carefully and intricately to ensure the best quality. Gucci shoes are some of the finest designer shoes on today's market. As leaders in high fashion, Gucci sneakers store's line always features the latest, most stylish shoes. As they are high in demand and well-made, Gucci sneakers are always available in expensive prices. You can, however, find more affordable Gucci shoes, if you know where to look. So searching on internet is really a good option to find your favorite pair of Gucci Sneakers. You could also find some great discounts if you are lucky and finding the most wanted brand while sitting at home is really a good experience for anybody.

Post a Comment:

You can post a comment here. Keep it on-topic.