World: r3wp

(Being forced to fire up a VM that is willing to run AltME, having 
it mangle my links, and be unable to do "shift up" and have my entire 
line selected or get a right click menu is... well, I'm a sympathetic 
audience, but there's just no comparison to how slick StackOverflow 
is.)

Fork, those code golf challenges are interesting, and I'm glad you're 
working on it.

I came up with a method for rendering links perfectly in an AltME-style 
display.

http://anton.wildit.net.au/rebol/doc/overlaid-hyperlink-text-face.r


It's a pity that AltME hasn't been improved with this method. If 
I had access to AltME message display code I could work it in.

Interesting challenge, I will live the evening trying to find something...

Fun stuff Brian.

Fork, you should make a sort of white paper on the power of Dialecting 
in REBOL using Rebmu as a reference.  Your language shows just how 
powerfull REBOL's Domain Specific Language capabilities are. Its 
a result of applying dialecting to a very specific Domain, but its 
still pretty much General Purpose .


I think that If its well written, without bias and personal opinion 
on REBOL itself,  it would make the cut for a nice article on REBOL.com's 
web site as an article on the subject.


its just my POV, but marketing information on this, with factual, 
non-trivial, examples is very scarce on the REBOL web site.  I think 
Carl would welcome such a complete example.  you've litterally transformed 
the semantics of the language, yet can still interpret it within 
REBOL.

maybe not the semantics as much as the syntax, but its such a different 
approach that its sort of a blur between both IMHO.

@Maxim: I've tinkered a little with the semantics, but tried to make 
it so that the abbreviated Rebmu primitives only extend the reactions 
to datatypes which Rebol currently throws errors on.  For instance, 
the letter "e" is mapped to "either-mu", which can handle things 
like constants or functions in the clause block.

Hence you can do things like pEf{Hello}{Goodbye} and get the effect 
of PRINT EITHER F [{Hello}] [{Goodbye}]

Such a feature would be too error-prone in an ordinary Rebol program 
to be worth the savings, but it is essential in shaving off characters

EITHER-MU and its bretheren are factored into what is called the 
"mulibrary.r", which can be used independently of Rebmu.  Though 
you never would.  :)

In my opinion, standardizing Rebmu would be far wiser than decisions 
in Rebol/Core like defining Q to be QUIT (I've pointed out how accidents 
involving this make Rebol seem like it crashes, like when you do 
APPEND [N O P] Q and forget the quote mark on Q).

I have been writing Rebmu programs in actual Rebmu, as opposed to 
writing them in Rebol and then translating, as a test of how "bad" 
it is: http://github.com/hostilefork/rebmu/tree/master/examples/

As I predicted, it's actually not so bad.  Especially when you can 
break into native Rebol at any point if you want to debug (so long 
as you use lowercase!)

Originally I had it breaking out symbols like - and + in such a way 
that they would cause token breaks, like [a-b] would go to [a - b]. 
 But not only did that cause issues with common naming conventions 
(to-block, etc) it also wastes a lot of two-character tokenspace. 
 So now [a-B] and [A-b] become [a- b], [A-B] becomes [a-b:], [a-b] 
stays [a-b].

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.