which is the difference with:

scope( s ) {
/** code **/
releaseResource@ResourceManager()()
}

?

That if you have a fault in your code then that release won't be executed, differently from the finally block in Java, which is always executed even if you have exceptions.

ok. Something like this?

scope( a ) {
install( default => releaseResource@ResourceManager()());
scope( s ) {
install( myFault => ....; rethrow ) /* rethrow is missing now /
/* code **/
}
}

If the .... in the fault handler for myFault encounters a fault, you are not going to reach that rethrow.
But I don't see how the handler for myFault is relevant.
Also, you want the release to be executed even if the fault is not thrown. So what you want is something like this, I think:

scope( a ) {
    install( default this => releaseResource@ResourceManager()() );
    scope( s ) {
       /* code */
    };
    releaseResource@ResourceManager()()
}

ok. so what about this?

scope( a ) {
/** code **/
}
;
releaseResource@ResourceManager()()

An uncaught fault inside of scope a may prevent executing releaseResource.

Ok, but this is a case of bad programming

What's your point?

I am trying to see the evidence of the benefit to introducing a new kind of handler.
We already have default, this and fault handlers. I am not so sure that the new handler will add benefits. If I just can obtain the same with

scope( a ) {
install( default => nullProcess );
/** code **/
}
;
releaseResource@ResourceManager()()

it is not so heavy I think. Ok, it is not structured I agree, but why it should be?
If we aim at giving a more complex structure to scope, maybe it could be better to write:

scope( a ) {
} finalize {
releaseResource@ResourceManager()()
}

but we have to define what happen in the case of termination and compensation. Also in those case the finalize is always executed. Right?

The benefit is just that the code is more modular. It doesn't add expressivity, just like in the other languages. It's a convenience. We have other conveniences, like default.

The code:

scope( a ) {
    install( default => nullProcess );
    /** code **/
}

is not really modular because maybe the programmer wants to rethrow the fault, or not. You have to go and change the code. With defer, you keep the finalisation code separate from all the rest.

I don't know if I can like your finalize, since it's static while defer plays with our current concepts and can be dynamically updated using cH. Your finalize block cannot.

default keyword alters the expressivity of the language because otherwise you need to specify all the handlers for all the faults.

I see the advantages to exploit the dynamic updating of the handlers, but I do not see when it could be useful. Why the finalizing activities should be updated during the execution?

About default: that's what I mean. You can encode it using the rest of the language, hence it adds no expressivity, it's only a convenient feature. You statically know which faults can possibly be thrown by your code, since fault names are static in the throw primitive and in interfaces.

About using dynamic handlers, we get two convenient features.

• It works with solicit-response. acquire@Manager()()[ defer => release@Manager()() ]. I like this because you write the code for cleaning up something you requested right where you should, instead of someplace else where you will have trouble remembering where you actually took the resource. In general our handler installation syntax for solicit-response is a big plus. I use it a lot since, in Jolie, adding handlers (faults, defer, default, whatever) is very often linked to contacting another service.
• It works with situations where the number of things we should do is decided at runtime, just like for fault handlers. If you have a loop of stuff you need to acquire, you can just update the handler using cH inside of the loop to remember all the clean-up you have to do.
• Perhaps more minor but still a nice bonus: We use a mechanism we are already familiar with. Implementation will be simpler than making a completely new mechanism, and also the cognitive load on the programmer will be lower, since she won't find different constructs for doing similar things. Using install makes everything nicely homogeneous.

So, if we add a finalisation primitive like defer, I see install as a simple and powerful way that will just provide the same handler installation mechanism we have now. Defer seems like a handler to me, so I don't see why it should be different from the others, from an elegance/linguistic perspective.

Now, should we add it at all? That's a different story. For this, we indeed need examples, that's why I'm asking for opinions.

@jolie/developers : Have you encountered situations where you have to remember releasing stuff (or something similar) in a system? Anything goes: locks in a concurrency library,

Here are a couple of examples from me:

// writing from a cell to another in readers-writers
readerLock@ReadersWriters( "cell1" )()[ defer => unlock@ReadersWriters( "cell1" )() ];
writerLock@ReadersWriters( "cell2" )()[ defer => cH | unlock@ReadersWriters( "cell2" )() ];
read@ReadersWriters( "cell1" )( value );
write@ReadersWriters( "cell2" { .value = value } )()

// a procedure for writing a series of temporary files, e.g., for unzipping something
// when the scope exits, we want the files to be deleted
for( i = 0, i < #fileContents, i++ ) {
    f.filename = new;
    f.content -> fileContents[i];
    writeFile@File( f )()[ defer => cH; delete@File( f.filename )() ]
}

These are not enough to convince me though, yet. I'm looking for feedback on whether more examples exist, meaning that: if you can think of any, please post. ;-)

This thing has come up again lately when developing caching mechanisms. It's not strong enough yet to motivate me to actually open a code editor and add the feature, but I'm putting it here for future reference. ;-)

I have a few remote resources that I want to cache locally (for speed/resilience) and update periodically (to keep them fresh). Without faults, the code looks like this:

[ timeout() ] { downloadPage@Srv()( cache ); setNextTimeout@Time( ... ) }

However, that's very flaky: if downloading the page raises a fault, you will never set the timeout and thus will never update the page again. One might think of setting the timeout before downloading the page, but that's not what I want (I want to take how much time it takes to download the page into account). So you end up with this:

[ timeout() ] {
  scope( s ) {
    install( default => setNextTimeout@Time( ... ) );
    downloadPage@Srv()( cache ); setNextTimeout@Time( ... )
  }
}