Some Syntactic Sugar for end Keyword

[Rayan Ivaturi]

How about having end as a function to make the code look clean when there are many blocks and 'end'up with a series of  continuous end statements?

 

Consider the following piece of code for  looping to create a term-frequency dictionary (quoted from http://randyzwitch.com/julia-language-beginners/)

 

term_freq=Dict{String, Int64}()
for word in english_dictionary
    for url in url_list
        if search(line, word) != (0:-1)
            term_freq[word]=get(term_freq,word,0)+1
        end
    end
end

 

If this can be written as the below snippet by making end as function with argument as number, which matches the 2 for loops and one if statement? Might look more clean.

 

term_freq=Dict{String, Int64}()
for word in english_dictionary
    for url in url_list
        if search(line, word) != (0:-1)
            term_freq[word]=get(term_freq,word,0)+1       
end(3)

 

of course, this particular use case applies only when there is a continuous series of end statements only...

[John Myles White]

I don’t think it’s likely that any changes are going to be made regarding the use of “end” in the language. I’d say this is one element of the language design that’s probably settled into its final state already.

 — John

[Chris Foster]

Huh, at first I thought this could be done with a macro (not that I'd
recommend using any such macro in actual code!), but when I tried I
couldn't quote an incomplete block:

julia> :(end)
ERROR: syntax: unexpected end

Looking at the underlying Expr for :(begin end) it becomes clear why
this is: the block itself is a single node in the AST (and what else
could it be, anyway). It's an interesting limitation though which
took a few minutes of digging to understand. Now, messing with the
syntax of basic blocks is something you can do with the C
preprocessor... but you inevitably feel rather dirty after doing so
:-)

By the way, what you're proposing is actually a new piece of syntax
rather than the addition of a function.

~Chris

[harven]

There are some alternative constructs that reduce the `end` noise, e.g.

     for word in english_dictionary, url in url_list
       search(line, word) != (0:-1) && (term_freq[word]=get(term_freq,word,0)+1)
    end

other examples:
 
    begin
       expression1
       expression2
    end

is equivalent to

  (expression1;  expression2)

if/then/else/end can be written using the ternary operator ?:  etc.

[Rayan Ivaturi]

Yes, but when there are distinct blocks of code and 'end' is just for marking the close of the block, may be one single 'end' would do. like

 
term_freq=Dict{String, Int64}()
for word in english_dictionary
    for url in url_list

        if search(line, word) != (0:-1)
            term_freq[word]=get(term_freq,word,0)+1       
end

But again this causes lot of confusion both for parser and programmer and brings in the indentation bites of python...

Looks like the end clutter can't be removed.. but much preferred over indentation.

--
Regards,
Rayan Ivaturi

[km]

why not just adapt indendation concept from python and forget about these trailing "end"s ?

"for loops" are ubuquitous  and the trailing end statements makes the code more redundant. infact boiler plate stuff is boring.

[John Myles White]

I don't see any future in which Julia is going to adopt Python's indentation rules. Discussing the issue seems like a total waste of people's time.

 -- John

[Kevin Squire]

For people just coming here, you'll find that this topic has been discussed many times before, and people who have been here for a while are kind of tired of discussing it. 

While only at version 0.3 (upcoming), Julia has also been around for a few years, and has a big enough installed base that large, incompatible changes are relatively unlikely, especially with regard to syntax. 

Anyone is feel free to fork and reimplement the parser using indentation, if they prefer, though. It is free software, after all. :-)

Cheers!

   Kevin 

[Rayan Ivaturi]

Yes.. the Julia's way of 'end' is just fine. It makes things easy and obvious.

[Steven G. Johnson]

To maximize terseness, why not eliminate all the vowels in Julia keywords?   For the most part, they serve no useful purpose.   Wouldn't our code be much easier to write if we could simply type fr, whl, brk, bgn, nd, fnctn, mcr, f, lsf, ls, and so on?

As my friend Matteo likes to say, "The Bible was written without vowels.  Don't try to outsmart the Bible."

(This occasionally does introduce a few ambiguities, e.g. it is not entirely clear whether, in Genesis, God created or destroyed the Earth, but a good editor and parser can always manage that sort of minor distinction.)

[Stefan Karpinski]

I kind of like a lot of those keywords. Seems like a pretty good change for next April.

[Bill McLean]

Fortran allows more verbose 'end' statements.  For instance, given

 real function foo(x)
 ...

 you can finish the function body with 'end' or 'end function' or 'end function foo'.  Permitting this in Julia would not
 break any existing code.  I guess you can achieve a similar effect with comments,

 end # function foo

 but actually parsing the longer form end statement might help detect some bugs.  Fortran also allows optional
 statement labels on do-loops to handle situations where you want to exit from an outer iteration, e.g.,

 outer: do i = 1, 1000
    inner: do j = 1, 1000
       ...
       if ( a(i,j) < 0.0 ) exit outer
    end do inner
 end do outer

 Without the label, 'exit' causes the program to exit from the innermost enclosing loop. I don't know if there is any
 simple way to achieve this effect in Julia.

[Mauro]

I like Fortran's annotated end's and would like to see them in Julia.
And it wouldn't break any code as they are voluntary. But yes, the
comments work too which is what I do now.

--

[Simon Danisch]

My philosophy is to have a language as simple and concise as possible. 

Every optional or alternative term makes it a little harder to read code written by another person.

Like code folding, hiding of comments, etc, this should be really rather an IDE feature, so that one can turn it on and off.

[Ivar Nesje]

It would be great if an IDE could add comments after end if the opening of the block can't fit on the same screen. A code formatter should definitely implement something like that. 

A syntax would be nice, because Julia could issue warnings/errors when the two come out of sync. It could also be helpful to give better error messages for missing/extra `end` statements. The only objection I can see is that it makes the language and implementation more complex, and it will increase the time it takes to learn Julia. That is a high price for a feature that is rarely used.

Ivar

[Peter Simon]

I would welcome Fortran-style end- and loop-labeling.  Emacs' F90 mode inserts these labels for you automatically on the corresponding end statements if you had previously included them on the opening do, function, subroutine, module, etc., statement.  The ability to concisely, clearly, and efficiently exit from a deeply nested loop structure is very powerful and useful.

--Peter