[e-lang] Why aren't guards allowed on forward declarations?

[Kevin Reid]

On Sep 26, 2007, at 16:57, David Hopwood wrote:
> Kevin Reid wrote:
>> On Sep 26, 2007, at 16:20, David Hopwood wrote:
>>>    def succeeded :boolean
>> (Syntactic note: Forward declarations may not have guards.)
> Any good reason for this? It seems as though the semantics would be  
> clear.

I was thinking about that myself. For the forward-declaration usage,  
it doesn't seem a problem.

"def foo" currently expands to

   def [foo, foo__Resolver] := Ref.promise()
   foo__Resolver

"def foo :bar" would expand to

   def [foo, foo__Resolver] := __makeGuardedPromise(bar)
   foo__Resolver

with this definition in the universal scope:

   def __makeGuardedPromise(guard) {
     def [promise, resolver] := Ref.promise()
     def guardedResolver {
       to resolveRace(value :guard) {
         return resolver.resolveRace(value)
       }
       # ... other http://wiki.erights.org/wiki/Resolver methods
     }
     return [promise, guardedResolver]
   }

The one maybe-problem with this mechanism is that it doesn't compose  
with other promises in the way resolvers are usually expected to.  
That is, given this resolver, resolving it to a promise is not  
transparent (and fails instead).

This is not especially surprising when using the bind syntax (it  
looks similar to assignment, which can also fail for a guarded slot),  
but might be when using the resolver explicitly.

   def foo(resolver) {
     resolver.resolve("a" <- add("b"))
   }

   foo(def answer :String)

"foo" here makes perfect sense as long as one is dealing with only  
ordinary resolvers, but it fails for these guarded resolvers (unless  
the guard accepts promises, e.g. the parameterizable "vow" or "rcvr"  
guards).

That said, perhaps this is a good thing. Whenever we're passing  
arbitrary "resolver" objects around, we ought to make use of, and  
test our programs against, variations in their behavior.

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>