Comments on: Queuing up the R3 Function Split Out
As we get closer to finishing R3, it has come time to organize the R3 default functions (modules). This is important so I'm mentioning this here on the main blog as well as the R3 blog.
Resident code within R3 will include these categories:
- Always there: The essential primary functions of the system.
- Optionally removed: Useful or "handy" functions that most programs might want, but various other programs may not. (We've also referred to this as the "plus" package.
- Optionally included: Useful modules for specific purposes, like CGI, HTML processing, network protocols, database access, etc.
When you boot R3, you'll normally get the first two, and your program can use w:import to include any of the third. A command line option can be specified to only get the first one (and of course you can control that in a host-kit build as well.)
There are a few phases to this project:
- Split out the primary system functions from those that are "handy" but not essential.
- Gather any other useful functions that we want resident in the system.
- Collect resident modules that users might want to import.
This official site for archiving these files will be R3 DevBase, which is easy to access from R3 on any client or server, no installation required. (And, it also give me the ability to use small REBOL scripts to manage the build process better.)
17 Comments Comments:
James_Nak
22-Sep-2010 11:21:42 |
Carl,
This may seem like heresy but I wouldn't mind having an "all-inclusive bloat" version just so I don't have to mind what I forgot to include. This happens to me a lot when I encap. And really, how large are we talking about 1.5 mb?
Thanks, James (and read your altme messages) | Andreas
22-Sep-2010 11:56:28 |
James, all of the above will actually be included in the binary. Some modules just won't be imported by default. But just import them when you need 'em and you'll be fine.
I guess a refinement to what to list all "optionally includable" modules will be a nice thing to have, though. | -pekr-
22-Sep-2010 12:32:59 |
OK, following the discusison on REBOL3 Altme - I don't want such basic functionality as networking protocols (at least http(s), smtp, ftp, pop3) being loaded via 'import. Don't forget also basic console prototyping - I would hate to call 'import each time for at least above named networking schemes. REBOL's a messaging language, right? | Gregg Irwin
22-Sep-2010 12:33:34 |
As I said on AltMe, I like REBOL because things just work out of the box, and I don't want to have to import what I've come to know as core functionality in every script.
If we had a list of modules, along with their cost in memory consumption, "clutter", and load time, it would be easy to weigh their value. A cross-reference or dependency list would be great too.
I'm 100% behind organization, I'm just not clear on the cost versus benefit. | Oldes
22-Sep-2010 12:55:38 |
Pekr, aren't you using %user.r file? I have quite a lot functions which I use defined here so if I will have to add one line to import networking or other modules, I really don't care.
Don't forget that to add something is easy, but you cannot remove stuff to for example have just YOUR script working using as few memory and as fast boot as possible. | Carl Read
22-Sep-2010 12:59:45 |
Has any thought been given to how upgrades will be handled? | Brian Hawley
22-Sep-2010 13:14:15 |
Oldes, noone can use a %user.r file that way in R3; the old %user.r behavior was removed for security purposes. You can still use %rebol.r though. We may reintroduce %user.r as a place to store declarative, non-code preference data (that was the plan).
Pekr, Gregg, importing is not as difficult as you might think. For normal modules you import into the system, rather than needing to import into individual modules. So importing the stuff you need only has to be done once per run of the process. Most of your code doesn't need to know anything about modules, and won't need to import anything.
Carl Read, yes. The module system has been designed to allow even in-memory upgrades of modules. Migrating in-memory data is tricky and application-specific, but that is to be expected. The good old-fashioned stop and start the new version upgrades are much simpler in comparison. | Brock
22-Sep-2010 13:53:54 |
+1 Gregg and Pekr.
I too really like Rebol because all of the functinality is right there in your hands. Rebol was originally attractive to me for many reasons, but one big one was the simplicity to get things done (the original target of the language).
If the language is now going to be more focused on PITL or more advanced dev work, then lets have it so only the people doing the more advanced work need to worry about this type of thing. Those who are compiling stand-alone apps or including modules etc are already accustomed to this type of procedure, and likely know what module they need.
I don't want to have to deal with this out of the box if at all possible. | Brian Hawley
22-Sep-2010 15:18:37 |
Brock, the module system is designed so that the average user script doesn't have to know that R3 is modular. PITS is supported, no problem.
It was a complex task to make R3 so simple, believe me. We couldn't go with a standard module system that required people to use import statements or headers, because managing those dependency graphs is a nightmare for most programmers. But for advanced projects we needed to support all sorts of crazy stuff. It was a hard problem to solve.
The new module system supports both kinds of development, simple or complex, even non-modular programming if you like. Most of the "optional" stuff above is for host kit users. There will be regular builds with the modules you need preintegrated and preimported, if you like. And specifying requirements for your scripts is no more difficult than it is in R2; it even uses the same Needs header, and even that will be unnecessary in most cases.
Internally, the code of R3 will be modular. But you don't have to pay attention to that in your code unless you want to. | Carl Sassenrath
22-Sep-2010 19:52:37 |
I agree with the above sentiments, and Brian summarized them well. We'll be sure to stay with the KISS principle for normal REBOL usage. The special controls and options will be for the more advanced users. We can keep a list as Gregg suggests and weigh the advantages of what to include on the default boot. | Endo
23-Sep-2010 1:08:54 |
What about the reverse way? command-line boot arguments like --no-cgi, --no-network, --no-gui etc. | Mark Ingram
23-Sep-2010 1:36:32 |
+1 Endo.
Especially if what Andreas says is true and everything is already in the binary anyway.
This would also reduce Carl's categories to just the first two.
A question for Brian, how can you say that HTML and networking are only for host-kit users? Unless you mean removing them, I must be missing something.
| Carl Sassenrath
23-Sep-2010 11:19:51 |
Endo: yes something like that... --core to disable all extra features, then you enable the ones you want from your script.
Mark: on HTML, networking and other features... they are standard. What Brian meant was that users now have access to that code via the host-kit, so can customize or remove those features as desired.
| Brian Hawley
23-Sep-2010 12:55:30 |
We have to modularize R3 to make removing features possible, but that doesn't mean that we are going to remove those features in the default build. All we have to do is include an import statement in the internal startup code then the code is available to everyone. And our module system lets you ignore the fact that the internal code is modular, and just write scripts. Best of both worlds. | Nick
24-Sep-2010 7:58:34 |
I'm glad to read these clarifications :) | Florin
24-Sep-2010 19:20:42 |
As tier 1-3 are packaged together why not add 2nd and 3rd dynamically as libraries are invoked? This makes all flags ( + or -), different builds, as well as module imports unnecessary - even this conversation. | Brian Hawley
24-Sep-2010 20:17:11 |
Re Florin:
Modules have to be built for you to know for sure what is in them and what they export, and the initialization code that builds the modules can have side effects. This means that you can't just export functions from a module before it is built, and so those functions won't be defined in the namespace until the module has been imported. Nor do you want them to be, since part of the reason we are splitting out some stuff into optionally loaded modules is to keep the namespace clean of the stuff you don't need, so you can redefine those words as you need to.
Thus, what you propose is not directly possible in R3. You can delay initialization of a module until first use with init functions, or split a module into a preloaded wrapper that loads another module when it is first called. But what you can't do is just load a module when you try to call its functions, because you can't even see those functions until after they have been exported, and that exporting can't happen until after the module is built.
You can't avoid it, something is going to have to import the modules. If they are designed that way, import can happen behind the scenes, but it will have to happen somewhere. So this conversation is still necessary. |
Post a Comment:
You can post a comment here. Keep it on-topic.
|
