World: r3wp

dialects, instead, are languages based on the rebol syntax. in a 
language you normally parse a text file into some internal representation, 
then you work with that representation (interpreting or compiling 
it)

in rebol, the internal representation is values, and you can do what 
you want with them.

Gabriele;  *poke*poke*  I hope we get LOAD/RELAX.  :)

Remembering that argument, I hope we get the opposite: Parse block 
rules for strings, a sort of parse dialect unification.

Well, something that will let Construction workers type in their 
own data is what I'm

hoping for.  Whatever the actual approach.  Though, the easier for 
me the better.  :)

Some more thoughts on the MS DLR http://vistasmalltalk.wordpress.com/
   His other entries particularly the Ironpython and Smalltalk ones 
are also very interesting.

The question is will the DLR as implemented on .Net and Mono provide 
a level playing field?

I think the DLR may be one of the more significant releases from 
MS in a very long time.

Will Rebol be able to play in this arena, and make use of Python, 
C#, Ruby, JS code?

Gabriele, Even though there Scheme uses two stages the line between 
compile time and runtime is not the same as in C. You can write macros 
during runtime that get compile on the fly and avaialbe without ever 
stopping a program. So in this sense the two phase is just process 
is not really important. The feature that macros brings is syntactic 
abstraction. Also in Rebol you can not do low level control structures. 
That is you can not add foreach without having a looping construct 
already in place. So the mezzanine is slow. Compare to delimited 
continuations of Scheme where is  only control structure and recursion 
and optimized goto. You construct other control syntaxes on top of 
that.

In Rebol adding control structures that are efficient requires coding 
in C. In Scheme adding control structures only requires Scheme.

The form use to introduce a  macro is define-syntax. Which allures 
the their syntatic abstraction function. Macros in Scheme are extremly 
powerful and complete. I understand that dialect in Rebol can be 
as powerful, but the techniques required in Rebol for good dialecting 
fall in the interpreter construction realm, which depending on the 
dialect can require more or less effort from the programmer than 
a macro. Context protection in Rebol is something that is importat 
to consider.

An if you mix dialect lexicon reuse can get tricky. Scheme macros 
are hygenic meaing they take care of name clashing for you.

Thank you Gabriele, I understand much better now. :)

Jaime: that is debatable. continuations are the control structure. 
so it's hard to say that in rebol you need a native control structure 
while in scheme you don't - of course you do. :) also, be it JIT 
or not, compilation is still compilation. it requires knowledge about 
the code before evaluation. which means, that there must be a syntactic 
difference between code and data.

also, if you accept to have a syntactic distinction between code 
and data, it is easy to add a macro preprocessor to rebol that works 
just like in scheme. (so easy that there's no need to have it in 
the language itself. try a scheme without macros, and try to add 
them in scheme itelf... ;)

Just got an email about this:
Micro Focus COBOL acquires Acucorp COBOL: http://www.acucorp.com/

Maybe it's time to do that COBOL dialect in REBOL!? ;-)

are there any language clones done with dialects at all?

I think %prolog.r from the library may count.

Didn't Gregg make a Logo dialect?

Jaime, How about a Scheme dialect in Rebol ?  ;-)

or Rebol dialect in Scheme? :-)

anybody volunteering to test a new Include version?

I'll sign up.  I was looking at your include.r just last night.

the new version is at: http://www.fm.tul.cz/~ladislav/rebol/include2.r

main differences:

- /only refinement added (to only make a Rebol block containing the 
code)

- Parse usage to speed the implementation up and to shorten it a 
bit

Snagged.  I'll be learning as I go, but I was doing that anyway.

No breaks yet.


include/only let's you include the source script.  Kinda cool, as 
it lets you

inspect preprocessor encapsulated #includes.  Not for real work, 
but nice on the learning
curve.

we need a smalltalk dialect and an erlang dialect. then everyone 
must agree that we rock. ;)

Ladislav;  I can't give you much of a 'technical' report, but I tried 
to break the

include sequences and failed.  I'm starting to feel the power of 
this.  I like the fact that
scripts can end with 
context [#include %libfuncs.r]
to let endusers pick their own name with
mycon: do %libouts.r

after an include/link   Very nice.  An easy grok, and I'll say I 
"get it" already and

won't have to read your docs over and over to actually use it.   
(Well except maybe

to refresh the #do [[  and (#do [false]) tricks, if I don't use them 
soon.)  This really needs

to be promoted.  Here's hoping the DevCon talk gets this into the 
fore.

Ladislav; as I mentioned before include/only is really really handing 
for interactive
exploring...awesome.

I started on a Logo interpreter, mainly just to do turtle graphics. 
I don't know how much value it has, but I'd be happy to send it to 
anyone that wants to pursue it.

Since finding REBOL, I have thought it would be a nearly ideal tool 
to teach language and interpreter design and development, because 
you can do so at a very high level. I think Lisp, Forth, and Logo 
would be a great place to start, but there is no reason I know of 
that would prevent us from doing Smalltalk, Erlang, Icon, and others. 
I would LOVE to see that happen.

Seeing different languages implemented, even naÏvely, in a single 
language like REBOL would be a great learning tool IMO.

How do lang "dialects" get round the loadable REBOL value restriction?

Brian: thanks for testing and for the kind words as well :-)

