You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When writing a package that introduces symbolic name for optional parameters to functions, it can be a burden to document them and to worry about whether they conflict with other packages, and hence many package writers are tempted to use strings instead. It might be better to introduce a paradigm where the package can introduce new protected global symbols in the Core dictionary, instead of in the package dictionary. Thus two packages could use the same option name Gamma, but there would still be a conflict if another package introduces code for the Gamma function.
What should be done?
The text was updated successfully, but these errors were encountered:
When writing a package that introduces symbolic name for optional parameters to functions, it can be a burden to document them and to worry about whether they conflict with other packages, and hence many package writers are tempted to use strings instead. It might be better to introduce a paradigm where the package can introduce new protected global symbols in the Core dictionary, instead of in the package dictionary. Thus two packages could use the same option name
Gamma
, but there would still be a conflict if another package introduces code for theGamma
function.What should be done?
The text was updated successfully, but these errors were encountered: