AltME groups: search

Added a couple commits to make Graham happy. :P

We need to do that again soon... I'm leaving for LA in about a week, 
then we have BIL2012 there, then I'll see if I can set up a hangout.

I expect it to be a bit like Lua.

Can you do operators with more or less than 2 arguments? We figured 
out how to do postfix operators in REBOL, Red, etc. if you support 
operators with 1 argument, and ternary operators if you support operators 
with 4 arguments, the third being a keyword. You could even support 
multiple ternary operators starting with the same word by making 
one that dispatches on the keyword.

Teaser 7: The range datatype

w> type? 2-5
== range!
w> block: [a b c d e f g]
== [a b c d e f g]
w> block/2-5
== [b c d e]
w> block/4-4
== [d]
w> block/4-3
== [c]
w> block/4-1

w> type? a-b
??

w> type? join a {"-" b] ?

Or :

to : operator [
	first
	last
][
	join first ["-" last]
]
type? a to b

Geomol: The use of a path! to  denote a range is a clever way.

But I don't think you need a range! datatype to express boundaries. 
A pair! would do the job as well.
>> block/2x5

Or
to range! reduce [a b]

Use pair! ... hm. Extrapolate that to be used in a matrix.

w> a-b: 1
== 1
w> type? a-b
== integer!
w> a-b: 1.0
== 1.0
w> type? a-b
== real!

Or in plain English: is range! a series! type?

Is a range! convertible to a block!/a series! type?

I've used x..y for range notation. In REBOL, that limits you to 255 
if mapped to a tuple, but World wouldn't have to have that limitation. 
I've also used dash/emdash. My BOUNDS dialect is flexible, as it 
was for experimentation.

Its too bad but http://world-lang.orgcannot be accessible from Turkey 
:( I'll try with a VPN.

so the legacy of Rebol will be Rebol clones - not so bad a legacy 
actually

I'm a little sorry to see the R2-style port model instead of the 
R3 style. Are all ports direct at least?

R3 port model is definitely a must :-)

Geomol: "How can that be?" Unfortunately many domain name is not 
accessible from Turkey. The telecommunication company restricts the 
access of many domains, IPs, and even domain names that includes 
some restricted words like porn, f**k or something..

The funny thing is the word of "forbidden" (in Turkish "yasak") is 
also restricted, no one can access a domain which includes "yasak" 
word without using a VPN.
Shame..

That's interesting reading. Can an instruction set for a CPU be copyrighted 
then?


Funny that the story is about SAS Institute and a company called 
"World Programming". A very dear frind of me works at SAS Institute 
France just south of Paris. I have to get his comments on that story. 
:)

Hand me 100k, and you can get a pre-pre-release! ;p


Or you can wait a bit and see it as a little extra early x-mas present.

I feel, it's better to hold the Q&As together, now it's a brand new 
language.


What do you mean? More about numbers, extension of complex numbers 
like Quaternion or do you mean more about physics/science?

is there a way loading and interfacing pure object files, how about 
callbacks ?

Is there a call-in interface available, meaning I can embed w-l in 
other programs?

Regarding your thesis I guess you have something like an integrated 
db or a special datatype for permanent storage too..

Q: Will the countdown run to 1, or to 0, or to a negative limit, 
or a complex! number, or some unknown kwatz!?

just a theory

How many people were working on this World:) Is it just a single 
man project?

Q: will there be a GUI?

I know too little about licensing at this point. I need a proper 
license at some point. The alpha license is just:


Alpha release. For testing only. Use at your own risk. Do not distribute.

Ask a question about portability.

If you do copy-on-write then TO-BINARY some-kwatz-value would be 
able to work on the same data, at least until you modified it. That 
would make the binary-vs-kwatz distinction less important. Nonetheless, 
Cyphre's solution of having an internal flag on the binary! type 
to mark it as kwatz! and a KWATZ? function to test for it is similar 
to the fake datatype trick used in R2 2.7.7 and 2.7.8.

