> It does not.  I just tried a simple test case with only half the
> enum elements in a select.  It compiled cleanly and ran; if the
> value passed to the select wasn't one of those with a 'when' clause
> then it was ignored silently (the behavior we'd like to avoid).

I agree with Michael that it'd be nice to have the compiler warn when a 
select over an enum doesn't cover all the cases.  The workaround (which it 
sounds like you anticipated in question 2) would be to add an 'otherwise' 
clause to your select statement that called halt().  Of course, this is 
creating an execution-time error for something that could/should be caught 
at compile-time.


> Ah, no, we weren't actually brave enough to try this; the comment was
> based on the spec (p. 77) which only lists a single statement as
> permitted, not a block.

In Chapel, a compound statement ("block") is a single statement, so should 
be usable wherever a single statement is expected.  This is also why:

        if test then
          singleStatement();

        if test {
          firstStatement();
          secondStatement();
        }

can be composed to form:

        if test then {
          firstStatement();
          secondStatement();
        }

(and ditto other control flow concepts that use 'do' as their keyword).



>>> 3. Can you access the size of a tuple with a query?  Something
>>>     like
>>>       proc p(pt : ?ndim * int) {
>>>         writeln("dimensionality of point is ", ndim);
>>>       }
>>>     doesn't compile with the message "syntax error: near '*'".
>>
>> Sounds like a bug (or at least future work). I don't think there's
>> any reason we wouldn't support such things. In the mean time, you
>> can use pt.size if you know that pt is a tuple...
>>
>> I believe you could write the equivalent thing with something like
>>        proc p(pt : ?t ) where isHomogeneousTuple(t)  && t(1).type == int
>> {...}
>>
>> although I haven't checked that compiles...
>>
>
> Yeah, we fixed this with a param to the class.  It just would have
> been nice not to have to specify it in the constructor and have
> a generic piece of code figure it out for itself.

There's no deep reason that we don't support this (along with a number of 
other pattern-matching based forms of formal argument queries) -- it's an 
area of the compiler where we've handled some common cases, but not others 
and requires more attention.

I'd be curious for more detail the class you wanted to write and the 
workaround you used, as it's not obvious to me that a param to the class 
should be required, but I'm guessing at what your class looks like.


>>> 4. Does a domain slice form a subdomain?  It's not clear in the
>>>     spec.
>>
>> I'm going to let somebody else answer that one.

Yes.



>> BTW, if you are going to have a long list of these requests, it
>> would probably be best if you can file them in our testing system
>> yourself.

I'll note that we're also working on establishing a public Jira system for 
filing such feature requests (though even then, having tests that back up 
the request will be highly prized).

-Brad


------------------------------------------------------------------------------
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users

Reply via email to