The <dequote> and <requote> parameter flags definitely represent a useful intention.
If the INTEGER! example I give doesn't compel you, let's say you want to SKIP around in a series while it's quoted, and item is ''[a b c].
Would you rather write:
num-quotes: quotes of item
item: quote/depth (skip (dequote item) 2) num-quotes)
...or something like:
item: skip item 2
Note: remember you could also use the MY operator, with item: my skip 2
Useful Though It Is, It's Currently Too Built-In
There's bits and tweaks in the evaluator for this feature, that probably shouldn't be there. As a technical matter, <dequote> and <requote> are consuming two typecode slots, and I'd like to have those back to try implementing things like COMMA!.
I'm thinking that we need a REQUOTE tool that would be able to take care of it.
So again, if item is ''[a b c]:
>> requote skip item 2
== ''[c]
I've posted about some of the mechanical implications of REQUOTE being a function that invasively takes over the evaluation process. And I mention changes that would help us not lose composability, e.g. so you could instead write:
>> item: my requote skip 2
== ''[c]
I won't rehash that post here. But I do have an observation...
QUOTE! Can Be Seen As a Monad...Do We Care?
When you think about doing an operation on something "inside" a quote "container"...it looks an awful lot like monads...
REQUOTE might be better expressed in terms of some general transformation framework for mapping, and that mapping language might be where to look next.
But for now, killing off <dequote> and <requote> is a step forward. Not much was using it, and it was contaminating the specification of functions that are more cleanly defined without it. This lets callers be more purposeful about when they mean quoted things to be OK, and I feel that helps avoid an aspect of randomness and "dirt" of incidental quotes that are permitted to be left on when they shouldn't be.