World: r3wp

also If it has several heaps, or tricks like generations, or whatever 
, we can optimise the code so that we make it work in the "best case" 
of the GC instead of the worst case.


right now all I know is that the GC is very disruptive in very large 
apps (in R2) because you can actually see the application jam for 
a noticeable amount of time when there is animation or interactive 
things being done.

Alas, that kind of problem is exactly why you don't want to rely 
on the implementation model of the GC. One thing we know about the 
GC is that it is the stop the world type. If we need to solve the 
problem you mention, we would have to completely replace the internal 
memory model with a different one and use a GC with a completely 
different algorithm (generational, incremental, parallel, whatever). 
That means that all of your code optimizations would no longer work. 
If you don't try to optimize your code to the GC, it makes it possible 
to optimize the GC itself.

BrianH, if I deliver an application to a client and he says to my 
face... why does it jerk every 2 seconds?


I really don't care about if the GC might change.  right now I can't 
do anything to help it.


if it changes, I will adapt my code to it again.   This is platform 
tuning and it is inherently "close to the metal", but in the real 
life, such things are usefull to do... 

just look at the 1 second boot linux machine in that other group.

something like this document (which has a Best Practices at the end) 
would be really nice.


http://vineetgupta.spaces.live.com/blog/cns!8DE4BDC896BEE1AD!1104.entry

obviously, since the GC is a "stop the world" system, I can't fix 
everything, but I might be able to help it along a little bit.

You can time when you call it...

I'm hoping that we might get a better collector when we work R3 over 
for concurrency.

yes, with proficient concurrency, its much easier to make non-blocking 
GC.

easier being a relative term  ;-)

It might be the other way around. It's harder to stop a multitasking 
world than it is to stop a single-tasking one...

recycle/ballast avoid the "stop the world" issue if well balaned

*balanced

How about a minor addition to/restructuring of the comparison functions:
- equal?
- equiv?: equal + binding

- strict-equal?: equal + type + case + alias + decimal  (but _no_ 
binding)
- srict-equiv?: strict-equal + binding
- same?: as currently


(See http://www.rebol.net/wiki/Comparisons#EQUAL.3Ffor the status 
quo.)

Alias?

See the referenced document.

strict-* makes alias distinctions.

Oh, right. All words are aliased. That's how case insensitivity is 
implemented in R3. So case = alias for words.

maybe alias implies case, but case does not imply alias.

What we seem to be missing at the moment is a comparison function 
with ignores binding but is otherwise "strict" in the sense of type/case/alias/decimal 
precision.

If we had such a function, the discussion around #1830 and related 
issues (such as a more useful map! type) would be much easier.

The proposal above now is to have equal/strict-equal not respect 
binding, and have equiv/strict-equiv be their binding-respecting 
counterparts.

The original purpose of EQUIV? was the decimal thing, so you might 
want to move it there.

#1830 doesn't actually use STRICT-EQUAL?, so reordering the hierarchy 
won't help. You need to see the new 1830.

That's the whole point of this proposal.

With the above strict-equal, it could safely use it.

Either in the default case, or with a /case, /strict or /whatever 
refinement.

Framed this way, this discussion would be a lot easier, imo; and 
probably more fruitful.

That is a seperate issue that needs its own ticket. FIND and SELECT 
use their own code, so they can only follow the same rules, not use 
the same code.

That is an implementation problem, not a design issue

I am OK with a DAG for the equivalences, but would prefer the exact 
decimal comparison to go in the EQUIV?, STRICT-EQUIV? branch.

Fine with me, but most likely only a minor issue.

For reference, also be aware that we have operator shortcuts for 
the comparison functions. At the moment:
=: equal? (and !=
==: strict-equal? (and !==)
=?: same?


The == operators should then probably become shortcuts for strict-equiv.

That's a bigger problem than binding, believe me. Exact decimal comparison 
makes floating point code nearly unusable by normal programmers.

As mentioned above, that's perfectly fine with me.

It's not decimal precision which makes the FIND (and STRICT-MAP!) 
discussion so cumbersome.

We don't need operators for the equiv branch. STRICT-EQUIV? and SAME? 
are the same thing for words and decimals.

If you want I can write up your reshuffled hierarchy as a CC ticket. 
I think Carl would like it, ans the binding issue has bit him in 
the past.

ans -> as

Thanks for your input. I'll also wait for Ladislav's input at least, 
as the "Comparisons" doc was authored by him.

So let's update this with the decimal precision moved:

- equal?
- strict-equal?: equal + type + case + alias

- equiv?: equal + binding + decimal 
- strict-equiv?: equiv + type + case + alias

- same?: as currently

Strangely enough, it's not binding or exact decimal comparison that 
are at issue with FIND or strict-map! either, it's case and type. 
Nonetheless, this would make it easier to point to the distinction 
between STRICT-EQUAL? and STRICT-EQUIV? when talking about those, 
precisely because those aren't at issue.

Sounds good to me.

As you see, case and type are the major distinction between equal 
and strict-equal.

Yup. That makes sense.

So that would make it easy to define FIND as using EQUAL? per default, 
and STRICT-EQUAL? with /case.

(Or a renamed /case option. A bit hypothetical due to backwards compatibility, 
but mentioning it for the sake of completeness.)

We can't rename the /case option - legacy naming rules. And if the 
equivalences are reshuffled this way, we won't have to.

Andreas, the proposal has been added here: http://issue.cc/r3/1834
- if you have any suggestions or tweaks, mention them here or there 
and I'll update it.

Yes, I have a suggestion: my explicit wish was to wait with this 
for Ladislav's feedback.

Please respect that in the future.