AltME groups: search

R2 and R3 are not bundled, so when starting them, is the same as 
other unixes.

Graham from Red - "Karl has failed to engage with the Rebol community 
as far as I can see."


Personally, I have found Karl very approachable and responsive on 
the Boron MIL.

My first experience with LLVM.


I tried to compile World with llvm-g++ under OS X. When compiling 
with gcc, I normally use -O2 option. I compared performance with 
the Mandelbrot test. Between compilations, I deleted all .o files 
and executable, so new compile started from scratch.

Compiling with llvm-g++:

With -O2 option, file size grow to 105% and execution time extend 
to 105% (slower).

With -O3 option, file size grow to 106% and execution time is the 
same.

With -O4 option (also Link Time Optimization), file size extend to 
122% and execution time grow to 107% (slower).


Then I tried to compile with gcc and -O3 option. Now file size grow 
to 105% and execution time shortened to 85% (faster).

Has anyone had similar experience with LLVM?

(And I thought, LLVM was much better, but maybe I do something wrong 
or miss some option!?)

There is a /usr/bin/llvm-g++ command under OS X. The man page say:
llvm-gcc uses gcc front-end and gcc's command line interface.

So maybe it isn't "clang"!? I'm not sure. It's my first real experience 
with LLVM.

Because I had no experience with LLVM, because I started World dev. 
on older MacBook, because LLVM was many MB download, because I wasn't 
sure, I could get LLVM on Windows and Linux easily.

And I notice, at least one of my tests don't finish with the LLVM 
and clang versions, which is disturbing. :/

So it seems, I made a good choise with gcc, because 1) it was easy 
to make World compile with LLVM and clang (if I choose that path 
now) and 2) it seems, some code doesn't work as intended with LLVM 
and clang.

gcc -O3 option
size: 362304
time: 0:00:00.579858


It seems, gcc beat LLVM and clang here on performance, if I use -O3 
option.

You might also look into LuaJIT, as it is supposedly faster than 
most VMs, and smaller too.

Thanks, Brian (LuaJIT). Could be later, when World is stable and 
the hunt for performance really starts.

Yeah, I've had it in the back of my head all the way with World. 
And then I just noticed, it was installed on this Mac.

So it's more about portability and maybe better error messages?

For typical end-users, clang is about fast compilation and good error 
diagnostics (at the moment).

LLVM can also be used as a set of compilation libraries, yes. And 
you can implement a JIT that way, yes.

When compiling blocks, each block instance has its own compiled code. 
And changing at one instance doesn't reset compilation for another 
(which would else add overhead). So:

w> s: [1]
== [1]
w> do s
== 1
w> t: tail s
== []
w> insert t 2
== [2]
w> do t
== 2
w> s
== [1 2]
w> do s
== 1


APPEND doesn't change at the block instance, so APPEND doesn't reset 
compilation.

Block compiled state will be reset by functions such as INSERT and 
REMOVE. And if the block is set to another location (NEXT/BACK with 
call-by-word for example).

And the WITH function would then be:

with: func [obj body] [do compile/at body obj]

That code leads to an error, if c is compiled before f is redefined. 
The error system isn't very good atm., and I'll probably work on 
that next.


I need more experience with World and more examples to say, if a 
compile reset is a good idea.

Correct. World is not designed to cope with such cases, where words 
changes from functions taking arguments to passive non-function values, 
or if number of arguments changes to a function. To change the behaviour 
of the c block, a compile is needed. So question is, if that compile 
should be executed by a COMPILE call, or if the compile state of 
the block could be reset, and in this case, it would be compiled, 
the next time, it was executed with DO.

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

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

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

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.

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?

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.

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.

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

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

Handles are made with:

	handle: make handle! none


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

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.

my only suggestion for structures...  make it so the semantics are 
exactly the same as C.    
i.e. you take a C header file, and do:

replace/all header-string "{" "["  
replace/all header-string "}" "]"  
replace/all header-string "char *" "pointer"
...


and basically you've got your simplest World version of the spec 
 ;-)

btw, regarding the struct interface, making as close to C as possible 
allows you to support any binary api and will allow you support the 
more complex twists.


things like arrays of pointers and pointers to arrays of pointers, 
etc... these things are often overlooked (like they where in R2) 
and create major headaches or downright project blocking in some 
cases.

It comes as surprise you new REBOL inspired new language. It is inevitable 
that things like TOPAZ and RED are created after the long absence 
of CARL. There is a stong need from the market and the market is 
US programmers which cannot wait any longer.

First of all a question: which will be the difference and improvements 
comparing to REBOL ?

Now will come my considerations about Licensing and development.

