I started writing a post, then solved my problem, but still have a question. So, here’s what I was originally going to ask you all:
The solution, it turns out, is that I can’t ask if something “does not match” for regular expressions. Instead, I have to say if B matches the regular expression "\s":
do nothing;
else:
say "[B] is not a space."
So my question is: is this intentional? I can kind of see “yes,” since the goal with regex matching is usually to go on to replace/manipulate the thing that did match. It was definitely confusing to me, though, since I’m used to thinking of “doesn’t” as, you know, just the opposite truth state from “does.”
The “if (snippet) matches (topic)” phrase has an inverse “if (snippet) does not match (a topic)”. (You can’t use “doesn’t” there, however.) So it’s reasonable to ask if regexp matching should follow the same pattern.
Most, but not all, conditional phrases are defined with “not” inverses like this. It has to be done case-by-case in the Standard Rules; the compiler doesn’t have a general understanding of negated verbs. In this case, I think it make sense to have them.
EDIT-ADD: I forgot to mention “unless”. You can say “unless (condition): …” , which is just like an “if” phrase but inverted. That works anywhere a phrase-level “if” does.
I’d go for unless in this case. I’ve always liked unless, ever since I first saw it in Perl.
On a related note, is there a cleaner way to say this?
To decide whether foo: yes
To decide whether bar: decide on whether or not not foo
(where bar is the negation of foo.) Adjective phrases have a nice way of defining either/or values - do “to decide whether” phrases have an equivalent?
And, if you’ll pardon the rant, why aren’t truth states interchangeable with the return value of a boolean expression? If I call a truth state “the foo has arrived,” why do I have to check “when the foo has arrived is true” rather than simply “when the foo has arrived?” If you really want to get fancy, why not allow a declaration like this?
The foo has arrived is a truth state with opposite the foo has not arrived.
You mean the “… rather than …” syntax for adjectives? No, I don’t know of anything.
You could define a general condition negator – not tested, but probably
To decide whether opposite (C - condition):
(- (~~({C})) -).
I’m pretty sure the only reason that’s not in the standard library is that there’s no nice English way to name it. “Opposite” is awkward, “not” is awkward in most cases, “not the case that” is too long, … etc.
I don’t know. Maybe it would interfere with parsing other things. Maybe it’s just an over-harsh rejection of the anything-is-interchangeable-with-boolean model that other programming languages use.
The foo has arrived is a truth state with opposite the foo has not arrived.
To be honest, that’s kind of horrible to anybody except a logician.
I could unpick all the syntactic ideas that that example implies, but I suspect that’s not what you’re looking for.
Whether or not the foo has arrived varies.
[or]
It can be true that the foo has arrived or that the foo has not arrived.
Okay, I didn’t grasp earlier what you were trying to do. Hm. I’m still not sure. Your suggestions aren’t actually suggesting to me what you want them to do, which is a black mark, I’m afraid.
Are you trying to define a global variable – that is, a settable truth state – but have it usable as a condition, rather than a truth state value? Or are you trying to define a “to decide whether” condition (not directly settable) that has a natural inverse phrasing?
For the former, I think that allowing the compiler to use truth state values and conditions interchangeably is a better solution than any new syntax.
For the latter, I wouldn’t mind being able to say:
To decide whether foo has arrived (rather than foo has not arrived): ...
It’s hard to shorten that, however. That is, I don’t expect the compiler to be able to parse “To decide whether foo has arrived (rather than not arrived)” because a phrase doesn’t necessarily have an “is” verb, nor a clear subject either.
I meant the former, except that I think truth states should also have definable inverse phrasings. A “to decide whether” phrase wouldn’t really be enough for that, because you couldn’t then declare “now the foo has not arrived.” But I like both your suggestions.
I’m not discounting the idea of getting the compiler to recognize linking verbs. I don’t know how difficult it is, but it would be a clear win.
That is: if you define “to decide whether zig is zog”, the compiler would pick out the “is” and defined “whether zig is not zog” and “zig isn’t zog”. Ditto for “are” and (stretching a point) “has”.
Applying the same logic to any truth state containing “is” requires a little extra infrastructure.
There is potential for confusion here. Users would have to understand that defining “whether zig is zog” implies an inverse, but “whether zig matches zog” (the original question here) does not.
Similarly, for truth states, defining “The roast is done is a truth state that varies” would be somewhat different from “Doneness is a truth state that varies”. (And different again from “Definition: the roast is done if …”, not to mention “the roast can be done”.) Arguably this swamp doesn’t need any extra logs thrown into it.
Getting back to this. Without the help of that very appealing feature, what’s the cleanest way to create a pair of “To decide whether” phrases? I’m getting really tired of this almost comically ridiculous formulation:
To decide whether foo has not arrived: Decide on whether or not not foo has arrived.
That was added a just few builds ago, for type safety. If a Decide phrase ends without returning anything, it returns the default value of whatever the return type is.