Q: Will this language be an open or closed source project?


A: Long answer: The plan is to fully open source it at some point, 
when version 1 is ready. Host depending sources are open in the alpha 
release, and it may make sense to open source more and more along 
the way, like sources for the different datatypes. The IT world is 
constantly changing. My nephew just went to the Devoxx Java conference 
in Belgium. Everybody had portable Mac computers. That was very different 
just a few years ago. Who knows, what devices we'll use in 5 years? 
I like to bring my software with me to new platforms. To be able 
to support new platforms faster, open source is a good thing. But 
some things needs to be fulfilled, before I'll open source it all.

1. This isn't a hobby project. I've invested a lot of time and work 
in this project, and I need to find a way to get something back from 
all that. One option is to have a good manual ready for developers 
to buy, open source it to get a lot of developers interested, and 
make a profit that way. There may be other ways (like someone or 
some company paying me to open source or make projects in World).

2. I need to know more about the consequences of open sourcing it, 
so I can avoid any nasty surprises. Knowing more from other similar 
projects could help. I need to figure out a proper license.

3. Even if I keep the sources simple and clean, I would like to clean 
up even more, before it can be open sourced.

A: Short answer: Currently it's partly open source.

Q: What is the main target?

A: The World prompt is a very powerful tool. Being what is known 
as "network transparent" helps in the era of the Internet. Server 
scripting and client scripting are obvious uses. The ability to easily 
make dialects makes it possible to wrap the language around the problem 
instead of trying to change the problem to fit the language. Interfacing 
with other technologies ... see "Introduction" on http://world-lang.org
in a few days.

Q: Is it closer to R2, R3, RED, Topaz architecture?

