World: r3wp

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.

I'm reading several times needs for CSV parsing enhancements, are 
they issues with parsing CSV files with R2's parse?

On example here -- the specific problem is the same in R2 and R3:
   http://www.curecode.org/rebol3/ticket.rsp?id=1042&cursor=2

This highlights the actual change that would need to happen to PARSE: 
http://www.curecode.org/rebol3/ticket.rsp?id=1079

Thanks, so it's parse's splitting ability that is causing an issue.

Brian - it seems that Ladislav does not agree to your conclusions 
towards parse internals ... and Carl is all but silent :-)

It reminds me of old ML discussions of gurus, trying to find internal 
REBOL representation, and differing in opinion of how things are 
done under the hood.

Carl revealed the internals, inadvertantly, earlier in that comment 
discussion. It was easy to figure out. Ladislav needs to read closer.

Back in 2000 I was one of those gurus on the mailing list, and my 
argument with Gabriele was the initial documentation for R2's context 
model and behavior. I was glad when Ladislav later fleshed out that 
discovery with more detail in his Bindology papers.

I do remember guys like Tim Peters, Joel Neely, etc., Well, those 
were the times :-)

:)

I remember Carl used to be on the mailing list ...

I remember I used to be on the mailing list. Haven't been for many 
years now.

I have a proposal - I think that we all know, that View engine itself 
needs few enhancements, which would be nice to have for the official 
3.0 release. I would like to create wiki page similar to Parse proposal, 
to which we could contribute our requests. What do you think?

I don't think Carl will work in View engine anytime soon, but having 
those things collected in one place would be surely good.

Sounds good ... and won't hurt

I think that Cyphre can't work on View engine because of C code alignment. 
We have to wait, untill Carl isolates kernel and host, and releases 
the code. But then - even few small changes might make some difference 
in the end. I think that View engine deserves few weeks of additional 
developments ...

My favorites are:

- better font support
- ability to precisely measure font-size
- draw level events?
- move to Multimedia Timers
- transparent windows - just setting bits in API
- we don't use bitmap caching yet
- eventual switch to compound rasterizer

my requirements are 

draw item word reference,   [target: circle 0x0 50 ]
draw item as objects,    [target/offset: 20x20]
vertice access & control,

key up events.
timers