AltME groups: search

If we had a compile reset, we could postpone the recompilation until 
the next evaluation.

Right, good explanation. Would a compile/reset be an idea? It doesn't 
compile, just reset.

as a refinement, I mean

Ah, I would like to do compile/reset/at too, so it's maybe a little.

About instructions being 256 bit, half can be used to hold constants 
of the types:

- complex! : 2 double
- range! : 2 64-bit int (also pair! in the future)
- tuple! : 14 bytes + length (could be 15 bytes)
- date! : 128-bit in all


The rest is used for opcode, type of constant and a register offset. 
I put a 32-bit filler in, when going from 32- to 64-bit to reach 
a 64-bit boundary. So it should be possible to go down to 192-bit 
instructions without loosing functionality. To reach 128-bit instructions, 
the above constants needs to be spread over two instructions, which 
will hit performance. But it's important to notice, there is room 
for improvements here.


It hasn't been important for me to uptimize in this area yet, so 
that's why it is like this for now, but that time will come.

On the other hand, on a 64-bit system with 64-bit pointers, compiler 
optimisation of code such as:

	0 GET_TVALUE	0		10031dff0
	0 GET_TVALUE	1		100150fa0
	0 ADD			0		0		1
	0 SET_TVALUE	10016f6f0	0


will require 192 bit just for the 3 pointers, which will mean 256-bit 
instructions (with opcode), if the code can be optimized into 1 instruction. 
Optimizing four 128 bit inst into one 256 bit inst will halve the 
memory required. I haven't dug enough into optimisation in World 
to say, if it's possible.

The above VM asm is produced by code such as:
	a: b + c

I wish you luck with World. It may be a bit difficult for me to use 
it though, because of the ASCII strings. Any language that isn't 
built from scratch with Unicode strings, instead having them retrofitted 
later when the inevitible need to support users outside the the English-speaking 
world, will have a great deal of problems. Python 3 is just the latest 
example of the problems with not having a well-thought-through Unicode 
string model. One of the best parts of R3 is how well we handled 
the Unicode transition.

I even have difficulty using R2 now because of how it can't really 
support nvarchar columns accessed through ODBC, a daily problem for 
me.

My view is, implementing unicode everywhere will add to unnecesssary 
complexity. Each such level of complexity is a sure step to downfall. 
My first rule of development is simplicity, then performance, then 
low footprint, then maybe features.


Words in World can hold 7-bit ASCII. Chars and strings can hold 8-bit 
characters. That's the level of simplicity, I aim at.


I will have to deal with unicode, of course, and I'll do that, when 
World is a bit more mature. There could be a unicode! datatype.

A word about license, since that has been brought up in different 
groups. The current license for World is simple:


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


