World: r3wp

volker: basically a block of blocks :)

you cannot address the block; you can only get the blocks matching 
a pattern, and publish other blocks.

having a defined set of operations, you end up with a system that 
does not have the usual problems of parallel processing.

i don't think there's any need to have this natively, the native 
code just needs to ensure that you cannot screw things up by mistake 
:)

Maybe determinism means here: Some things must happen in order, for 
example writing to a log? So that different runs produce the same 
result?

Which this server-thing should do.

if you want to log events a and b, and they can happen with watever 
order, you want to log them in whatever order. if they can only happen 
in a given order, there is no parallelism.

Just thinking loud about tuple-space: Could xpath and threads go 
hand in hand?

But a parralel processed image looks the same all the time, or the 
processing of a big matrix. Still deterministic. Whatever happens 
inside the box.

Sun blesses Java phone - http://www.deviceforge.com/news/NS6109398413.html
.... java penetration is the reason why I asked if rebol-4-Java would 
make sense :-)

Anton, Yes I read the last line and I agree with it. The question 
is what should Rebol do to takle the concept of concurrency and do 
it properly, like Erlang, Termite, or Mozart/Oz.

Volker, I was ilustrating that just using the function TASK is not 
enough. You need a way to prune non-determinism. The example I posted 
ilustrate the problem. Your example has the same problem than mine, 
because TASK it doesn't introduce an order of execution. The fact 
that your example is coded sequentially doesn't mean that the computation 
will be carried in that order and produce the same result always. 
Your example only introduces notatation to pass messages between 
tasks.

Gabriele, using threading only computation  with no overlaps is limiting 
concurrency to one problem space. If that is the case then why add 
TASKs to Rebol, when we have already processes.  The only advantage 
will be memory use, and context switching time, but not extra gains.

Your example looked like locking to me, i saw two threads accessing 
a shared resource. Semms i missed the point.

processes are heavyweight and we don't have fast ipc across rebol 
processes.

imho the only reason for task! is because it is lightweight and because 
communication is very fast.

Complete determinism makes no sense with parallel IMHO, if you dont 
allow for some random things, you basically can drop the whole parallel 
thing.

Reminds me to VLIW, which made great promises. Then it turned out 
to be very tricky to precalculate the actions of ~10 ALUs.

So i think a coordination language needs more features, so its similar 
to a general purpose language. While you said above " a coordination 
language need not specify anything more than coordination."

Coordination must allow for some random schedule and be able to "route" 
based on the runtime-situation IMHO.

Coordination can help prune non-determinism, coordination is different 
than communication between threads, lazy evaluation and continuations 
couuld help here, using a declarative approach to the whole computation 
can help get rid off non-determinism. The basic ideas are found in 
the CTM book.

Gabriele, Do you have documents that delienate how the communications 
between tasks will happen?

ideas == principles

Jaime, not yet, but most likely each task will have a message port.

Volker, Do you really mean this "Complete determinism makes no sense 
with parallel IMHO", the idea of paralellism is to  be able to perform 
any computation  done by a sequential machine faster, a random paralell 
machine may have some uses, but none of the mainstraem ;-)

huh, cool discussion - not that I would understand most of the things 
:-) Don't you want Pierre to join us to help you find the correct 
philosophy? :-)

Getting Real Work Shop - 

https://workshop.37signals.com/

   Getting Real is about getting the interface right before you get 
   the software wrong. It's about less software, making change inexpensive 
   and constant iteration. Less paper, more work. Less talk, more walk. 
   Getting Real is about deliverin

What sense makes perfect determinism with multiple physical inputs 
, like sensors or people entering data? The entries and their order 
is slightly off anyway.

It must be determined that things are processed, but not where and 
when.

Has anyone made rebol software to fill out forms scanned from paper?

Whoops. Wrong group, but I'll not post again.

that would be reading with OCR?

No. Just scanned in as graphic file.

I also want to save the data so I can edit it and fill out the form 
again later.

huh?

that sounds a little ineffective?

I am thinking the data would be in a layer above the graphic form. 
Click in the right spots, fill in the right data, print out the completed 
form, then save the data with the form  for later use. Something 
real simpe anyone can use.

There are still companies using paper forms, and I have to fill them 
out by hand. No fun.

that sounds like XForms to me

openoffice 2.0 has a free XForms implementation. it can save PDF's 
like this so you can edit them like a real form. I haven't worked 
with it deeply, but I think you can save data from them in a database.

edit them like a real form
 => edit them like a real form in adobe reader

OK, thanks. I''ll check it out.

An image can be used as a backdrop to a layout.  Stick some fields 
on top and you're done.

or just make your own form

What sense makes perfect determinism with multiple physical inputs 
, like sensors or people entering data? The entries and their order 
is slightly off anyway

 You can still have deterministic computation even in such situation. 
 We do have that today with any multitasking OS. Or would you like 
 to have your programs to produce any random result?

Volker, The fact that events can arrive at any given time doesn't 
mean that you can not have deterministic paralellel computation.

No, i want my program to have s much determinism as needed. I call 
"perfect determinism" when i know "this stuff is done on cpu3, then 
the other thing a bit later on cpu4". That is perfectly repeatable. 
But that is not what i need. "this stuff is done on the next free 
cpu" is enough. But to do that, i need a language which can determine 
what this next free cpu is. And for that i need a general purpose 
language (counting cpus, acountig used time, priorities etc). While 
you said general purpose is not needed for a coordination language. 
But maybe i miss simething, maybe coordination means something different?

I never said that you need or not a general purpose language. As 
matter of fact, I don't think being general purpose has anything 
to do with concurrency. What I understand is than any new features 
that add concurrency  to  a language should do so in a manner that 
avoid non-deterministic results. Some languages have already accomplished 
 this goal, usually avoiding  threads. Threads operate more at  the 
OS level than the language one. So I hope R3 bring us good concurrency 
features, that ensure that our programs are deterministic, otherwise 
we could be shipping programs that at first glancelook correct and 
 will work, but could  fail later in production as the paper points 
out.

I understood that the should be a coordination language coordinating 
stuff written in general purpose language. instead of putting coordination 
features in those languages.

And Erlang seems to work good, based on general purpose with threads 
and messages.