World: r3wp

I have also been working with Ladislav on many math fixes... which 
he wants to test out.

If you undo the DO string break, that would be worth it too.

But, is there a solution to the bug it causes?

It is not thhe cause of the bug. Read the ticket again - I found 
out the real bug and fixed the ticket at least a day before alpha 
55.

Maybe we need DO string! to error out with a message: "old fashioned 
char-based coding is not allowed."

Ok, I missed it -- or it was not clear to me.

DO of file causes the same bug.

DO of string not working is a worse buug than CATCH/quit messing 
up a TRY block.

Yes, but there's DO file! and there is DO string!  And one is good 
and healthy, the other nasty and perlish.

Anyway, will do.

Yes, and both disable TRY because the real problem is CATCH/quit.

CATCH/quit is rather special.

I was a little surprised that it cased the problem. I thought catch-or-try 
blocks were nested, their contexts stacked.

CATCH and TRY are actually quite different mechanisms. The problem 
is how best to combine them. They both have advantages.

The TYPE? THROW or RETURN issue was interesting. I'm not sure how 
important it is to fix, but it was an interesting insight into how 
those two functions work in R3. Apparently they don't throw until 
their return values are evaluated?

OMG CAAAAAAAAARL  !!! the real CAAAAAAAAARL !!! OOOOOOOOOO MY  GOD 
 ^^

welcome back in rebol3  world  Carl nice to see you here  ^^

pekr nope  the os futur is rebol 3 :P

TomC: what is your favourite RANDOM for R3?

Each time I see someone mention Erlang model I want to post my last 
"actor-ish" rebol samples I made like 3 weeks ago and still haven't 
found time to post .. it's nothing special, but it can give a little 
feeling and future ideas how it would look in rebol

does rebol 3 have a fast function which converts  [[1][2][3]]  into 
[ 1 2 3] ?

No, you'll have to write your own flatten function.

We discussed adding one, but everyone wanted the function to do something 
different. No consensus.

I think it should be simple. But then again, that's in the same territory 
as "parse string none". What should it do?

What types do you want to flatten? Just blocks, or other block types?

just blocks... cause its a recurring "problem" thru the years.

well, any block, list, hash but not things like objects.

obviously, I know how to write one... but its a pretty recurring 
need for inclusion in the /plus pack... no?

Yeah, it's a good candidate for /Plus. The problem is that whenever 
the need occurs, what it needs to do is slightly different. Flexible 
semantics like that lead to a slow function - which is a bad thing 
for a mezzanine or library func.

June - we need updated R3 Plan :-)

Already mentioned it to Carl here yesterday.

load form  [[1][2][3]]
== [1 2 3
]

That is so true: "everyone wanted the function to do something [a 
little] different".


So, the question always becomes: what is the most common pattern, 
and how common is it really?  Difficult to know, especially when 
you start thinking about adding reduce or compose into it.

R3 Chat #4395:
  

Re #1890: Question on DO/next: currently, it returns a block as a 
result. That means it must allocate a new block each time. An alternative 
would be to provide a variable name as an argument, and it would 
not need to allocate a new block each time.

   result: do/next block1 'block2

It would also be possible to:

   result: do/next block 'block

Something to think about.

OK with me

(I don't know how many people use DO/next - I don't use it myself.)

can you check bug#879?

Tomc needs it for a homework assignment, unknown due date.

Ok, where best to post the answer?

I will post it in the bug report.

Do/next I defined my %build.r dialect with it

...and later %spider.r dialect, %xyplot.r dialect, using %build.r

I am using %build.r instead of Compose as I advertised many times

BTW, BrianH is a co-author of it

Ladislav: random ticket updated with code

Carl, there are at least a half-dozen mezzanine/library function 
requests that are waiting for DO/next. Your continuation word idea 
is good though :)

For compat, it could be different refinement name.

The difference in overhead is large, but not sure how much it matters 
to anyone.

no prob with me even with the same name

overhead: yes, I found a test showing really huge diff when not generating 
blocks every now and then