Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow for _{digit} in module names #137

Open
gaow opened this issue May 11, 2018 · 5 comments
Open

Allow for _{digit} in module names #137

gaow opened this issue May 11, 2018 · 5 comments

Comments

@gaow
Copy link
Member

gaow commented May 11, 2018

This is currently disallowed because it conflicts with our internal convention and violation of it causes infinite loop in DAG. This can be relaxed, though, given some work (not hard but tedious). Please bump this if it is an urgent request. Otherwise I'll not fix it immediately but perhaps in a month time or so.

@gaow
Copy link
Member Author

gaow commented May 11, 2018

Okay to continue on the slack discussion let me be a bit clear on what are allowed and what are not, for module name and variable names.

Not allowed:

  1. Any . anywhere in the module name, or parameter name, because it is not valid Python or SQL variable names.
  2. _ as prefix. eg, _simulate, because R does not like it.
  3. _ as suffix, eg. simulate_, because it looks incomplete and ugly.
  4. - in variable name, because it will not work in most languages
  5. _ followed by digit / digits as suffix, in module name, eg, simulate_1. This is because _1, an internal convention of index, will cause us troubles. The reason we pick _{digit(s)} as index is because it feels natural that way (eg, LaTeX). Also, since our automatic output file naming convention is with _{digits} it will create a minor issue there too.

Allowed:

  1. simulate_V2 or simulate_2V for module names.
  2. x_1, x_2 etc in variable names.

So the only restriction that we can possibly relax is _{digits} in module names.

@pcarbo
Copy link
Member

pcarbo commented May 11, 2018

@gaow It seems that there would be more restrictions than this! Which of these are valid variable names? What about other punctuation in variable names? e.g., @#$/?{}[](). Is 17 allowed as a variable name? What about 0out?

@gaow
Copy link
Member Author

gaow commented May 11, 2018

@pcarbo those are not, but i was not listing because people will mostly assume they do not work for parameters thus do not use them. Even if they do, i'll surely throw an error message. I'm just listing the ones that are normally allowed in one language but not another (1,2), one that people may very likely commit a mistake for (4) and two that would work with other languages but DSC does not allow (3,5).

@gaow
Copy link
Member Author

gaow commented Jan 30, 2019

Still pending tests in DSC, but I believe this is no longer an issue (we've done some work on SoS to have it relaxed). I changed the label from later to soon to add more tests on the DSC part.

@jdblischak
Copy link
Member

@gaow I ran into this exact issue today (DSC 0.3.2 and SoS 0.18.4). That's why the names of my simulation modules all end in _name. When I tried to use, e.g. b_0_0, it threw an error.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants