Brad Chamberlain wrote:
>
>> 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.
>
>
Yes, and handling the otherwise case prompted the second question,
because it seemed that you could do only one thing there, not print-a-
warning-and-return-a-safe-value.
>> 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 expted. 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).
>
>
>
Got it, thanks. The confusion is in the spec on page 77, which says
when-statement:
when expression-list do statement
when expression-list block-statement
otherwise statement
which makes it seem like otherwise acts like the when/do, ie. only
the single statement.
>>>> 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.
>
The specific example is for a generic kd-tree. You need to know the
number of dimensions as you cycle through the coordinates (x, then y,
then z, ...). If it was available from the procedure arguments then
we could use the tuple size directly; since it's not, it seems like
the param is needed.
>>> 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
>
Thanks again,
Greg
------------------------------------------------------------------------------
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
