SUMMARY OF PERSPECTIVES
My bias is [type: module] over [Type: 'module] when technical and aesthetic issues are taken into account. @iArnold agrees.
Oldes Rebol3
It seems that Oldes may be ahead of the curve here... e.g. in his GitHub Module:
REBOL [
version: 0.2.0
title: "Rebol/GitHub utilities"
name: github
type: module
date: 8-Nov-2024
needs: json
home: https://github.com/Oldes/Rebol-GitHub
exports: [
github-query
github-repo
github-run
github-get
github-post
github-edit
]
]
I have stated that despite our seeming disagreement, retrospectively I've noticed that I more often agree with his comments on old threads or bugs than I do with other people on the thread who aren't me.
UPDATE: Maybe I spoke too soon, I was browsing through his commits and on March 29th he added ANY-WORD! as the type for module names, labeling it "FIX: Allow lit-word as module name in header". So he thinks it should be allowed for some reason, though doesn't explain why.
Chris's $0.02
In another thread, @rgchris observed:
There's a bit of ambivalence there...which he can clarify. But the greater aversion appears to be having to use the uppercased keys on access:
Rebol [title: "text/html"] ; a bit sad it's a little less formal than Title:
system.script.header.Title ; measurably more annoying ("would balk at")
So if the keys must match the access--and you only get the two choices--seems he'd go with the lowercase keys in the header.
Worth noting is that HTTP headers are case-insensitive. But the issue of wanting to FORM a header with the caps is something to be aware of. Yet maybe this is a job for applying PROPERCASE on those keys when serializing them, vs. making header objects themselves carry that responsibility...?
Carl's (BrianH's?) Rebol3 Examples
In the Rebol2 documentation on script headers, Carl doesn't have any examples of words. But he does say (emphasis mine):
When a script is loaded, the header block is evaluated and its words are set to their defined values. These values are used by the interpreter and can also be used by the script itself.
So that runs up against my feeling that the header block should specifically not be thought of as being "evaluated" (in the sense of DO)... rather as a dialect.
But looking at the Rebol3 documentation for modules, we see plain words... how much of this is Carl's leaning or Brian Hawley's one has to guess:
REBOL [
Title: "Stock Trading Module"
Name: stock-trade
Version: 1.2.0
Type: module
Exports: [buy sell]
]
There's not a lot of examples of this in the Rebol3 sources themselves. But we do see for instance [Context: sys] and [Name: draw, Type: extension, Exports: none].
And an example that comes up from @earl is consistent with this. So I'd
Rebol.org Guidance On Module Headers
I cached it here:
Cache of rebol.org Writeup of Standard Header Fields
It makes explicit mention of LIT-WORD! in four places:
platform: - The platform(s) on which this script will run. Can be a lit-word or block.
type: - Says what type of thing the script is, or how it is used. What its purpose is. Can be a lit-word or block.
domain: - What application area(s) the script addresses. (...) Can be a lit-word or block.
license: - Conditions under which the script can be used. See http://www.opensource.org/licenses/index.html for information about various open source licenses. A string, lit-word, block, or none.
You wind up with kind of evaluation rules, where NONE isn't an enumeration value but something that gets "looked up" in "scant evaluation"...so it does look like evaluation:
library: [
level: 'intermediate
platform: 'all
type: [tutorial tool]
domain: [ftp game]
tested-under: none
support: none
license: none
see-also: none
]
Red Source Code
Red doesn't seem to make very aggressive use of headers in its own sources. They do propercase the keys, and the Needs field uses a LIT-WORD!s in the header... at least in the examples I can find... such as their recent Textual UI stuff
Red [
Title: "Red TUI test script"
Needs: 'View
Config: [GUI-engine: 'terminal]
]
Red doesn't seem to error if you say [Needs: view], but it also doesn't error if you say [Needs: asdf]. Sigh, am I going to look to see what is happening, yes... okay here
list: select header first [Needs:]
find [word! lit-word! block!] type?/word list ;-- do not process other types
So explicitly tolerating WORD! and LIT-WORD!, for whatever that is worth.
Boris's Scripts
I look at @hiiamboris's stuff as an example of a "prolific modern adopter with strong opinions".
He typically uses lowercase keys, plus no quotes on WORD!s:
Red [
title: "#ASSERT macro and ASSERT mezzanine"
purpose: "Allow embedding sanity checks into the code..."
author: @hiiamboris
license: BSD-3
provides: assert
notes: {
...
}
]
But it's not 100 consistent. e.g. in his Tetris clone, he puts the apostrophe on view...and on the license as well:
Red [
title: "Tetris Redborn!"
description: "Red Tetris Game YAY!"
author: @hiiamboris
license: 'MIT
version: 1.0.0
needs: 'view
]
Then on his PARSE visualizer he puts the needs in a block, but still quotes the license:
Red [
title: "ParSEE"
description: "Parsing flow visual analysis tool"
purpose: "Never again debug Parse rules using randomly inserted print statements"
author: @hiiamboris
license: 'BSD-3
needs: [View]
notes: {
...
}
]
In a bug he reports he seems aware you can write just [needs: view] without the quote.