really? that is exactly the reason ?? nothing else?
(of course, I mean only if everyone can choose not to use it. I do not want to remove ‘end’.)
Correct. C preprocessors does not respect ANY semantics of the C language. It’s a language of it’s own. This of course leads to many other problems and the infamous hygiene (scope) is just one of them, a minor one if you ask me compare to not being able to reason anything about a macros behavior without looking at its definition or document.
The point is that if you want to use it, you’ll either force other people to use it or you’ll force people to mix.
it is the same in julia. macro hygiene is still a problem in julia. I think there are other problems with the C peprrocessor, too. this ability to tinker with redefining words is not exactly the problem. there are many other problems—it is a powerful tool that can be used badly, and not powerful enough to do everything one may want to do.
forcing other people to have to look up my code (e.g., my callmyroutine()) when they want to understand my code is also still a problem now. and I venture to guess that ‘endfor’ is likely to be more innocuous and less demanding on others than, say, having them try to figure out callmyroutine().
but we can agree to disagree.
If you wanted to do this kind of preprocessing correctly, you would need a full Julia parser that accepts endif, etc., where the standard Julia parser accepts end and which then replaces each such instance with end. Presumably, you’d want this to also enforce that endif is paired with if and not with for (for example).
There are various other complications. For example, endif is a perfectly valid identifier in Julia code. What would you do with code which used endif as an identifier? What if it was used in a position where an end paired with an if could legitimately go? For example:
if cond
# ...
endif || println("something")
end
1 Like
I guess you may get this idea from Fortran, however, even if you have endif, endfor, etc., when there are nested structures, these identifications will quickly lose effects, then you may need endif1, endif2, endif3, endfor1, endfor2, endfor3…
This will make your code look super verbose. I guess one way of not getting confused by nested structure is to use features similar to colorized brackets. Such features need be from editors instead of Julia itself. For example, see:
https://marketplace.visualstudio.com/items?itemName=CoenraadS.bracket-pair-colorizer
PS: Thanks for your free text book!
No. Not in the same way. Hygienic macro in C can be impossible. Hygienic macro in julia should always be possible, but does need care.
As I said, it’s not the redefinining word that I’m talking about. It’s doing anything that doesn’t respect C syntax.
I should clarify that by “why C macros are terrible” I mean “why using C macros are terrible”. I’m not talking about their limitations. I also didn’t say this is the only reason (and by exact reason I am refering to this single most important one). I’m intersted (to see examples of other terrible things C macros are allowed to do but practically I do still believe what I said is the main reason one should not implement something as macro as long as it’s possible.
And I didn’t say there’s no problem now. It’s replying to “any cost”, or whether it’s creating more problem.
Exactly. That’s why I think having this comment style for blocks that are rarely nested and can be long is good for a linter. Not at all as a new, alternative syntax though.
1 Like
Why not use an editor that tells you what sort of expression an ‘end’ or ) closes
6 Likes
In cases where the closing end is more than one screen height away from the opening of the block, I tend to just make source code comments end #loop over xyz done, computed abc. Having more functions also helps.
If you don’t want tooling support anyway, then what is the problem with this?
1 Like
I guess I don’t understand the need for this. You should use indentation, and with any modern editor you also get indent guides, like this:
All these extra keywords seem like they would cause a lot of visual and cognitive noise.
3 Likes
I am indeed using end#if# these days. it’s ok…a few extra chars. the functionality difference is modest.
endif could be used, if so desired, on the same line with subsequent statements, presumably in one-liners. then again, a plain end on a one-liner is easy to understand.
I wouldn’t expect endif to have meaning that is different from end…a pure alias. but, yes, of course, a check would be nice, but it is not necessary. I could then write my own lint program that checks my own code to make sure that I have not lost track over my few pages of code. Indeed, I have written little-lints to match my end#if#.
there is a visual clarity advantage for a long function (or conditional), where the start is no longer on screen. there is plenty of julia code in important packages that is long enough to go beyond a laptop height. the most common problem here that I have is to determine whether my end closes a conditional or the loop.
yes, tooling could use it.
most important to me, I occasionally need to write (incorrect q&d) parsers for julia fragments. this is a little easier with matching ends. the one-liners that do not allow me to use end#if# end#while# make this a problem. (ok, the one-liner conditionals, like (bool) && y=2, can reduce the need for consecutive ends.)
endif and a few others would really have to become a reserved keyword. I know keywords should not proliferate, but using words like endif as a variable name sounds like a lousy idea, anyway, esp. for anyone who has to switch languages.
the shell language also uses endif. probably a few more.
PS: my post-update really was about the fact that the @for macro did not work.
You can get an overview of what kinds of blocking syntaxes different languages use here:
There is a fairly strong temporal trend from older languages using various matching closing keyword schemes towards more modern languages using either C-style { and } for all blocks or using various opening keywords (if, for, while) with end as a common closing token. We have deliberately tried to keep the syntax as bland and standard as possible for modern Algol-derived languages. Not everyone will love every specific choice but giving everyone the ability to make up their own idiosyncratic dialect of Julia would lead to a really unfortunate situation. Frankly, I’d like to follow Go here and have a completely standard formatting to reduce the spurious variation in Julia syntax even further. The main reason we haven’t gone there is simply for lack of an appropriate formatting tool.
3 Likes
as an old perl, C, and R hack, I am most used to curly parens. julia is my first end language for general use. my most common confusion about julia (because I often switch langauges) is that types follow rather than precede variable name arguments in functions. it’s just is a matter of getting used to it.
may I ask what the “Go” syntax is that you like? I don’t know Go, but it says it uses curly paren blocks.
Is the julia syntax too complex to offer a “simplified” julia fragment parser (in Julia). For example, in one of my use cases, I need to determine when the REPL will come back. and then there is the painful aspect of string (escape) parsing, but this is the case in almost all languages.
It’s not the syntax, it’s the fact that Go has a standard format which is applied to code automatically and which has, as far as I know, zero options: there is a single comletely standardized way of writing Go code.
No, it’s not all that complicated and simpler than many languages which require global state for parsing. The CSTParser package may do what you want.
1 Like
Sometimes I follow end with a comment.
function foo!(A)
for in eachindex(A)
if A[i] < 0
A[i] = 3
end #if
end #for
end #foo!
yes, it would indeed be nice to have this.
DNF—actually, my emacs editor does not give me the vertical lines, but it can help indent. the confusion comes in when the distance between top and bottom increases—with the extreme of the top having scrolled off the screen. /iaw
You realize this is in principle opposite of what you’re asking for in this thread? This thread is asking for a feature that allows insignificant syntactic variation whereas an autoformatting tool would eliminate all insignificant syntactic variations. In other words even if the language allowed it, an autoformatter would change all instances of endif to end.
3 Likes
I thought of it as a “formatting tool” that I can use when I want to…and perhaps even modify to my own taste (which admittedly defeats your purpose of universal consistency, but allows me to make all my own code to be consistent “my way”).
That’s not the way Go went with it—there are no options and everyone is expected to use it.