I've had a discussion with @hostilefork about this topic a while ago in chat, but I think it is better if it is in a more permanent medium.
So the questions are:
should it be possible to get the source of functions from within Rebol?
what should be displayed, when viewed?
Possible answer:
You should be able to get the source as it was written.
Pros:
this is the best way to learn and understand the language.
Cons:
if taken out of context, you will never know what it really does, because of binding, etc.
(But, the same is true when you copy/paste source-code, and textual representation is still how humans and computers understand source code. I'm pretty sure there is C-code out there where it depends on the version of the compiler, what it does.)
; function
>> f: func [a][a * 2]
>> source f
f: make action! [ [
a
][
return: make action! [
["Returns a value from an action" value [<opt> <end> any-value!]]
[unwind/with (binding of 'return) either end? 'value [] [:value]]
] (a * 2)
] ]
; object
>> o: make object! [a: 1 f: func[][a * 2]]
>> mold o
== {make object! [
a: 1
f: 'make action! [[] [...]]
]}
I, personally, like the Rebol 2 way better. (Well, that's the only thing where I like the Rebol 2 way better).
Rebol [
Title: {Lemme show ya somethin'}
]
data: [a b c]
print [line of data]
print [file of data]
There are tools in the making for connecting dynamic structure back to its source. And they're being accounted for. But, there's a really hard problem here.
Almost every programming language which involves abstractions (e.g. macros) gets screwed in terms of connecting what the runtime processes and can understand (the expanded macro) vs. what was written (the instantiation, e.g. "source").
Mapping backwards from a projection is a challenge. This may be amusing:
I'm open to ideas here, but... the thing is, this is non-trivial.
I wonder if the basic function generator (whether that be FUNC or FUNCTION) should not define RETURN and thus only reflect the body block as supplied. Undoubtedly some people use RETURN—I generally don't—and as needed could specify it on generation thus the appearance of extra code would not be a surprise.