A: World run its code within a custom made virtual machine (VM). 
Compiling in World compiles World sources to this VM. This happen 
when source code is run or if explicitly compiled. REBOL is always 
interpreted (AFAIK), so that's different. I'm far from an expert 
in Red and Topaz, but as I understand it, Topaz is compiled/translated 
to JavaScript. So the JavaScript engine can be seen as the VM in 
World. And Red is compiled to native code, so that's different too. 
As I see it, all these languages work differently and can complement 
each other. (Help me here, if I'm wrong in any of this.)

Q: What was the main motivation, aka - why yet another language?

A: After I've learned REBOL, I find it frustrating to program in 
most (all) other languages. The difference is like when humans moved 
from carving words in stones to using a printing press a la Gutenberg. 
Then I found, I couldn't complete projects like my Canvas RPaint 
program on all major platforms (Win32, OS X and Linux), I couldn't 
run my code on new portable devices, and I needed better performance 
with scientific applications. With my background in graphics, music 
and science, I expect the language to develop into those areas.


Q: If (you) don't have any other target, why don't you work on Red? 
Or fork a project from Red?

A: I started initial work on World in late March 2009. The first 
post in the Red group here in AltME is from 27-Feb-2011. At that 
time, World was more than 7'000 lines of C.

Q: Does World compile into bytecodes (a la java) or machine languages?

A: Into bytecodes for the virtual machine. Each VM instruction is 
32 bytes (256 bits) including data and register pointers.

Q: Can you do operators with more or less than 2 arguments?

A: Not yet. I've considered post-fix operators (1 argument), and 
it shouldn't be too hard to implement. To motivate me, I would like 
to figure out some really good examples. With more arguments, I can 
only think of the ternary operator ("THE ternary operator"). I'm 
not sure, World needs that.

Q: Is range! a series! type?

A: No, range! is a component datatype. It has two components just 
like pair!.

Q: What platforms are supported?

A: For now Mac OS X (64 bit), Linux (32 bit) and Windows (Win32). 
The code is very portable. It took me a few hours to port to Linux 
from OS X and just a few days to Windows.

Q: What platforms do you plan to support in the future?

A: It would be cool to see World on all thinkable platforms. I personally 
don't have time to support all. World is not a hobby project, and 
I'm open for business opportunities to support other platforms. The 
host depending code is open source. I mainly think 64-bit.


Q: I'm a little sorry to see the R2-style port model instead of the 
R3 style. Are all ports direct at least?

A: Yes, ports are direct (no buffering). The ports and networking 
are some of the most recent implemented. More work is needed in this 
area. I would like to keep it simple and fast, yet flexible so we're 
all happy.


Q: What in the world is going on with the World Programming Language? 
This looks like something that must have been under wraps for a long 
time. What's getting released?

A: I didn't speak up about this, until I was sure, there were no 
show-stoppers. The open alpha of World/Cortex is being released as 
executables for Mac OS X, Linux and Windows (Win32), as are the platform 
dependent sources and initial documentation. World implement 74 natives 
and more than 40 datatypes. The Cortex extension (cortex.w) implement 
100 or so mezzanine functions and some definitions. The REBOL extension 
(or REBOL dialect in rebol.w) implement close to 50 mezzanine functions 
(not all functionality) and some definitions.

Q: Did you do some speed benchmark? (R3 vs R2 vc World) ?
A: Yes:

(All tests under OS X using R2 v. 2.7.7.2.5 and R3 v. 2.100.111.2.5)

- A mandelbrot routine (heavy calculations using complex! arithmetic) 
is 6-7 times faster in World than code doing the same without complex! 
in R2 and 11-12 times faster than R3. If using same code, it's 2.5 
times faster in World than R2 and 4.2 times faster than R3.
- A simple WHILE loop like:
n: 1000000 while [0 < n: n - 1] []

is 1.8 times faster in World than in R2 and 2.8 times faster than 
in R3.

- I tested networking in two ways. One sending one byte back and 
forth between client and server task 100'000 times using PICK to 
get it, and another sending 1k bytes back and forth 10'000 times 
using COPY/PART to get it from the port. Both were around 3 times 
faster in World than in R2. (I didn't test this in R3.)

- I tested calling "clock" and "tanh" routines in the libc library. 
I called those routines 1'000'000 times in a loop and subtracted 
the time of the same loop without calling. Calling "clock" is 2.4 
times faster in World than in R2. Calling "tanh" (with argument 1.0) 
is 5.9 times faster in World than in R2. (I didn't test this in R3.)


(Some functions are mezzanines in World, which are natives in REBOL, 
so they'll in most cases be slower in World.)

Q: We already know that your physics background influenced the new 
complex numbers datatype. Should we expect further progress of this 
kind (physics/science)?

A: After pointing this language out to a couple of friends from university, 
I was quickly asked to give scientific examples, like making a Lorentz 
attractor. There will come examples like that. Also I have some contacts 
at the Niels Bohr Institute (Copenhagen University), that I would 
like to show the language to and see, if we can create some projects.


Q: How long has this been in the making in general & how much time 
have you spent programming it?

A: I started R&D late March 2009. In March 2010, I had >7'000 lines 
of C. Then I took almost a year break from World and started up again 
Spring 2011. I have used much time on it this year (2011). So I've 
used 1-2 years effectively, I guess.


Q: Is there a way loading and interfacing pure object files, how 
about callbacks?

A: I don't have much experience in this area. Two of the closed alpha 
testers have looked at interfacing with sqlite3, which uses callbacks 
for some stuff. I would say, it doesn't work 100% yet, but it's being 
worked on. I need to see examples of loading and interfacing with 
pure object files to judge, how much of such functionality should 
be in World.


Q: Wouldn't it be useful to treat the kwatz! type same way as binary! 
so you don't need to always convert it? I mean, all functions that 
are able to take binary! arg should be able to use the kwatz! as 
well...or do you think are there any problems regarding that?

A: I've thought of that and came to the decision, that KWATZ! should 
be treated with some care. Are we always sure, we want to treat that 
data as binary? I need more experience using KWATZ! to judge that. 
Conversion could be fast, if the AS function was introduced, which 
should just change the type without copying.


Q: Is there a call-in interface available, meaning I can embed World 
in other programs?

A: Not yet. Internally I do call World functions from C (to parse 
URLs) by pushing arguments on the VM stack and call the execute_vm() 
C function. I imagine an interface much like in Lua (lua_call), but 
a little more work is needed, before we're there. This is an alpha 
release, so things will change/be added, before we move to beta release.


Q: Regarding your thesis I guess you have something like an integrated 
db or a special datatype for permanent storage too.. ?
A: Too early! :)

Q: What subset of REBOL2 will run without change in World?

A: Uh, ah, hard to tell at this point. When I need new functionality 
in World (because I want to run some of my R2 scripts), I consider, 
if it should be part of World/Cortex or if the new functions should 
go into the REBOL expansion/dialect (%rebol.w). I want World/Cortex 
to be small and compact. The idea with %rebol.w is, that much of 
R2 code could run, after this script has run.


Q: Are there datatype and function comparisons between World and 
REBOL2?

A: No, I haven't documented that ... yet. Maybe someone else wanna 
document that!? But there are differences, like the REBOL decimal!, 
which in World is called real!. And then %rebol.w just include the 
line:
decimal!: :real!
, so REBOL scripts using that will run.


Q: How many people were working on this World? :) Is it just a single 
man project?
A: Yes, just me.

Q: Will there be a GUI?

A: I would really need a GUI for my own work at some point. I have 
ideas, but nothing set in stone yet. And I want World to be open, 
so different GUIs should be possible, also the native GUIs in the 
different OS.


Q: Are you rich enough to buy Rebol Technologies and employ Carl? 
:-)
A: [KWATZ!]

When we tried something similar to the LOAD/on-kwatz trick in R3 
(named LOAD/on-error there) it turned out to slow down LOAD so much 
that it made it unusable - something about switching back and forth 
between native and interpreter execution schemes. The alternative 
of having a kwatz! type returned had the effect of changing a load-time 
check for syntax errors in the source code into a runtime check for 
invalid values, but only if you are expecting such things and testing 
for them explicitly. Under normal circumstances a kwatz-accepting 
loader would often result in code that would run slightly wrong but 
not trigger an error to help you figure out why. This is why you 
should make sure that your regular code loader triggers errors by 
default when it encounters unexpected syntax. An option to be more 
forgiving would be helpful when loading dialects that explicitly 
support particular kinds of extended syntax - and thus are expecting 
kwatz! - or for loading user data for analysis.

Yeah. I'm also glad, it's faster. That was some of the first tests, 
I did, long before you could call it a language.

I've dealt with unicode in some REBOL projects, simple by making 
functions to deal with it. I would initial do it like that in World, 
but on sight, a unicode! datatype would probably be a benefit.

REBOL can be blazingly fast if you use it for REBOL-like tasks. It 
has a different set of tradeoffs. Unfortunately for its image, most 
language-vs-language comparisons tend to have C-like code since it's 
the common denominator, and that makes languages that aren't optimized 
for that style of code look bad. However, if you have to do C-like 
tasks, a language that isn't optimized for them won't help you very 
much. This is one of the reasons that I like the REBOL spinoff languages. 
For me R3's model leads to the fastest code, but I don't have to 
do much C-like stuff.

Words are probably ok as ascii, but unicode! datatype is a must if 
you don't want to end with binary data instead which is doable like 
in R2, but ugly.

I fear, that implementing unicode! datatype will mean, all series 
functions will have to deal with it separately, like LENGTH?, NEXT, 
SKIP, etc. Would it be an idea to make a unicode! datatype just to 
pass data back and forth and be able to view it somehow, but without 
support for all the series function?

@Janko, it's about the fact, that Lua implement a virtual machine, 
that runs the vm asm code, after Lua source has been compiled to 
that. World does it the same way, but in many ways, World is also 
very different from Lua.

Janko: Compiled to a byte-code VM, it looks like a similar embedding 
model. The advantages of bytecode VMs are that they can be tuned 
to be faster for low-level operations that can match the VM author's 
needs, though most are optimized for C-like code, simple math and 
loop evaluation. The embedding model makes it so that you can embed 
in a C-language program (lowest-common-denominator) without affecting 
the language itself much, though the actual interface is slow enough 
that efficient code tries to avoid going back and forth across that 
barrier. Disadvantages are that higher-level operations tend to be 
slower than the lower-level operations that have bytecodes associated 
with them.

thanks for explanations to both of you. so it's more of a backend 
similarity

Thanks for the comprehensive Q&A, John.

I also think that 256-bit VM insn size sounds a bit wasteful. That'll 
thrash the data cache easily.

REBOL code is interpreted, but not its source. The slow part of a 
source interpreter is parsing the source into the intermediate code, 
the AST. REBOL is an AST evaluator. The advantage to that relative 
to a bytecode VM is that you can extend the runtime with more fast 
operations without breaking the bytecode encoding, but the disadvantage 
is that the interpreter overhead is larger so if you want your operations 
to be efficient you have to use larger ones. This is why C-like code 
is slow in REBOL, but high-level code can be fast.


If you want to get the advantages of a bytecode VM with the extensibility 
advantages of REBOL's model you could go with an address-threaded 
interpreter. Address-threaded interpreters have more data going through 
the processor than bytecode interpreters do, but it you need to support 
higher-level operations they are more efficient overall. However, 
if you don't need to support higher-level operations and only need 
to support a tiny number of low-level operations then bytecode can 
be encoded in a much smaller amount of space. If your language is, 
for instance, a spreadsheet formula evaluator then you might even 
be able to have 4-bit bytecodes, with two operations per byte, and 
have an interpreter that fits entirely in the instruction cache of 
a processor. Bytecodes can be much faster then.


Still, Lua's bytecode VM, as efficient as it is, has been running 
into performance limits as well. Fortunately, a bytecode model that 
maps well enough to the native code model (remember what I said earlier 
about C-like bytecode VMs?) can have the bytecodes translated to 
native code at runtime and then execute the native code. For C-like 
code that is usually even faster than address-threading. This is 
why LuaJIT has been doing so well when compared to Lua's bytecode 
VM.


World being Lua-like means that it can improve using methods similar 
to the ones that Lua has been using to improve. That's definitely 
a good thing, since it means that Geomol doesn't have to work from 
scratch :)