Difference: Based on a virtual machine, that source can compile to. 
Many different design decisions, but many of those can be redone 
to be REBOL compatible by defining words. This is what %rebol.w is 
for.


Improvements: Faster in many cases because of the VM. I try to make 
it better in all those areas, where I find REBOL not good enough. 
Datatypes like complex! and more in the future. I also try to cut 
into the bone and only create that at the core, that is really needed. 
I see that as an improvement.

You are the project LEADER and you are the creator of this wonderful 
project. You have a VISION, a destination.

Back in time, when CARL was developing REBOL3 he created a roadmap 
explaining us what would be the structure of the language, its modules 
and how they cooperate.

This inspired suggestions from the community, changes in the roadmap 
but more preciosuly it created expectation, commitment and willingnes 
to cooperate.

You are a programmer but you should be an inspirator and entrepreneur. 
Like a programmer you first released the alpha version before selling 
the idea ! :-) You came out from your BatCave after 2 years of silence 
telling us "look here what I have created". This is good as it proves 
you deliver other than promising. 


Somewhere, in the road to version 1.0 you will need help. It belongs 
to you teling us when you will have clear in your mind the whole 
project. Then, please SHARE THE VISION and ask for cooperation and 
involvement of other programmers.


You are not alone. There is lot of skilled people here. They will 
be happy to give their input to you.

This will avoid being World as a one man project and will put the 
basis for collaboration.

Now 3 years have passed since then and no upgrade took place.

I am still with the same idea: I believe that documentation and communication 
is everything. If someone has the willingnes to setup a linux system 
with the proper wiki software I am ready to DONATE MONEY for hosting.

It will be the basis for World Documentation. You are a programmer 
and you know how much important is this aspect. I am sure we will 
find someone which could create the official World Web Site.

Somewhere, in the road to version 1.0 you will need help. It belongs 
to you teling us when you will have clear in your mind the whole 
project. Then, please SHARE THE VISION and ask for cooperation and 
involvement of other programmers.


It's pretty clear in my mind, what version 1 is about. When I started, 
I wrote down the natives, which are really necessary to create a 
REBOL like language on a virtual machine. All the other functions 
should be able to be produced from this set of natives. I listed 
about 100. World currently has 83 natives implemented. Maybe some 
of them will get some more refinements before version 1, but you 
could say, the natives are 80% done.


You may think of this project as the Wildman project (see that group), 
not on native hardware, but on a virtual machine.

And I listed close to 50 datatypes. World currently operate with 
41 datatypes.

As things are clear to you I suggest to spend a couple of days creating 
the White Paper, The structure of the programming language and the 
ROADMAP. You may think that you will loose 2 days but I am sure you 
will gain lot more.

Personally I have a great private project in mind and a skilled developer 
for it.

The project is blocked because he want to make money now and someone 
who finances the project.

I told him that First of all we must show a concept application. 
This will sell the application itself and we start fundraising.

Until something usable won't be ready I will not be able to sell 
the idea. He refuses this view and we are blocked.


As you are writing a programming language you are in a worst scenarion 
than us.

You need to have a commercial class programming language ready for 
the mass to sell it and this is not the case.

Commercial Class mean: IDE, Solution for interfacing SQL Databases, 
Solutions for communicating, Solutions for interfacing to other projects.

This is too much for one man to accomplish. You need to live, you 
need money and World is your Hobby project (Isn't it ?)


Open sourcing and delegating is the solution for creating a mature 
project: you seth the path, the specifications, the rules, the others 
will help.


I won't give a Penny and Time to REBOL Tech. because its source is 
closed and this model is wasting my precious life waiting for Carl 
to resurrect.

Open Sourcing solves this problem. Don't you think that if REBOL 
was open sourced many developers would have inproved it in Carls 
absence ? Do you think that someone, like an university will donate 
money to a private held project ? I don't think so.


When we (you) will have a mature project and you will be able to 
show to the world the advantages of your solutions money will come.

Think of SQL lite. There is a consortium behind it. Other open source 
solutions have the same consortiums behind them.


There are many ways to raise money: You can produce vertical solutions 
for your baby.You can give consulency to companies and other institutions, 
you can create products with World. These are few that comes into 
my mind.

I repeat: I am ready to cooperate once you will chose an open source 
 licence. I am ready to give money and TIME. Carl didn't seem to 
apreciate. Hope you will.

You list of 5 things:


1) Not sure, I wanna do that. It takes time away from me finishing 
version 1.
2) I have set the goals for ver. 1.
3) No (see Q&A)

4) "Ask for cooperation" - World would need schemes for the different 
protocols. I will welcome others work in that area. Me (and most 
likely others too) would like to see World on more platforms than 
the current 3. Host kit is open source. I will welcome ports to other 
platforms. (That's what I can think of for now, but I'll keep it 
in mind.)