There is a LICENSE function to show that. World is currently an alpha 
version for testing. When World moves to beta stage, I have to figure 
out a proper license. (I think, that's in the Q&A too.)

There is a lot of interest from people from France in REBOL-like 
languages, it seems. The month stats for world-lang.org shows most 
visitor from France, closely followed by Denmark and United States. 
Then Germany, Switzerland, UK, Czech Rep., Japan, Canada and Malaysia.


I should say, that I informed my SAS friend from France about this, 
so he could have spread the word too.

That's cool, Brian! :)

A note about KWATZ!, you suggest it to be text!, but it's not quite. 
It sure can be e.g. UTF-8 data:


(Setting my Terminal program to character encoding Unicode (UTF-8) 
and trying to load 3 ASCII letters, 3 danish letters and 3 greek 
letters)

w> load "abc ?????? ??????"
== [abc #{C3A6C3B8C3A5} #{CEB1CEB2CEB3}]


(Notice World isn't prepared to unicode yet, but can load it, as 
it can just be seen as bytes.)


But beside text, KWATZ! can also handle all other data, like escape 
codes or any binary format maybe combined with more understandable 
data, you wanna load.

On the word KWATZ!, someone found a couple of good links:

http://seedsforsanctuary.blogspot.com/2008/06/kwatz.html
http://www.livingworkshop.net/kwatz.html


I first heard the word in a dialogue between an AI and a poet in 
a very good book by Dan Simmons.
[KWATZ!]

maybe you can add an easy switch just by one key code to switch between 
 a line mode

Maybe a control char?

Like ctrl-a

What if World is used through a telnet on a server? Ctrl-A is SOH 
(Start of Heading). Could that give problems?

sorry, I had to switch to an other pc,  where Altme is already well 
configured.
Good was meant for a control char.
Why not make the key, that changes the mode configurable?

And if you don't mind, I may start poking around in your wiki as 
btiffin on GitHub.  Feel free to tear any writings apart.


I'll admit to having some deeply ingrained misunderstandings about 
REBOL, so those will likely slip right on over to World.    (I've 
got notes from Ladislav, Gabriele and a few others that pointed out 
these misunderstandings (and when documenting, misunderstandings 
are simply untruths and need to be treated that way)).  In particular, 
I still don't see clearly the 'value - premake - type - make (and) 
word' semantics of REBOL (at least in terms of trying to explain 
it)  I'm hoping your World engine code is let out so I get a chance 
to view my problem from a different angle and hopefully 'see the 
light'.


I'll add that if you want to send any snippets for markup in LaTeX, 
I'll sign up for grunt work too.

Ok, dug in a little.  But still reading back matter...

Regarding cortex.w - is that in the far-plan?  Mezzanines ship with 
the binary instead of in?  Should it be documented that way?

It's not really junk!, it's human text, encoded as humans see fit, 
gibberish or deep meaning symbolic.

Funny, when I first implemented KWATZ!, I called it gibberish!, but 
I found KWATZ! better suited and more interesting. And it kinda give 
you the same feeling, as when you see a computer go down with a "Guru 
Meditation". :)


And if you don't mind, I may start poking around in your wiki as 
btiffin on GitHub. Feel free to tear any writings apart.

The idea with the wiki is, that it's for everybody to edit, so it's 
not really "mine". And as I have very little time for documentation 
right now, I will only contribute a little. It may be needed to step 
in at some point and clear things up, make different pages consistent 
with each other etc., and that may be me, who does that, but it could 
be somebody else too. For the dictionary, it may be an idea to write 
a script, which does most of the documentation (I think, there's 
an old REBOL script for that lying around somewhere, which may be 
suited with some modification). system/words may be needed to do 
that properly, and that's not in World yet. I produce LaTeX output 
with my NicomDoc format, so I'm covered there with the documentation, 
I'll do (a proper manual).

Regarding cortex.w - is that in the far-plan?

Yes, the binary will be as basic as possible. I even consider removing 
definitions of natives from the binary, as it's possible to define 
them in cortex.w. Same could be done with datatypes with a little 
change to World. Then the binary could only define MAKE and DATATYPE! 
(and probably also SYSTEM), and the rest could be build from that. 
It's a good idea to split the doc up in a native section and a mezzanine 
section. And then there's rebol.w, which will make it possible to 
run even more REBOL scripts. There could be a dictionary for that 
too.

Btw. in World, natives are being called functions too (it's easier 
for the user to understand, I think). You can distinguish them with 
PICK, as the second item is an integer. Examples:

w> type? pick :add 2
== integer!			; so ADD is a native function
w> type? pick :loop 2
== block!			; so LOOP is a mezzanine function

If LOOP becomes a native, we can just move it in the dictionary. 
I try to create as few natives as possible to keep World simple, 
but my need for good performance too might lead to a few mezzanines 
becoming natives.

+1 Brian, though we can write mezz wrappers using the PICK interface. 
Is there a reason they need to be native?

The important thing is to *not* use PICK for this, to use a different 
function instead. If you use PICK, it will make it more difficult 
for PICK to be useful in secure code that should have limited or 
no access to the reflectors. It slows down PICK too. That is why 
R3 uses REFLECT instead.

Or we could consider a more practical situation directly related 
to World: If you can compile blocks, it would make sense to use the 
reflection facilities to get access to metadata about the compiled 
blocks (especially since that would be something that you might want 
to secure, or since functions would need similar reflectors), but 
PICK already has a defined meaning for blocks.

- Added datatype, struct!
- Ctrl-A at the prompt toggle auto-brackets
- Ctrl-D at the prompt quits World
- Fixed networking like: open tcp://8080

Struct can be made in different ways:

	make struct! [[float f] none]
	make struct! [[f float] [1.0]]		; var name before type

And there is a STRUCT helper func:

	struct [float f] none

A real example under OS X:

timeval: make struct! [[
	slong sec
	sint32 usec
] none]

timezone: make struct! [[
	sint minuteswest
	sint dsttime
] none]

gettimeofday: make routine! [
	[typecheck]
	libc "gettimeofday" [
		tp [struct!] pointer
		tzp [struct!] pointer
	]
	sint
]

w> gettimeofday timeval timezone
== 0
w> timeval/sec
== 1323951188
w> timeval/usec
== 314011
w> timezone/minuteswest
== -60
w> timezone/dsttime    
== 0

Hi, I am interested into building an maintaining documentation for 
those programming languages based on REBOL.
It would be nice to have a DOCBASE for them.
What I search is:
- Someone ABLE to SETUP the Linux and the Wiki Software
- Someone which would share with me the cost of hosting.
Do you like the idea ?
Write me at [giuseppe-:-chillemi-:-eu]

There seem to be a problem with routines returning a handle. A library 
like MagickWand (part of ImageMagick) works this way. I'm not able 
to test it with MagickWand, as I'm not able to load that library 
for different reasons, and I don't wanna use too much time on it.


So I'm after another library, that has a routine, which returns a 
handle, so I can test. A library easily to get for OS X, Linux and 
Windows would be nice. Any suggestions?

I was able to load MagickWand under Linux, and it seems to work with 
uint32 datatypes to hold the handle (a C pointer). But it doens't 
work so well when using the handle! datatype for that. It would be 
nice, if it worked, I guess. It's probably some type casting problem.

actually, any library which returns a string could use a handle! 
as a return value instead.    the handle could be used to store the 
reference to the string as-is and give it to another routine which 
requires a string on input.

Yeah, I'm in a productive period.

To get a binary, click it, then click raw.

Ladislav, if you did try and mean having that code inside a function, 
then there was a bug, which will be fixed in next release.

w> c: context [a: 1 print a print (a)]
1
** Script error: a has no value
** Near: print (a)

I need to find a balance with World for how much should be tested 
for. I'm after good performance.

ok, that's a good argument to do something about it. Thanks!

About copying from a port, I get a zero, if the port is closed, but 
just under OS X and Linux. Windows version seems to hang in that 
situation. Networking code is open source, and you're welcome to 
suggest changes. I consider using a lib for networking instead of 
coding it all by hand.

at the moment i am just in holiday and have only limited access and 
not the infrastructure i am used too. maybe when i am back, i will 
have a look at the code.

Suggestion:


Some routines return a pointer to a structure, like LOCALTIME (from 
LIBC). The structure is struct tm and consists of 11 fields.


In World, we can define LOCALTIME to return a pointer to a handle!, 
but how should we get to all the data fields?


I suggest, TO should be used to copy data from a handle to a structure, 
like:

tm: struct [
	sint sec
	sint min
	sint hour
	sint mday
	...
] none

h: localtime time	; time is some variable holding seconds
to tm h	; This will copy the data (pointed to by h) to tm

Comments? Concerns?

As I understand localtime is not thread safe, the thread safe version 
locatime_r requires the address of a tm structure as an argument. 
(Though it returns the pointer to that same structure if the call 
is succesful.


In general, isn't it a better option for strucutures to be allocated 
in World rather than the called function?

Yes, it's probably a better idea to use routines, where you can allocate 
the structure in World, and handle the routine a pointer to it. But 
some routines does the other thing. In the case of localtime, it's 
a static buffer. Some routines in some libraries dynamic allocate 
memory, that the user can deallocate again with other routines. (Oldes 
pointed me to such a case in ImageMagick.)


If World should support calling such routines and be able to operate 
on the result, we need something like my suggestion, I think.

In the ImageMagick/MagickWand example, it was a string, and it's 
possible to get the string from a handle in World with:

	to string! handle

I thought of something similar with structs.

The to approach seems neat syntactically but is there a danger it 
would be slow with large data structures?

I don't think so, as it's a simple memcpy. The C code looks like 
this:

	if (rb->type == STRUCT_T) {
		if (rc->type == HANDLE_T) {
			Struct *U = (Struct *) rb->value.rc;

   memcpy (U->u, (char *) ((Handle *) rc->value.rc)->pointer, U->size);
		} else
			invalid_argument (W, rc);
	} else
		invalid_argument (W, rb);

Routines able to operate on structures, you define in World and give 
a pointer to to the routine, doesn't need this memcpy, and it'll 
work today.

To avoid the memcpy, the AS function could be used to redefine a 
handle to a struct. Like:

	as tm handle


, but then handle is redefined as a struct, and it now points to 
a mem area, the routine made. So this can't be deallocated by World, 
and the memory management has to deal with that situation. Not good 
in my view.

I found a way under OS X using AppleScript to launch World scripts 
from the Finder by dobble-click, and to start World the same way, 
if anybody is interested. It may be useful for REBOL and other languages 
as well. The method makes a world.app. Speak up, if you need it.

I test under WinXP with cmd and with cygwin bash terminal, and it 
works:

C:\world\src>.\world.exe -?
Loading Cortex... Done
usage: .\world.exe [options] [script]
...

I should get a Win7 soon, then I can test that.

http://issue.cc/r3/1892shows some circumstances that will trigger 
the problem, so it's a good model for building tests.

Andreas wrote this earlier, in response to your question about this:


Is there a way to figure out, what directory a command launches from, 
which will work across platforms?

Yes and no. There are platform-specific ways. This gist of it:

- Linux: readlink("/proc/self/exe")
- OSX: _NSGetExecutablePath
- Win32: GetModuleFileNameW

(We recently discussed this issue in relation to R3 as well.)

The argv method was fast to implement and works in my cases, so I 
went with that for now. It maybe will need to be replaced by something 
else. Putting cortex.w (and user.w later) into an install dir like 
Library/Application Support/world/ could be a way under OSX, and 
something similar on other platforms.

Thanks, Gregg. Some thoughts...


I create World, because I need the tool. So when I have the functionality 
planned, I've reached one of my goals, because I then have the tool, 
I need for my own future developments. For World to become a success 
for others to use also, it needs to be better in crucial ways than 
the tools, others use today. Therefore I also focus on making World 
slim (not bloated), stable and bug-free, very well defined, easily 
integratable and with good performance. There still is work to do 
in all these areas.

I have World calling COBOL code.  It'll be nice to get a full on 
64 bit core though.  Much mucking about with 32 bit libraries, compiling 
COBOL in a VBox etc.

Getting close to automating the Dictionary wiki pages as well.


Adding to the old topic of openeness.  OpenCOBOL is open source, 
but very few people fork it.  Roger is the principal developer, and 
we wait for his releases ... but we get to see the compiler, build 
it on our platforms.   John, I don't want to see World core open 
so I can change it, I'd like to see it open so I can read it, build 
to suit, learn things.  So, if it's not asking too much, put the 
core code up in a read-only repo and ignore the forks while you develop?

Lastly; fun and looking forward.

I have a Win7 (64-bit) install now and did some work yesterday on 
porting World. I ran into problems with building libffi, which World 
use. I will look into it.

Another try to close the topic on openness: So you expect to get 
man-years of work open-sourced for free? And this in a situation, 
where I get nothing from doing so? Please, be serious! World is not 
a hobby-project for me. I have invested a lot of time and money in 
this.

I have my hands full, and the World project do very good progress 
right now. I see no business benefit from making World open source 
at this point in time.

Case closed. :)

Geomol - it is just that you depreciate psychological factors. Ppl, 
especially with previous experience with RT, are very carefull here. 
In the end, you might just wonder, why noone is interested in such 
a model anymore. And in the end, it is just end result, which matters. 
You either get some community surrounding World, or you might wonder, 
why while your product is excellent, noone really cares anymore. 
Or - you might end up finding some nice niche e.g. embedded market, 
having lots of customers, etc. There is many possibilities, how your 
decision might influence something.


What I really don't understand is one thing - you sound too protective. 
You have full right to sound that way. But what escapes my mind is 
- "when I get nothing from doing so?".  And what do you get from 
actually not doing so? Also - do you expect any harm, caused to the 
business side of your project, by eventually open-sourcing?


As for me - I am used to commercial and licensed products. I just 
wanted to point out, that in the end, your attitude, might be contraproductive. 
If you keep product developed, ppl might feel safe, but ppl might 
also be carefull with their contribution to the project, because 
such kind of REBOL related project already failed big time. Not your 
falt, that's for sure, but the negative assumption is in the air 
nonentheless.

And so he wants support for free. :-)

