World: r3wp

COMPOSE is in R3, and it's a way to get the desired result.

You can also use a function like this:

flatten: func [block /local result] [
	result: clear []
	forall block [
		append result either block! = type? block/1 [
			to paren! block/1
		][
			block/1
		]
	]
	result
]

>> flatten [1 [a 2] 3]
== [1 a 2 3]


Can only flatten one level. If you have blocks within blocks within 
blocks, you need another loop or make it recursive.

Any reason why dates can't be determined by the system preferences 
so that  1/12/2010 is 12-Jan-2010 ?

I don't see a techinal reason. It could be implemented, but will 
slow date recognision down a little bit. I've considered sort of 
the same for thousand separators, so these could be recognized:

1.200,00
1,200.00

But will slow scanner a little bit and make code more complex.

*technical*

Why is REBOL3/Docs Recent changes subpage protected by password? 
This page is essential to me, as well as recent changes page on wiki. 
This is the only way to find out, if there is something new happening 
...

Graham, about the date thing. It's also a potential problem, if you 
forget to set the system prefs back and then run some script. Your 
dates would suddently behave strangely.

most people don't change their date preferenes

:-)

Let's say, you did change you date pref once. Then a month later 
you read some data with some dates. Now, what format would you guess, 
those dates were in?

slow down date recognition a little ... I don't think so.  It could 
be vectored on rebol start up.

Hm, maybe we don't talk about the same here? I understood you, as 
all dates should be recognized MM/DD/YYYY, if you so choose?

Or, you could set the date preference as the top of the script

You should be able to also set the date window ...

Argh, my flatten function can be much simpler:

flatten: func [block /local result] [
	result: clear []
	forall block [
		append result block/1
	]
	result
]

Yet another version, that works with nested blocks:

flatten: func [block] [
	forall block [
		if block! = type? block/1 [
			change/part block block/1 1
		]
	]
	block
]

>> flatten [1 [2 [hmm] 42 3] 4]
== [1 2 hmm 42 3 4]

Well, last version can't cope with blocks as first element in blocks:

>> flatten [1 [[hmm] 42 3] 4]
== [1 [hmm] 42 3 4]

so not perfect.

flatten: func [block [any-block!]] [
        parse block [

            any [block: any-block! (change/part block first block 1) :block | 
            skip]
        ]
        head block
    ]

Steeve, there was no Context! datatype in R2 either.  It has always 
been Object!

;Here is my old one from R2 just quickly formatted for R3:

flatten: make function! [[

    {Returns a new block with desired blocks flattened or removed}
    blk [block!] "block to flatten"
     /fine "Flattens blocks to finest representation"
     /semi "Flattens to support 'select operations"
     /full "Flatten fully - ignored with other refinements"
     /local blk2
    ][
    blk2: copy []
    fl: func [b][
        either parse b [block!][
            b: first b
            fl b
        ][
            either semi [
                insert tail blk2 b
            ][
                either full [

                    foreach val b [either block? val [fl val][insert tail blk2 val]]
                ][
                    insert/only tail blk2 b
                ]
            ]
        ]
    ]

    if fine [full: none while [parse blk [block!]][blk: first blk]]
    foreach item blk [
        either block? item [fl item][insert tail blk2 item]
    ]    
    blk2
]]

Graham, so, if I load your rebol files, they would work differently 
on my machine because i have different preferences? :)

Absolutely :)

but then I would expect you to have different data from mine

here's mine:

flatten: funco [data [block!] /deep][
    deep: if deep [[:data]]
    parse data [
        while [to block! data: change skip data/1 deep]
    ] 
    head data
]
>>flatten [[[1]] [[2]][[3]]]
== [[1] [2] [3]]
>>flatten/deep [[[1]] [[2]][[3]]]
==[1 2 3]

graham, yes, but code is data as well. how can we make something 
like that apply to "data" only and not scripts? in the end, i think 
it's more a matter of needing "custom" parsing for your data, which 
could be made easier (eg. by having special built in parse rules 
for dates and so on)

This is a very nice version Steeve. You should post it to the "favourite 
parse" blog. So we at least get back to it's topic.

it's done since a while, but noone noticed it. :)

http://www.rebol.net/cgi-bin/r3blog.r?view=0302#comments

A little something I put together to help R3 developers: http://www.dobeash.com/REBOL/r3-ref.html

Is r3 chat working?  I can't login

not working here

not working for me either.

I get two different crashes. They should both be fixed.

hi,

hi, where we can download makedoc3 script please ?

which one? there are makedoc3's by several authors. Carl's is not 
available for download.

don't think it has been released

Carl doesn't release stuff he has no time to document!

i think he start the documentation about makedoc3 http://www.rebol.com/r3/docs/markup.html

Does anyone know, if protecting R3 Docs Recent changes site is intentional? 
It served me well to look into new stuff.

Interesting .. so we should push him to release it

Pekr, perhaps he doesn't want another debacle as with the license 
one

hi another problem for me !!!

'import do not 'do a module !!!!

in R3 console

new_word: make object! [test: 1]

test_mod: module [title: "test"][o: make new_work[]]

no problem with this..................but

when i but new_word into a file new_word.r and test_mod into test_mod.r 
and i try to import them

>> import %new_word.r
>> import %test_mod.r
** Script error: new_word word is not bound to a context
** Where: do applier make module do applier make catch if import
** Near: do body obj