From blerner@cs.washington.edu Thu Dec  6 14:39:20 2007
Date: Thu, 06 Dec 2007 14:39:17 -0800
From: Ben Lerner <blerner@cs.washington.edu>
To: Brad Chamberlain <bradc@cray.com>
Subject: Re: Thoughts on using Chapel


> > > Does anything prevent you in this case from moving the declaration of
> > > the array after the sparse domain's initialization?  If not, I'd
> > > suggest doing that -- declare the dense domain, the sparse domain,
> > > initialize the sparse domain, now declare the sparse array.  That way,
> > > the allocation happens in one fell swoop as you'd like.
> > 
> > I wanted all the declarations to be global, so I wouldn't have to pass
> > them around in my code.
> 
> Globals are evaluated/initialized in order in Chapel, and code can exist
> at the file level (it becomes initialization code for the module), so this
> still ought to be workable (I have to admit that I hadn't had a chance to
> connect your comments to your code, and am just starting to do so now).
> Imagine:
> 
> var StartIndices: sparse subdomain(AllIndices);
> 
> // compute StartIndices += ...;
> 
> var Arr: [StartIndices] real;
> 
> 
> 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. 
> > 
> > Not in my case -- the sparse domain StartIndices, for instance, is the
> > location of all "<" characters in the input, and the positions just
> > after all ">" characters.  That said, they are constant, right after I
> > figure that information out.
> Or, can the sparse domain be initialized on its declaration line rather
> than after its declaration (using an iterator, e.g.)?  This would be the
> ideal way to do it since it would allow the sparse domain to be declared
> const, which should result in other optimization and readability benefits.
> 
> This still seems like it should be doable, though.  Imagine something
> like:
> 
> ...
> 
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.  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>; ... }
> 
> > Here's a wacky thought: would the following work?
> > const AllIndices : [1..length(input)]
> > var StartIndices : single sparse subdomain(AllIndices)  <<== note the
> > single!
> > var EndIndices : single sparse subdomain(AllIndices)  <<== note the
> > single!
> > var parsedElements : [StartIndices, EndIndices] single XmlElement  <<==
> > hierarchical domains, not there yet but soon :)
> > 
> > /* expectation: parsedElements has not been allocated yet, since it's
> > waiting for StartIndices and EndIndices to be assigned */
> > 
> > StartIndices = ComputeStartIndices(input); /* still waiting... */
> > EndIndices = ComputeEndIndices(input);
> > /* Ok, go!  Both sets of indices are available, so parsedElements can be
> > allocated.  Moreover, unless it's reassigned, the domain of
> > parsedElements must be constant. */
> 
> MMMmmmmaybe.  I think we've been vague/uncertain about what single should
> mean in the domain context, which is the main thing that makes me nervous
> about this.
> 
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...

> > There are some BNF-style descriptions in the spec, but I'm not sure they
> > match reality explicitly.  (I think the syntax for class declarations
> > and deriving from base classes is missing a colon separating class D :
> > B, for instance.  Also evidently semicolons are prohibited following
> > class and function body definitions, but are required after variable
> > definitions in class bodies.  I didn't gather that from the spec; just
> > from the example programs.  I was also confused by the if-then syntax,
> > see below.)  It's not so much that the spec is blatantly poorly
> > specified, but when there are mismatches between the spec and reality, I
> > don't know which is newer or more correct.  Having an appendix at the
> > end containing the Bison grammar you actually use in the compiler
> > (dropping the semantic actions or other cruft) should be an automated
> > way to keep the spec in sync with the code.
> 
> OK, thanks for pointing out the cases you found that seemed wrong.  These
> are bugs in the spec -- the spec's syntax is meant to describe what the
> compiler currently has implemented.
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.