Joke appart, I feel bad because we saw many projects failed because 
of the same reason.

A language implementation itself without real businnes application 
will get you nothing but some fame.
And so he wants support for free. :-)

I don't ask for your support.


I bring World to the awareness of you guys, because you might benefit 
some a REBOL like language in the current situation with REBOL. I 
could just have continued keeping my mouth shut and made the tool, 
I need, without others knowing about it.

benefit *from* a REBOL like ...

And I won't like World to become in a situation, where there are 
lots of bugs and no progress for years, and it's still close sourced. 
That won't happen.

I feel bad because we saw many projects failed because of the same 
reason.


Don't feel bad! A month ago, you didn't know about World. Now you 
do, and now you have an extra option. Where is no reason to feel 
bad.


Afaik projects like Boron are open source, and you may put it in 
the category of "failed projects". So open source doesn't equal success.

Have you thought of some "escrow" type arrangement to give people 
the confidence that World will not just disappear at some time in 
the future?


It doesn't have to be a full commercial arrangement but perhaps you 
could give a copy of the source to somebody that you trust with instructions 
on what circumstances it would be released (and how it should be 
released).

Peter, no, I haven't seen a reason for an "escrow" type arrangement 
yet. World has just been available for 3 weeks or so. And I feel, 
World isn't quite yet in a situation, where I would build larger 
projects with it. Close to version 1, maybe around going from alpha 
to beta release, it could be justified to make arrangements.

