World: r3wp
[Dialects] Questions about how to create dialects
older newer | first last |
Fork 27-Jun-2010 [597] | That forces you to basically build a map of the numbers before you start drawing the lines :( |
Steeve 27-Jun-2010 [598] | Yes I finally understood that point |
Fork 27-Jun-2010 [599x2] | 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 | |
Steeve 27-Jun-2010 [601] | :-) |
Fork 27-Jun-2010 [602] | Did you go through my solution at all? |
Steeve 27-Jun-2010 [603] | Sorry not at all, If you could decipher your code for me... |
Fork 27-Jun-2010 [604x16] | 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 | |
And it is the x and y functions which translate those into coordinates. | |
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. | |
BrianH 27-Jun-2010 [620x2] | 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. | |
Fork 27-Jun-2010 [622] | It's a good question, and regarding that, I noted that many of the solutions to Code Golf problems utilize base-64. |
Rebolek 27-Jun-2010 [623] | Janko wanted some script obfuscator and as I see, Rebmu is already less readable than Brainfuck, so I think it's a good candidate. |
Fork 27-Jun-2010 [624x3] | @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. | |
BrianH 27-Jun-2010 [627] | Spite for Perl is a noble motivation :) |
Fork 27-Jun-2010 [628] | But also a desire to get "fringe"/"creative" people to become aware of Rebol. |
BrianH 27-Jun-2010 [629] | That's why making an ultra-cool demo is a priority :) |
Fork 27-Jun-2010 [630x5] | @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--" | |
BrianH 27-Jun-2010 [635] | 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, ...). |
Ladislav 27-Jun-2010 [636] | 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 |
Fork 27-Jun-2010 [637] | @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..." |
BrianH 27-Jun-2010 [638] | 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. |
Fork 27-Jun-2010 [639x3] | 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. | |
BrianH 27-Jun-2010 [642] | Actually, they called it Firebird, and we saw what happened: They had to change the name again to Firefox :) |
Fork 27-Jun-2010 [643] | :) I skipped a step. |
BrianH 27-Jun-2010 [644] | 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 :) |
Fork 27-Jun-2010 [645] | 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. |
Rebolek 27-Jun-2010 [646] | Wasn't the first name Phoenix? |
older newer | first last |