5) It's faster for me to write the documentation than building a 
comm/doc infrastructure. I'll write the World 'bible'. Work has started, 
and I'll use more time on it, when version 1 is a bit closer.

Point 3 is important for me and many others. If the project is open 
sourced I will be ready to donate. No waste of money donating to 
a private held company.

There are many ways to raise money:
Yes, I know, and I plan to do something about it. :)

Personal I discourage you from closing the part/all of the source. 

Having learnt from REBOL Tech., the language itself will not sell 
and closing the source closes the opportunity of cooperation.

An open source give you a boost into the develpment and believe me: 
you stongly need cooperation.
However I am not GOD and I cannot force you into making anything.

I could only share my opinions and give you time to thing on them.

When I started "Countdown: 10" 2 weeks ago, the C sources were close 
to 23'000 lines. Atm. World is 24'372 lines and growing. The project 
is moving forward fast.

Geomol: don't make the mistakes of CARL. 

You strongly need developers and adoption from the open source community. 
We are now in the right momentum. Please belive me: you have more 
adavantages than disvantages and you won't loose the contro of your 
baby.

I am not religius to my I will light a Candle in any case a GOD exists 
and could help you :-)

Well, good luck but as in the tech news .. HP paid $1.2bn for WebOS 
and are now open sourcing it

I just thought of another way to help. Make a list of REBOL functions 
missing. There are many missing from %rebol.w

And there already is a wiki started with differences from REBOL at:
https://github.com/Geomol/World/wiki/Differences-from-REBOL

I don't have time to write it. But everybody can write in that wiki.

Now, go try World out. And remember to have fun!

I have my hands full now, and I make really good progress. When we're 
around version 1 (or if I don't make more progress), it would make 
much more sense to think about open source. And as I've said, it 
may also make really good sense to open source parts along the way. 
I have considered library.c and library.h, which holds the C code 
for library! and routine!. That almost makes sense now. When I've 
implemented error! correctly (working on it), it really makes sense. 
You have only been able to run World for 5 days. Patience! :)

Disadvantages: me loosing focus and loosing time, when having to 
answer all kinds of questions and approve new developments. The horror 
of World being fragmented to 100 versions, where none of them are 
compatible. You wouldn't like that! I make sure, that doesn't happen.


You need surplus of time and resources to open source things like 
this, if you wanna be sure, it doesn't run off rails. Look at how 
many ways, you can do any single thing in Linux. It's way too fragmented 
in most areas.

And it may make sense to share code in some areas.

It's actually a lot like Linux. Every distro has something you need, 
but none of them has everything you need. If I want to build the 
Russian Syllable website, I can only use R3. If I need system integration 
and speed, I can only use Red. If I need to write web apps, only 
Topaz targets that. If I need open source, I can only use half of 
them. If I need dynamic binding, I can only use the interpreters. 
If I need infix operators, I can't use Boron, although I could use 
its predecessor. Etcetera ad nauseum

But doesn't "trying to do everything" mean, it becomes bloated and 
complex?

REBOL started out as a Swiss army knife, and was it bloated and complex?

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

:) 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?

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.

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

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

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.

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? :)

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

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

Geomol; by text!  I was referring to the old junk! argument.  It's 
not really junk!, it's human text, encoded as humans see fit, gibberish 
or deep meaning symbolic.  Naming things is hard.  ;)   KWATZ! is 
ok...but I don't get the 'ahhh, that's optimal in meaning and depth' 
from it - and I lean Buddhist and did see the Zen references. But 
kwatz is still sinking in, if it's going to (and perhaps that is 
the best kind of deep meaning).

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.

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.

This is first release with struct!, so not all features are there, 
and it needs further testing.

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

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.

World is free to use and can be found at https://github.com/Geomol/World

Why don't you try those things out yourselves? I would like to comment, 
but I feel, you get most from it by trying it.

For minimum install, just pick one of the world_* files and cortex.w

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.

About bit operations, I looked at SHIFT. R2 got it at some point, 
but there is no ROTATE. Wouldn't that be useful too? I think about 
graphics operations and maybe other areas.

if you open and connect and the peer closes, this happens too

- Reimplemented bitset! as binary
- Added native function: COMPLEMENT
- Added native function: ROTATE
- Added native function: SHIFT
- Added << and >> operators to cortex.w
- Added hex form for characters, ^(00) - ^(FF)
- Added REFORM to rebol.w
- Added DETAB to rebol.w
- Added ENTAB to rebol.w
- New test
- Bugfixes

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.

SHIFT and ROTATE can only operate on 64-bit integers for now. We 
have to see, if operating on binary! and maybe other datatypes is 
needed.

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?

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.