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

conditional expressions that eagerly evaluate the condition at top-level? #5892

Closed
simonster opened this issue Feb 21, 2014 · 4 comments
Closed
Labels
speculative Whether the change will be implemented is speculative

Comments

@simonster
Copy link
Member

It would be great to do things like:

@cond VERSION >= v"0.3-" ? eigvecs(A, ev) : eigvecs(A, ev)[1]
@cond isdefined(:setfield!) ? setfield!(x, y) : setfield(x,y)
@cond WINDOWS ? 1 : 2

This would fix #4233 as well as give us an approach to writing code that is compatible with multiple Julia or package versions that isn't as awkward as #5029. (It would be great to have something like this for 0.3, so that package authors can avoid separate branches for different Julia versions provided the differences aren't too big.) I'm not sure how to do this, though. It seems like @cond would have to be a macro that calls eval. Ignoring that this is considered bad practice, the argument to eval seems to be executed in the macro's module and not the calling module, which could be confusing. Any thoughts?

@StefanKarpinski
Copy link
Member

It would be nice to call this @if, but you can't use a keyword (currently).

@ihnorton
Copy link
Member

ihnorton commented Jul 2, 2014

crossref #7449 which covers one of the use-cases.

@MikeInnes
Copy link
Member

I implemented this for Lazy.jl so that you can do things like

@cond if WINDOWS
  foo()
elseif OSX
  bar()
else
  error()
end

It supports chains of both block and ternary if syntax (you could even mix them I guess, yay recursive macros). Base is welcome to it.

vtjnash added a commit that referenced this issue May 5, 2016
vtjnash added a commit that referenced this issue May 5, 2016
vtjnash added a commit that referenced this issue May 5, 2016
vtjnash added a commit to vtjnash/julia that referenced this issue May 6, 2016
vtjnash added a commit that referenced this issue May 13, 2016
vtjnash added a commit that referenced this issue May 16, 2016
vtjnash added a commit that referenced this issue May 17, 2016
implements #5892
closes #6674 and #4233

Sys.KERNEL now replaces OS_NAME and unambiguously returns
the name of the kernel reported by uname for the build system configuration
vtjnash added a commit that referenced this issue May 17, 2016
implements #5892
closes #6674 and #4233

Sys.KERNEL now replaces OS_NAME and unambiguously returns
the name of the kernel reported by uname for the build system configuration
vtjnash added a commit that referenced this issue May 20, 2016
implements #5892
closes #6674 and #4233

Sys.KERNEL now replaces OS_NAME and unambiguously returns
the name of the kernel reported by uname for the build system configuration
vtjnash added a commit that referenced this issue May 20, 2016
implements #5892
closes #6674 and #4233

Sys.KERNEL now replaces OS_NAME and unambiguously returns
the name of the kernel reported by uname for the build system configuration
vtjnash added a commit that referenced this issue May 20, 2016
implements #5892
closes #6674 and #4233

Sys.KERNEL now replaces OS_NAME and unambiguously returns
the name of the kernel reported by uname for the build system configuration
vtjnash added a commit that referenced this issue May 21, 2016
implements #5892
closes #6674 and #4233

Sys.KERNEL now replaces OS_NAME and unambiguously returns
the name of the kernel reported by uname for the build system configuration
vtjnash added a commit that referenced this issue May 21, 2016
implements #5892
closes #6674 and #4233

Sys.KERNEL now replaces OS_NAME and unambiguously returns
the name of the kernel reported by uname for the build system configuration
@tkelman
Copy link
Contributor

tkelman commented May 29, 2016

@static implemented in #16219

@tkelman tkelman closed this as completed May 29, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
speculative Whether the change will be implemented is speculative
Projects
None yet
Development

No branches or pull requests

5 participants