search

chapel-lang / chapel

a Productive Parallel Programming Language
https://chapel-lang.org
Other
1.8k stars 421 forks source link

Should Chapel support tuple or range config vars? #17410

Open dlongnecke-cray opened 3 years ago

dlongnecke-cray commented 3 years ago

As a Chapel user, I would love for the language to support the use of tuple or range config variables (or constants). While writing a test, I found myself expressing the low/high bounds for loops in the following way:

config const (lo, hi) = (1, 8);

I was surprised (after some thought, much less so) to get a compiler error pointing inside internal modules instead:

$CHPL_HOME/modules/internal/ChapelBase.chpl:1332: In function '_do_command_line_cast':
$CHPL_HOME/modules/internal/ChapelBase.chpl:1351: error: illegal cast from string to 2*int(64)
$CHPL_HOME/modules/internal/ChapelBase.chpl:1351: note: unresolved call had id 1360678
  $CHPL_HOME/modules/internal/ChapelBase.chpl:1358: called as _do_command_line_cast(type t = 2*int(64), x: c_string) from function '_command_line_cast'
  TupleConfigConst1.chpl:2: called as _command_line_cast(param s = "tup": c_string, type t = 2*int(64), x: c_string)
note: generic instantiations are underlined in the above callstack

My hope was that the tuple destructuring would cause lo and hi to be treated as separate variables (that could be configured separately).

My first example has complicated semantics. To be thorough, I tried configuring a tuple that was not destructured:

config bounds = (1, 8);

This produced (unsurprisingly, I suppose) the same error.

A similar problem happened when I attempted to configure a range:

config const bounds = 1..8;

Supporting these more complex types would be great, but at the very least I think a clean error message that doesn't point into the guts of _do_command_line_cast would be in order.

bradcray commented 3 years ago

Making the error message better would be simple, and mostly requires distinguishing supported from non-supported cases in https://github.com/chapel-lang/chapel/blob/master/modules/internal/ChapelBase.chpl#L1332-L1353

Supporting other types ought to be as easy as adding casts from strings to those types, I believe? (where maybe the only tricky question would be whether we want casts from strings to those types? Otherwise, we could special-case such types to not use casts).

dlongnecke-cray commented 3 years ago

Yeah I think I should have written "Should" instead of "could", my bad (pun?).

bradcray commented 3 years ago

Generally speaking, my philosophy would be to make configs as general-purpose as possible (so "yes it should" barring major challenges that I'm not currently anticipating).