Dear all,

I agree that until or unless justice will not prevail in the society, it
will keep deteriorating and frustration of the people will keep mounting.
However, we cannot only stick to the judiciary crisis. We have so many other
important issues engulfing us that we cannot stay stick to this for long
(that movement can be carried in parallel with little flexibility, if all
the parties are not agreeing to a single point) and ignore all others saying
that first of all this should be done then come rest of the problems. I
think that we should move-on, find a middle way out and start focusing on
the other issues as well. I am a great supporter of a good judiciary system
but we cannot jeopardize the whole nation on this issue and ignoring other
issues with which life of common man is concerned more.

I totally respect your point of you, but I think its not about giving chance
to one party or the other, we cannot keep trying different sects of society.
Even then, some would say, they are good and some will say they are not. We
need to think on a wider frame, I guess.

Best regards,
Irum

On Tue, Sep 2, 2008 at 11:54 PM, Nauman Ilyas <[EMAIL PROTECTED]>wrote:

>
> Dear Natasha,
>
> I believe that we as common people of Pakistan should give these lawyers a
> chance. Everybody (politician, army, bureaucracy) got a chance; why not
> these lawyers. Who knows what good they will bring to this country; I am
> sure you agree with me that these lawyers will do no damage to our beloved
> country as compared to what Army and our political elite did.
>
> Nauman.
>
>
> >
>

--~--~-----, otherstuff);
  req.add_callback(finish,stuff,otherstuff)
  If (stuff.may_async) {
    stuff.did_async=true;
    Return OK;
  }
  // this also calls finish callback
  req.wait_till_done();
  return(stuff.status); 
}

The obvious candidate for the lambda is the finish function, giving something 
like this
(assuming lambda local-vars support is complete)

server_do_things(stuff) {
  req=do_thing(stuff, otherstuff);
  req.add_callback( (req) => (
    stuff.status=req.receive(stuff);
    // do more stuff here
  ) )
  If (stuff.may_async) {
    stuff.did_async=true;
    Return OK;
  }
  // this also calls finish callback
  req.wait_till_done();
  return(stuff.status); 
}

It's a little puzzling that the lamda appears halfway through; but it gets more 
complicated if the server has to issue more than one client request; the nest 
lambdas make the whole thing look like lisp.

The idea of implicit lamdas is to allow the code to be laid out as if it were 
synchronous but still work asynchronously, see:

server_do_things(stuff) {
  req=do_thing(stuff, otherstuff);
  req.add_callback(finish,stuff,otherstuff)
  If (stuff.may_async) {
    stuff.did_async=true;
    Return OK;
  } else {
    // this also calls finish callback
    req.wait_till_done();
    return (stuff.status);
  }
finish:
  stuff.status=req.receive(stuff);
  // do more stuff here
  return(req.status); 
}

finish: is a regular C style label; but if it's address is taken for a delegate 
then it becomes simultaneously a lambda until the end of the enclosing block 
and also a call to that lambda.

Thus the code can be run_into during normal execution as well as apparently 
run-into for async execution.

If such a thing were possible, the rpc glue would differ so as to make better 
use of it.

Here's a more complex case which unwinds a terrible state machine into an 
apparent linear function:

server_auth(stuff) {
  req=send_get_auth_types(stuff);
  // I'll talk about block this later...
  if (stuff.may_async) {
    req.add_callback(type);
    Stuff.dyd_async=true;
    return;
  } else {
    Req.wait_for_response();
  }
type:
  if (stuff.kerberos) {
    kreq=send_kerberos(krb);
    ...
krb:
    If (kreq.success)...
  } else if (stuff.ntlm) {
  }
}

I said that implicit lambdas ought to last to the end of the containing block, 
but really when that block finishes a new implicit lambda should start in the 
outer block as if it were declared in the same manner as discussed; and so on 
until the end of the enclosing function block is reached.

That way parts of the function can be deferred or executed immediately without 
a problem.

I don't know how such a lamda would cope with being in a loop.

The If block for which I said: "// I'll talk about block this later..." clearly 
it's a pain to have to repeat that async/sync fixup code everytime, but I think 
I've said enough to layout the problem and how lamdas could unwind horrible 
continuation chains and async state machines, so I'm open for comment.

Sam
  


_______________________________________________
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Reply via email to