World: r3wp

There's an exception for runs with multiple characters in this class 
to make programming with ++, --, etc easier.  If multiple characters 
in this class appear in a row then they split the token.  [a++B] 
=> [a ++ b]     [A++b] => [a: ++ b]    ...but...   [A++B] => [a++b:] 
  [a++b] => [a++b]

I also backed of on overwriting the definition of "IF".  The letter 
"i" now starts off mapped to "II" (which stands for "iiiiiiif...."). 
 Similar rationale for "oo" as "ooooor..." which is the non-infix 
version, since infix is useless for code golf

Just checked in Rebol 2 compatibility for Rebmu: http://github.com/hostilefork/rebmu/commit/eed98b9570ce957ca248dfd6c67b976ec651beb4

I didn't know Rebol 2 didn't have a "continue".

Yeah, and it can't be backported as mezzanine either (tried already). 
I'll request a native.

I should start a Rebmu quotes page for what people say when I send 
it to them.  "Reading the hourglass solution at first threatened 
to give me a brain aneurysm, but actually after reading this I now 
see you were up to with 'mushing'.  Clever!"

I thought of writing a "derebmu" which converts things like "is" 
into "insert" just as a teaching tool.  I now realize that it's essential 
to have this functionality for things like parse, which are dialects 
in their own right and look at the literal words.  Hence Rebmu's 
PA for parse will have to take its rules argument and derebmu the 
block before execution.

Which leads to the question of why map the words in the do dialect 
at all, and not just derebmu the whole thing before execution.  (I 
think it's just a different way of thinking about what to do with 
the word map, not a tremendously big deal.)

you can use ALIAS to "change" the words used by PARSE or any other 
dialect.

@Gabriele: BrianH says alias is dooooomed.  But he seems to have 
alternatives in mind.  Hopefully something will exist allowing one 
to give names words in such a way that they pass equality tests despite 
different spellings... that would be a huge enabler for international 
markets, as I know of no text-based interpreted language able to 
cater to people in their own tongue the way Rebol can.

Fork, you are right, that REBOL allows internationalization. Problem 
is, that there actually is no demand for internationalization of 
the Do dialect, so it would make sense mainly in other dialects.

Since English is not my native language, I have experiences with 
internationalization myself dating back to 1978, but the main result 
is, that such languages as the Do dialect e.g. are better when not 
internationalized.

I agree with Brian and Ladislav that "internationalization" of a 
programming language makes no sense at all. Not sure why only some 
americans think it does. :-) ALIAS may not be there in R3 but I'm 
not sure why you should be worried about R3 at this point; but in 
that case you can do the compilation on R3 and use ALIAS in R2, so 
I don't see it as a big issue even if you want to worry about R3. 
:)

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