Allow ? in identifiers

[johnmyleswhite]

This will allow us to have functions like contains? and empty?.

[JeffBezanson]

As a Schemer I'm certainly sympathetic to this, but renaming all the predicates would break a lot of code, and we would have to require whitespace to use the ? operator, or get rid of it.

[johnmyleswhite]

@StefanKarpinski seemed alright with requiring whitespace. Since the ? operator is dear to him, I tend to defer to his opinion.

I agree that a lot of code would break, but the fixes only require basic string replacements.

[ViralBShah]

I am not too excited about this one.

[Keno]

We have decided to not allow this one. The convention will be to use isxxx for predicates i.e. isempty though perhaps isin instead of contains.

[diegozea]

I like the idea of isin instead of contains

P.S.: How has is going to follow the is rule ?

[toivoh]

Could you provide the rationale?
The asymmetry of allowing trailing ! in identifiers, but not ? is still hurting me.

[JeffBezanson]

1. Conflict with ternary operator. Would require a space to use the ? operator, but this might not be obvious to everybody.
2. There is a strong tradition of function names like isequal, isodd, isreal, etc. Changing them to ? would disrupt a lot of code and add a stumbling block for new users. And we'd rather not have two naming conventions for predicates.

[jiahao]

I noticed recently that ? by itself is a valid identifier. Is this intentional?

Although you can't type it into a REPL anymore, you can easily write ? = 1 in a script and use ? as a variable later. Some expressions like 2? don't work, while other statements like ? = ? + 1 and

? = ? == ? ? :? :  :(? ? ? : ?)

do.

You can get quite far with writing valid code with ?, like this implementation of the Minkowski question-mark function:

function ?(x::Real)
    0≤x≤1 || (y=floor(x); return ?(x-y)+y) #Range reduction
    (x==0 || x==1) && return x #Base cases
    p=floor(Integer, x)
    q=1
    r=p+1
    s=1
    d=1.0
    y=float(p)
    (x<y || (p<0) $ (r≤0)) && return x
    while true
        d /=2
        (y+d==y) && break #Reached maximum possible precision
        m=p+r
        ((m<0) $ (p<0)) && break #Overflow
        n=q+s
        (n<0) && break #Overflow

        x<(m/n) ? (r=m; s=n) : (y+=d; p=m; q=n)
    end
    return y+d
end

using Base.Test
@test_approx_eq ?((√(3)-1)/2) 2/7

[tkelman]

One place that gets used right now is for fake-ternary syntax in the OS-testing macros:

julia> dump(:(@osx? true : false))
Expr
  head: Symbol macrocall
  args: Array(Any,(3,))
    1: Symbol @osx
    2: Symbol ?
    3: Expr
      head: Symbol :
      args: Array(Any,(2,))
        1: Bool true
        2: Bool false
      typ: Any
  typ: Any

[jakebolewski]

I think those should go away. '@osx' should so what '@osx_only' does currently.

[tkelman]

Maybe. They are kind of messy, but it's convenient to have a boolean-like version of those. People seem to like using them more than OS_NAME == :Darwin, anyway.

[jakebolewski]

How are they better than something like an isosx() function. I don't
know if they are used really in places where it would be critical to inline
the code for performance.

On Mon, Feb 23, 2015 at 10:26 AM, Tony Kelman notifications@github.com
wrote:

Maybe. They are kind of messy, but it's convenient to have a boolean-like
version of those. People seem to like using them more than OS_NAME ==
:Darwin, anyway.

—
Reply to this email directly or view it on GitHub
#1910 (comment).

[tkelman]

They would probably be better as functions.

[StefanKarpinski]

@tkelman I hate those macros. They should definitely go away. They appear to parse as ternary operators, but they don't and are instead crazy brittle for parsing.

[jakebolewski]

Maybe now is the time to deprecate them (or get rid of them entirely)?

[Keno]

They can't be functions, because sometimes you need to make sure an expression never appears in the AST on an operating system (e.g. because it's a ccall or cglobal). How about something like:

@os if osx

else

end

[tkelman]

@StefanKarpinski I know you do. If we're going to get rid of them, the sooner the better, because people who don't know any better about how they're implemented will keep using them otherwise. Preferably with a deprecation, or handling in Compat.jl.

[StefanKarpinski]

I like @Keno's suggestion.

[ivarne]

deprecation and handling in Compat.jl

deprecation:
Make code written for the previous version work (with an annoying warning, and a performance penalty), so that code doesn't have to be rewritten immediately to work after a change in Julia Base. Ideally this means that programs that work under 0.3.X (without deprecation warnings) should run in 0.4 without modification.

Compat.jl:
Provide the new functionality to the old version. This means that you can use the new functionality with the old versions, so that you can future proof your code, while still being compatible with the old version. Ideally this means that if you have using Compat and a few @compat macros in your 0.4 code, it should run the same in 0.3.

[MikeInnes]

As a generalisation of @Keno's suggestion, there's a handy macro called @cond in Lazy.jl which moves conditions to compile time for exactly this purpose. For example

@cond if WINDOWS
  println("windows")
elseif UNIX
  println("unix")
else
  println("What are you??")
end

will compile to a single println.

What's also nice about this is it trivially generalises to, for example, OS versions, as well as Julia versions:

@cond VERSION > v"0.4-" ? Dict(1=>2) : [1=>2]
@cond windows_version() < (1,2) ? ....

I can also see the argument for giving users less of a swiss army knife, though – something like @os, which could limit allowed conditions, might be harder to misunderstand or misuse.

[StefanKarpinski]

No, I like the general version. It would be nice if we could write it as @if, of course.