Pekr, sorry I don't comment on all you say. But look e.g. at a product 
like WebOS, which was mentioned here in this AltME world not long 
ago. It was developed to the current state as close source. Just 
recently HP announced it to go open source. I judge it to be an ok 
success for the people behind it, even if it was developed as close 
source. Open source doesn't equal success. And close source also 
doesn't equal success. But they may be related.

Geomol: "man-years of work open-sourced for free? And this in a situation, 
where I get nothing from doing so?"


You could get _a lot_ from doing so. Increased participation in general, 
with all the positive effects that can encompass. But whether you 
consider that worth the trade-offs necessary to reap those benefits 
is obviously your choice.

A lot of us would like Rebol and its derivatives to  be successful 
because success brings validation, and more importantly brings new 
people and development to Rebol.  We've all seen the closed source 
model fail, and specifically we have seen people leave Rebol or refuse 
to learn Rebol on this account.  Orca and Boron are not relevant 
because there was never a critical mass of people aware of it, and 
the GPL license put commercial developers here off.  Partial open 
source models like R3 would suggest that this model is also not attractive 
enough with a lack of investors to keep Carl working on the project. 
 Perhaps you do have some wonderful business plan that is going to 
work against all odds but the majority of us are not so optimistic. 
  We don't wish to see history keep repeating itself and so we are 