If you want to compare to a source interpreter, try old versions 
of TCL before it switched to bytecode interpretation. That was *slow*, 
not like REBOL at all.

Just a thought, though. You (John) probably already tried that :)

Uh, I'm not 100% on the technical terms. Registers are on a stack, 
and a register pointer is an offset. So you can have lots of registers, 
and the VM can access each of them very fast. Values can also float 
in memory (not on stack), and then we have a real pointer to it. 
See blog tomorrow.

(As long as it's a 64b-multiple, thats fine.)

Is your bytecode polymorphic, or is it statically typed? A polymorphic 
VM like REBOL's wouldn't have problems with higher-level series like 
unicode!, but to support that on a static-type VM you would need 
either a lot of opcodes or compiling to a lot of code to support 
it.

REBOL's actions are a polymorphic VM, btw.

(That's only when you use interpretation for the VM implementation. 
If your VM implementation is a JIT-compiler, register-based VMs match 
typical target architectures more closely, as Brian mentioned.)

Andreas: The compelling evidence being Lua, which is the main register-based 
VM in popular use for which that is true. However, that depends on 
a number of other factors, not the least of which is the target architecture, 
or instruction-set design, or how well the register model maps to 
the underlying register model. It might be noted that there are not 
that many hardware platforms with 192-bit registers, so that might 
affect things.

That you will need to figure out yourself within a few days. It's 
more fun that way. :)

