Scant Evaluation - Should it be Extended? [No]
(See below for updated information.)
REBOL 3.0 defines three methods of evaluation:
| Evaluation | Normal evaluation of all functions. This is just
your regular REBOL code.
|
| Safe Evaluation | Evaluation based on a subset of functions that are secure.
Safe evaluation makes it possible for blocks like draw to do more
complex types of evaluation, but without the risk of
security problems. This is a new mode of evaluation, but I will be
explaining more about it later (not in this article).
|
| Scant Evaluation | A minimal form of evaluation used for headers and
other data blocks that do not allow any level of deep evaluation.
|
This last method will be the focus of this article. You are familiar with
scant evaluation when you load a file that contains a REBOL header and
also when you use the construct function to import object data
safely. Scant evaluation is really just another kind of REBOL dialect.
For example, using construct, this block is made into an object
without any side effects:
obj: construct [
author: "Smith"
when: 10:20
action: delete
]
The object's action variable is set to the word delete, and the
delete function is not evaluated. This is a handy notation for
storing data in external (serialized) objects because it eliminates
the possibility of "malware" lurking in your objects.
However, what happens if the block above contains values that have
no matching set-words? For example, what would happen with:
[
author: "Smith" "Jones" "Davey"
when: 10:20 past last edit point
action: delete on request
]
Normally (in REBOL 2.0), each set-word would get set to only the first value that follows it.
However, would it be useful to allow the scant evaluation dialect to
collect all values that follow a set word? When more than one value appears, should a block be implied?
Molding the above object would produce:
[
author: ["Smith" "Jones" "Davey"]
when: [10:20 past last edit point]
action: [delete on request]
]
Of course, we'd provide a refinement for molding scant output, so your
objects and headers can be serialized back to the scant format.
I think now you can see how scant evaluation could come in handy for
REBOL headers and other types of objects. However, you know that I don't just
throw "anything" into REBOL without a lot more deep thought and
discussion regarding its merits. So, post a message and tell us
what you think.
Note: this feature is already internal to the method REBOL uses for
header evaluation; so, bringing it into the language as a formal method
does not expand the REBOL executable by much. It's nearly free.
Additional Notes (Added 16-Aug-2006)
Many good points have been made in the comments section. Thank you for taking the time to post them. I agree with the general consensus that perhaps this form may go too far beyond normal REBOL, and as a result may cause difficulties for users. It is a little "out there", but I wanted to gather your opinions before dismissing the idea.
But also, from some of the comments, we should be sure we're talking about the same thing. To help clarify the proposal: Headers are already dialects and this form is mainly intended for explicit uses related to the secure instantiation of objects. In other words, a script header cannot be fully evaluated, because it is automatically evaluated when a script is loaded (to provide information to REBOL itself). So, it must be made secure.
For example, in headers (and in the construct function) both word lookup and function evaluation are disabled, but set-word (assignment) is not.
Of course, it is also true that if you want such behavior as described above, it's easy to implement yourself. With that in mind, and from your comments, we will leave this concept to the implementation of the user, and not part of REBOL 3.0.
12 Comments
|