World: r3wp

so just for a lookup?

Pekr, where you see chaos I see the design process. R3 is being designed 
as we go. It's a work of art - I mean that in a literal sense, not 
as a compliment. Open projects usually grow, or fail. The preplanned 
ones usually fail.

Interesting...


I'm using blocks to manage a lot of name/value pairings which I will 
sort and copy/part the top x items.  I was hoping to be able to utilize 
the speed of map! for doing this.  Maybe I should use map! while 
creating/modifying and then when it comes time to pull top x items 
I could convert it to a block...

map! is for lookup and deduplication, yes.

Ammon, converting map! to block! is the usual method of doing that, 
yes.

Ok, good enough.  I think that will work.  I'll modify some of my 
scripts to use that method and then do some benchmarks...

BrianH: don't you mind that we have 'map function, which is complatly 
unrelated to map! datatype? I mean - sometimes we use shortcuts - 
e.g. 'context for make object! ... so I thought it might confuse 
a bit to have map func, which does something unrelated?

While I have your attention and I'm thinking about sorting I just 
thought I'd mention that I'm using the following work-around for 
the lack of /compare in sort:

; R3 /compare bug work around
sort-compare: func [
	blk
][
	; disorder the rows
	forskip blk 2 [change/part blk reduce [blk/2 blk/1] 2]
	; sort em
	sort/skip/reverse blk 2
	; reorder the rows
	forskip blk 2 [change/part blk reduce [blk/2 blk/1] 2]
	blk
]

The map! type is used extensively in the GUI, and some mezzanines. 
The MAP function's name wasn't my idea - some Haskell fan thought 
we needed a map function (true) and that it should be called the 
same thing (not REBOL-like). This came before the name of the map! 
type was chosen, and prevents us from making a proper functional 
map function of that name. At least we already had a fold-like function 
with a REBOL name: REMOVE-EACH.

I really wanted the map punction, but I don't mind it being called 
anything else, I agree with pekr's reasons

map function is similar to apply, no?

Ammon, that is a known (already submitted) bug, and not the only 
SORT bug. Work in progress :)

It is even similar to new  'resolve func in the same regard as to 
'apply func. It just maps something to something else

I love the MAP function, but it could really use a *-EACH name since 
it is in that family. We're probably stuck with the name :(

Oh, I *really* love RESOLVE - already backported it to R2 :)

hmm, then you could say the same for apply too, and probably foreach 
should be renamed to for-each, etc :-)

I know it's reported and in CureCode.  I'm just saying that I'm working 
around it now in the hopes that the priority might be bumped up a 
bit. =D

wow, great release.. ithings are moving

APPLY doesn't act like a *-EACH. Backported that too :)

Ammon, right now we're working at a lower level. It's high priority 
:)

BrianH: what is 'resolve good for? Couldn't it be achieved with some 
mixture of difference, intersect, and such? :-)

Hmm, R3 is whole new REBOL. So far I am using at R2 level. I have 
my own old map func, which maps some object fields from other object. 
Now I need to learn how 'resolve could be usefull.

Not as quickly, and those work on blocks, not objects.

then object should be a series :-)

Resolve is good for assignment of values in objects to other objects 
without them having to be in the same order or even have all the 
same fields. If anything, it makes objects even *less* series-like 
than they were before :)

RESOLVE is *fast*, even in the R2 mezzanine version, much faster 
than the typical ugly loop it replaces.

Here's the R2 version of RESOLVE:

resolve: funco [
	"Set known values in target from those given by the source."
	target [object! port!]
	source [object! port!]
	/only from [block!] "Only set words listed here (exports)"
][

 set/any bind either only [bind/copy from] [words-of source] target 
 get/any source
	also target set [source target] none
]

I think. The /only changes are still being tested. Here's the pre-/only 
version:

resolve: funco [
	"Set known values in target from those given by the source."
	target [object! port!]
	source [object! port!]
][
	set/any bind words-of source target get/any source
	also target set [source target] none
]

It took a lot of thought to get that code so small :)

It takes a lot of thought in order to understand the code (for me) 
:-)

Darn, /only doesn't work there. I was trying to come up with it on 
the fly and I failed, miserably :(

The version without /only works perfectly.

It works in R3 of course. I just haven't had the time to backport 
the changes in the last 9 alphas (in two weeks) to R2-Forward yet..

Sorry, 10 alphas in 2 weeks :)

Two alphas yesterday evening alone - that's my kind of release pace 
:)

What do you think of system object? It looks chaotic to me. It makes 
no sense for me to rename, or move stuff around.

Oh, I love it. The old system object was chaotic. This one will be 
organized. We need this for memory protection and multitasking.

R2 works now, but it has a lot of design flaws and bugs we are fixing. 
That's why R3 is different than R2.

I can understand. But I liked e.g. system/components, which listed 
internal modules. Now we have some stuff in codecs, some stuff in 
contexts, View is separate, etc.

Think of modules as the new components, except you can write them 
in REBOL too. They even use the same Needs header.

Codecs are like port schemes, but for encoding and decoding. Different 
thing.

So why is View separate, and not in Modules section?

... and  - what is Contexts?

btw - Codecs were moved away from Catalog, because Codecs will change. 
Where's the catalog/file-types placed now? (it will not be immutable 
too)

SYSTEM/view is View settings - we'll have View modules too, in with 
the rest of the modules. We just haven't modularized the code yet 
- we needed to have modules first. The file-types setting is in system/options 
with the rest of the general system options.

As for system/contexts: Do you remember system/words ? We have more 
than one now. It's a module thing - separated contexts.

We need to have volatile settings separated from unchanging settings, 
becuase the unchanging stuff can be shared between tasks and the 
volatile stuff can't. And the hidden stuff can be tricky to access 
if you don't know what you're doing, so that is separate too. The 
new organization strategy makes sense. The only thing I miss is system/user/home, 
so we'll need a new place for that too - maybe system/options/user-home.

I am thinking of a preferences system too. But that is not really 
a problem - user.r can be good place to place various settings. What 
we haven't solved or even thought about is - localisation. Messages 
and other stuff are hardwired into the system. I don't want to translate 
REBOL itself, but e.g. R2 does not allow easily callendar data being 
translated. Other thing is currency, flating number separator (for 
display purposes, etc.)

The main thing you need system/user/home *for* is to know where to 
look for %user.r - it is not safe to look for it in the current directory, 
and not multi-user-friendly to load it from the same directory as 
%rebol.r. R2 is horribly broken in that.

having user.r in current directory is really simplistic though ...