I was looking at this from the emscripten config file:
And I thought to myself: well that's kind of ugly. The comment is having to list things that would be more obviously shown by just demonstrating the options:
Being dialected, it could even have visual hints as to whether many options are allowed, or just one.
Or maybe it uses optional parameters to tell you how many you can have.
toppings: circled 0..3 [(cheese) tomatoes (pickles) (lettuce) onions]
It could default to NULL if you circled nothing, but you could use MUST to suggest people needed to select something:
>> number: must circled [#one #two #three] ** Error: MUST requires argument not to be NULL
It's Almost Too Easy
When it's this easy, who wouldn't whip such things up?
Ultimately I believe this should work (once PARSE is renamed and there's Terminal Parse Alternates):
circled: lambda [block [block!]] [ parse block [return [ thru into group! [<any> | (fail "Circle One")] maybe [thru group! (fail "Circle One")] ]] ] >> circled [a (b) c] == b >> circled [a b c] ; null >> circled [(a) b (c)] ** Error: Circle One >> circled [a (b c)] ** Error: Circle One
But of course PARSE is called UPARSE right now, and there's a detail of alternates not being offered in blocks seeking completion before failing...that makes you need
elide <end>, so for now:
circled: lambda [block [block!]] [ uparse block [return [ thru into group! [<any> elide <end> | (fail "Circle One")] maybe [thru group! (fail "Circle One")] ]] ]
It finds one group to extract an element from, and extracts it via INTO. Then it has a second clause that's optional--and if it doesn't match is invisible...but if it does match it fails.
Remarkable plasticity, and I want to see these weapons come to the code golfing field.