World: r3wp

Not much, no. But that also means I haven't yet changed my mind and 
still believe we need one :)

("Domain specific dialect" is just another label for "yet another 
purpose-built language".)

:) I see it as:


I have compiled function, I would like to change -> I make changes 
-> I want the new version to run


With compile reset, that can be cone at any point between first run 
and second. Doing it with COMPILE, it needs to be done right before 
2nd run. But isn't that good enough? Or can we come up with situations, 
where it isn't?

cone = done

Well, just remember the example we had.

This:

c: copy []
f: func [x] [x]
append c [f 10 20]
;; recompiling c here, do c would == 20
f: func [x y] [x * y]
;; recompiling c here, do c would == 200

I have a compiled block which I need to change. I make changes. In 
some cases, compilation state is automatically reset (INSERT), in 
other cases it is not.

If I, as a writer of some code-modifying helper function want to 
also provide the behaviour of INSERT, I can't.

Doing it with compile, the recompilation is forced to happen right 
after the modification.

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.

Yeah, sounds perfect.

as a refinement, I mean

ok, consider it done

Nice, but no hurry :)

It's maybe 5 lines of C code. :)

Sure :)

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

World should accept REBOL [] as header to run R2, R3 scripts through 
it without editing these.


World can already run scripts without header, so it's possible to 
run REBOL scripts without editing them by first defining REBOL as:

	REBOL: none

or something similar.

You can write this and it will work in R2 and R3, because the stuff 
before the header will be ignored:

world []
rebol: none
rebol []

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.

Any language that can do aliasing between the string and binary types, 
rather than requiring conversion, won't work.

Fortunately, it's not too late to fix this in World :)

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

New release at https://github.com/Geomol/World

- Added /reset to COMPILE
- Implemented error system. Error system include:
	system/standard/error
	system/standard/errors
	system/state/last-error
	Better error reporting
- Added sys-utils/print-last-error

Uploaded new version with quick fix, in case someone downloaded latest 
release.

New blog "One week of open alpha" at http://world-lang.org

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.

And 5 visitors from Brazil today. The Lua guys maybe? :)

Just tell when you want to be noted on OSNews, there might be some 
more significant traffic :-)

John;  I want in.  Do you need assistance writing docs?  Please. 
 :)


See http://my.opera.com/btiffin/blog/2011/12/09/rave-post-world-programming-language

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!]

About writing docs, I've started the dictionary.

See: https://github.com/Geomol/World/wiki

Also "Difference from REBOL" has almost nothing yet. I mostly code 
and not writing docs at this point.

re: automatic closing of brackets

sqlab, I added it to issues at
https://github.com/Geomol/World/issues
so it isn't forgotten.

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

ahh, yes, thanks

Maybe a control char?

Like ctrl-a

that's good

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?