world as value

[Adrian Hey]

On Wed 23 Jun, Fergus Henderson wrote: 
> >  First question   - What time should the computer output?
> >  Answer           - The time of the "me ask computer" event I.E. 2:00 pm
> >  Second quesition - When does it do this?
> >  Answer           - When the FPGA has been placed and routed, lets say 4:15
> > 
> > I think most people would regard this as "intolerable behaviour". What it
> > should do is suspend the placing and routing of the FPGA to for moment, in
> > order to respond, telling me the time is 2:00 pm at 2:00 pm, or very shortly
> > thereafter. But it simply can't do this if it's running a program expressed > > as a function mapping input events to output events. This would be
> > non-deterministic.
> 
> You can express this as a function mapping input events to output events.

Whoa there! Now it's you who's cheating. You can implement the program by
invoking non-deterministic pseudo functions (I.E. Haskell IO Monad or Clean
*World). I don't think that's the same as expressing it. As far as languages
which are supposed to be "purely functional" are concerned, I think these are
a hack. A necessary hack perhaps, but still a hack.

> But you can express forkIO in Haskell too, using the techniques
> described in the papers I previously cited to handle the required
> nondeterminism.

Have you told Simon this?

I've had a quick look at your program, you say forkIO is the problem, I'll
take your word for that. I have a much harder time understanding how
merge_requests is ever going to work reliably in a causal system (as any real
system must be).

Is this a model program which can only run in causality violating pseudo time,
or a real program? If it's the former, I can see how this might have uses for
pseudo time simulation purposes, but I need a real causal program which will
run in good old fashioned real time without getting blocked by trying to look
at the future. If you do such things it will only get un-blocked when the
future has become the present.

> The modelling technique described above uses only one language,
> and describes all of the system except the bits which are deliberately
> unspecified, which are treated as input data to `main'.

Earlier I said I wanted to reason about non-deterministic programs, not just
implement them. Perhaps I should turn this round by saying that I want to
implement non-deterministic programs, not just model them :-)
(and ideally, I want to do so in a language which hasn't been hacked.)
 
> If your virtual machine is completely specifies all details, then it
> won't be sufficiently expressive -- you won't be able to model the
> concurrency that occurs on real machines.

It doesn't have to specify all the details. I'm looking for constrained
non-determinism, not absolute determinism.

> If, like the JVM, your
> virtual machine leaves some things unspecified, then there's really
> not that much conceptual advantage in using a low-level virtual machine
> model rather than a high-level model like the one I described, because
> in both cases, some things will be left unspecified.

I had nothing as primitive as the JVM in mind when I used the term 'virtual
machine'. As you say, this is at such a low level it might as well be a real
sequential machine. What I need is an abstract, concurrent, "Non Von" machine.
 
Anyway, we know that non-deterministic systems can be implemented in
(not) purely functional languages. I don't think that was ever in doubt
(although I still maintain that such a thing is not possible in purely
functional languages). Perhaps most people think that's enough. I don't.
I think it would be useful to have a good think about formalising the idea
and building it into the semantics of what I would consider to be a viable
general purpose language. In the process we can get rid of the pseudo
functions I think.

After all, we _can_ implement functional programs in C or assembler if we want, so why bother with Clean or Haskell? Because they make it so much easier,
that's why. Is it unreasonable of me to hope for the same simplicity in
concurrent systems one day?

Regards
-- 
Adrian Hey