World: r3wp

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

It would matter to me. If DO/next were more efficient, I would not 
consider use of it to be a sign of a bad function :)

I'm not that worried about compatibility here - see bug#666 :)

It would be simple to search for, like copy/deep which is also improved 
in R3.

thanks, Carl. BTW, I am using www.rebol.org as a truly random source, 
since it is so easy in REBOL

errata: www.random.org

I just read bug #666. Cool number and cool ticket at once :-)

When I saw that number coming up, I had to do something appropriate 
there :)

I just lost my connection to rebol.net -- quite odd -- as if a router 
along the way just stopped working.

See R3 Chat #4403 regarding how to get new R3 to test DO/next.

Carl, btw, something in liquid is causing a  prior versio of R3 to 
crash.  I'll try next week with the latest version, there might be 
some new tickets coming as part of the R3 conversion of liquid.

BTW, I estimate DO/next overhead about 30% of full speed DO.

quite slow, no?

Maxim: is it just the math part of Liquid or includes graphics?

Pekr, no... that's very fast!

There were no changes in gfx kernel for quite some time, no? Well, 
but maybe it could be related due to some other changes?

carl: just the dataflow part.... the graphics engine is obviously 
not compatible.

In other words, it is running at 66% of full speed of REDUCE!!

its an object within an object, so I am thinking it has something 
to do with binding.

Maxim: ah good, I look foward to seeing the problem.

BTW, there is a bug in objects related to a copy loop if the object 
references itself (directly or via a block).

Is that  new?