r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3]

Ladislav
18-Feb-2010
[895]
well, "part of that direction" - maybe, just not working in this 
case, as demonstrated
Pekr
18-Feb-2010
[896]
Then CureCode it, and maybe Carl will answer that one :-)
Gregg
18-Feb-2010
[897]
Brian, if "Returns TRUE if the values are equal and of the same datatype 
& case." is OK, but "Returns TRUE if the values are equal and of 
the same datatype and case." is not, that's where I think uor priorities 
are out of order. 


Maybe the first thing we should do is write a clear goal for doc 
strings. What is their main purpose and what constraints should be 
placed on them for each purpose (or maybe I just haven't seen the 
doc that does this)? For example, are they be limited for console 
output only when listed with other funcs, or also when used with 
HELP individually? Should ? be short help and ??? link to a detailed 
help page for funcs? If console group list is the constraining factor, 
can it truncate and ellipsize longer strings?
Robert
18-Feb-2010
[898x2]
Is there a difference between an object! or context! Any rules wheren 
to use one or the other? I use contexts more likea "class"(data, 
functions) and objects mor like blocks.
I think that modules are the way to go, but than why we have context! 
and object! ?
Steeve
18-Feb-2010
[900]
wait... there is not context! datatype...
Robert
18-Feb-2010
[901x2]
Hmm... true. So CONTEXT seems to be just a short-cut.
How about an unblock function? This would help in cases like:

reduce [words-of my-object]
== [[my-words...]]

reduce [unblock words-of my-object]
== [mywords ...]
Geomol
18-Feb-2010
[903]
Your unblock returns a series of words. You need to have them in 
a series (a block). You can do these:

first reduce [words-of my-object]
or simple
words-of my-object

I can't see, an unblock would be possible.
Robert
18-Feb-2010
[904]
word-of returns a block
Geomol
18-Feb-2010
[905x4]
yes
So
unblock words-of ....
should return what?
Remember every function and operator in REBOL returns exactly one 
return value. Some would argue, PRINT doesn't, but it returns a value 
of the unset! datatype. If you need to return many words, you have 
to put them in one return value, like a block.
>> type? print "Hello, World!"
Hello, World!
== unset!
Robert
18-Feb-2010
[909x2]
Example: I want to get

["some string" word1 word2 word3]

If I write:


reduce ["some string" words-of ...] will return: ["some string" [word1 
word2 word3]]
So I need to get rid of the 2nd block.
Geomol
18-Feb-2010
[911x5]
You can get that by:

reduce ["some string" first worlds-of ...]
sorry
haha, late here. Let me think.
Try this:

join ["some string"] words-of ...
I see, what you want, but you can't do that in REBOL, because a function 
can't return more than one value.
Robert
18-Feb-2010
[916]
Yep, used the JOIN as well. But thought it's a generic pattern.
Izkata
18-Feb-2010
[917]
Has 'compose been removed or changed in R3?
compose [ "some string" (words-of ...) ]
== [ "some string" word1 word2 word3 ]
Geomol
18-Feb-2010
[918x2]
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.
Graham
18-Feb-2010
[920]
Any reason why dates can't be determined by the system preferences 
so that  1/12/2010 is 12-Jan-2010 ?
Geomol
18-Feb-2010
[921x2]
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*
Pekr
18-Feb-2010
[923]
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 
...
Geomol
18-Feb-2010
[924]
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.
Graham
18-Feb-2010
[925]
most people don't change their date preferenes
Geomol
18-Feb-2010
[926x2]
:-)
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?
Graham
18-Feb-2010
[928]
slow down date recognition a little ... I don't think so.  It could 
be vectored on rebol start up.
Geomol
18-Feb-2010
[929]
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?
Graham
18-Feb-2010
[930x2]
Or, you could set the date preference as the top of the script
You should be able to also set the date window ...
Geomol
18-Feb-2010
[932x3]
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.
Gregg
18-Feb-2010
[935]
flatten: func [block [any-block!]] [
        parse block [

            any [block: any-block! (change/part block first block 1) :block | 
            skip]
        ]
        head block
    ]
Paul
18-Feb-2010
[936x2]
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
]]
Gabriele
19-Feb-2010
[938]
Graham, so, if I load your rebol files, they would work differently 
on my machine because i have different preferences? :)
Graham
19-Feb-2010
[939x2]
Absolutely :)
but then I would expect you to have different data from mine
Steeve
19-Feb-2010
[941]
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]
Gabriele
19-Feb-2010
[942]
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)
Oldes
19-Feb-2010
[943]
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.
Steeve
19-Feb-2010
[944]
it's done since a while, but noone noticed it. :)