I hope this doesn't come of as a flame, but I'm wondering if anyone is using scope(success) and why. I can't find any reason for it.

Some background: I've slowed my D work to focus on some C experimental
features I'm calling Cx: http://www.tinycx.org and currently I'm
implementing the error handling using reserved labels "error:" and
"finally:". The error label is roughly like scope(failure) and the finally
label is roughly like scope(exit). There's no try-catch-finally. I don't
plan on adding anything like scope(success) because I couldn't think of why
anyone would want to use it. Why not just put the code at the end of the
scope like normal code-flow? I suppose one could code the entire scope in
reverse just for kicks:
void main() {
  scope(success) printf("world\n");
  scope(success) printf("hello ");
}

-Ben

Ben Hinkle wrote:
> I hope this doesn't come of as a flame, but I'm wondering if anyone is using scope(success) and why. I can't find any reason for it.
> 
> Some background: I've slowed my D work to focus on some C experimental features I'm calling Cx: http://www.tinycx.org and currently I'm implementing the error handling using reserved labels "error:" and "finally:". The error label is roughly like scope(failure) and the finally label is roughly like scope(exit). There's no try-catch-finally. I don't plan on adding anything like scope(success) because I couldn't think of why anyone would want to use it. Why not just put the code at the end of the scope like normal code-flow? I suppose one could code the entire scope in reverse just for kicks:
> void main() {
>   scope(success) printf("world\n");
>   scope(success) printf("hello ");
> }
> 
> -Ben 
> 
> 

