We already have an opaque process object so I don't see a reason spawn can't return it as well. Is there a platform
that's difficult to implement spawn to return it?
Currently the process object does not compel the implementation to keep the exit code alive after waiting, and I would rather not require it to do so, as this complicates the execution model. A wait operation performed on a raw pid (which is allowed) would have to find the corresponding proc object and install the exit code in it. Of course one fix would be to forbid waiting on a raw pid.
Furthermore, the actual pid is no longer valid after wait; the OS may reuse it freely. I would rather treat a waited-for proc object like a closed port: not really useful for anything.
I don't like spawn returns
different type of object depending on whether it waits for the process to exit or it runs the process asynchronously.
I agree in principle. However, to separate spawn/wait from the other two just to keep the return type fixed means having 16 spawn procedures instead of 8. That seems to me excessive.
I thought it would be consistent that spawn returns a process object, from which the exit status can be retrieved (by wait).
I would rather have wait always wait and return the exit code, and retrieve the exit code later on by proc:exit-code (which would return #f if the exit code is not yet known). But as I say I am not convinced that this is the right model.
That leads to the question: should not-yet-spawned and spawned processes
be the same type of object, and do we even need to specify that.
I don't even know what a process object for a process that has not been created yet would look like. Or do you mean "not-yet-waited-for"? In which case my answer is sketched above.
John Cowan
http://vrici.lojban.org/~cowan xxxxxx@ccil.orgMay the hair on your toes never fall out! --Thorin Oakenshield (to Bilbo)