Comments on: PARSE: CHECK vs IF, then EITHER

The CHECK word has been proposed for parse:

check (condition)

If the condition evaluates to true (using normal if rules), then parsing continues, otherwise the rule fails.

So, this expression parses an integer and checks that it is odd valued:

[set i integer! check (odd? i)]

My initial reaction was that CHECK should be named IF, like the if function.

[set i integer! if (odd? i)]

That seems good.

But, there's also a proposal for EITHER, which has the form:

either rule1 rule2 rule3

It parses with rule1, and if true, then continues to parse with rule2, otherwise if rule1 is false, continues with rule3. This is not the same as:

rule1 rule2 | rule3

nor:

rule1 [rule2 | rule3]

but actually:

rule1 rule2 | not rule1 rule3

But, EITHER is more efficient, because the NOT of rule1 is unnecessary.

However, in this case, the argument to EITHER is a rule block, not a paren expression as in IF above.

So, if we want IF, then is it problematic for EITHER not to work the same way (with an evaluated expression)? If so, then what do we want to call EITHER?

17 Comments

Comments:

Brian Hawley 22-Sep-2009 3:22:52	The reason I chose the name CHECK is because the operation doesn't act like the IF function: It only takes one parameter, and it must be true or it won't continue. CHECK really isn't like IF - it's more like a weak ASSERT. As for EITHER, the reason I said maybe is because it doesn't act like the EITHER function. Programmers would get confused. But Peta made a good theoretical argument for its existence. Maybe EITHER could be renamed, like AT?
-pekr- 22-Sep-2009 4:17:39	There will always be problem with dialects, if they contain the same keyword names as REBOL functions. So we have to somehow live with that. So the question is, where to introduce new name and why, just to be different, and where to not. E.g. parse 'copy keyword has already different semantics to REBOL's one, or VID's 'at has different semantics to REBOL's one. Now can users be confused? It depends. I try to think about each dialect in the context of the dialect itself - so the only measure for me actually is, when reading the source code (or trying to understand one's), how quickly I am able to understand, what is going on? But then we could as well replace 'stay by 'save-position, 'of by 'any-of, 'if by 'only-if, etc., which would imediatelly map the meaning to what the keywords are really doing. But we are somehow mysteriosly looking for one-word-only-mantra naming convention, and I suppose it is already our style, and we will not change it :-) ... so, the topic is a little bit more abstract - it is about contexts, and user/programmer switching between contexts, and his/her ease of understanding of the code. In above case, all 'if, 'check, 'either are OK, even if their semantics is a bit different to their REBOL counterparts. From 'either, you can continue to 'swich or 'case later :-) OK - enough of philosophy :-) I do prefer 'check, because its name is OK enough, and because of the difference between its argument to 'either - paren (REBOL code) vs. the block rule.
Steeve 22-Sep-2009 6:57:48	Why not allow that words bunded with functions behave like CHECK (my_function) by default ? There is no other use for such words currently. i.e >>parse data [my-function] same as >>parse data [check (my-function)]
Ken Singleton 22-Sep-2009 8:19:33	I think that if and either are better. They read more fluently and they fit into the existing understanding of if and either from the core, just as copy does. Eg. "set i to the next integer and if i is odd continue" and "either rule 1 is true then rule 2 else rule 3" That rule 1 is a block and the if condition is in parens makes sense because the (odd? 1) is normal rebol and the rule 1 block is a normal rule.
Carl Sassenrath 22-Sep-2009 12:01:35	BrianH: yes, they are a bit different... but... Petr makes a good case, and I think he's throwing our own words back at us (at least it sounds a lot like what I've stated before.) Steeve: that's an interesting idea... I've been thinking about what would be a good use of functions within parse rules. What other possibles uses for functions might be found? Ken: that's about where I am right now too. Kind of sums up all the above. (It would still be possible to use Steeve's suggestion, if we don't find anything better for functional values.)
Carl Sassenrath 22-Sep-2009 12:19:56	It probably should be noted, that if we use IF, then EITHER should be: either (cond) rule1 rule2 So, that does indicate the need for another name for the above "EITHER" that uses a rule, not a paren (or we could allow both, if that makes sense.)
-pekr- 22-Sep-2009 12:47:12	I would stay with 'either name, no matter what the condition is like - allowing both paren and rule is not a bad idea, but of course condition has to return logical value :-) I think that in future, we can really have even 'case ('either with more than two options) or even 'switch implemented for branching.
Maarten 22-Sep-2009 13:03:59	Checks, conditions: the common name these days seems to be "guard". I think it covers better what it does. Often observed in Type/pattern matching languages: {a,b,_} when a integer, a > 0: etc.
Maarten 22-Sep-2009 13:06:38	Feature: break with return the current position. Re-entering a deep (nested) block directly with parse. Errrr.... Nevermind ;-)
Maxim Olivier-Adlhoch 22-Sep-2009 13:08:29	Re "functions as conditionals": maybe, wouldn't they be even more powerfull as: "create the rule on the fly". much cleaner than allocating a word to act as rule storage, using a paren to call a func, then assign it to that word. its akin to building our own keywords, which makes parse reflective to the rest of REBOL. if we can create our own control structures in REBOL, why not in PARSE Too?
Maxim Olivier-Adlhoch 22-Sep-2009 13:11:48	'EITHER should allow both parens and block. less to syntax to remember and no reason not to AFAICT. if its a block, use the fail condition, if its a paren, use conditional logic (none=false).
Ken Singleton 22-Sep-2009 14:40:14	I feel strongly that we use the words if and either in the parse dialect. Why? Because the 'concepts' expressed in the words if and either are identical in Rebol and the Parse dialect. The only difference with the if in the parse dialect is that the action is fixed and so implied (hidden) - 'continue parsing' - whereas normally it is explicit only because we can change it. But the concept is identical. Likewise with either, either X then Y else Z - the X is irrelevant except it results in a true or false value. So X can be a rule, a condition, a function or program running on the opposite side of the world, as long as it returns true or false to either. So, why complicate the language by using yet more words to convey the 'same concepts' just because the concept has to have a slightly different syntactical nuance out of necessity in the dialect?
Carl Sassenrath 22-Sep-2009 14:44:21	Pekr: still thinking about it. As for CASE, it's the basic pattern of parse already. Maarten: GUARD sounds more like PROTECT, and I've even thought about using it along those lines. Yes on BREAK return current. What about deep blocks? Maxim: interesting idea on function usage. WRT EITHER: I'm still considering it... because it seems to me that there's something important lurking within it.
-pekr- 22-Sep-2009 15:51:15	Ken might have a point. If we use words for the same concept, it maybe does not matter, that the semantics differs a bit, and hence there is no need to introduce new words. After all, the word is the same, it is the usage context, which differs Carl: wouldn't Maxim's proposal possess any security issues? I mean - allowing functions directly?
Maxim Olivier-Adlhoch 22-Sep-2009 21:16:32	pekr we can already execute code in parse... using () and replacing rules... like I describe. I don't see where a shortcut for something we can already do manually would add more risks than what is already possible with parse. its just a shortcut. repetitive rules can be more easily build on the fly, especially with SOME, :word and word: usage.
Gerard Cote 23-Sep-2009 22:36:54	I agree with Maxim. The idea of having functions when possible is expressive and flexible while shorter too. A bit like the path notation ... but may be I am misunderstanding something.
Brian Hawley 29-Sep-2009 1:24:37	Maxim, with parens, change, insert and remove, you can statically analyse the parse rules to determine whether they are safe to run. If they contain any parens or any of those keywords, it's unsafe. You could parse the rules to remove those references and they would be safe. Having PARSE call arbitrary functions would open you to problems that would require data flow analysis to catch. Not the same thing.

Post a Comment:

You can post a comment here. Keep it on-topic.