Idiom Economics

In the article Calling all idioms I suggested we should look at adding a few useful idiom functions to REBOL.

To clarify for anyone just joining us: we see regular patterns in our daily coding, and sometimes it makes sense to shorten those patterns into a new function. Since we often treat the pattern in our mind as a single thought, we call them idioms. They are short little helper functions.

A common example:

For example, you can get the last value in a block (or any series) with:

value: last block

This is shorthand for:

value: first back tail block

And in fact, first is an idiom, so it's really:

value: pick back tail block 1

Which would you rather write?

So, that's a good example of a useful idiom. In fact, it happens so often that it's now a native action in R3.

Test of a good idiom:

What makes last a good idiom is:

It's a common pattern.
It's several words long.
Does it have a good name, one that's easy to remember.

We should call this idiom economics, because each has value (or not), and each will strengthen or weaken the benefit of the idiom overall.

Take TAKE for example

For example, we recently added the take function. It's an idiom pattern we saw often. It removes a value from a series, and returns it:

block: [red green blue]
value: take block
red
probe block
[green blue]

Again, this idiom saves us some code:

value: first block
remove block

So, using our idiom economy test:

It was common (used often for stacks and queues)
It required several words (and took two separate expressions)
It had a good name

False idioms

Some patterns may seem like they would be good idioms, but we should examine them closer.

For example, in code see the back tail pattern a lot:

back tail block

But, does it qualify as an idiom?

Is it a common pattern? Yes.
Is it several words long? No.
Is there a good name for it? Maybe.

Maybe we could call it at-last to associate it with last and also the at function, making it easier to remember. Perhaps you can think of a better name for it too.

But, is it really an improvement?

at-last block

back tail block

This is one of those border line cases that is difficult to decide. Perhaps we need to ask:

Does it really happen that often?
If so, is the performance trade-off worth it?

This last point comes from the fact that you must implement at-last with:

at-last: func [series] [back tail series]

And, in fact, you'd want to standardize its implementation with:

at-last: func [
    "Returns the series at its last element."
    series [series!]
][
    back tail series
]

If you measure the performance:

dt [loop 1000000 [back tail "abc"]]
0:00:00.437
dt [loop 1000000 [at-last "abc"]]
0:00:00.735

But, that's an extreme case for a million iterations, so in most code we probably won't see any difference between the two.

So it's borderline. The only way we can decide is if we really think we're going to use it a lot.

Are there such idioms already? Yes, in fact look at first, which is an idiom for:

pick series 1

We might say that it does not really qualify according to the rules above. But, it does turn out to be useful, mainly because it removes the second argument from the expression. We would rather write:

first find at series 4 pattern

than:

pick find at series 4 pattern 1

So, that is worth nothing as well.

In conclusion

In conclusion, we need a simple system of justifying our idioms.

It's all about trade-offs. If the pattern is very common, and it saves a lot of code, then all it needs is a good name and it's a winner.

But, if it's one of those borderline cases, then the name becomes critical. Without a good name, it will rarely be used.

3 Comments

Updated 9-Mar-2024 - Copyright Carl Sassenrath - WWW.REBOL.COM - Edit - Blogger Source Code