not = !

[ShalokShalom]

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]

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]

Hmm, true.

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

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

[cormullion]

See also

#19788

[ShalokShalom]

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.

[vtjnash]

The issue is that it won't help to just add and as an alias for &&, since new programmers will still frequently encounter && in other code, so they cannot avoid needing to learn that it means the same as and. There was much development in the direction of trying to make scripts very natural english in the past, but they end up reading as quite stilted english, gaining little in clarity nor reducing friction for users by much. If you are interested in this line of research, a language that is still widely available and used which had that goal is AppleScript for which you can see some examples here.

The decision in #19788 was primarily that it was not worth the churn to consider a change of that magnitude at that point in the languages evolution. That is only more true now.

[ShalokShalom]

I don't really see, why newcomers have to encounter 'other code' at all, as they may stick with their learning material and exercises. 😃

As a student, you are unlikely to tap into 'wild code' and in order to gain an understanding of the language, is it surely not needed, to understand && and ||, and besides that is it just not as nice to read, as demonstrated.

Some cases may be like that, and I think it's clear, that in some cases, literate styles are objectively more readable.

if ! updated
   update --skip-mirrorlist --noconfirm

How will hurt this the language, if we allow instead:

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

That is just a small example, and I program entirely in this style, and at least for small scripts, it has proven to be very readable.

I think it would be perfectly possible, to have both styles to be co-existing.

[DanielVandH]

I don't really see, why newcomers have to encounter 'other code' at all,

The newcomers will have to see new code one day - and indeed, Julia makes it easier to go and see other code.

Some cases may be like that, and I think it's clear, that in some cases, literate styles are objectively more readable.

I also think it would be wrong to say it's "objectively more readable", at least for !, &&, and ||... Personally, I find the symbols more readable - makes them more recognisable to me as operators (especially if you need complicated expressions or nested expressions). I also think picking up on what these symbols means is pretty easy; just as newcomers have to learn functions and e.g. adding numbers, having to learn these symbols will not hurt them.

[PallHaraldsson]

I don't like not (and and and or) as redundant ways too much since it means non-conformity.

But given there is @not already in a package (which is nonideal syntax to me), I don't see a very good reason to not allow not as an added keyword through a package...

The you would have well three ways for this... I think we should at least reserve not, and and or as (non-functioning) keywords in case we add them later (since they are bad anyway as variable names, this would be breaking though if someone has used as such already...?). The linked (closed) PR was for the Flisp parser. You could try to add in the new JuliaSyntax.jl. It does (more easily) allow for opt-in syntax. A package, for now, could cann a function to enable these as real keywords.

I had an idea where and and or are NOT synonym for && and ||, so at least don't add them, nor as macro in a package. But the experiment could be started for not.

[ShalokShalom]

Could I raise this issue at JuliaSyntax, or would it be more appropriate to succeed that here?

I mean, its easy enough for me to just const not = ! (this is why I still wonder why there is a macro) but I care about other newbies and the general sentiment towards literate programming generally.

I had an idea where and and or are NOT synonym for && and ||

How would they differ, in your experiment? The fish shell has a different precedence for them, but I don't know if I would like that.

I would probably prefer to just define my not myself. 😄

[PallHaraldsson]

You could of course open an issue at JuliaSyntax.jl; I've discussed there opt-in syntax already, which wasn't ruled out (and either way it would end up there). But for non-opt-in, then this is not just a package like any other, since it's a (upgradable?) stdlib, and people at JuliaLang would have a say, and likely object. Even for opt-in syntax, it might make Julia a tiny bit slower to start, maybe not if this extra code is not precompiled, so people might also object to opt-in syntax.

I mainly suggested JuliaSyntax.jl since there you could add yourself (maybe with help from others). Just opening an issue means expectation of help to add this or at least help/guidence. You can ask if this would never be merged. You can fork the package and work on a PR yourself, then less of a burden to just review a concrete PR, then an idea?

What a PR there mean is that you might have enable_not_keyword() in your main file and it would work for all code, and unclear to me also packages. It seems easiest to me that this is a global option rather than opt-in into each package that would have to add a dependency to NotMacro.jl which would surely be annoying to do. I don't see a good other definition for not (except a variable) so it seems like we don't want to apt in that way, which allows different name-space for each module that imports.

[ShalokShalom]

Why would that be a macro in the first place?

What is the benefit of the macro compared to const not = !?

I will evaluate to raise on issue on JuliaSyntax.

[PallHaraldsson]

Before you spend too much of your (or others) time on this, consider the downsides:

Arguably it helps to have not for English speakers, or people coming from Python. But now you have to explain why not and !, and why not and and and or available too (unless you convince people of that, and for me, I wanted those for parallel programming, still same precedence).

I've not looked at literate programming closely, but to me it implies literate [English] programming. We are not going to add nicht (German), ekki (Icelandic), ikke (Danish) etc. You might say well Julia is English (but it's not really), with e.g. while keyword. To a Chinese person ! is something to learn once, and not might not be better (three keystrokes to learn), or the confusion of having both meaning the same.

I'm not saying Chinese people wouldn't know English or the Latin alphabet, likely most educated people do. But not all people, e.g. for teaching programming to kids. Then not and while are just a string of keystrokes... E.g. I started learned English BTW, when I was 10 years old (for the computer I had just bought) from my Oric-1 BASIC manual just to do programming, such as SAVE keyword (why?).

[ShalokShalom]

I really think having Chinese languages, are ultimately transpiler to translate the keywords, would more help here.

Literate programming is generally about .. well literate programming. 😄

[ShalokShalom]

And yes, I want and and or as well. 😃 👍🏻