Big Alien Proposal 🛸 "/WORD" Runs Functions

Development Datatypes
20

Responses To Potential Criticisms

append:dup.2:line is less readable than append/dup.2/line because : visually does not separate the words so strongly as /.

Yes, I will admit it doesn't stand out as strongly. But there are priorities.

To me, seeing XXX.YYY and knowing that will not run a function vs. XXX/YYY and knowing it will run a function (and that YYY is the function) is a higher priority.

Along similar lines, when I introduced generic TUPLE! I had some doubts about pushing things down and losing some of the "heft" of slash:

foo/some-thing

foo.some-thing

I thought "the dash now looks stronger than the dot", to where you might try to grok that as:

(foo.some)-thing

But the mind is fluid. You read things how you are used to them. While I found this a little upsetting at first, that upset quickly gave way as I re-learned. I don't even think it took a week. I now think nothing of it, and read it naturally. (For that matter, we are used to this in filenames, such as my-file.txt not being my-(file.txt))

My bet is that this will just be another such thing, to where the benefits will vastly outweigh the downsides.

Rebol's ambiguity problems are not solved with optional slash. Only with a mandatory one--which would be a lot of syntax, and reduce the flexibility.

Only WORD! are left as the fuzzy case. And I believe that it will be annotated enough at the boundaries that you will know what you are getting into.

foo: func [block /baz <local> bar mumble] [
    baz 1 2 3
    /bar: frotz 5 6 7
    bar 8 9 10
    mumble: splat 11 12 13
    append block mumble
    print "You know this print isn't an argument to mumble"
]

It's unavoidable that the "keywords" in Rebol have this character, and you won't want the slashes on them. But I am thinking this is "as good as it gets" in terms of letting you mitigate the burden of the ambiguity, and write clear and safe code.

Note that we have even more safety offered now with APPLY, which you might use whenever you're getting functions you aren't completely confident in the arity of:

foo: func [block /baz <local> bar mumble] [
    baz // [1 2 3]
    /bar: frotz 5 6 7
    bar // [8 9 10]
    mumble: splat 11 12 13
    append block mumble
    print "You know this print isn't an argument to mumble"

    ; ... and you know mumble isn't an argument to block!
]

You're losing readability and making the language even more filled with syntax of all kinds.

Consider the difference between these two things.

Traditional Redbol:

old-append: :lib/append
old-orange: lib/orange

vs. /WORD is active proposal:

 /old-append: lib.append
 old-orange: lib.orange

These are the same number of characters. But the second not only looks better, it has many nice properties:

  • It keeps you from having to use an ugly prefix colon when you're fetching APPEND as an active function out of LIB by value... using a tuple (dot) as APPEND.LIB is enough to ensure you won't run a function

  • The prefix slash on /OLD-APPEND shows your acknowledgment that what you're getting can be active (if you just said OLD-APPEND: it would be an error)

  • You are shielded from executing a parameter-consuming function from LIB called orange by using the tuple of LIB.ORANGE

  • If orange in lib happens to be an antiform active function, it shields you from assigning that to old-orange because you didn't say /OLD-ORANGE:

I'm really skeptical of the good faith of someone who has used Rebol/Red at all and won't acknowledge the superiority of the second form.

1 Like