World: r3wp

I don't care about any mass

I just want it to work well enough for me to develop applications. 
 Who cares what they're written in?

Well, as you have to write the applications, I suppose you would 
care. Not your users though :)

yes, that's assumed :)

For me the neat thing is that I can give my users access to Rebol 
inside the product and so they can extend the product as they wish.

One language for all ....

Hey, I had an idea today that you might be interested in. I want 
to come up with a REBOL notation that has the same basic semantics 
as JavaScript but is still valid REBOL syntax. Corresponding concepts 
should match corresponding syntax (= to :, etc.). If it could be 
executable by the standard REBOL interpreter that would be even better. 
As far as I can tell, the only thing without an approximate mapping 
is regex.

Obviously this dialect wouldn't be as powerful as the DO dialect, 
but if it is a proper subset it could be executed by DO and its buddies 
as is. Once you have this, all you would need is a syntax transliterator 
and you would have a JavaScript interpreter in REBOL.

you mean a javascript dialect for Rebol ?

Yup.

Go Brian go!

I was thinking that if I could do that, then reimplement the rest 
of REBOL in that dialect, I could write a REBOL compiler to JavaScript. 
At the very least I could write a JavaScript compiler to REBOL. Or 
for that matter, a compiler for a subset of REBOL to JavaScript. 
Semantic equivalency is what would matter here, not syntax. Syntax 
is irrelevant.

Having a javascript interpreter embedded inside Rebol would allow 
more users ( familiar with javascript ) to write their own add ons 
without having to learn Rebol.

Agreed.

It would also bringe the gap of REBOL and....the "web". :)

Should I make a task for this? :)

Is this on 20% time? :)

This is what Gab and I have been talking about, although even more 
abstracted from REBOL <-> JS, more like REBOL->Dialect->anything 
(HTML, XHTML, JS, HTML+JS, etc.)

I have been giving this a lot of thought over the years, but have 
started coming up with real strategies for doing this for real in 
the last few weeks. I would like to discuss this kind of thing with 
you some time later.

By the way, I would like to ask you that 20% time question for real.

( shouldn't this be in private chat? )

BrianH, You should speak with Henrick too. I believe what you are 
planning is part of long range goals for his html dialect.

I would like to discuss those details, yes. :-)

Brian - bring this topic/plan in Complilers group in R3-alpha world. 
Carl is reading this group, as I pointed him to that interesting 
chat privately ...

Reading this discussion since Terry's first post 8 hours ago (the 
"be serious" one), shows to me how hard it gets to think outside 
the box and that's another challenge when it comes to marketing the 
REBOL browser. When we think of browser, we automatically refer to 
a whole range of technologies and languages. It's something so ingrained, 
we never notice it. Partially you can say it's the same for a PC, 
as it's very likely to run Windows and that if you want to read an 
electronic document mailed to you from an average person, it's very 
likely to be written in MS Word. That's not how we want it to be. 
That's how people think. They think in axioms and familiarity, because 
they don't know any better.


I think the marketing should play strongly on familiarity, such as 
with the aforementioned GMail clone, where it's easy to tell the 
difference in speed between the two technologies. Keep duplicating 
existing stuff. I disagree that the average person can't tell the 
difference. I've observed average people praising that GMail now 
runs faster in FF3 than it did in FF2.


The REBOL browser is disruptive technology. It will be able to do 
things that normal webbrowsers won't be able to do for the next 5 
years at least, if ever. But only if it's done right, by playing 
on familiarity. If it's done right, dumping the traditional web can 
happen faster than we think and I would do it in a heartbeat.

I imagine that if Reichart was ever to do QTask for the REBOL browser, 
he could probably build it alone at 1/3 or 1/4 the time that it takes 
to build it for a traditional browser and the final product would 
run faster.

I think we should wrap some services. Do you remember few scripts, 
wrapping SlashDot? What about wrapping Google mail? And then showing 
the source code of VID? I think it could cause some jaws drops, how 
small the source can be. Then we could encap it, and provide it as 
a Flash app. It could be downloaded in millions. And Google might 
get interested. They imo need something against Flash/Silverlight, 
and there is not third technology to the game but REBOL imo ...

But - we also need multimedia later, so hopefully codecs get finished 
one day ...

These are all great ideas. Is it possible to get started of them 
before we know what Rebol 3 is going to be?

of them -> on them

We have to see the browser and its capabilities first, before we 
can make a next move.

Perhaps it would be easier to appeal to the porn industry to gain 
acceptance. :-)

IMO we can't even be surely Carl will come with browser? Maybe it 
will be "just" VID 3.4, which will allow creation of such browser.

Pekr, why not ask him directly?

But I am glad that my idea of REBOL "player" is fulfilled with the 
browser idea. I never liked ViewTop (desktop paradigm). I wanted 
it to strip down to "go" screen = a browser :-)

to be honest, I am interested in VID 3.4 first, to see how styles 
are built, how it is extensible and in the first place - how flexible 
it is. If it will not allow everything Gabriele had in VID 3, I will 
be strongly disappointed. I expressed it several times publicly and 
also privately to Carl, that I don't accept any unnecessary simplification, 
resulting into R2 VID like limitations. Carl assured me he is taking 
the right aproach, so we will see ...

As for the browser itself, I am not sure Carl is the right person 
to do it (judging how rebol.com looks graphically :-). I think we 
need to cooperate on the idea.

I don't think the design of the browser GUI is as difficult as its 
underlying concepts, like security and basic page display mechanisms. 
He'll want to get those right first.

imo any kind of rebol browser is just VID 3.4 app. That could come 
later imo. We first need to get VID itself right ...

I think he knows that :-)

can't wait for first code examples and screenshots (although those 
will not tell much about architecture itself)

Yeah, let Carl write the stylesheet engine, but have someone else 
do the stylesheets.

Nobody is going to learn Rebol so they can generate Javascript code.. 
and Javascript -> Rebol seems odd. 

I would rather see Rebol -> C or especially Objective C.. then you 
could export to iPhone. 


I played around with Jiggy for my jail broke iPhone.. which lets 
you use javascript to write iPhone apps.. works well. 
http://www.jiggyapp.com/

Terry, Rebol -> JS is kind of similar in purpose and in concept to 
what the Ruby on Rails guys did with Ruby -> JS (aka. RJS).  With 
Rebol's lexical muscles, it is surely a great candidate for abstracting 
what happens in the browser.

I think a few, including Reichart (Qtask), Henrik (HTML Dialect) 
and myself (not started yet, QM) are going this route.

Terry - why would not anyone use VID like fluent description of GUI 
instead of crap js code? Then tell me, why JAVA guys came with declarative 
JAVAFX aproach, if they had JAVA itself already ....

I already used Rebol -> ECMAScript (at least to generate data (mainly 
nasted arrays)) to skip a need to write something like XML parser 
on the client side, how most people do now:)

Terry, I am not going to learn REBOL to generate JavaScript code. 
I already know REBOL. I already have to generate JavaScript code, 
for my job at the very least. As for a REBOL-hosted JavaScript runtime, 
that is likely to be just a useful side effect.

Petr "JavaScript, despite the name, is essentially unrelated to the 
Java programming language, although both have the common C syntax, 
and JavaScript copies many Java names and naming conventions. "

And what I learn can be adapted to other targets, including C, in 
theory. Though C is a poor choice for generating iPhone apps - it 
would be better to generate LLVM code directly, as it has a better 
semantic model than C.

Or even Objective C.