AltME groups: search

Here's a 77 character Roman Numeral to integer converter:

If you start a mushing sequence with a capital letter that indicates 
the desire for a set-word

And I just pushed the source for a proof of concept to GitHub: http://github.com/hostilefork/Rebmu/blob/master/rebmu.r

But I bet that it could put Rebol on the map as a code golf language.

Wait, that's a 72 character translater.  The 77 one was different. 
 :)

but in fact it's a little bit cheating, the code cannot be execute 
as-is.

Is there a real difference with the following idiom used to shorten 
rebol sources
>> do load decompress #64{...........}

My goal was to create a language you can program in on paper

A little awkward, but, not so bad when compared to things that have 
disposed the entire program logic into constants like n=1;$.+=n/2-n%n=10**(494254%C/9)%4999while 
C=getc;p$.

Also it's not corrupting the language (much).  If you learn this 
"rebmu" dialect you'll be learning a useful language and your knowledge 
will transfer.  As opposed to GolfScript which is just garbage.

(But good for a CS class, or whatever.)

There is a burden.

When you add Something inside a sequence, you may have to swap all 
the followings caps/tiny letters :-)

True, but renaming variables is a burden as well.  As it happens, 
each numeric constant, symbol, or path operator breaks the chain 
so you get to start anew

aaBBccDDeeFFgg... if you really do have a long long uninterrupted 
chain of that nature then there's a problem.  But I bet usually a 
number or path or symbol would pop in there.

if each new word always begin with a capital letter, you don't have 
anymore the problem.
You just lost the compression of the ":" char. Not a so huge loss

Problem is that single character words play a huge part in this

ABC
 would mean [A B C] with this new system

and changing the case of text is something that can be relegated 
to a good editor :)

Well you're free to work out an example of a better dialect but you'll 
be parsing URLs or something... like where I can do Ab to get a: 
b how would you get it?

A:B

>> type? A:B
== url!

You're starting to tread on the question of taking away things and 
making a non-superset

And you added a character :)

Yes i added a character

but i don't have to take care of the correct alternation of uppercases

A character here, a character there... pretty soon you're talking 
about real whitespace!  :)

>> 'A:B
** Syntax error: invalid "word-lit" -- "A:B"
** Near: (line 1) 'A:B

