World: r3wp

It's for R2 only.

It's a Core-only script, so the changes to create a version that 
runs under R3 (or even runs under R2 and R3) may be fairly simple.

Ladislav and I have both documented our early efforts to convert 
scripts. If someone does convert JSON.r, that may uncover other useful 
conversion guidelines.
   http://www.rebol.org/art-display-index.r?a=R3

Hmm, I think I have a json.r adapted for R3 somewhere.

Let me check.

Nope, I was mistaken. Sorry.

In theory, JSON-to-REBOL should be better in R3. The JSON and Javascript 
object type more closely corresponds to the map! type in R3 than 
it does to anything in R2.

map! with string keys, mind you. But map! won't show values assigned 
to none, so if you use map! you might want to use a 'null keyword 
instead of none for the null value. You could use object! instead, 
but then you would have problems with some keys not getting through 
TO-WORD's character restrictions.

I would guess that for most JSON data the string-to-word conversion 
would work, so you might get away with using object! in R3.

One thing will definitely be easier though: JSON and Javascript define 
that they have Unicode source, but don't have a way to specify the 
encoding (they are text standards, not binary). They can be handled 
easily in R3 once the source is converted to a string though, since 
that conversion will handle the encoding issues. In R2 you'd have 
to either stick to ASCII data or use Gabriele's text codecs and then 
parse the UTF-8.

And of course you'll have to work around map! being case-insensitive.

Hm, does that differ from hash!? I can do a find/case on a hash!

Yes and no. It depends on whether the source of the dataset is also 
case-insensitive. The JSON standard doesn't specify one way or the 
other.

Kaj, map! is object-like, hash is series-like.

That's a problem

I'm using hashes to cache directory contents. They need to be case 
sensitive to support Unix file systems. Now I have a problem with 
porting to R3

Binary is treated case-sensitively. Convert the file names to binary.

Cool, thanks

The map! type is not a direct replacement for hash!, it is a different 
type that serves the standard purposes that hash! usually served 
in R2, where it was mostly used in the way that map! can be used 
now. As a related benefit, object! can also be used in ways that 
hash! used to be used: SELECT and APPEND work with object! and map!.

Yeah, that's good. I never understood why R2 objects can't be expanded

R3 objects can't have fields *removed* because that breaks binding, 
but maps can *because* you can't bind to them. Most of the differences 
between maps and objects are because of that difference.

All R3 objects are now like R2's system/words.

That makes them way more useful

Having to convert all non-binary map keys over to binary is still 
rather stupid, but well.

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 ...