So @BlackATTR has brought up the idea that there is a likely very large opportunity in what might be thought of as a sibling dialect to PARSE, namely QUERY.
(For anyone who didn't see his talk on the subject, it's about 10 minutes long (edited), and good to re-watch for context.)
Rebol2 had a native
QUERY target /clear which "Returns information about a file or URL." The /CLEAR refinement would "Clear modified state of target object".
R3-Alpha instead had
QUERY target /mode field, remarking that /MODE would "Get mode information", and passing NONE for the mode would return a list of available modes to pass.
Being able to at least narrow down what you are asking for is important. Because in the OS, a lot of times each property might require a different method call. This is costly for filesystems, and even moreso over a network.
But the /MODE refinement seems ignored:
r3-alpha>> query/mode %README.md none == make object! [ name: %/home/hostilefork/Projects/ren-c/prebuilt/README.md size: 1425 date: 28-Oct-2020/3:50:27-5:00 type: 'file ]
We Must Replace This Weak Form of QUERY
The proposal is to model after SQL, which is widely known and understood.
So we'd be looking at something a bit more like:
>> query [select date from %README.md] == 28-Oct-2020/3:50:27-5:00
The idea of this grammar being rearrangeable is something being suggested as well:
>> query [from %README.md, select date] == 28-Oct-2020/3:50:27-5:00
Usual questions abound: should you say
select 'date and use a LIT-WORD!, or
select #date, or
select <date> or
select /date etc. etc.
The opinion of @rgchris has historically been that undecorated words are the thing that give leverage. SQL is successful and doesn't make you decorate the names, so you only need to escape when you trip across a keyword. The use of quoted words may be the most natural way to slip into this distinction when you have to make it.
But then, if you have
field: 'date (or whatever) you can't expect indirection implicitly from
select field...you have to do something like
select :field or
select @field, or do you always use GROUP!s for composition with
select (field) ?
My point is that across dialects, it's not all that comforting to say "each one has whatever its own rules are". It would be nice if there were some systemic guidelines.
Some Opening Thoughts
The move to a dialect where "everything is in a block" is a pretty radical one. PARSE could have done that, enabling weird features like adding more input for the same operation.
>> parse [input "aaabb" rules [some "a"] input "bbcc" [some "b" some "c"]] == "aaabbbbcc"
(I'll point out that Lisp's LOOP macro has some of this same feel, which has made me wonder if the LOOP word should kick into a similar dialect.)
Thinking of query as not trying to pull any aspects out into separated parameters sends it into its own universe. It can't be a beneficiary of things like specialization. You'd probably see a lot of cases of:
my-query-date: func [file] [ query compose [select date from (file)] ]
In situations like this, it's just a fact that the system is going to have to break down the dialect into parts in order to process it. Those parts will be parameterized with formal arguments, digested and collated into a machine-processable form. There would likely be a lot of applications for these routines, where monolithic QUERY wouldn't be suitable.
To model what the internal parts would look like, I've suggested looking at the plugin architecture of systems like osquery. They've abstracted querying across a wide range of non-database things:
This might let us get a glimpse of what the middle forms would be. I did a bit of investigation into building osquery, which I should get back to looking at...
I lamented while trying to make BITWISE that dialecting is very poorly defined. We don't know what role binding plays in dialect evaluation or what good and bad are. So really, any thoughts here on the tradeoffs or even examples of what not to do would be good...