>> unmush ['aB]
== ['a b:]

>> unmush ['aB]
== ['a b:]

That's the Rebol parser.  I'm not taking strings as input, I'm taking 
Rebol blocks.  It's a dialect.

I showed you my answer to get ['a b:] in a brief notation

>> unmush ['aB]
== ['a b:]

ok i understand, i just proposed to avthe burden caused by a safe 
alternance of letter's casing

Following some thoughts of Christoph Budzinski back in December, 
I wrote a short article on an approach to REBOL code golf last month......It 
takes quite a different approach to yours. But as it was never published, 
your approach must have priority :)

What I suggested in the article was:


  1. we create a private group here to thrash out the principles and 
  practicesl then launch a set of REBOL code golf challenges


  2. current code golf is seriously flawed as it counts characters 
  not lexical elements:
        variable1: variable1 + variable2
       is much better  code than:
         v1: v1 + v2
       and should have the same golf score

3. in REBOL, the First Rule of Code Golf is:
       Parse always wins

  (this has been empirically observed over many REBOL code challenges)

only to save ":" what a tremendeous gain !!! :-)

Saves 40%.  The colons and the spaces are intertwined issues, just 
due to the rules of Rebol.  And I feel that if the dialect wasn't 
parseable Rebol but a string it wouldn't rightfully be called a Rebol 
dialect.

Sunanda: I feel from my experience with parse that it's the sort 
of thing that can, if it fits your problem, help you a great deal... 
but it often seems to be just short of the needed functionality. 
 I feel if your task does not depend on knowing the true/false result 
of matching, then series operations are often better.  I've been 
thinking "if you don't use the boolean result of parse, you probably 
aren't working on a task that needs parse."

Generally Rebolers don"t make any difference with dialects parsing 
a string or a loaded block. It's called dialect as-well.

My other main article point was:

  4. Real golf has 18 holes per round. Most code golf plays just one 
  hole. To be more realistic, there should be at least three holes 
  -- ie after the first hole's scores are published, the challenge 
  setter makes a modification to the challenge. Scores for that hole 
  are (somehow) equated to the amount of original code the survives.

5. you do not bring your sony robot, night vision goggles, laser 
guidance systems, etc. onto the golf course.  You bring a bag of 
sticks and you use your own arm, eyes, and brain.

REBIRDY would be a better suitable name for your dialect ;-)

What Rebol can do is solve the problem and then do a coup-de-grace, 
like upload the results to a web server or something crazy like that.

at least, make a birdy

is the return carriage counted as a char or not ?

Not unless it's part of the program function (e.g. you use it in 
a multi-line character constant bounded by braces to get a carriage 
return in your target program)

Sunanda: The idea of a minor modification to the challenge and seeing 
what that does to the program is a good one; I would do that with 
interview candidates who knew the "right" solution to a problem (due 
to studying or seeing it before)... just introduce some whimsical 
constraint they hadn't memorized...

Could an offshoot of this be a method for thumb coding? I'd love 
an app for phones which allow you to write code solely with your 
thumb.

I'd put as a challenge to the Rebol community to refine Rebmu (or 
a similar syntax) to the point where they can submit an answer to 
code golf challenges that demonstrates some awesome feature of Rebol 
while still being in striking distance of the "winning" answer.  
I thought that perhaps showing Rebol 3.0 extending the roman numeral 
system to support higher order numerals than 1000 through unicode 
characters for M with a bar over it, etc. would be a good one.

Stevee: Hm?  I don't know what you are referring to.  I wrote the 
roman numeral function from scratch, in a fairly naive way.

I was contemplating the good and bad of a "mush" function, and I 
think I'm against it, because it undermines my point--namely that 
you should be able to write this code without assistance from a tool.

So there are some k's in the commented version that should be js. 
 So it is when you're trying to maintain a document in wordpress. 
 :(

Okay maybe just one k.  Reason is I reformed the spec so that n, 
j, k were default defined to 0 as integers and had a rewrite in the 
middle.

I also changed continue's shortcut from CO to CN because I wanted 
CO for compose.  Every time you change something it wrecks everything. 
 I know text files have their... um... way.  But I still want computers 
to step up to the plate and give every reference a UUID.  Someday...

Rebmu now has a fledgling homepage/logo/rationale: http://hostilefork.com/rebmu/

Well, Rebmu has a set of starting definitions for one letter things. 
 So s starts out as the empty string, i starts out as IF.  You can 
redefine these things.

I've had some internal debates on questions like whether LN should 
be LENGTH? or if I should make any Rebol identifier that ends in 
a ? also have a ? in it.  These are some tricky questions, but on 
that particular decision (for instance) I've decided that the ? in 
the name is something important to keep.

I'm also thinking that it's better to use three-letters for things 
rather than use letter combinations that don't make sense.  If you 
run out of things RE can be (RETURN, REJOIN, REPEND, etc.) then the 
answer is not to pick one and make it RZ for no reason... but to 
pick the least likely to use in code golf and go to three letters. 
 If this is a problem for any particular challenge they can just 
write (for instance) Rrej at the beginning of the code and then have 
a shorthand.

I recall a childrens book from England when I was a child where each 
of the cartoon children in the book spoke in mostly single letters, 
it was something like:

Boy - I C U 
Girl - I C U 2

Boy - R U  HP 
Girl - I M HP

Boy - U R A QT


It was a bit silly, but well made, and they had some MUCH BETTER 
tricks of this than I have given from memory.

Never knew it as a kid's game, but the Two Ronnies spun it into a 
TV sketch:
http://www2.prestel.co.uk/cello/swedish.htm

I'm rethinking the behaviour of my 'import dialect (library: http://bit.ly/rebimport
) when working with structured data. At it's simplest form, 'import 
filters a block of key-string pairs based on a supplied set of constraints: 
import [a "1"][a: integer! is more-than 0] == [a 1] ; or none if 
the constraints are not met


There are two nested forms I'd like to support: 1) a continuation 
of key-value blocks [a [b "1"]] and 2) a block of values [c ["b" 
"1" "foo"]]


The first could just be a recursive function or parse call. The second 
needs a little more thought - on the face of it, it could just verify 
the contents conform to a preset group: [ ["a" "b"] contains some 
of ["a" "b" "c"] ] (or any of), which'd be fine for validating web 
form input (eg. multi-select list), but would rule out, say, a JSON 
block containing objects (as key-value pairs).  I'm trying to figure 
out if this is overkill or a genuinely useful way of validating structured 
data...


Then there's ["1" "2" "3"] <- be nice to validate as [some integer!] 
or [some integer! | decimal!]. I don't want it to be overly complex, 
but it should at least be useful - anyone have any conventional cases 
for validating a block of strings?

I'm doing a filtering dialect facing similar problems. 
Examples:

[msg-id] = [ 10 .. 50 ]  ; msg-id must be between 10 and 50.
[msg-id] = [ .. 50 ]  ; msg-id must be any number up to 50.
[msg-id] = [ 50 .. ] ; msg-id must be 50 or beyond.

[group] = [ "Dialects" ]  ; group name must be "Dialects"
[msg] = [ .. "import" .. ]  ; message text must contain "import"

[msg] = [ all [[ .. "import" .. ] [ .. "dialect" .. ] ] ]  ; message 
text must contain "import" AND also contain "dialect".

[user] = [any [ "Chris" "Anton" ] ]  ; user name must be any of "Chris" 
or "Anton"

A "code golf" question on StackOverflow caught my attention yesterday, 
and especially the frustrating ability of perl to win these competitions 
with utterly disgusting code which is unmodifiable with the slightest 
change in spec motivated me to resurrect my rebol dialect for code 
golfing.

AltMe put a wacky thing in that link, I'll try again

Anyway, if you look at the active community of people who like to 
tinker in code golf, I think they're freaky and obsessive enough 
to perhaps appreciate that Rebol is not only terse, but powerful 
in a generic way.  Note the solution from the guy solving this dot 
connection problem on the commodore 64 in screen memory.  Well, trying 
to solve, it fails on edge conditions

The link is probably fine. It's a problem with View that AltME inherits. 
Some of us will see it fine, others see it a little screwed. Resizing 
the window can make the problem go away. Usually the link is clickable.
Good luck with converting the golfers!

Well it's more fun if I'm not doing it alone!!  Note that Code Golf 
answers are wikis, and rebmu is quite easy for Rebol programmers 
to grasp, easy to improve--I think it could be a showcase that might 
get the language in front of "fringe"/"outlier" developers.  (And 
earn perhaps a bit more respect than RebolTutorial's questions, though 
I will say that the visibility he's given by doing Q&A on a modern 
medium is better than nothing...any publicity is better than no publicity, 
the popularity of a tag in sheer number counts is rather important.)

(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.

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.

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

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/

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 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.)

@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.

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.

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?

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 want do do more with it - this is just a test

I've added a new event : 'on-write-chunk to allow modification of 
the chunks of big files just before they are sent. This can be the 
hook to implement compression or encryption when sending big files.

Btw, this new event is untested yet. I should be able to provide 
you a small prototype service and client protocol to show you how 
to use it.

It could be quite simple in fact (at least in theory) :


1) Send a first message telling the name and size of the file (unprocessed) 
to transmit
2) Send the file in parts (done automatically by Uniserve)

