World: r3wp

Maybe we'll get #1315 (or an alternative) before too much harm is 
inflicted.

I consider not having a key/value datatype which can store external 
(non-REBOL) data using a sensible internal (REBOL) type a major annoyance.

Agreed

REBOL is case-insensitive by default, everywhere any-string or any-word 
types are used. Maps are no exception.

Case-insensitive key-value stores are not uncommon. And we do have 
a workaround.

#1494 fits in better with the rest of R3 than #1315.

It's not that big a deal to use binary keys for map! because most 
data is binary when it comes into R3, so it's just a matter of *not* 
converting it *from* binary.

Btw, in a comment to #1494 Andreas brings up the possiblilty of another 
map type with a different, case-sensitive hash function. That would 
be a possibility, whereas #1315 would not, not would #1437 where 
it was suggested that case-sensitivity be an option.

not would -> nor would

+1 for possible case-sensitive hashes.. I need it quite often

+1 here too

As Brian says, case sensitive map is easy to do with binary keys.

Here's my implementation of such, for anyone who needs it today). 
Improvement suggestions are welcome!
   http://www.rebol.org/view-script.r?script=r3-rehash.r

The problem is, that using something like this will slow down the 
evaluation.. the reason why we were using hash! in R2 was the speed.

Case sensitivnes is very common outside our REBOL world.

I've tried some timing tests..... 


r3-rehash seems around 10% faster than native R2 hashes on my test 
data.


That does not remove the speed increase that an R3 native hash may 
have.

But it does suggest that migrating from R2 hash to R3 rehash will 
not cost performance.

That's probably because R2 hashes all values but R3 just the keys. 
But good result anyway.

That sounds a likely explanation, thanks.

My timing tests were flawed.....R3-rehash is __significantly__ faster 
than R2 native hash.


That is still true even if we remove the set-up time and just look 
at random retrieval.

{Of course that is based on my random dataset....your's may vary]

Thanks for testing. I'd been wondering about that for some time

NIST has decreed that federal agencies must move from SHA1 to SHA2 
after 2010.  I found this JS implementation ..  anyone able to convert 
JS to R3 code?

http://sourceforge.net/projects/jssha/files/jsSHA/1.3/jsSHA-1.3.zip/download

There's also this SHA2 library written in Haskell http://davidmercer.nfshost.com/projects/shaskell/shaskell.html

From a quick look, it doesn't seem that it should be too hard to 
convert the JS to R3 on Big Endian systems.

which sha-2 do you need?

It doesn't matter .. sha-256 is good

Ideally we should have an encryption port so we can also compute 
SHA2 on large files as we can with R2

Whole functionality of encryption ports should be imo added into 
R3, if not already there ...

Are there are practical differences between these two R3 ways of 
extending an object?
    obj: make object! []
    extend obj 'a 1
    bind/new 'b obj obj/b: 2
    probe  obj
     == make object! [
              a: 1
              b: 2
        ]

Extend is a mezz, so that much be slower.

And I always try to avoid GC overheads due to excessive  usage of 
'reduce


Thats why I think bind/new is more capable especially, this form:
>set bin/new 'b obj 2
instead of:
>>bind/new 'b obj obj/b: 2

Besides the readability/performance trade-off, things also start 
to differ when non-true? values are involved:
    obj: make object! []
    extend obj 'a none
    extend obj 'b false
    set bind/new 'c obj none
    set bind/new 'd obj false
    print mold obj
==>
    make object! [
        c: none
        d: false
    ]

(Which probably is a bug in EXTEND.)

Nice catch

Hum...
Seems not a bug, but deliberate.

EXTEND is a wrapper for APPEND....So are there any practical advantages 
in using BIND/NEW rather than APPEND ?
    append obj [c: 3]
    == make object! [
        a: 1
        b: 2
        c: 3
    ]


I know right  now there are some differences when messing with PROTECT/HIDE, 
but there are many  CureCodes to go before we'll know if those differences 
are for real.

I like the SET BIND/new trick. There has already been code in the 
mezzanines where such a trick would come in handy, but it had never 
occurred to me. Thanks Steeve!

The practical advantages of the SET BIND/new trick as opposed to 
APPEND is that you don't have to REDUCE a block to be appended. The 
point to the IF :val guard in EXTEND was to screen out false and 
none in GUI code, but that is likely no longer necessary. There was 
a blog where it was suggested that EXTEND be rewritten to work differently, 
but I think that various natives were enhanced instead. EXTEND is 
now a little anachronistic.

I think that the code where we wanted to screen out none in the GUI 
code is now using the map! type instead, which does this itself.

Btw Steeve, mezzanines aren't necessarily slower than natives, particularly 
in R3. It all depends on how much work is being done by the function. 
Interpreter overhead is really low in R3. Mezzanines can use more 
memory though, but we are enhancing the natives here and there to 
make it possible to lower the memory use of mezzanines - enhancements 
like the /into option.

Based on some simple experiments I did some time ago, mezzanines 
are roughly 2.5 times slower than the aequivalent command (i.e. extension 
function).

That was for functions with minimal arithmetic, so that should basically 
be mostly the additional function call overhead.

Real
 natives should be a bit faster still.

Should probably dig out those experiments again to see exactly what 
I was measuring (or redo them), but that's the number that stuck 
with me :)

That would indeed be very low overhead

And even less for regular mezzanines, which generally contain calls 
to more advanced native functions rather than just minimal arithmetic.

Thanks for the EXTEND vs APPEND vs BIND discussion, guys. It can 
be useful to have different mechanisms that have their own default 
behaviours.


One use of BIND/NEW is that it allows words to be unset when an object 
is created:


    obj: context [bind/new 'word self]   ;; this works, and WORD is UNSET!

    obj: context [word: #[unset!]]       ;; this does not work
    * Script error: word: needs a value
    * Where: make context
    * Near: make object! blk

APPEND object! word! does the same thing.

Well, I don't think REBOL suddenly has the speed of C

Certainly not for C-like code, agreed. But if you are writing REBOL-like 
code then you are mostly calling fairly complex functions that are 
written in very good C, functions like PARSE and APPEND. Most of 
the code you run in REBOL is actually implemented in C, including 
the interptreter itself. So in that case REBOL has the speed of the 
C that it is written in.

I just feel you're overdoing it a bit. If you were to follow that 
reasoning through, the conclusion would have to be that REBOL has 
negligable overhead over C. Indeed, that's what some people claim 
on the web because they heard it somewhere in the community, and 
that's how REBOL people become known to the outside world as lying 
or delusional

Among dynamic languages, REBOL is slow. Not the slowest, but slow. 
Not that this matters in practice, but that's a whole other set of 
myths