World: r3wp

Ok. I understand that view. We can reset compiled state now with:

next 'c back 'c
or
c: back next c

Ok.

Something similar for functions?

w> f: func [v][v + 1]
w> f 1
== 2
w> compiled? :f
== true
w> f: make function! reduce [pick :f 1 pick :f 2]
w> compiled? :f
== false

Hmm, that creates a new function, though, doesn't it?

Are compiled references to values or to names in contexts?

(Well, I can just try that myself :)

And I get a malloc error, when doing that a couple of times. Yes, 
crash. I'll hunt that down.

(Well, I can't, as I get a crash immediately :)

:)

World suxx!

Nope :)

I agree with the notion that those particular examples illustrate 
bad programming practice. But re-binding words to different values 
(functions) is possible in World, so I believe it should cope nicely 
with that situation.

I don't think you should keep the compiled block in memory when DO 
is used.

Compiled blocks (including the nested ones) should be linked with 
functions only (whe functions are created).

I don't think it would be a real perf problem  because DO is not 
used that much to execute standard code in an app.
Just my opinion though.

A possibility, but I think that would on the one hand make implementation 
more complex, and on the other would just introduce more semantic 
corner cases.

Such as a block being shared by a function and a global word.

I agree, the compilation of a function would be more complex (because 
of the nested blocks)

Yes, because compiled code would become an attribute of a function, 
instead of just dangling off a block.

Andreas in R3, nested blocks inside a function can't be shared with 
global words.
The body of a function is deep copied before compilation.

This is the #World channel, though :)

np

Just to say that the R3 model of a function is better than R2 in 
that case

Yes, sorry for the snark.

Block sharing can also occur through code blocks passed as parameters, 
though.

t: [...]
f: func [c t f] [either c t f]
f ... t ...

yead but it"s generaly not the blocks which are executed (data only)

But you could of course "localise" those blocks (or at least their 
compiled code) upon function compilation.

that's my point ;-)

Mine as well :) That's certainly one of the "weird semantic corner 
cases" I'm talking about :)

But keeping a "compiled block pool" attached to a function is certainly 
a very interesting idea.

My focus is to get the simple cases to work first. But interesting 
ideas, what I may take up later. :)

what = that

Topic: routine! and handle!

At present without typecheck, World think string! when seeing a pointer 
in a routine spec. And the World types are just seen as comments. 
With typecheck on, the Would types are considered, and only certain 
combinations of World types and libffi (C) types makes sense, like 
string! and binary! for pointer.


I'm about to implement handle!, and maybe handle! should be the default 
for pointer. And then it's required to specify typecheck, if string! 
or binary! want to be used with pointer.

I get a malloc error under OS X (64-bit), when redefining a function 
with code like:

f: make function! reduce [pick :f 1 pick :f 2]


I didn't find the error, so I tried it under WinXP (32-bit), and 
the error isn't there!? Any suggestions?

Use Valgrind to debug memory allocation issues: http://valgrind.org

Found the error with Valgrind, thanks Doc!

Glad it helped you, it's a great tool.

does read work with url, im getting an error with: read http://www.rebol.com

** Error: invalid argument: http://www.rebol.com
** Near: read url

No, not yet. The HTTP scheme isn't made. Only basic TCP networking 
is done for now.

More about routines.

The next release of World will introduce the handle! datatype. It's 
used to hold pointers, which are normally handled by structs and 
integers in R2.

If we take the sqlite3_open routine as an example:
http://www.sqlite.org/c3ref/open.html


The routine takes a pointer to a pointer as its 2nd argument, and 
this is the db handle updated by the routine. The handle is again 
used in sqlite3_close:
http://www.sqlite.org/c3ref/close.html


, but this time, it's the handle itself as the argument, not its 
address.


In World, using routines should be as easy as possible, and the consequence 
is, the definition of the routine gets some complexity. World uses 
libffi as the underlying motor to carry out the calls. libffi defines 
15 datatypes, where World uses 14 of them (not longdouble). Beside 
"pointer", I will introduce "pointer-adr", and routines like sqlite3_open 
can use that. Then the address of the handle will be given as an 
argument. Routines like sqlite3_close should just use "pointer", 
and World will internally typecast the handle to an integer (32- 
or 64-bit depending on version), and give that to the routine.

The routines could then be defined as:

sqlite3-open: make routine! [
	[typecheck]
	sqlite "sqlite3_open" [
		filename [string!] pointer
		ppDb [handle!] pointer-adr
	]
	sint
]

sqlite3-close: make routine! [
	[typecheck]
	sqlite "sqlite3_close" [
		ppDb [handle!] pointer
	]
	sint
]

looks good

clear enough.

Notice that the world-datatype after sint (the return type) will 
be optional too, even when typecheck is on. The argument names are 
optional too. The World types of the arguments are not optional, 
if typecheck is on, else they're just treated as comments and can 
be left out, but not their blocks, as those are used to count no. 
of arguments.


Btw. argument types in functions and operators are treated as comments 
too in World. I plan to introduce [typecheck] special attribute for 
those too.

Naming pointer-adr, I considered also *pointer, but found it too 
C-like and 'pointer, so didn't quite like the syntax, even if it 
lead the thought to call-by-word.

I also considered leaving pointer-adr out, and let the call define, 
how the routine should be called. Something like:

h: make handle! none
sqlite3-open "test.db" 'h		; notice the lit-word!


But this will slow calling routines down, because the call will have 
to look h up.

So I ended with: pointer-adr

The reason, I put the world-types of the arguments into blocks is, 
that in the future, polymorphism could be introduced for routines. 
So routines could be called with different types of arguments, and 
internal conversion will then happen. This is for the future. Second 
reason is, that argument names are optional, so parsing the routine 
spec needs some way to figure out, what is name and what is type.