Andreas: So in the case of register-based hardware architectures 
with a lot of 64bit registers (AMD64, PowerPC, Alpha), for a value 
space that rarely has direct values more than 64bit in size (the 
JVM model) implementing a variable-based procedural language rather 
than a stack-based language, a register-based model is faster than 
a stack-based model. Yup.

I'm surprised that in that case the register-based VM is only a small 
amount faster than the stack-based VM. Their register-based VM most 
have been crappy.

On a Mac again ?

Brian, the size of a Geomol bytecode is twice the size of a Rebol's 
cell

Sorry, I missed that. So it's a VLIW VM, like Itanium. Not quite 
the same thing as Lua at all. So we should believe him when he says 
"I have only done very little in compiler optimisation", but at least 
we don't have to worry too much about running out of opcode space.

I wonder how well the book sales idea would work. A side-effect benefit 
of that is good documentation for the language and some marketing.

:)

Like I said, when World is version 1 and I have written a good manual, 
it may make good sense to fully open source it.

single level Mark and Sweep GC?  or did you put a bit of time into 
making it a bit more powerful (multi-zone, multi-level, multi-threaded, 
etc.) ?

The nice thing about the book I bought is that I can report errata 
directly from the pdf ... click on errata and it takes me to a web 
form

And of course if it becomes popular you can do a second edition ;)

