World: r3wp

So, if we had a built-in, or standard library implementation of LEAP-YEAR?, 
would you want it to be the shortest or fastest one? The easiest 
to understand? The most REBOLish? 


The various approaches people use in REBOL always makes me think 
about this, and how hard it is to choose sometimes. e.g. here's mine:

leap-year?: func [

 {Returns true if the specified year is a leap year; false otherwise.}
	year [date! integer!]
	/local div?
][
	either date? year [year: year/year] [

  if negative? year [throw make error! join [script invalid-arg] year]
	]
	; The key numbers are 4, 100, and 400, combined as follows:
	;   1) If the year is divisible by 4, it’s a leap year.

 ;   2) But, if the year is also divisible by 100, it’s not a leap 
 year.

 ;   3) Double but, if the year is also divisible by 400, it is a 
 leap year.
	div?: func [n] [zero? year // n]
	to logic! any [all [div? 4  not div? 100] div? 400]
]

Using REBOL to help figure it out, even with error trapping, seems 
very REBOLish. 


Also, My days-in-year func is based on leap-year?, rather than the 
other way around, and John did.

Gregg, my preference is the one that offers the best performance.

My priority for library functions goes like this:
1. Stable
2. Fast
3. Easy to use
4. Easy to understand the implementation


That last one is only for maintainability - otherwise it is not a 
priority at all for library code.

Error trapping has a lot of overhead, so the more you can avoid basing 
your library code on it, the better off you will be.

anyone know what stats/types counters are reflecting?  i know when 
I add a block for example the counter remains the same value.

How transient are the blocks?  REBOL seems to do a fair job of not 
over allocating.   a: copy [] a: copy [] will only change the count 
by an entry, not two.   a: copy [] insert/only a copy [] should change 
select stats/types 'block! by two or so.

afaik

I figure if I created a block it would update the counter for each 
new block created as long as the older ones were still set as well.

Well, yes, but it could well replace an unused slot etc etc ... (I'm 
GC clueless) etc etc.  Wrapped in recycle you should see the numbers 
change a little more sensibly.

That's just it Brian.  All I did was open up the console and assigned 
a word a block value and check the stats/types for the block counter 
and it didn't change.  I added another one and still didn't change. 
 So I'm a bit perplexed.

Yeah, even after boot there are reallocatable blocks.   Try recycle 
first thing in the console, then run the experiments.  Once again, 
this is only afaik, 'cause I don't.

REBOL may allocate things in "pools" for efficiency. You shouldn't 
care Paul, except in extreme cases.

Yeah but if I know how they work I might be able to utilize that 
functionality in the future ;-)

Here is a total flatten function:

b: func [blk [block!]][to-block trim/with mold/only blk "[]"]

forgot to name it - here instead:

flatten: func [blk [block!]][to-block trim/with mold/only blk "[]"]

That kills the bindings of the words - is that intentional?

Yes it is intentional if someone wants to completely flatten a block.

I can't see where someone would want to keep context if they are 
deciding to flatten it to that extreme.

I have a more useful flatten function that encompasses that one that 
will be more useful for someone that wants to keep contexts of no 
so flattened blocks.

It could probably be a mezz as it is very useful

Brian, I'll see if I can whip up my comprehensive flatten function 
to include a context sensitive full flatten and post it here.

Here's a version which modifies in place:

flatten: func [blk [block!] /local rule a b] [
	parse blk [some [a: set b block! (change/part a b 1) :a | skip]]
	blk
]

Nice Brian

I've had to do something like it before. It doesn't preallocate or 
copy, but what can you do.

yeah true

Are they planning to put something like a flatten function in R3?

You can copy/deep first if you like, though that has allocation overhead. 
A version was proposed in the R3 discussions, but hasn't made it 
through the screening process (not general-use enough I guess).

to bad I can see why we need it.

Here's the thing: How often are you going to use it?


