World: r3wp

Brian - that makes a difference then ... isn't example comment wrong 
then? "Back in the same position as before the AT."

Let me check...

forget AT, there should be AND, it is a typo. But as I understand 
it, it returns back at initial position?

As you described AND few moments ago, it sounds logical - if all 
conditions are succesfull, then OK, otherwise return to the starting 
position right in front of AND?

Ah, but you didn't get that AND only appears to take two arguments. 
It actually only takes one argument, and the second works on its 
own.

hmm, so and is not semantically aligned with | ? I mean [a & b & 
c]?

btw - how is that => is not infix?

Simply put - so far I am confused ....

AND has to be prefix to work, which is why it isn't called &. Algorithmically, 
it is the commplement of |, which needs to be infix to work, and 
is the only operation that *can* be infix. Implementation restrictions 
that we try to make sensible, by using visual naming tricks.

OK, but - we always think about OR vs AND as their logic counterparts. 
Now it is not true, or is it? By our definition:


AND: Purpose: A look-ahead rule: Matches the parse rule without changing 
the current position. 


I am denerved about the "without changing the current position" part. 
It is some explicit rule user will have to know. Why not to advance 
the position?

All of these are rules the user will need to know. It's a programming 
language, not baby talk.

hmm, actually I wonder, how can I match one input stream by multiple 
rules (the real logical AND), this is not probably even possible 
:-)

The whole point of AND is to *not* advance the position. It allows 
you to check more than one thing about the same data.

AND block! into rule - does mean - check if the next match is being 
a block, but don't advance. And if so, go into rule? If so, then 
AND is totally weird name ...

It works the way you want.

I need following to work in terms of parse dialect :-)

keep: :and

Not a weird name, it is the closest equivalent to a logical and that 
you can get in a backtracking system. The only weird part is that 
it is prefix instead of infix. However, if you remember that *all* 
parse operations are prefix (except | ) then it won't seem so weird.

=> needs to be prefix, since in [a => b | c] the => doesn't test 
the a at all:

- The a is matched first, and if it fails it backtracks and advances 
to the next alternate (aka, past the next | )
- If a succeeds then the next rule is processed.

- The next rule is =>, which matches its argument rule and then skips 
the next alternate, whether the rule succeeds or fails
- b is the argument rule of =>
- | c is what => skips

Strangely enough, you can think of the | as being prefix as well: 
it signifies the beginning of an alternative.

Does AND, in our parse situation, have anything in common with math/logic 
AND? I am not able to see so deep, but I know that parse is in fact 
some deep math ...

AND is like the shortcut boolean logic and. | is like the shortcut 
boolean logic or.

And can I explain, by such math layer, why it moves, or not? All 
I am trying to find out is, if we can explain to the user, why "AND 
block! into rule" does not consume block! position :-)

Because that is how you can check that the current value is a block! 
AND matches into rule.

re: => needs to be prefix, since in [a => b | c] the => doesn't test 
the a at all ... I thought, that underlying C level can decide, if 
something can be prefix or infix = match a and look if next keyword 
is =>. But then it would mean, that we would slow down parse engine? 
Because then we would have to perform such check for each rule applied, 
to check if eventually => follows?

Because that is how you can check that the current value is a block! 
AND matches into rule.

 - remember that one for the docs. There will be many stupid users 
 like me, trying to understand, what the heck AND is doing and why 
 it is doing so = we want to have description theory why it is the 
 way it is :-)

The evaluation method requires that operations be prefix - it's a 
state machine. The only carried-over backtracking state is used to 
implement | alternates. It would double the complexity of PARSE to 
make another infix operation.

I've learned a lot about the implementation of PARSE this week. I'm 
almost to the point of being able to write it myself.

Hmm, interesting. Does not Carl think of 'either in terms of infix?

I like => more and more (especially as I suggested it :-), but Henrik 
suggests, it has different meaning in Math. Is that true? I do remember 
that I often use ==> to express "then", so I just shortened it to 
=>

I was also inspired by one script, and now I dont remember which 
one, which used something like ---> in combination with some indentation, 
but maybe it was just a debug output ...

I havn't commented much on parse because I tend to only use it in 
its most simple form:

	parse string delimiter


which got me thinking that, if we havn't already, perhaps this major 
use case is deserving of its own "split" function?

>> ? split
USAGE:
	SPLIT series dlm /into

DESCRIPTION:

 Split a series into pieces; fixed or variable size, fixed number, 
 or at delimiters

Mezz or native? Not exactly clear how the /into refinement works.

/into is a new refinement for most series. It makes it possible to 
store the result directly in a series without copying. I've been 
watching BrianH jump up and down over this feature a few months ago. 
:-)

split is mezz.

So how does the "fixed size" bit of split work then?

the 'dlm can be either a char/string for variable size or an integer 
for fixed size.

>> split "1 2 3 4 4" 2   
== ["1 " "2 " "3 " "4 " "4"]

>> split "1 2 3 4 4" " " 
== ["1" "2" "3" "4" "4"]

Ah thanks. That's a very usefull addition.

ok, there are some bugs in this function. /into does actually not 
work this way. bug reports will be needed here.

it seems that it's bound for a rewrite. perhaps the priority should 
be bumped.

Being mezz makes that easier at least.

anyhoo, the point is that the obscurity of splitting using PARSE 
might be removed, so we will be using SPLIT in the future.

Maybe TOO is too similar to TO,  but it's meaning is appropriate 
for this AND or  &

write parsing CSV like input, there was a proposal to solve it via 
external function or decode-csv aproach, which could internally use 
parse.

for new parse rewrite, there is going to be default /all mode, and 
/ignore mode and even maybe /case, so dunno, if delimiters will be 
provided as with R2 parse ...

I have a small CSV parse and CSV generator library that we could 
start from.

Henrik, i hope we will not remove the splitting behaving of PARSE 
because actually SPLIT is damn slow

SPLIT has too much useless options and use other mezzanines (COLLECT) 
in his code, it why it's not a good mezznine to my mind.

Actually, i don't like mezzs which return block of data with unlimited 
sizes.

I like mezzs with async behavior, to treat each data set, step by 
step.