Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

not = ! #51485

Closed
ShalokShalom opened this issue Sep 27, 2023 · 4 comments
Closed

not = ! #51485

ShalokShalom opened this issue Sep 27, 2023 · 4 comments

Comments

@ShalokShalom
Copy link

ShalokShalom commented Sep 27, 2023

I like literate programming and as such, that my code reads like a book.

Currently, there is no way to use the word "not" in that sense:

const not = !

function check(number)
    if not (number >= 0)
        error("number must be non-negative") 
    end
end

This checks for not being followed by an in, as not in is valid syntax.

And I assume, it is easy to check, if in is followed, and if not, to just use not as a replacement for !.

I don't know the policy of adding two distinct syntax elements to do the same thing, so I would also be fine with a solution that I define myself.

I would still welcome not becomes a dedicated control flow keyword, as I find ! to be unreadable for people from the outside, who read the source code within a domain driven design.

@Pangoraw
Copy link
Contributor

This checks for not being followed by an in, as not in is valid syntax.

The issue here is that space is not allowed between a function identifier and the parenthesis. Also I don't think not in is currently valid syntax. Consider the following call to function f which also does not work:

julia> f (1)
ERROR: ParseError:
# Error @ REPL[7]:1:2
f (1)
#╙ ── whitespace is not allowed here

I guess the reason for this is macro arguments where it would be impossible to distinguish between @show f (1) (shows f and 1) and @show f(1) (shows the results of f(1)).

@ShalokShalom
Copy link
Author

ShalokShalom commented Sep 28, 2023

Hmm, true.

And then, why is there a macro, if a simple const can do it?

https://github.com/jolin-io/NotMacro.jl

@cormullion
Copy link
Contributor

See also

#19788

@ShalokShalom
Copy link
Author

ShalokShalom commented Sep 29, 2023

Thanks.

The linked PR contains the argument, that both && and and carry the same meaning to everybody, and that there is no difference in clarity to anybody.

I really don't know, how anybody can come to the idea, that this is true.
&& is a completely unused symbol outside of programming and casual developers, who come from Python don't know the symbol, neither does anybody who just start to get a hang of programming.

I know it may sound picky, and if it's just a small issue, but for a newbie everything that is small for an expert, is big for themselves.

And it piles up, since this sentiment is very widespread in the community.

Why do we lay stones in the way of the people, simply based on the premise that they "will learn our ways", when we can just pick them up, from where they are?

Everybody knows what an and means. A script of mine has the following part:

if not updated
   update --skip-mirrorlist --noconfirm

Everybody in their right mind would understand this, and basically every non-programmer has no idea, what it means, once you change not to an !.

Code will not read natural for them, and I don't know, who is going to hurt, if we support programming syntax that reads natural to them.

This is just outright ignorant towards new programmers, and has an elitist attitude to it.

The science background of Julia provides strong support for symbolic programming, and I don't think that is hurting the readability for anyone, as it is optional - at least so long as literate alternatives are available.

@JuliaLang JuliaLang locked and limited conversation to collaborators Sep 29, 2023
@vtjnash vtjnash converted this issue into discussion #51507 Sep 29, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants