Ren-C shifted to the idea that slashes in paths are used to convey function calls. Refinements are done with colons (CHAIN!), and field selection is done with dots (TUPLE!)
This means you can tell the difference between:
obj/xxx ; a function call
obj.xxx ; picking a member out of an object
But Rebol depends visually on not needing any decoration to run a function out of a word. This means that when you see:
some-word
You don't know if that's running a function or not. While that is "by design", there are sometimes cases where you want to disambiguate it. So Ren-C offers:
/some-word ; runs a function
some-word. ; gets a non-function value from the word
(The some-word/ case is for getting a function without running it... chosen for its semiotic value of separating the word from its arguments with a "barrier" at the end. And .some-word is used for picking members out of objects inside of a method, e.g. self.some-word.)
Who Would Ever Use /SOME-WORD ?
I've explained cool applications of the leading slash in things like ACTION! combinators for UPARSE.
But is it useful in non-dialected code?
YES.
In doing some updates to Shixin's c2r3, there was some code like this:
cpuid: tcc/load-func prog "cpuid" [
eax [pointer]
ebx [pointer]
ecx [pointer]
edx [pointer]
return: [void]
]
cpu-string: func [
return: [text!]
][
let eax: copy #{00000000}
let ebx: copy #{00000000}
let ecx: copy #{00000000}
let edx: copy #{00000000}
cpuid eax ebx ecx edx
return as text! join blob! [ebx edx ecx]
]
CPUID doesn't necessarily sound like a function invocation. But let's imagine that's what something is named. You're confronted with the question: should I name the wrapper something like get-cpuid: ? But now you've created a mismatch between something that exists and your wrapper.
Using the leading slash gives you the ability to mark things more clearly as a function at the assignment:
/cpuid: tcc/load-func prog "cpuid" [
eax [pointer]
ebx [pointer]
ecx [pointer]
edx [pointer]
return: [void]
]
This not only visually reinforces that what you are assigning is a function, but it also requries that what you're assigning be an action. So it's a convenient shorthand for:
cpuid: ensure action! tcc/load-func prog "cpuid" [...]
The callsites have a similar benefit...not just visual, but enforced that it's a function call:
/cpuid eax ebx ecx edx
return as text! join blob! [ebx edx ecx]
It's There On An As-Needed Basis
For a time, I was wondering if all function assignments should require slashed-set-words.
But I realized that it was too much.
/something: func [...] [...] ; but I KNOW FUNC makes functions...
/alpha: beta/ ; BETA/ promises to return a function, why double-enforce?
But it can make some situations more clear, and give you cheap insurance that the assignment is doing what you think.
Similarly I think the leading slash is something to apply judiciously. We don't want to read code with tons of /append junking it up. But cases like this /cpuid show an effective and helpful communication that a function call is happening.