Konstantin Popov <kost@sics.se> wrote:
>
> When it comes to time line - as I got a new load of things to do -
> realistically speaking (I believe) it won't happen before January 1st
> (because of code freeze, etc.). But any news from the book's publisher
> can force us into higher gear ;-) But we're making definitive
> progress, I'd say - it is stalled or so.
OK, thanks for the info.
> Now, could you tell us (in two words) about what exactly causes you
> [such serious] problems with new ByNeed? I believe it would of
> interest to at least some of us (hey, Raph!?)
What you consider "serious" is subjective, of course. But for example,
renaming the former ByNeed to ByNeedFuture surely is an incompatible change
that requires adapting all occurances of it in the Alice system.
That and other more subtle changes certainly break the semantics of the
Future module in the Alice lib, which is specified at
http://www.ps.uni-sb.de/alice/manual/library/future.html
Here is the current implementation of the primitives (operations not found
below are implemented non-primitively in Alice):
'Future.await':
fun {$ X} {Wait X} X end
'Future.awaitEither\'':
fun {$ X Y} {WaitOr X Y} {Not {IsDet X}} end
'Future.byneed':
fun lazy {$ P}
try
{P unit}
catch error(InnerE ...) then
{Value.byNeedFail error(InnerE)}
end
end
'Future.concur':
fun {$ P}
!!thread
try
{P unit}
catch error(InnerE ...) then
{Value.byNeedFail error(InnerE)}
end
end
end
'Future.isByneed':
fun {$ X}
{IsFuture X} andthen
case {Value.toVirtualString X 0 0} of % hack taken from
Inspector
&_|&<|&f|&u|&t|&u|&r|&e|& |&b|&y|&N|&e|&e|&d|_ then true
else false
end
end
'Future.status':
fun {$ X}
if {IsFuture X} then
if {Value.isFailed X} then 'FAILED'
else 'FUTURE'
end
else 'DETERMINED'
end
end
AFAICS, at least byneed, concur, status and isByneed would break with the
proposed changes. Since Alice relies heavily on futures (and essentially
uses futures as the exclusive means of synchronisation), the system is
unlikely to work properly at all without adaptions.
OTOH, if somebody finds a way to express the above operations in a
backward-compatible *and* sufficiently efficient way in the new semantics
then we can relax and simply go with it. Any ideas?
Cheers,
- Andreas
-
Please send submissions to users@mozart-oz.org
and administriva mail to users-request@mozart-oz.org.
The Mozart Oz web site is at http://www.mozart-oz.org/.
Please send bug reports to bugs@mozart-oz.org.