New Issue: Should we change the names of compilerError/Warning/Assert ?

mppf1 · July 1, 2021, 9:04pm

18025, "mppf", "Should we change the names of compilerError/Warning/Assert ?", "2021-07-01T21:03:52Z"

Should we change the names of compilerError/Warning/Assert ?

opened 09:03PM - 01 Jul 21 UTC

This issue is a discussion of whether we should change the names of compilerErro…r, compilerWarning, and compilerAssert while working towards module stability. Note that some previous conversation about the names of these occurs in https://github.com/chapel-lang/chapel/issues/16807#issuecomment-738479451 . Currently we have compilerError, compilerWarning, and compilerAssert. These names have some downsides: * seem wordy / long * they are asymmetric with the execution-time commands (both because of `halt` vs `error` and because it's just `halt` and not `executionTimeHalt` e.g. ) * "compiler" as a modifier seems strange and might be innacurate with the Chapel interpreter * the current method names are not verbs even though they take some action On the other hand, these names are fairly clear and people rapidly figure out what these functions do when reading Chapel code. Brainstorming different names, we've come up with: * alternatives * `compilationError` * ways to shorten them: * `compError` `chplError` `paramError` * ways to make them more verby * `haltCompilation`, `haltCompiler`, `emitCompilationError`, `failCompilation, `reportCompilationError` * but note, the corresponding `warnCompilation` / `warnCompiler` don't seem quite right * having e.g. `halt` with a `compileTime=true/false argument to help with generic programming (but we probably would still want the different function names) Adding a `compileTime=true/false` argument to `halt` / `assert` / `warning` doesn't impact module stability so isn't a primary concern (unless the thought of adding it causes us to want to choose particular names).

This issue is a discussion of whether we should change the names of compilerError, compilerWarning, and compilerAssert while working towards module stability.

Note that some previous conversation about the names of these occurs in should compilerError be included by default? · Issue #16807 · chapel-lang/chapel · GitHub .

Currently we have compilerError, compilerWarning, and compilerAssert. These names have some downsides:

seem wordy / long
they are asymmetric with the execution-time commands (both because of halt vs error and because it's just halt and not executionTimeHalt e.g. )
"compiler" as a modifier seems strange and might be innacurate with the Chapel interpreter
the current method names are not verbs even though they take some action

On the other hand, these names are fairly clear and people rapidly figure out what these functions do when reading Chapel code.

Brainstorming different names, we've come up with:

alternatives
- compilationError
ways to shorten them:
- compError chplError paramError
ways to make them more verby
- haltCompilation, haltCompiler, emitCompilationError, failCompilation, reportCompilationError`
  - but note, the corresponding warnCompilation / warnCompiler don't seem quite right
having e.g. halt with a `compileTime=true/false argument to help with generic programming (but we probably would still want the different function names)

Adding a compileTime=true/false argument to halt / assert / warning doesn't impact module stability so isn't a primary concern (unless the thought of adding it causes us to want to choose particular names).