From bradc@cray.com Thu Dec  6 16:56:55 2007
Date: Thu, 6 Dec 2007 16:56:55 -0800 (PST)
From: Brad Chamberlain <bradc@cray.com>
To: Ben Lerner <blerner@cs.washington.edu>
Subject: Re: Thoughts on using Chapel


> > But wait, you don't declare any arrays over your sparse domains!  :)
> True, I didn't.  But that's because I didn't have hierarchical domains.  I
> wanted to define parsedElements over [StartIndices, EndIndices], didn't
> have support for that, so switched to AllIndices, and made it dense.

That's right, you told me this.  I'm having trouble keeping all the details
in my head at once.


> I like that.  It seemed weird to me, because I'd gotten file-level
> constants and config values mixed up in my head.  Also, I didn't think you
> could have code at the file level outside functions, and still didn't make
> the connection between user-defined iterators and sparse subdomains.

Yeah, the file-level code outside functions is a little funky, but having
decided to try it, we find ourselves liking it a bunch.  Formally, that code
is the module's initialization code, run when the module is initialized.
Practically speaking, it tends to do exactly what you want.

> Some wacky connections here :)  Also, this would be a good example to have
> in chapter 19, because the current description of sparse subdomains
> is...sparse.  Having an example saying "Like all domains, sparse
> subdomains are particularly effective when they're constant, as the
> compiler can optimize them effectively.  One convenient idiom is to define
> 
> const D : sparse subdomain(B) = computeIndices(...);
> def computeIndices(...) { ... yield <some index>; ... }

Fair enough.  I think the sparse example is currently better documentation
than the sparse section of the language spec.  :)  Unfortunately, I think I
wrote both.


> Hehe.  It seems like an idea with potential.  Another thing that would be
> "nice to express" is when an array's domain is constant, that is, I can't
> say "A.domain = newdomain;"  Because even if I know D is a constant
> domain, and A was defined over [D], I may change it later...

We've recently decided that allowing an array's domain to change via
A.domain is a bad idea for reasons similar to this.  As a result, we're
moving towards making A.domain being supported to query a const domain
value, rather than a reference to the array's domain.  The downside of this
is that if you want to change an array's domain, you'd need to be able to
refer to it by name or pass it along with the array.  The upside is that I
think there will be a whole lot less self-foot-shooting going on.  (And
there were some subtleties in the implementation that led us in this
direction as well).


> The other thing I was confused about (though I gave it only a quick scan)
> was the user-defined compile errors, and what kinds of expressions are
> permitted in defining them.  The thing I was must confused about was how
> much of a phase-distinction you maintained between compiling code and
> running some code during compilation.

OK, we'll try to clarify that.  The short answer is that the compilerError()
function generates the error if it is found to be invoked during function
resolution, and it can only refer to param expressions (and possibly
types?).  Basically, similar rules as our other compile-time computation
machinery (which we may have discussed before you got back from Europe?).

-Brad