We are modularizing REBOL so that you don't have to bundle the whole 
thing together. Functions like FLATTEN would make a great addon module, 
but if the core code doesn't need it, or it's usage would be uncommon, 
it doesn't make the cut.


For that matter, the functions in R3 that I am backporting to R2 
are only those that I have actually seen in regular use in R3 mezzanine 
code. There are some more advanced functions that just won't be making 
it because their design hasn't been settled yet.


Picking something to go into the core is an involved process. And 
you can always make code libraries.

I agree with that.  keep it out and use it as a module.

>> help flatten
USAGE:
    FLATTEN blk /fine /semi /full

DESCRIPTION:
     Returns a new block with desired blocks flattened or removed
     FLATTEN is a function value.

ARGUMENTS:
     blk -- block to flatten (Type: block)

REFINEMENTS:
     /fine -- Flattens blocks to finest representation
     /semi -- Flattens to support 'select operations
     /full -- Flatten fully - ignored with other refinements

flatten: func [

    {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
]

>> test: [[1 ["select"]] [2 ["me"]]]
== [[1 ["select"]] [2 ["me"]]]
>> flatten/semi test
== [1 ["select"] 2 ["me"]]

>> test: [[[1 ["Select"]] [[2 ["Me"]]]]]
== [[[1 ["Select"]] [[2 ["Me"]]]]]
>> flatten/fine/semi test
== [1 ["Select"] 2 ["Me"]]

>> test: [[["this"]] [[["is"]]] ['a] 'big [[['mess]]]]
== [[["this"]] [[["is"]]] ['a] 'big [[['mess]]]]
>> flatten/fine test
== [["this"] ["is"] ['a] big ['mess]]

>> test: [[["this"]] [[["is"]]] ['a] 'big [[['mess]]]]
== [[["this"]] [[["is"]]] ['a] 'big [[['mess]]]]
>> flatten/full test
== ["this" "is" a big mess]

I'm not sure I care for the refinement names I chose with the exception 
of /full.  I kinda like that name as it gives me a better perspetive 
of what it is doing.

how can I make object words local to the context of object? I mean

obj: context [a: 1 pri: does [print a]]


I would like to be able to use 'a in the closed context, but I don't 
want it to be available via obj/a ..... I tried to enclose it to 
'use, but then it is not available to 'pri function :-)

See these ML threads on REBOL.org.


http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-thread.r?m=rmlRJCC

http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-thread.r?m=rmlTLVQ

thanks ...

Wrap the USE around the CONTEXT, rather than the other way around.

This topic comes at a good time for me as I have a complex issue 
that I need to address which is similiar to what Pekr's sounds like 
except that I'm binding object/words to object/some-func.  I'm going 
to have the need to not allow someone to access object/words by probing 
object/words.  Object words is to large to have all of it inside 
of object/some-func which is why it is external to that function 
and only parts of it get bound to that some-func.

I just remembered the 'self trick, don't know whether it's officially 
supported, but it works ...

given: ....

o: make object! [ 
	self: make object! [
		p: does [print [a b c d]]
		ca: func [x][a: x]
		d: 4		
	 ]
	a: 1 b: 2 c: 3
]

you have ...

>> o/p
1 2 3 4
>> o/ca 7
== 7
>> o/p
7 2 3 4
>> probe o
make object! [
    p: func [][print [a b c d]]
    ca: func [x][a: x]
    d: 4
]
>> o/a
** Script Error: Invalid path value: a
** Near: o/a
>> o/self/a
** Script Error: Invalid path value: a
** Near: o/self/a

nice that is what I'm looking for.

o/p is directly known? I did not know 'self allows such functionality 
:-)

It's sweet for sure.  Another one of those hidden REBOL perks.

i don't think this is intentional, but it's something i've used quite 
a few times. basically make is returning self, whatever you make 
that be :)

>> make object! [self: "blabla"]
== "blabla"