[Nickle]Boolean type, twixt, static vs global, built-in profiling

[Bart Massey]

In message <E17ZDKl-0006pB-00@localhost> you wrote:
> Around 1 o'clock on Jul 29, Bart Massey wrote:
> > If we leave things the way they are, we probably need to
> > give up on the else clause of twixt(), and simply assert
> > that everything should raise exceptions on failure.  Right
> > now, I'm having to write
> >   import File;
> >   twixt((file f = open("/tmp/foo", "w")), true; close(f)) {
> 
> That makes try_acquire much less useful; I'm not sure I want it raising an 
> exception when the mutex can't be grabbed.

try_acquire() is just a bad idea anyhow :-).  But to take a
page from your book, why not just write this?
   exception no_acq();
   try {
     twixt(bool func(){ if (!try_acquire(m)) raise no_acq();}();
           release(m)) {
        ...
     }
   } catch no_acq() {
     ...
   }

Answer: because it is unreadably ugly :-).  Also because it
isn't super clear you want to retry the try_acquire(m) on
re-entry anyway.  IMHO this whole thing is a mass of
potential bugs: if the try_acquire() succeeds initially but
not on subsequent re-entry, things get pretty weird.
Perhaps better is
   if (try_acquire(m)) {
     twixt(;release(m)) {
        ...
     }
   } else {
     ...
   }
which ensures the release, anyhow.


This begs one question: for inline use, the lambda syntax is
verbose and inconvenient, partly because the types are a
pain.  This is what I ran into with initializer functions
for arrays as well.  Perhaps we need a smalltalk-like "block
expression" that works something like
  (func x *= x; return x + y;)
where the expression is constructed as a lambda and
auto-evaluated and its type is the result of the return
expression else void.


While I'm at it, we probably need a builtin apply()
where
   poly apply(poly fn(...), poly[*] args)
and the actuals in the array are supplied as the formals of
fn().  Obviously, static typechecking goes out the window
here, at least for now.  C'est la vie.


Also, while I'm at it, you were going to make else
syntactically independent of if, so that we could get rid of
that stupid extra semicolon at top level interactive.  Any
reason not to do this?


> But, the bool type has already helped me out:
> 
> 	if (a & b == 0)
> 
> Without the bool type, this typechecks just fine and gives the wrong 
> answer.

I know.  I just wanted feedback from a third and fourth
person for a change of this scope if possible...


> For your twixt example, really what you wanted was:
> 
>     import File;
> 
>     file f;
> 
>     twixt (bool func () {
>         try {
>             f = open ("/tmp/foo", "w");
>         } catch open_error (string message, errorType error, string name) {
>             return false;
>         }
>         return true; } ();
>            close (f))
>     {
>         ...
>     }
> 
> This turns the exception into an appropriate boolean; of course, the lambda
> could check the errorType...

No, this really *isn't* what I wanted to write: see above
:-).  I really intend the twixt() to be *good* syntax for
things like opening and closing files, creating and removing
temp files, locking and unlocking mutexes, etc.


> > Finally, Keith, I give up: I figured out how to turn on
> > Nickle-statement-level profiling, and it looks from the
> > source like just printing a function ought to now show its
> > per-statement profile data, but I'm afraid I'm not having
> > that experience.  Suggestions?
> 
> Just a bug in the profile code when I converted to bool.  Try 
> profile(false) for a good time, or update to current CVS :-)

Got it, thanks :-).  Now, how do I read the mystic pairs of
numbers?  What are the units?  I think one is self and one
is sub, right?

Thanks much,

	Bart