ANSI World ... oh no, a fully standardized Earth.

That's the rub ... a single person can only do so much.  And few 
people these days will contribute to a closed source project

its more like I want to link my C version of liquid rather than use 
an interpreted one.  the speed/memory impact is tremendous (10 million 
node allocations a second on the latest early prototype).

btw, wrt the licensing issues... if it may help you, one thing I 
can say is that you will never make (real) money from a programming 
language itself.

once the language actually works, here are possible money making 
potentials:

-the tools which go around it  (frameworks, IDE, etc).

-integrated modules, individual or sets.


-consulting services & adapting the language and its tools for specific 
(high-profile) clients.


-corporate funding by a company , university or research institute 
which uses the language in core components and wants to make sure 
the language stays alive.

-apps/web sites you build with the language.

-donations from enthusiasts (many apps live solely on this!).

Thanks for all your work on World, and the QA John. It's very exciting.


As far as the outrageous bytecode size, from one who hates bloat 
as much as the rest of you here, I am happy to make certain tradeoffs 
in return for other benefits. If I have the choice of REBOL, World, 
Red, and Topaz as "mindset compatible" languages, I can choose which 
one to use for a given purpose. Yes, that opens up other questions 
and issues, but I'm happy to see more REBOL-like langauges.

John, on range! values, do you envision transparent iteration/lazy 
generation support for them? I use the term 'bounds for what you 
call range! and my 'range is a series with the values filled in (with 
/skip support).

I'd really like to see such a combination, a fully working glass 
with a "compiled" rebol clone .. I just have too many performance 
issues with what we have at present.  It may be fast to write .... 
but ...

I think the range datatype should be tweaked a little:
 block/4-3
should return.
== [d c]
 

otherwise  it becomes mightily confusing, since as you have it now, 
when going backwards, its 0 based and going forwards its 1 based.


also,   /4-4 and /4-3 shoudn't return blocks of the same length, 
its almost impossible to compute ranges since we'll have to add IF 
to know if the start and end are the same, and then decrement them 
by 2 instead of one, for example... pretty odd.

I'm not sure about that either Max. We'll let John catch his breath 
and he may have a reason.

World alpha has been released.

Who's the first one to successfully run a test?

Well, I ran the test and just created a function. I love the automatic 
quotes by the way.

Re: naming convention from ann-reply

