World: r3wp

Right, and we have to figure out, if we really need that.

I am a strong believer that in cases such as this, whatever is helpful 
internally should also be exposed at the user-level.

My personal view is, that it's sort of bad programming practise to 
change number of arguments to a function in the middle of a program, 
or to change a work from meaning a function or operator to meaning 
e.g. a number.


But I think, it's possible to cope with such strange situations, 
because we have COMPILE.

I.e. as INSERT is able to _reset_ compiled state, so should be the 
user.

(Then a mezzanine APPEND could just reset compiled state, and would 
behave identical to INSERT in that aspect.)

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.