World: r3wp

If the existing Rebol community thought it was useful to create a 
localized version of Rebol, you probably would have done it by now. 
 Because it wouldn't be hard.

My point is, it wouldn't hurt anything in the existing ecosystem 
and who knows, maybe it would take off in China or wherever and create 
a new market.

Like I say about web pages which have chinese characters in them... 
Google doesn't prohibit them or not index them.  It knows not to 
show them to you unless you ask, if you don't speak Chinese.  Or 
they translate it.  With the kind of thinking you're promoting, you'd 
just say "they should write in English, that makes the world more 
compatible."

Is it worse to have a Chinese programming ecosystem out there which 
you don't draw code from, or to have them all writing in Perl and 
Ruby and Python?

hmm, AFAIK, the reason Carl wanted to remove ALIAS is that in 10 
years of R2 nobody ever really used it except to show what it can 
do.

so I don't think anyone is "against" a localized rebol, it's just 
that noone is really interested in that. what happens is you start 
playing with it and think it's cool but you never actually use it 
(i did play with an italian version of REBOL in 1999 or something 
like that).

ie. ALIAS is solving a problem that nobody has.

I think there's a big gap between the usefulness of a spanish or 
Italian localization and a chinese localization.

If Alias permits one to set up word equivalencies, then it's solving 
a problem I have with Rebmu.

(Which I will again say is not some kind of joke.  It is trying to 
position Rebol as the leader in Code Golf, and I'm tuning it so that 
knowledge transfer with Rebol is as good as it can get.  Random example: 
I did some tweaking so that now first+ isn't FP anymore, it's F+ 
and all the functions which end in "+" are understood as being in 
the family of those which modify their arguments.  A+ FOO BAR is 
understood to add foo to bar and store the result in foo, for example.)

You will reinvent FORTH if you continue :)

Also I changed AN for AND~ and OO for OR~ into "a~" and "o~", thus 
keeping consistency with the Rebol notation for prefix operations, 
because the prefix ones are the ones that make sense in character 
count minimization.  I'm bending and thinking of what makes those 
look common and came up with "n~" for NOT, even though Rebol doesn't 
have a tilde after prefix NOT (since there's no infix not).  So it's 
a balance of consistency.

@Steeve ... but look at the "Doomsday Clock" modification to my hourglass 
solution

http://stackoverflow.com/questions/1683857/code-golf-hourglass/3110684#3110684

The "oh, and another thing..." part of supersetting the Rebol by 
staying pure to the dialect rules is the baby in all this bathwater. 
 That's what will blow people's minds.  I'm only scratching the surface 
there because I'm still working out the kinks.

But by comparison, look at the ridiculous "Golfscript" solution which 
has to resort to shell scripting to loop the "stdin": http://stackoverflow.com/questions/1683857/code-golf-hourglass/1687686#1687686

can't you use one char length for those ? 
OR AND NOT = | & !

Empirically those are not good candidates for one character optimization.

i (if-true-mu) and e (either-true-mu), which can be remapped but 
are by default mapped to their equivalents "IT" and "ET" (there's 
also WT for while-true) are pretty good one-character ones, but even 
those can be questionable.  But they are reasonable defaults.  The 
point of one-character-choices in Rebmu is to anticipate the need 
for flexibility for redefining them, to use as variables or whatever.

Originally I had "r" and "w" for "readin-mu" and "writeout-mu" but 
found that w for while was more frequent than the number of writes, 
and in fact I also found that my writeout was not as useful as print's 
default behavior, so I remapped w.  These one-character decisions 
are in flux as I look at how some of my ideas are panning out in 
real solutions.

This "mushing" I've come up with is delicate, because of course I 
can't break Rebol's parser... so I have to work within it, and the 
language is beholden to what forms can be naturally combined without 
spaces vs. those that require them.

Anyway, the various crack-smoking mods I'm doing (such as if-true-mu 
being able to take constants in the code block and evaluate to those 
constants without the brackets) are intended to be minor things... 
something one could quickly unlearn in Rebol programming and say 
"Oh, right, you need a block around that."  Increasingly I'm backing 
off anything which is overly focused on character optimization at 
the price of creating a pattern that is too far off from a reasonable 
Rebol programming practice.

It applies to for instance not Huffman encoding the names for the 
sheer sake of saving characters.  The abbreviation has to line up 
with the Rebol word in some vaguely reasonable way.

Another issue of using single character symbolic things for operators 
is that because they lack a "case", they don't play well with mushing. 
 [A&b] unmushes to [a: & b]...  [a&b] unmushes to [a&b]... [a&B] 
unmushes to [a& b] .... and [A&B] unmushes to [a&b:]

Consequently, you're better off with a two character A~ for AND~, 
because you'd end up having to throw in spaces on the left and right 
of the & all the time otherwise, which gets you three characters, 
and you'd probably have to throw one on the left half the rest of 
the time.

Is there a "weirdest dialect" award I'm going to win with this?  
:)

Well, you could prevent not alphabetic chars from being part of any 
word. It would make sense.|

It doesn't make sense if trying to retain compatibility with lowercase 
Rebol code.  I want to be able to paste "to-string" in the middle 
of a Rebmu program and have it "just work"

hum ok

Again, that is the baby in this bathwater.

To superset Rebol when coded natively, in lowercase.

I'm glad you tackled the connecting dots problem, though I don't 
think your solution worked... but it was in the spirit of my desire 
to see Rebol step up to these challenges and prove itself.  Because 
if it can win at anything, it can win at this.

And like I say about my Hourglass solution vs. the "winning" golfscript 
solution... it broke the rules, it has no reusable parts, it exploits 
symmetries and gimmicks in the problem such that if the problem specification 
changed only slightly you'd have to rewrite the whole thing.

Well, i saw the remaining problems in my code, correcting them would 
not enlarge so much the length of the code

In solving it I found that like with many code golf problems there 
are some little "nuances" which emerge as you look at it...

Bit I don't think we can beat the shortest solution

*But

Specifically, there are cases when lower numbered dots can connect 
and cross over the second digit of a larger numbered dot

That forces you to basically build a map of the numbers before you 
start drawing the lines :(

Yes I finally understood that point

A lot of these problems have gotchas like that where you think "oh, 
easy I'll just do it like this..."

Then you get there and realize "oh crap" and suddenly you've added 
like 50 characters

:-)

Did you go through my solution at all?

Sorry not at all, If you could decipher your code for me...

It's simple at heart.

Well, if what BrianH is true I may need to write "unrebmu" sooner 
rather than later

So this line here: "w [j: d ++ n] [ro g [x j y j]]" is that building 
of the initial coordinate map.  It keeps incrementing n, and passing 
it to the "d" function which returns either the coordinate pair where 
that digit resides (or none if the digit could not be found).

while [j: d (++ n)] [repend/only g [x (j) y (j)]]

Er, no the d function returns the series position