You could use the same names as they are now: world_linux.xxx and 
then suggest the user can/should rename his version as world.xxx. 
That way a person can get going immediately without that step if 
he wants to.

First let's see, how many REBOL scripts will actually run. I assume, 
a lot of work is needed in %rebol.w . You guys are welcome to contribute. 
Maybe we need a project for that!?

I don't think, there is a cmandelbrot function.

%rebol.w will extend World with some REBOL stuff. We could say, REBOL 
then is a dialect of World.

It is quite a long time I last used it to get R3 sources ;-)

It would probably require a small fix in the current colorizer used 
for Rebol (so World is recognized as well)

(once there will be a new versions)

Geomol - absolutly - not impotant, just a question of couriosity 
.... You better focus to some other areas :-)

I guess you should give us a bug tracker.

nooo too much work for me. :)


Well, for now I would not have time enough to deal with lots of bug 
reports. At a later time, when I'm mostly done coding on it, and 
have removed all the bugs, I already know about, and added missing 
features, bug reports are very welcome. But simple tests, like you 
see in the test/ dir is a good idea. I can handle a couple of falsed 
tests at a time now. So maybe that's a way.


What do you guys think is a good way? What way will get to the goal 
knowing I'm booked with things to do already.

And the defining rules for routines will most likely change, so don't 
use a lot of time making routines, unless you're ready to change 
your code later.

Do you have a place to keep a list of REBOL incompatibilities?

For example:

** Error: set has no refinement called any

Nenad uses Github issues for bug and feature request tracking for 
Red though perhaps the wiki would be better for a List of REBOL incompatabilities?

I'll create a wiki.

re bug tracker: i think we can just use github's issue tracker [1] 
to _record_ issues we find, for now. so just so that there's a single 
place to collect them.

[1] https://github.com/Geomol/World/issues

Code is compiled in two ways.


1) Code is being compiled to the VM, when it's being run. So if I 
define and run this function:

w> f: does [return 1 return 2]
w> f
== 1

only the first RETURN statement is being compiled.


2) If I instead compiled the functions, both statements are being 
compiled, e.g.:

w> compile :f


will compile both RETURN statements, but this has no impact, when 
running the function (of cource), and DISASM just stops, when it 
sees a RETURN.

Functions can also be in a parthly compiled state:

w> f: func [v][if v [return 42] print "Hello!"]
w> f true
== 42
w> disasm :f

...	(just part of the function is seen ending with an END_EXECUTE)
w> f false
Hello!
w> disasm :f
...	(the full function is seen ending with a RETURN)

Q: Does binding work similarly to REBOL? I mean can World support 
current advanced REBOL block binding/building for generating code 
like Parse compilers or such oddities like this:
>> reduce [word word word]
== [1 2 3]


A: No, binding works differently in World. In World, each block is 
bound (points to a context).

btw - if World is supposed to be about dialect, I would rename it 
to simply a Word :-) You acronym still would make sense ....

Terry would explain to you, that in the beginning, there was a God, 
and right after him, there was a Word - the first dialect of our 
cosmos :-)

Maybe I should tell a bit, how I work, to make it easier for you 
to understand, what you've got for now. I do much of assembly line 
programming, because it reduces the time of development. So when 
I wrote the lexer, I didn't just implement e.g. numbers, because 
arithmetics would be the first functionality, I would finish. I implemented 
all 40-50 datatypes, I wanted in World, in the lexer at the same 
time. So the lexer is prepared for more datatypes, than what actually 
works for now, and you will just see "Valid <something>" from the 
lexer, when it recognizes such a type.

Why does world open a listening socket at port 8080?

World seems to be fussy about which directory it is launched from


Is there a way to figure out, what directory a command launches from, 
which will work across platforms? I could check argv[0] in main(int 
argc, char **argv) , but that wouldn't work, if world is put in a 
bin, which is part of $PATH.

Sorry. it opened a listening socket at port 0.