Question mark in variable names

question

#1

Why aren’t question marks allowed in variable names in Julia? This question has probably been discussed elsewhere so perhaps someone can point me there if they know the location.

Its a small thing, but it would be nice to write scheme style predicates if possible (eg. integer?(x) instead of isinteger(x)).


Naming: Remove all underscores to matter what?
#2

Should have googled harder: #1539 Discusses this but doesn’t come to any conclusion other than that it is currently prohibited by allowing triple statements without spaces (eg. a?b:c). So the question remains…


#3

I agree that this would be nice. I find that multiple dispatch is conducive to a pattern in which I use short, simple function names, so it’s nice to have as many ways of doing that as possible.

One good argument I can think of against this is that it’s probably good to reserve special characters like ?,!,&,%,: for future use as special syntax. ! in variable names already has a well-established and important use, whether that would be the case for ? is less clear.


#4

i’d really like ’ to be allowed in variable names, but i suppose that’s pretty much impossible.

having variable-name-prime is really handy.


#5

Prime is allowed

julia> a′ = 1
1

julia> a′ + 2
3

How to call a function that returns a function efficiently
#6

julia> a’=1
ERROR: syntax: invalid assignment location “a’”

julia> a’ = 1
ERROR: syntax: invalid assignment location “a’”

julia>
edit: and i just tried 0.6rc2 and got the same result


#7

You are using the wrong symbol. Copy the one I have and it should work. (It types as \prime though it seems that the repl help for it is broken.)


#8

This works though

help?> a′
"a′" can be typed by a\prime<tab>

#9

ok! that’s great.
clearly i need to go read something in the julia documentation.
now I just have to figure out how to type that character into emacs :slight_smile:
edit:
ctrl-x 8 RETURN prime
meta-x describe-char


#10

The same key binding should work in julia-mode in emacs.


#11

and so they do! that’s very nice.


#12

While we are on the subject, it would be really nice if and were special characters reserved for transpose and adjoint, respectively (is there a superscript dagger? I couldn’t find it). I’ve made some ill-conceived suggestions about unicode before, but I feel pretty confident that this one is pretty universal. Obviously, this wouldn’t need to replace the current ascii forms.


#13

About , see https://github.com/JuliaLang/julia/pull/19344.


#14

Opened an issue about this here.


#15

The more I think about ? the more I think it’s a good idea. The possibility of having ugly expressions like isthistrue? ? :yes : :no makes me a bit uncomfortable, but at least in the most common usage ? would only appear in function names (if everyone behaves themselves).

One further qualifying comment I have about this is that there are loads of unicode characters available for this sort of thing, but freeing up ? seems valuable since it can be easily typed without Julia-specific tools (how is LaTeX-to-Unicode not a ubiquitous thing?!).


#16

Yeah ¿ (\textquestiondown) is a decent substitute, with the caveat that it takes a lot longer to type.


#17

This is a common naming pattern in Ruby, used to designate Bool values. This would make prepending is to function names unnecessary.

Thus, functions like isempty would become empty? which would pair nicely with existing empty!.

x |> empty? && do_stuff() would be very nice. But I find that empty?(x) affects readability.

A significant difference from Ruby is that parentheses around arguments in Ruby are optional. And the guidelines recommend that they are not added to methods that take 0 arguments, both when defining and when invoking the methods.

But Ruby is strongly OOP focused, so code looks like connection.ready? or number.zero? or array.empty? etc.

But since Julia leans towards a FP syntax, we’d end up with ready?(connection) or zero?(number) or empty?(array) etc.

Bottom line, OOP dot invocation of 0 argument methods returning booleans looks great with ?. For FP it hinders readability.

However, if Julia would fully implement the pipe operator to be usable everywhere (by supporting piping to methods taking multiple arguments) then methods ending in ? could promote writing beautiful piped code.


#18

This is an interesting discussion. However, while I sometimes miss the ability to include pretty much any character into variable/function names for languages with an S-expression surface syntax (pretty much Lisp, with functions like CL:1+), for languages which allow an infix syntax (eg Julia) this could easily end up visually confusing even if parser acrobatics could support it.

I that the status quo is pretty much a sweet spot.


#19

I’m not so enthused with this suggestion, and prefer the is prefix.

Firstly, putting in a ? seems to imply that there is something special about the function that needs to be called attention to. Newbies tend to ask what’s up with the ! at the end of some function names. It looks like it perhaps does something to the previous function automatically. It’s just a convention, but it indicates something that is a pretty big deal, namely mutation on an input variable. In contrast, there is nothing special about checking whether a variable e.g. equals zero that warrants such eye-catching syntax. I think it will only be confusing, where iszero is crystal clear.

Secondly, checking some property of a variable isn’t necessarily naturally phrased as a question at all. Observe:

if myvar is zero
    then do this
    else do that

I mean to say that these checks are tests or conditions, not questions. A question mark is out of place, because you’re not asking a question.

Edit: Also, thinking a bit more: if !zero?(x) looks pretty bad. “What the heck is going on here, and is there a connection with the zero function?”


#20

I disagree. The question mark indicates that the return value of the function is a boolean. Now there is nothing special about a boolean per se, but giving people information about the function without looking up the definition is the key. Its one character that tells you a lot about what the code is doing at a glance, much in the same way ! does.

The thing about is- is that it simply isn’t the way all predicates are stated in the english language. If it was, I’d be all for prefixing with is. Predicates do always state something about an object, which can always be rephrased as a question.

example:

“myvar is zero” --> “is myvar zero?”
“array contains 10” --> “does array contain 10?”

The question mark is also a faster read. No ambiguity arises because it reads as a seperate piece of punctuation. For instance iseven can be read as “i seven” or “is even” but even? has no such problem.