3) Catch the 'on-write-chunk event to process the chunk data (compress, 
encode...) then add a header containing :
     - size of the chunk

     - a sequence ID (an incremental counter starting with 1, 0 would 
     mean last chunk)

Please find here : http://softinnov.org/tmp/UniServe0919.zipa snapshot 
version of latest UniServe sources. It fixes some of the issues I've 
been asked about (UDP support for example). It's a beta version, 
no updated docs, no samples. ChangeLog in %uni-engine.r file. Any 
questions ? Ask them here, I'll answer as my available time permits.

Terry, with the release of Cheyenne (soon I hope), you'll get a complete 
working example of encap-fs library usage.

UniServe is a network programming framework. Cheyenne is web server 
(with lot of features) using UniServe as low layer.

Hi Scott, my fault, the release archive contains a duplicate HTTP 
protocol file, so they collide on loading. Just remove the following 
file : uniserve/protocols/HTTP2.r

it states stable, but it really is not. Doc, before he left scene 
for another few months :-), stated something like that he has new 
reimplemented session handling, which is going to be "soon" released. 
But don't take it for granted, maybe I misunderstood something. But 
really - sessions do not work properly ... There is a demo with multiple 
frames, e.g. Mozilla (but even IE) did not open all boxes, there 
were some errors or timeouts, dunno ...

I'd say the core is actually stable, have it running with quite some 
traffic and no problems, there are indeed problems with sessions.

Had a sign very recently that let suppose Dock will soon be back, 
hopefully 8)

very interesting tool ... i go to do a site on it

How does uniserver tcp async compare with a) async://, b) atcp:// 
and c) the new async core that may eventually be released (and was 
available two years ago !)

They are all 3 abstractions of a lower-level rebol async layer, performance 
is in the same range.

Thanks Pekr, that would be a suprise if i was running a server somewhere

I started to play with the proxy-http service a little bit and found 
that there is a bug: the on-error http-event has args: [reason port] 
not [port reason] !