World: r3wp

So the issue we discussed about needing to build the map ahead of 
time is taken care of right there.  After this step, G is an ordered 
series of two-element blocks... each with two integers, the coordinate 
pair of where that dot is.

Then clearly we loop through G.  On each loop iteration, B is the 
coordinates of the start of our pen and F is the location of the 
finish of our pen.

We keep bumping B until we reach F.  How much do we bump the X coordinate 
of B and how much do we bump the Y coordinate of B on each iterator 
step?  That is stored in H and V which are in the set (-1, 0, 1).

; string containing the (l)etters used for walls
l: {-|\/}

Which letter we use to draw the wall depends on h and v, right?  
If our vertical bump is zero, we know we want the first element. 
 If our horizontal bump is zero we know we want the second.  If the 
bump is [1 1] or [-1 -1] we know we want the "/" (third element), 
otherwise the fourth ("\").  This line is really rather boring:

ch c b pc l ez v 1 [ez h 2 [ee h v 3 4]]

change c b pick L either-zero v 1 [either-zero h 2 [either-equal 
h v 3 4]]

Hopefully you get the idea.  It's really simple.  I'm not trying 
to beat the winners based on libraries or tricks, I'm not trying 
to write clever code, I'm writing REALLY boring straightforward code 
with function definitions and everything which can be adapted easily 
if the problem spec is adapted.  And still within a stone's throw 
of the winners, or even beating them.  In this case I got 218 characters 
compared to the winning "perl" at 222.

And that perl is garbage.  No functions, no reusability, no intelligence.

Meaningless letters, far from being able to handle N-digit numbers... 
y'know, the usual.  I'm standing on the shoulders of giants here, 
but that's why I can see farther.

Your unrebmu proposal would be a compiled dialect, with the target 
being DO dialect code. This is a good technique for many dialects, 
and can be very fast. That makes it a good idea for a demo.

I wonder how rebmu would compare to COMPRESS for space savings? Compressed 
scripts/modules are planned for R3 (actually, implemented but not 
included yet). This includes binary! syntax encoded compressed data.

It's a good question, and regarding that, I noted that many of the 
solutions to Code Golf problems utilize base-64.

Janko wanted some script obfuscator and as I see, Rebmu is already 
less readable than Brainfuck, so I think it's a good candidate.

@Rebolek: For the sake of the psychological testing, these Code Golf 
problems I'm solving... I'm actually solving *in Rebmu*, mushed form.

I break into Rebol of course for debugging, probing etc, but that's 
just inserted in the margins, then I delete them.

I am driven largely by spite for Perl, to be honest.

Spite for Perl is a noble motivation :)

But also a desire to get "fringe"/"creative" people to become aware 
of Rebol.

That's why making an ultra-cool demo is a priority :)

@BrianH, continuing: So I thought "well, Rebol can uncompress, why 
not make an operator that takes compressed data and uncompresses 
it".  I was surprised that compress was returning significantly larger 
data than the input for small inputs.  What's up with that?

I assume it's because of using a standard that expected the "do not 
compress" to be taken care of at a higher level.

In any case, the single-character operators in Rebmu are a tricky 
bunch for reasons I explained above, but one case that they do pop 
up in is assignments where the left hand is an all-caps target (set-word) 
and the right hand is a string or block or something.  That's when 
you can get them easily.

Although this bunch is in flux, I tried making [^ foo] map to [to-string 
debase foo].  This means S^"badfjakshdg--" (or whatever) will give 
you the un-base-64'd string.

s: ^ "badfjakshdg--"

COMPRESS uses the Deflate algorithm, plus an integer on the end for 
the length of the uncompressed data, for allocation purposes. It 
has the same limitations as any other Deflate compressor (zip, gzip, 
zlib, png, ...).

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

 - actually not, as Jerry mentioned some time ago, there are exactly 
 the same reasons why it is not useful

@Ladislav: Tonight I was discussing the Firefox/Mozilla thing with 
my roommate.  It was an issue where Mozilla was building a lot of 
functional stuff, but they didn't have quite the ability or agility 
to see and take advantage of opportunities.  Some weird dude came 
along and said "Hey, I'm gonna chop all this stuff off, and insert 
this stuff, and call it 'Firefox', and let's see what the heck happens..."

It would have enough overhead that it should not be there by default 
- LOAD does enough as it is. However, it might be an interesting 
tool for somebody, and a great demonstration. And it can be an add-on 
module, which makes it an even better demonstration.

The layman today does not know what Mozilla even is.

Despite it being the very foundation of something they all know -- 
Firefox.

In my opinion, Rebol is a more significant and interesting technical 
artifact than Mozilla.  Bear in mind I have a lot of context, so 
I'm not saying it's the greatest technology ever, I'm just going 
to say that on many axes it is essentially the best in its class 
that we know of.

Actually, they called it Firebird, and we saw what happened: They 
had to change the name again to Firefox :)

:)  I skipped a step.

One interesting related trick: The EXPORT keyword in R3 modules is 
done with a similar preprocessor in the MAKE-MODULE function. Just 
a few lines, and it works like magic :)

Bringing it back to dialects, I am serious with the Rebmu thing. 
 I'm fully aware it *looks* like a joke but it is not.

Wasn't the first name Phoenix?

I'm not compressing random digits here, I'm trying to make a domain 
demo of a domain that people are (for reasons better or worse) rather 
interested in.

And it pains me to read some of these code golf solutions, I know 
that as with the connect-the-dots I can beat perl and still write 
coherent code.

That's why I like the idea of unrebmu as an implementation strategy 
- it makes for a more impressive demo :)

You guys can do better, you know the language better.  I only just 
learned "Any" and "All".  I know the gist of Rebol but I've clocked 
not too many hours with it, this Rebmu thing is the most time I've 
ever spent with it to be honest.

I probably spent less than a week on that Rubol thing, which I think 
isn't a bad idea either: http://hostilefork.com/rubol/

I spent not only time, but money paying some guy to 3D render this 
darn logo: http://www.rebol.net/wiki/REBOL_logo

As well as experimenting with making the thing out of clay: http://hostilefork.com/shared/rebol/clayrebol_idea.jpg

As per Jerry Maguire... "Help me, help you!"  :)

Moving to chat.

You do need some award for the Clay one.  And the WHOLE photo is 
simply cool unto itself...

You do need some award for the Clay one.  And the WHOLE photo is 
simply cool unto itself...

I've a notion to build a business rules parser in Rebol. But as a 
self-taught hacker with no background in computer science, I'd welcome 
any advice on flattening the learning curve. The docs cover the low 
level parsing details well enough, but I'm looking for enlightenment 
on the higher level issues involved in designing a little domain 
level language. Given that Carl is pushing Dialects as the Big Idea 
in Rebol, it's surprisingly difficult to find much on the topic in 
the Rebol community. Or am I missing something? I'd welcome any Rebol 
specific or generic resources to help me get up to speed on the whole 
DSL thing...

I agree mostly. I would like to see some generic parse rules built 
into REBOL for general use.