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

[Bart Massey]

I haven't heard much comment from anyone on the recent
dramatic change to Nickle to use a bool type instead of int
everywhere.  I'm not sure I like it: it is quite un-C-like
and it hasn't helped me noticeably yet.  Do we have any
Nickle users?  Have you noticed yet?


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)) {
    ...
  }
where the comma expression is pretty obviously bogus but
shuts the compiler up.

If we ditch the else clause and have to use exceptions, we
need some more convenient way of handling those exceptions
than wrapping the twixt() in a try.  One possibility would
be to get rid of try {}, which is an endless pain in the
neck to use in any case.  We've talked about this before,
but haven't come up with a great alternative.  The "obvious"
ones from the POV of this example are: (1) allow any block
to be followed by a string of catch clauses, eliminating the
try keyword.  Thus, one could write
  twixt(file f = open("/tmp/foo", "w"); close(f)) {
    ...
  } catch open_error(fn, msgcode, msg) {
    ...
  }
This is ugly syntax, though, and it's not obvious that the
catch clause should indeed scope in the open() in the
twixt() head.

Another possibility (2) is to make catch a first-class
statement.  We talked about making it extend to the end of
the current scope, ala
  catch open_error(fn, msgcode, msg) {
      ...
  }
  ...
  twixt(file f = open("/tmp/foo", "w"); close(f)) {
    ...
  }
but then falling out of the catch body almost always does
the wrong thing.

The alternative (3) I think I favor is to have the catch
extend to the *beginning* of the current scope, ala
  twixt(file f = open("/tmp/foo", "w"); close(f)) {
    ...
  }
  ...
  catch open_error(fn, msgcode, msg) {
      ...
  }
This is very convenient for the programmer, but of course
the reader surprise factor here is nontrivial.

Other suggestions?


AFAIK, in an outer function scope, static and global mean
the same thing.  Also AFAIK, if a function is static or
global, there is no reason to make its auto variables static
or global.  IOW, in
  namespace Eg {
    public bool f (int i) {
      static bool[*] g() {
        bool[*] u = {true, false, true};
	return u;
      }
      static bool[*] v = g();
      return v[i];
    }
the definitions of g and v only can get evaluated once, so
there's no reason to use global here.  Thus, the auto class
of u is harmless, since it will only be initialized once
anyhow.  Have I missed something?

Note that this code is a poor-man's way of doing array
comprehensions: better syntax would be nice.


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?


	Bart Massey
	bart@cs.pdx.edu