Hi Greg --
> 1. It would be nice to see the default value of config
> constants in the help message (in the table that lists
> the command-line options).
I completely agree. We actually used to support this, but ended up
retiring it at some point when the implementation path taken became
unwieldy, with the best of intentions to put it back in, but then never
have. A question for you is whether you'd prefer to see the logical
(source) value of the config or the actual (execution time) value.
For example, given:
config var m = 10,
n = m;
would you prefer ./a.out --help to say:
m = 10
n = m
or:
m = 10
n = 10
Related requested items that we'd like to support:
* the ability for a Chapel programmer to provide help text for a config
* the ability to support short-form options for a given config (e.g., make
-o foo.txt equivalent to --outputfile foo.txt).
> 2. We've found it necessary often enough to iterate over
> the ranges of a domain separately. Doing array.domain.dim(1)
> is a bit of typing. Would it be possible to have a
> method array.range(i)?
We could potentially add this -- it seems like there's always a tension
between providing a minimal set of features for clarity/precision (an
array doens't technically have ranges, its domain does -- and then only if
its a rectangular array) and a convenient set of features. In this case
we've currently opted for minimalism, but I could personally go either way
on it.
Note that with a slight bit of bother (relying on a non-public symbol
name), you could provide such a shortcut yourself by supplying this
method:
proc _array.dim(d) {
return this.domain.dim(d);
}
which would let you do:
...A.dim(1)...
...A.dim(2)...
The fragile aspect of this is that the identifier '_array' isn't public
and is subject to change...
Other options (short of us changing the internal modules) might be to
create a helper iterator that takes care of these details for you or to
name the array's domain and use that instead (whether or not these make
sense depend a lot on the context of course).
> 3. Could the M_* constants from math.h be added to Math.chpl?
> (Especially M_PI.)
Yeah, I'd think we'd want to do that. I think the main challenge is
probably choosing names (e.g., I don't think M_PI is probably right for
Chapel...). If you have names you'd like to propose, please let us know
> 4. What is the reason for not setting a class instance to nil
> after calling delete, if you can't use it any more?
This has been discussed at times, and I believe we could. But note that
it wouldn't necessarily make your code safe. Specifically, if you did
something like:
var myC = new C();
var myC2 = myC; // alias myC
delete myC; // assume this sets myC = nil
myC2.foo();
in the current implementation, 'myC2' would still point to the just-freed
object, and so would not be 'nil'. In order to make things more
bulletproof, one would need to make all class objects use a handle or
double-dereference. We've discussed supporting a "safety over
performance" compilation mode that would take this approach for all class
variables to help catch errors, but then it's never felt high enough
priority for anyone to undertake.
Doing the 'nil upon delete' that you suggest would help with some cases,
but not others, and so may be worthwhile, but I think we haven't dived
into it because it feels like such a partial solution.
> 5. The compiler stops after each error, which makes it
> frustrating to fix problems since it's not the fastest.
> It feels like trying to get a script working: you hit
> one typo then have to re-start the script.
Yeah, this is something we'd like to improve, and others have commented on
it as well. Some errors are easy to plow through to see the next one;
others are harder (e.g., if I can't resolve the type of a variable, I'm
going to have trouble doing much with code that's downstream of it). Is
there a particular class of errors that you're running into that is giving
you these problems?
> 6. The minloc and maxloc reductions need a zipper with the
> array and its domain. Can't it get the domain from the
> array itself? 'maxloc reduce zip(A, A.domain)' is just
> verbose, although having the ability to provide a
> separate labeling sequence from the data would be useful
> in other situations.
I agree that this is frustrating in the common case. The challenge here
is that the compiler doesn't have any special knowledge of minloc and
maxloc compared to any other reduction that an end-user might write. So
for example, when you type:
myReduction reduce expr
this gets translated into a loop over 'expr', passing its elements into
the methods of 'myReduction' for accumulation and combining. For example,
if I write:
myReduction reduce A
you can think of this as being rewritten as something like:
forall a in A do
myReduction.accumulate(a);
and the problem is that, given an element from an array ('a' in this
example, or more specfically, perhaps the value 1.2 if it were an array of
reals), there's no way to get back to its index in the collection if it's
not passed down directly. So the zippered iteration effectively gives us
the ability to do:
forall (a,i) in zip(A, A.domain) do
myReduction.accumulate(a, i);
The other reason for the current approach is that you may be reducing
something that is not an array and therefore does not have obvious logical
indices for it -- so the explicit zippering allows you to specify some
numbering scheme for such cases.
Of course for the array case, you can create a helper minloc routine:
proc minloc(A) {
return minloc reduce (A, A.domain);
}
which would save you both the duplication and typing the 'reduce' keyword.
-Brad
------------------------------------------------------------------------------
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
