Tapping The Untapped Potential of Short Words

I have to say that I am very gung-ho about the new behavior with OF. That's a word that didn't have a previous usage, and seeing how pleasing it is, I've asked if we might want to consider rethinking if some words that were formerly prefix (AT, IN, TO might be reasonable candidates for adaptation).

But going further out there, I wanted to start a thread to discuss more generally creative usages of common words that aren't likely to be variable names. While not all the "most common" words in the scrabble universe are actually common, it's worth it to think about some of them.

http://www.poslarchive.com/math/scrabble/lists/common-234.html

IS already has a planned future. But getting into the outside the box philosophy, what about things like:

 ; NON could be MAYBE, but in reverse:
 if non [integer! even?] 13 [
     print "wasn't an integer, or was and wasn't even"
 ]

 ; BY could construct pairs from expressions
 x: 10
 y: 20
 10x20 = x by y

 ; CAN might test operator availability
 if foo can append [
     append foo ["this should work"]
 ]

 bar: the foo ;-- canonization?  e.g. bar: (is) *THE* foo
 barify the foo ;-- some sort of application?

I thought it might be interesting just to have a thread for anyone's weird ideas, past or future, for novelties in the DO dialect. I keep wondering what go and run might do.

How about EACH as an infix?

for each [a b c] some-series [... only does this ...]
map each [a b c] some-series [... sets a b c from this ...]
remove each [a b c] some-series [... removes per this ...]
collect each [a b c] some-series [... keep a ...]

This is a spitball rather than a proposal.

Each instead of Every?

Wanted to make a note that we've discussed cast as a possible prefix form of something like to, if TO were to become infix.

cast integer! x
x to integer!

Though I'm kind of skeptical of infix TO and AS at the moment.

Since I started thinking about these short words, I noticed a few cases where I thought it might behoove us to leave a few out of being built-in functions...so they can be naming conventions users might take advantage of. So by convention, run might be what you'd call a method inside your object that means "do your thing"...given that "DO" is taken.

Basically just saying we might not be greedy and take all the short/useful words. As a sidenote, it's rather annoying that DO is a keyword in C, because I wanted to say block.do() in RenCpp...

I keep wondering what but might do.

"used to introduce something contrasting with what has already been mentioned."

It would be nice if it could be the "anti-THEN". Yet BUT does not negate the truth of the previously introduced statement...though it can sort of imply negation of something: "He says he fixed the bug, BUT I had the same crash again today."

 1 > 2 but [print "this use of BUT doesn't cohere very well."]

So for now, NAY is still the sub-optimal choice to beat for that. It sucks, but seems coming up with the anti-THEN (that isn't ELSE, which I've essentially now -proven- to myself that it can't be) is hard.

But what about BUT? Can this useless variable name be cast as some useful language feature?

Something bizarre called "Gherkin" uses it, but it seems to be for commenting vs. anything actionable:

But keyword is used to add negative type comments. It is not a hard & fast rule to use but only for negative conditions. It makes sense to use But when you will try to add a condition which is opposite to the premise your test is trying to set. Take a look at the example below:

Feature: LogIn Action Test
Description: This feature will test a LogIn and LogOut functionality

Scenario: Unsuccessful Login with InValid Credentials
    Given User is on Home Page
    When User Navigate to LogIn Page
    And User enters UserName and Password
    But The user credentials are wrong
    Then Message displayed Wrong UserName & Password

Here you can see how adding But has helped define a negative test, in this test we will try to test failure conditions. Where a wrong credentials are a failure condition.