[Feature Request]: Change config params on module import.

[Iainmon]

Summary of Feature

Description:

I am using the Image module that Chapel provides. I would like to be able to set the config param bitsPerColor compile-time param without having to change the compilation arguments. Would this be possible?

chapel/modules/packages/Image.chpl

Line 74 in 49dc49c

config param bitsPerColor = 8;

I am implementing image loading functions for tensors in ChAI, and need to expose the bit size for color channels. Right now, I can only support 8 bit channels, but wish to make these functions work on all images with supported imagTypes.

Is this issue currently blocking your progress?

Yes. It is just preventing me from writing a generalized utility method.

Code Sample

import Image with {pixelType = 3*real(32), bitsPerColor = 32}; // ?

[bradcray]

One challenge with this request, at least under Chapel's current compilation model, is that if distinct import or use statements were to provide distinct values for a config param, then we'd effectively need to create a clone of the module per unique value (or potentially declare the compilation an error). In essence, this would be a lot like making a module a third type of object in the language, along with classes and records.

I also worry a little bit about interactions with things like:

• a user setting the config param on the compile line
• a use or import that didn't take any action to set the config param — which instance of the module would it get?

It may be that all of these challenges are surmountable, but I do worry about it making the language more complex, relative to the status quo.

Rather than changing the language for this use case, would a viable approach be to have the Image module push its contents into an object and to move the bitsPerColor param into that object as a field? If so, that's much lower-hanging fruit. Tagging @jabraham17 on this since they are the creator of the module and may have opinions about whether that's a good or bad idea.

I'd also be curious to understand more about your disinclination to supply config param arguments on the compiler's command-line. E.g., if there isn't a need to have distinct bitsPerColor values in different parts of the code, maybe all that's needed is a different or more ergonomic way to provide config param values globally across a particular compilation? (e.g., some sort of config or resources file that the compiler would consume).

[jabraham17]

Rather than changing the language for this use case, would a viable approach be to have the Image module push its contents into an object and to move the bitsPerColor param into that object as a field? If so, that's much lower-hanging fruit. Tagging @jabraham17 on this since they are the creator of the module and may have opinions about whether that's a good or bad idea.

I think that is a great idea. Right now the Image module just uses 2D arrays as an 'image', with free functions to do things like reading and writing. This is a very low-level view of an image. But having a proper image type that holds certain metadata with methods to do various operations is a much nicer interface. Its something I have been thinking about, but have not had the time to go back and implement

As a simple sketch

record image {
  param bitsPerColor = 8;
  var data: [...] ...;
  proc init(data, param bitsPerColor = 8) {
    this.bitsPerColor = bitsPerColor;
    this.data = data;
  }
  proc read(...) ...
  proc write(...) ...