advising you to change your plan.   Think King Canute!

If you add functionality to Boron, it becomes a derivative work and 
subject to GPL restrictions.  And stop shouting. lol

Yes, and the distinction warrants some shouting after half a decade 
of Boron and ORCA development

Where and how do you handle a closed socket during receive (total 
== 0)

Under OS X, I get an empty binary, which is expected behaviour. Under 
WinXP, the process hangs here. The OS X and Linux version of World 
use standard BSD networking, the Windows version use MS networking, 
where an init is needed. You're welcome to suggest changes to the 
host specific sources. At this stage, I won't use a lot of time on 
Windows specific sources, as I don't use that platform very much.


I consider using cURL for networking, as that could give a lot of 
features fast. If I find, it adds too much to the overall size of 
World, it could be cut along the way by moving features from cURL 
to World sources.

In fact, it's libcurl, I consider, as cURL is a command line tool.

The last release was only a couple weeks ago.

Gregg - "only a couple weeks ago"? That pretty much sucks. Geomol 
HAS TO relalise, that noone is really intereted in old school models, 
or he is on his own ....

Gregg - not a sarcasm, just my point of view ...

I admit that I haven't made time to dig into World, but there is 
already a *lot* there from what I have seen. Personally, I am very 
interested. I am also very interested in leveraging community efforts 
in support of all the REBOL-like languages that are available.