They don't. :-) If you *can* do something as a dialect, and parse 
it as blocks, that makes things much easier, but you don't have to 
make them dialects, they're just interpreters; that's why it's important, 
I think, to start with lanugages that have simple syntax rules. Otherwise 
the grammar may dominate and distract from learning.


I should also say that the interpreters don't have to be complete. 
That is, you could do a Ruby interpreter, but not support the full 
spec of the language. You just do enough to get an idea of how you 
might implement something like Ruby, and see how it works internally.

Ladislav;  No problem...learned a new bag of tricks today.  :)  And 
I'll be sure to report
any problems if they arise.

Gregg;  I've been keen to get the REBOL console into an immersive 
mode, like I was

used to in polyFORTH.  The line editor vocabulary means parsing random 
string input.

p [


would place an open square etc...  String parsing seems so, umm, 
not the way.  A CLI

dialect is tricky if everything has to be loadable.  p "[" is not 
immersive, it becomes

a little disruptive to the "stay in the context mode".  Anyway...not 
on the table today.
Just unparked   peoplecards.ca  :)

Interview with Mozilla's CEO Mitchell Baker - http://apcmag.com/6054/firefox_ceo_speaks_out


There are also some off-line app support information (they call it 
web 3.0)

Gabriele, We have this debate before. You are quick to disregard 
macros as nothing. Data and Code are the same in Lisp and in Rebol. 
As matter of fact Rebol borrowed this feature from lisp, so did smalltalk. 
It is call homoiconicity. And it has nothing to do with compilation 
or interpretation.

Rebol is an interpreted language and with the current syntax it can 
not be made into a compilable language. At least with the current 
stage of CS development. That is drawback, because you pay for this. 
Either in performance or in memory footprint.

You certainly gain in expressivity, but the reason Scheme abandon 
dynamic binding for lexical scoping is due to the problems that can 
arise with the former in programming-at-large.

R3 requires modules to address this.

I like Rebol syntax. I even started to get into creating a clone. 
But I like Scheme semantics much more. So I side with clean semantics 
over pretty syntax.

An while Scheme has continuations and tail recursion optimization 
as only control structures. Rebol has more that 10 nitives just dedicate 
to control. So one feature plus macros gives you the 10+ features 
you need to implement outside of the language.

Scheme  JIT is cool, but it doesn't have to do anything with DATA 
as CODE. Even rebol code needs to eventually schedule  the bits and 
opcodes required by the hardware. So that imo has nothing to do with 
Programming Language Design (PLD). It has to do with how the Programming 
Language carries out a computation. So the debate of interpreter 
vs compiler is pretty arid for me. The important thing in a PL is 
how expressive it is?  How can you enhance it? The beauty of LIsp 
and SmallTalk is that the ng of Lisp and SmallTalk is writting in 
themselves and that for me is beauty.

For example. For years the Haskell community has disregard Scheme 
beacuse of it lacks static types, and it uses eager evaluation instead 
of lazy evaluation, strongholds of the strict PLs like ML, Ocaml, 
Haskell and others.  But one year ago the wizards at North Easter 
University, added lazy evaulation and types to scheme. So you can 
pick during different parts of your code the style of evaluation 
(lazy or eager) and the to type or not your values (static vs dynamic 
typing). This enhancements are thanks to the *hygenic referential 
transparent  macros*  feature of Scheme. Also not that Common Lisp 
macros are not as powerful as define-syntax, nor Common-Lisp can 
support continautions without making a quagmire.

So a language that was not intended to have certain features can 
added later on, without losing performance or expressivity and remaining 
backwards compatible. I think that is power. Some days ago Sunanda 
was appealing to an R2 compatibility mode in R3. I hope this example 
shows the power in Scheme.

The power in Rebol is different. I think Rebol is good for KISS, 
where simple things are simple, hard things are hard. Like adding 
co-routines. We added this feature to BEER. It works but they require 
careful programming of your routines. Otherwise you get blocking. 
The solutions is R3 tasks. Similarly situation has happend with other 
features, like the FastCGI request that I see sometimes, or callbacks 
for C routines which was dormant inside the interpreter for years 
until discover by cyphre and later released.