int fn(int i)
{
   scope(success) printf("Good\n");
   scope(failure) printf("Bad\n");

   /* big huge logic block with a bazillion returns and throws +/
}

Ben Hinkle wrote:
> I hope this doesn't come of as a flame, but I'm wondering if anyone is using scope(success) and why. I can't find any reason for it.

How about a DB transaction you only want to commit if there are no errors generating data.  You might want something like this:

    scope(success) tran.commit();
    scope(failure) tran.rollback();

Sean

In article <e3qpsj$igc$1@digitaldaemon.com>, Ben Hinkle says...
>
>I hope this doesn't come of as a flame, but I'm wondering if anyone is using scope(success) and why. I can't find any reason for it.
>
>Some background: I've slowed my D work to focus on some C experimental
>features I'm calling Cx: http://www.tinycx.org and currently I'm
>implementing the error handling using reserved labels "error:" and
>"finally:". The error label is roughly like scope(failure) and the finally
>label is roughly like scope(exit). There's no try-catch-finally. I don't
>plan on adding anything like scope(success) because I couldn't think of why
>anyone would want to use it. Why not just put the code at the end of the
>scope like normal code-flow? I suppose one could code the entire scope in
>reverse just for kicks:
>void main() {
>  scope(success) printf("world\n");
>  scope(success) printf("hello ");
>}
>
>-Ben
>

I'm considering using it for some code generation technqiues (parsers mostly).

Being able to declare what happens at the tail-end of a scope *first*, rather than last, means that you have to maintain less state (across nested scopes) in your code generator.

- EricAnderton at yahoo

>
> I'm considering using it for some code generation technqiues (parsers mostly).
>
> Being able to declare what happens at the tail-end of a scope *first*,
> rather
> than last, means that you have to maintain less state (across nested
> scopes) in
> your code generator.
>
> - EricAnderton at yahoo

Ok. That sounds like an interesting application. If it comes on line sometime soon let me know.

In article <e3qvhn$q3v$1@digitaldaemon.com>, Ben Hinkle says...
>
>>
>> I'm considering using it for some code generation technqiues (parsers mostly).
>>
>> Being able to declare what happens at the tail-end of a scope *first*,
>> rather
>> than last, means that you have to maintain less state (across nested
>> scopes) in
>> your code generator.
>>
>> - EricAnderton at yahoo
>
>Ok. That sounds like an interesting application. If it comes on line sometime soon let me know.
>

Sure.  Although the use of scope() here is really just theoretical at this point...  I have something that digests EBNF (w/some annotations) to build a self-hosting parser frontend, but it makes heavy use of exceptions and anon delegates.  I'm pretty sure that I can make some of the pass/fail semantics of the various parse expressions more straightforward (almost as much as goto) by way of scope(), but I haven't tried it yet.

// I'll let y'all know what's up when I get there, regardless. :)

- EricAnderton at yahoo

On Tue, 9 May 2006 15:17:38 -0400, Ben Hinkle <bhinkle@mathworks.com> wrote:

> I hope this doesn't come of as a flame, but I'm wondering if anyone is using
> scope(success) and why. I can't find any reason for it.
>
> Some background: I've slowed my D work to focus on some C experimental
> features I'm calling Cx: http://www.tinycx.org and currently I'm
> implementing the error handling using reserved labels "error:" and
> "finally:". The error label is roughly like scope(failure) and the finally
> label is roughly like scope(exit). There's no try-catch-finally. I don't
> plan on adding anything like scope(success) because I couldn't think of why
> anyone would want to use it. Why not just put the code at the end of the
> scope like normal code-flow? I suppose one could code the entire scope in
> reverse just for kicks:
> void main() {
>   scope(success) printf("world\n");
>   scope(success) printf("hello ");
> }

Maybe... self documenting functions, listing all return values at the top?

int foobar( ..etc.. )
{
  scope(success) return 1;
  scope(failure) return 0;

}

As someone else mentioned, commiting changes to a database, perhaps several, some of which are optional depending on program flow eg.

int foobar( ..etc..)
{
  if (a) {
    ..make changes to a..
    scope(success) db.commit(a);
  }

  if (b) {
    ..make changes to b..
    scope(success) db.commit(b);
  }

  ..make changes to c..
  db.commit(c); //no scope.. required here
  return 1;
}

Regan

> Maybe... self documenting functions, listing all return values at the top?
>
> int foobar( ..etc.. )
> {
>   scope(success) return 1;
>   scope(failure) return 0;
>
> }

Does scope(failure) continue unwinding the stack? I wonder what the behavior is of returning from a scope(failure).


> As someone else mentioned, commiting changes to a database, perhaps several, some of which are optional depending on program flow eg.
>
> int foobar( ..etc..)
> {
>   if (a) {
>     ..make changes to a..
>     scope(success) db.commit(a);
>   }
>
>   if (b) {
>     ..make changes to b..
>     scope(success) db.commit(b);
>   }
>
>   ..make changes to c..
>   db.commit(c); //no scope.. required here
>   return 1;
> }

I believe writing "scope(success) foo;" followed by the end of the current scope is equivalent to just writing "foo;". Maybe I'm misunderstanding the example.

> Regan

On Tue, 9 May 2006 22:36:03 -0400, Ben Hinkle <ben.hinkle@gmail.com> wrote:
>> Maybe... self documenting functions, listing all return values at the top?
>>
>> int foobar( ..etc.. )
>> {
>>   scope(success) return 1;
>>   scope(failure) return 0;
>>
>> }
>
> Does scope(failure) continue unwinding the stack? I wonder what the behavior
> is of returning from a scope(failure).

Good question. No idea. :(

> I believe writing "scope(success) foo;" followed by the end of the current scope is equivalent to just writing "foo;". Maybe I'm misunderstanding the example.

You're right. For some reason I got it in my head that scope(success) happened when the function itself returned, as opposed to the current scope closing.

So, what about in this case:

int foobar( ..etc ..)
{
  if (a) scope(success) a.foo();
  //A: immediately after if
}
//B: at function return

when does a.foo() get executed? at A or B? I get the impression it's A.

Regan

I used to manage it with exceptions, and more or less happy with it:
> deleteNode(node_id)
> {
>   node = getNode(node_id);
>   if (!node || !db.hasSQLFeature(SQL_TRANSACTIONS))
>   {
>     return false;
>   }
> 
>   db.beginTransaction();
>   try
>   {
>     ...
>     lots of stuf that may throw,
>     or maybe throw something right here...
>     ...
>   }
>   catch (Exception e)
>   {
>     db.rollbackTransaction();
>     return false;
>   }
> 
>   db.commitTransaction();
>   return true;
> }

In this particular case I don't want rollback on returning false, just if a db operation failed. And exceptions handle that rather well.

My point is, if case is a bit more complicated then a 'hello world' example, there most likely will be different error conditions, and they meant be handled differently. Exceptions are convenient way to do it.

IMHO 'on scope exit' approach is not much different from 'one return at end of function' with condition flag(s).

And it is kind of obscure code for me - it can be anywhere in function, maybe even may times, etc... It's hard to maintain (just like goto's), and as so, it's no use for me at this point.

Sean Kelly wrote:
> Ben Hinkle wrote:
>> I hope this doesn't come of as a flame, but I'm wondering if anyone is using scope(success) and why. I can't find any reason for it.
> 
> How about a DB transaction you only want to commit if there are no errors generating data.  You might want something like this:
> 
>     scope(success) tran.commit();
>     scope(failure) tran.rollback();
> 
> Sean