Mchean - as for Geomol - I feel sorry for him - he is a victim of 
RT's treat of the community .... Geomol has clear view of how to 
put his project forward, but ppl don't seem to be interested - that's 
my impression at least ...

on the other hand I understand his concern about getting a return 
on his investment, and if world were

My impression (correct me if I'm wrong, Geomol) is that Geomol doesn't 
require our interest to get a return on his investment. He's already 
got a planned use for World in his own projects. Our interest and 
feedback is a bonus.

Pekr! Take a breath. When you're calm, then read your words here 
again. You're very off topic. Please move such rants to appropriate 
group. Please!

Then reality check:


This group was started 2 months ago. It's easy to go through it and 
look for my blue and yellow releases and notes. That's a lot of progress 
in 2 months. If you see it otherwise, then you're blind. The C sources 
of World has grown a lot in those two months, and it's quality work 
with few errors considering the amount.


You will most likely see the progress of World come in waves. I had 
worked intensely on it more than full time since before summer. Yes, 
more than full time (more than 8 hours a day, also week-ends), so 
that's a lot of man hours. The last month, I've done paid freelance 
work too. At the same time, for World I'm researching better networking 
(cURL), getting lib calls to work under Windows 64 using libffi and 
finishing the memory model, so circular references are coped with 
correctly. Why didn't I say so? Because I like to announce things, 
when it's done, instead of giving false hopes, but now I made an 
exception.


1) I'm not going to give my work away for free at this time. That's 
because I see no benefit in doing so.

2) World will not come in a situation like REBOL, with lots of errors 
for a long time and still closed source. If I wasn't able to continue 
work on World (to fix errors, make further progress or whatever), 
and if people relied on work already done, then I would open source 
it. As this isn't the current situation with World, this is no argument 
to open source it.


If you don't like my model, move on. Negative rants here are not 
productive.

First try on a World Map:
http://www.fys.ku.dk/~niclasen/world/World_Map.html

Made with FreeMind and exported as Flash.

Oh and also try "Auto Layout" under Format menu, it makes it nice, 
but make a copy before use it.

That's cool. Making a RoadMap diagram can be useful as well. So everyone 
can easily see what is next, what you are working on, what priorities 
are etc. of course if it helps you as well.
It is much more readable than a wiki.

Gregg wrote in group #Red: "World has similar goals I believe."


