[Python-logic] Stackless Python Logic Variables (archiving old foreign thread)

[Nicolas Chauvat]

Taken from the mozart user list, stored here for future reference:

===========================================================================
From: Denys Duchier <duchier at ps.uni-sb.de>
Date: Wed, 11 Jun 2003 14:37:18 +0200

jabowery at technicalpursuit.com (James A. Bowery) writes:

>> >     Stackless Python [1] is an ideal environment within which to
>> >     implement logic variables for thread synchroniziation [2].
>> >     The 3 additions required for this are 1) the addition of the
>> >     "unknown" keyword that declares a logic variable, 2) the
>> >     "final" keyword that declares a logic variable to be single-
>> >     assignment and 3) the "=:=" operator that performs a
>> >     unification of a logic variable with an expression.

I don't think that would be the way to do it.  This just doesn't fit
the Python way.

    Q. What is the expected benefit?
    A. Transparent synchronization on data.

In this regard, the better generalization (which for us was started in
Mozart and pursued in Alice) is the dual notion of future/promise and
does not apeal to the notion of logic variable nor of unification.

    - a future represents a value that is not yet available, but which
      is presumably being computed concurrently

    - synchronization on futures block.  In particular all access and
      mutation primitives perform implicit synchronization and block
      until the data represented by the future becomes available

    - a promise is the dual notion.  The thread computing the value of
      a future keeps the corresponding promise.  When the value has
      been computed, the promise is used to make this data available
      through the corresponding future.  We say that the promised has
      been fulfilled.

    - once a promise has been fulfilled with a value, its
      corresponding future becomes indistinguishable from the value:
      we say that it has become bound to the value.  In other words,
      all operations taking this future as argument behave exactly as
      of they were seing the value directly (dereferentiation).

    - this gives us transparent data-flow synchronization (futures are
      transparent).

    - this allows us to create safe concurrent abstractions: you can
      only bind a future if you have access to the corresponding
      promise.

Whether such an approach is worthwhile for Python, or whether
Stackless the better foundation on which to experiment with such an
extension is a question that I'll leave to the experts.

Cheers,

-- 
Dr. Denys Duchier
Équipe Calligramme
LORIA, Nancy, FRANCE

Date: Wed, 11 Jun 2003 16:41:50 +0200 (CEST)
From: Peter Van Roy <pvr at info.ucl.ac.be>

On Wed, 11 Jun 2003, Denys Duchier wrote:

> jabowery at technicalpursuit.com (James A. Bowery) writes:
> 
> >> >     Stackless Python [1] is an ideal environment within which to
> >> >     implement logic variables for thread synchroniziation [2].  
> >> >     The 3 additions required for this are 1) the addition of the
> >> >     "unknown" keyword that declares a logic variable, 2) the
> >> >     "final" keyword that declares a logic variable to be single-
> >> >     assignment and 3) the "=:=" operator that performs a
> >> >     unification of a logic variable with an expression. 
> 
> I don't think that would be the way to do it.  This just doesn't fit
> the Python way.
> 
>     Q. What is the expected benefit?
>     A. Transparent synchronization on data.
>     
> In this regard, the better generalization (which for us was started in
> Mozart and pursued in Alice) is the dual notion of future/promise and 
> does not apeal to the notion of logic variable nor of unification.    
  
Exactly.  If all you want is dataflow synchronization, then full logic
variables are not needed.  BTW, a future is called a 'read-only view' in  
our programming textbook.  The original term 'future' was introduced
by Bert Halstead in the Multilisp language and means something a little
different than the original way we used it in Oz.                

It all depends on what you want to do.  If you want the most expressive
possible declarative sublanguage, then logic variables might be a good
idea for you.  See, e.g., the exercise on 'tail-recursive convolution'
at the end of Chapter 3 in our book.  Having logic variables and 
unification lets you avoid some funny contortions that functional
programming would otherwise force you to do.

Peter

Date: Wed, 11 Jun 2003 01:26:18 +0000
From: David Hopwood <david.hopwood at zetnet.co.uk>

Denys Duchier wrote:
> jabowery at technicalpursuit.com (James A. Bowery) writes:
> 
> >> >     Stackless Python [1] is an ideal environment within which to
> >> >     implement logic variables for thread synchroniziation [2].
> >> >     The 3 additions required for this are 1) the addition of the
> >> >     "unknown" keyword that declares a logic variable, 2) the
> >> >     "final" keyword that declares a logic variable to be single-
> >> >     assignment and 3) the "=:=" operator that performs a
> >> >     unification of a logic variable with an expression.
> 
> I don't think that would be the way to do it.  This just doesn't fit
> the Python way.
> 
>     Q. What is the expected benefit?
>     A. Transparent synchronization on data.
> 
> In this regard, the better generalization (which for us was started in
> Mozart and pursued in Alice) is the dual notion of future/promise and
> does not apeal to the notion of logic variable nor of unification.

For an example of a language that supports dataflow variables/promises
without unification, see E (www.erights.org; I suggest starting with
<http://www.erights.org/elang/intro/quickE.html>). I agree that this
approach may be better suited for an extension to Python.

- -- 
David Hopwood <david.hopwood at zetnet.co.uk>
===========================================================================

-- 
Nicolas Chauvat

logilab.fr - services en informatique avancée et gestion de connaissances