The CIRCLED Dialect: Example of the Form

Usage Show & Tell
1

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]

It could default to NULL if you circled nothing, but you could use NEED to suggest people needed to select something:

>> need number: circled [#one #two #three]
** Error: Assignment to number NEEDs argument not to be NULL

It's Almost Too Easy

When it's this easy, who wouldn't whip such things up?

circled: lambda [block [block!] <local> result] [
    parse block [
        result: try thru subparse group! [
            one <end> | panic "Circled Items Must Be Singular"
        ]
        try [thru group!, panic "Only One Circle"]
        accept (result)
    ]
]

>> circled [a (b) c]
== b

>> circled [a b c]
; null

>> circled [a (b c)]
** PANIC: Circled Items Must Be Singular

>> circled [(a) b (c)]
** PANIC: Only One Circle

Remarkable plasticity, and I want to see these weapons come to the code golfing field once they are adequately Rebmooshed. :slight_smile:

This example tipped the balance to where I decided that matching <end> should be invisible. Because I wanted a way to synthesize the result while doing the end match. Writing elide <end> is possible, but there's essentially no cases in practice where you don't want to elide the end.

 >> parse [1 2] ['1 <end> | panic "Not a 1 followed by the end"]
 ** PANIC: Not a 1 followed by the end

 >> parse [1] ['1 <end> | panic "Not a 1 followed by the end"]
 == 1

The previous result was evaluating the <end> to the input position at that moment of being at the end--so effectively a series at its tail:

 >> parse [1] ['1 <end>]
 == []  ; old behavior...how often would you want this?

If that's what you actually want (which no one ever did) you can can say <end> <here>.

 >> parse [1] ['1 <end> <here>]
 == []
2 Likes
2

Originally I thought "you wouldn't want to return a list of circled things, because how would you know if it was a circled list or a list of circles":

>> circled [a ([b c])]
== [b c]

>> circled [a (b) (c)]
== [b c]

But SPLICE! Can Disambiguate That!

>> circled [a ([b c])]
== [b c]

>> circled [a (b) (c)]
== \~[b c]~\  ; antiform (splice!)

If you need to narrow the types, you can do that by constraining your variables, so the constraint "sticks" for future assignments:

constrain word! x: circled [a (b) c]

Or you can just do a one-off and ENSURE the type is what you expect for this single evaluation.

; Select more than one of the following
;
data: [(a) b c d (e)]

x: ensure splice! circled data

For that matter, dialected function calls could let you say exactly how many things you want... succinctly!

; Select any two of the following
;
data: [(a) b c d (e)]

x: circled/2 data

The creature from the alternate language evolution timeline strikes again!

:octopus:

1 Like