Yes. To clarify: There is World and there is World/Cortex. World 
is written in C and the Cortex extension is written in World. It's 
a design goal to have as little as possible in the C part, but because 
it's also a goal to have good performance, especially with math stuff, 
some functions are native (written in C), which could have been mezzanines 
(written in World), like ABS, COS, SIN, TAN (all small functions 
in C).


But large functions like PARSE and SORT and many other functions 
are part of the Cortex extension, so they're written in World and 
is therefore open source.


With the good support for dynamic loaded libraries, good performace 
with heavier functions can be achieved that way.


And then there is the REBOL extension (in the World file %rebol.w), 
which is there to hold further extensions and definitions needed 
to run REBOL scripts. Those are not in the Cortex extension, because 
I disagree with some of the REBOL design decisions, and because I 
would like the Cortex extension not to be too large.


For me, World and Cortex has the higher priority, the REBOL extension 
the lower priority, meaning I use more time on finishing World/Cortex 
for now.

Geomol - could you please explain, how wrapping libraries in World 
are done? Call me dumb, but I can't understand it from a website. 
OK, found more in PDF docs. I just wonder, if I always should use 
typecheck? Eg. I wanted following function to return 0 or 1. I tried 
with variou int types on the C side, and integer! datatype on the 
World side. I was receiving very large integer numbers as a result, 
untill I put [typecheck] in there. Maybe I just had incorrect argument 
type on the C side selected?

led: load/library %ledctrl.dll

led-is-power?: make routine! [
   [typecheck]
   led "LSN_IsPower" []
   uint integer!
]

World is 64 bit. If you don't specify typecheck, it assumes the return 
value to be a 64-bit integer, e.g. sint64 or uint64 in C and integer! 
in World. If the return value of the C library routine isn't a 64 
bit integer, you need to specify typecheck to get it converted from 
8, 16 or 32 bit to 64 bit. If the return value of the C library routine 
is 64 bit, typecheck isn't necessary, but can still be used, and 
it will slow the routine call a bit.

Well, a trade-off :-) It is about to get the most expected result 
preferably, vs your mentioned speed :-)

What about a compiler option to turn on and off the typecheck? More 
complicated, but we would have a chance to run in default (typecheck) 
and then test it without typecheck by changing just one option.

After I wrote the above, I considered it some more. Right now, most 
people will probably run into this problem, because most libraries 
return 32 bit values. But in the future, and with what World is very 
much designed for, namely science, 64 bit values will be used. So 
I'm not gonna change it.


Problem with compiler option is, that we then have two versions of 
World, and programs made for one won't run on the other.


Maybe better to make a World wrapper function with it's own routine 
definition dialect!?

Like ROUTINE is a helper function calling MAKE ROUTINE!, a ROUTINE32 
(or something) can be made to have typecheck as default.

But we should set the option in the (on top of) source code, not 
in runtime, so it should not be a problem having 2 versions of World. 
We can say "compile this source with "typecheck" options". No?

Continuing from #Not REBOL. A MORE? function could look like:

more?: make function! [[
	"True if a series isn't empty."
	series [series! none!]
][
	if none! = type? series [
		return false
	]
	0 < length? series
]]

Could also be made easier to read maybe, but slower:

more?: make function! [[
	"True if a series isn't empty."
	series [series! none!]
][
	not any [none? series tail? series]
]]

And to make is less confusing, the function description should probably 
read "True if a series isn't at its tail."

Working on the next release of World, I implemented coercion for 
words and datatypes, so things like block! = 'block! returns true. 
This lead to a much simpler implementation of SWITCH, which is a 
mezzanine in World, so it looks like I'm on the right track.

Another point talking against open sourcing at this time. World is 
not completely set in stone yet, I admit that. When I make design 
changes like this coercion between datatypes and words, it affect 
all other code, which can fast become a mess, if you have 10 people 
working on it. When it's completely set in stone, it's another situation.