World: r3wp

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.

Today World types in routines are considered, when typecheck is on, 
and conversion is then carried out between the World type and the 
C type for the arguments, and the C type and the World type for the 
result. Examples with "clock" from libc under OS X:


w> clock: make routine! [libc "clock" sint64]	; The simple version
w> clock
== 79551135

w> clock: make routine! [[typecheck ]libc "clock" sint64 real!]		; 
Result as real!
w> clock
== 79576741.0

w> clock: make routine! [[typecheck ]libc "clock" sint64 complex!]	; 
Result as complex!
w> clock
== 79621776+0i

just brainstorming... don't you want to use something like datatype 
notation for world's types as well?

World types as exclamation mark (!) in the end. C types don't. Do 
I misunderstand the question?

as -> has

In the above, sint64 is a C type, real! is a World type.

(Shouldn't I had said: "World types *have*", because it's plural?)

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

- Added handle! datatype
- Gave routines an overhaul
- Added AS native to change type of series without copying.
- Fixed crash with function redefinition to reset compile state

- Updated cortex_alpha.pdf, the section about routine!, and added 
handle! and AS.

Regarding AS, the REBOL AS-BINARY and AS-STRING can be achieved with:

as binary! ...
as string! ...

But it's also possible to do:

w> as issue! "abc"
== #abc
w> as paren! [a b c]
== (a b c)
w> as tag! "title"
== <title>

and many other combinations.

Performance wise, it's of course faster to use AS than e.g. TO:

w> dt [loop 1000000 [to binary! "abc"]]
== 0:00:00.420204
w> dt [loop 1000000 [as binary! "abc"]]
== 0:00:00.133765

People trying out the routine! implementation, please speak up, if 
you find anything strange, so I can fix it, while it's fresh in memory.

Handles are made with:

	handle: make handle! none


Some routines might return handles, and those are not necessary to 
made yourself.

wow a lot of activity here since I last checked...

one little note about handle! is that it should be immutable and 
cannot be created from within the interpreter beyond defining a null 
pointer, as above.   value holding handles should only be returned 
from a routine.


the idea here is that you should not be able to mangle handles, for 
a variety of reasons.

its tempting to be able to do:  

i: to integer! my-handle
i : i + 1
some-routine i


but its very bad practice (from within a scripting language) IMHO 
since it allows all manner of crashes to occur, not to speak of security 
issues this can open up as well.

Yes. I made it possible to view the content of a handle with MOLD. 
That should be ok.

peeking is ok (often neccessary for debugging), as long as you can't 
change it  :-)

Right.

btw VERY happy you kept the lib-ffi type names within your routine! 
implementation  :-)

Having all the libffi C types should cover all possible libraries. 
(I guess.)

struct! isn't there yet though. I think, structures are needed for 
some routines? Else it's a hard job juggling with binaries.