Port "Schemes" For Finding Module Dependencies

[rgchris]

@hostilefork

Because of that, you're more limited in what you could write. Internal @ signs aren't legal (for example). And if you put 0.1 in that will be a DECIMAL!, but 0.1.x will be a TUPLE!. Etc.

I did consider other, more conventional forms. module://xml, module://rgchris/deflate&version=1.x, but that adds certain connotations and expectations that aren't appropriate.

@hostilefork

I'm not that concerned about being prescriptive about module names (e.g. saying you can't name a module file something that would be an illegal WORD!).

If there's one other advantage to this switch, it's the possibility of transitioning away from words as the pivot point for modules.

@hostilefork

I haven't gotten to a good point of understanding about the balance between Needs: and import in the body of the module.

Who needs NEEDS: headers when you have IMPORT?

Putting it in the header where you can't write imperative code is strictly less powerful, but I'm not exactly sure how to gain leverage from that power.

I guess it's a matter of style. Like the Type header, you get a top-level view of what the script is about and where it fits. You also get an immediate loud warning if modules are unavailable before a single atom of code has been evaluated. I suppose if you use a URL scheme, you can scan each whole script for those values and provide availability warnings that way.