I was looking at this from the emscripten config file:
; Right now, either #web or #node (someday #wasm-edge ?)
;
javascript-environment: #web
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:
javascript-environment: circled [(#web) #node]
Being dialected, it could even have visual hints as to whether many options are allowed, or just one.
extensions: circled [[
(javascript)
(debugger)
view
jpeg
(crypto)
]]
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. 