'Enum' Handling

Usage
1

I'm curious what the current best practice is for handling 'enum'-like scenarios.

For my contrived example, I have an ORDER-FOOD function where you pick your dish, and that dish comes with onions.

order: func [
    'dish [word!]
    /sub 'veggie [word!]
][
    ...
]

You can substitute onions for one other vegetable, but obviously I only have so many vegetables at a given time, so I'd like to be sure that you either get onions or another available vegetable.

order enchiladas
order/sub burrito mushrooms

First thought is using 'default:

veggie: default ['onions]

That's fine so long as I have what the given vegetable is. What if I only have [onions zucchini artichoke carrot]?

There is the FIND approach:

if not find veggie-box veggie [
    veggie: onions
]

Then again, I'm always mindful of CSS's: if it doesn't exist, ignore it. This approach has allowed CSS to adapt as new methodologies exist. How display that has been around for as long as I can recall gains a grid value that permits all kinds of heretofore layout possibilities. Any browser out there that doesn't know what grid means will happily display content as if it was whatever the call to grid replaced. Similarly, all the properties associated with grid layout are just ignored by older browsers.

Not quite sure how that maps to my function, but it'd be interesting to say:

any [
    order/sub bibimbap bok-choy
    order/sub bibimbap carrot
    order burger
]

In the event of its availability one day, that I may have that fresh crunchy cabbage.

2 Likes
2

I don't know if you remember, but I wrote about developing an enum type as the first Rebol involvement, long ago:

"An Enumerated Type for Rebol2"

I'd have to think more about what my opinions on enums are these days.

The only enum-oriented thought I'd had was that WORD!s were a bit awkward to use for inert data, because if you forgot to quote them they would execute...and you didn't want them to. This made me think that when you were passing around things meant to serve as an identity you would use something else... e.g. an #issue.

With issues being stringlike, there's a bit more overhead to their comparison...which means words are faster to compare symbolically. This is part of why I thought @word could be useful, if it didn't have evaluator behavior.

Things have gotten murkier since...as alternate usages for @(...) have come up. But also, COMPOSE having features like being able to add ticks on composed things makes it a bit easier to preserve enum-ness:

 >> veggie: 'onions

 >> compose [x: '(veggie)]
 == [x: 'onions]

Well, we can just add working through more real examples into the infinite queue...

1 Like
3

I do. I figured that it'd be curious to follow up on that.

I was contemplating what to cook when putting this one together. I had forgotten that you'd used fruit in your original post.

Am actually contemplating a codec where there are several modes of decoding, e.g. [tokens sections document] but more possible.

While that is a fear, I'd still lean to vanilla words as first class currency.