but if we're going to take that route we want to know there's something better on the other side of it, that we can work towards. so we want to think through what the parameter-based CLI would be.
in particular, would it be
./evoke evoke.e inscribe ? or ./evoke inscribe evoke.e ? or would it be permissible to leave out the .e ?
and how would this relate to situations where we're not compiling anything and we want to use the parameters as something else, a list of files to pre-load or a list of stack operations to perform?
the usual non-Forth conventions for command-line parsing treat each word as potentially affecting the syntax of everything later on the line, but not before it. breaking with that would be a big deal and should only be done if it allows a different form of consistency that we find more important
a rule we could create is that filenames as CLI parameters are turned into string literals, while other types of word are executed as they're encountered. this would make ./evoke evoke.e inscribe work as-written. but, uh, is that.... good? lol
an alternate rule would be that the only words that can happen on the command line are words drawn from a specific closed vocabulary which provides special syntax support for being used that way. so there would be some sort of internal inscribe-from-command-line helper which gets called for this situation.
that would let ./evoke inscribe evoke.e work, at the cost of forbidding the user from doing ./evoke 2 3 + 9 * logfloor . or whatever
(of course * won't work in that context anyway because it's special to the shell, but let's imagine we have a user who doesn't mind working around that every time)
or, we could forgeo all these special rules and treat the command line parameters as just like any other execution context. then the invocation would be
it does require the user to work around the shell's handling of quotation marks, but that may be worth it for consistency. after all, it's their shell, they can swap it if they want...
now, one more thing. imagine the someday-voice-control version of this UI. in that setting, we don't get to directly type punctuation marks, we have to say everything out loud as a word, which means we need a vocabulary of words and short phrases that deal with our syntactic constructs. it's highly important that it be a very small vocabulary, to make things easier for the speech-to-text engine and for the user; larger vocabularies lead to ambiguity problems.
that's a little awkward, but probably acceptable. if anything, it's better than the typed shell version, as long as it's processed in a way that handles the quoting
this form of it would require an approach similar to the thing we proposed above for the typed ./evoke inscribe evoke.e command, allowing the word "inscribe" to have special behavior attached to it that changes the meaning of following utterances.
the same pressures apply, though, where we don't really want to have to have the acceptable words to use as parameters be such a tightly controlled vocabulary. we want to be able to use the whole language that way.
ah well. we had hoped writing this out would help us decide what we want, and perhaps it will, but we need to let the thoughts settle first. thanks for reading along :)
it didn't come up above, but one reason we hadn't done that yet is that the transformation system and the other stuff used in outputting executable binaries isn't actually part of the evoke binary by default. we could trivially add it, but it's nontrivial to remove things from the binary, so we were waiting to have a good reason to.
we suspect Evocation is already large enough that the lack of directory structure has been an obstacle to readers (please do weigh in if you worked on the code - as a couple of people have now)
it was fine when it was just us, because we have that in our head, but it should be "official"
@ireneista it's not something we noticed but it would've definitely made it more coherent! we use all the metadata-aids we can when working on something so utterly foreign like Evocation is. so it would be good :)
