# Why begin/end instead of { } for block delimiter
**URL:** https://discourse.julialang.org/t/why-begin-end-instead-of-for-block-delimiter/89735
**Category:** Internals & Design
**Created:** [November 3, 2022, 8:25pm UTC](https://discourse.julialang.org/t/why-begin-end-instead-of-for-block-delimiter/89735 "2022-11-03T20:25:19Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@jar1](https://discourse.julialang.org/u/jar1)
#### Post date: [November 3, 2022, 8:25pm UTC](https://discourse.julialang.org/t/why-begin-end-instead-of-for-block-delimiter/89735/1 "2022-11-03T20:25:19Z")
Why does Julia use `begin`/`end` as the block delimiter instead of the more common and concise `{ }`? Why is that better?
---
### Author:  [@adienes](https://discourse.julialang.org/u/adienes)
#### Post date: [November 3, 2022, 8:28pm UTC](https://discourse.julialang.org/t/why-begin-end-instead-of-for-block-delimiter/89735/2 "2022-11-03T20:28:27Z")
`{}` is used for types.
Also `end` can end any of `let`, `for`, `while`, `if`, `function`, `struct`, `module` etc. so it means an opening `{` can be skipped. After all, it’s just `for ... end`, not `for begin ... end`
---
### Author:  [@jar1](https://discourse.julialang.org/u/jar1)
#### Post date: [November 3, 2022, 8:32pm UTC](https://discourse.julialang.org/t/why-begin-end-instead-of-for-block-delimiter/89735/3 "2022-11-03T20:32:20Z")
That means built-in blocks are easier than user-defined blocks, which I consider bad not good. Still `{}` is shorter than `end` anyway.
---
### Author:  [@adienes](https://discourse.julialang.org/u/adienes)
#### Post date: [November 3, 2022, 8:35pm UTC](https://discourse.julialang.org/t/why-begin-end-instead-of-for-block-delimiter/89735/4 "2022-11-03T20:35:39Z")
Unfortunately, [Julia is not at that stage of development anymore](https://discourse.julialang.org/t/psa-julia-is-not-at-that-stage-of-development-anymore/44872). I hope this minor syntax choice will not be a blocker for you to explore the language.
---
### Author:  [@jar1](https://discourse.julialang.org/u/jar1)
#### Post date: [November 3, 2022, 8:37pm UTC](https://discourse.julialang.org/t/why-begin-end-instead-of-for-block-delimiter/89735/5 "2022-11-03T20:37:44Z")
At this point I’m just looking for an explanation of why it is this way.
---
### Author:  [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [November 3, 2022, 8:43pm UTC](https://discourse.julialang.org/t/why-begin-end-instead-of-for-block-delimiter/89735/6 "2022-11-03T20:43:51Z")
Parameterized types are used heavily in Julia, and are often deeply nested ala `Dict{Int,Vector{Complex{Float64}}}`, so a compact (single-character bracket) ASCII symbol was crucial, and there aren’t many to choose from. (C++ was forced to choose `<...>` and it’s a mess for nesting because `<` and `<<` are also operators.)
`begin/end` blocks are used much less densely — you rarely have multiple nested blocks on a single line! — and anyway we actually do have a shorthand `(a; b; c)` for `begin a; b; c; end`. So, the preference was for a slightly more verbose, human-readable syntax.
There is also the fact that Julia’s surface syntax and keywords were (very loosely) influenced by Matlab, among other influences.
(In the early days of Julia, we also had regular influxes of Python programmers asking why we didn’t use indentation for blocks, which “everyone knows” is vastly superior.)
---
### Author:  [@jar1](https://discourse.julialang.org/u/jar1)
#### Post date: [November 3, 2022, 8:55pm UTC](https://discourse.julialang.org/t/why-begin-end-instead-of-for-block-delimiter/89735/7 "2022-11-03T20:55:17Z")
Thanks. I think something is missing from this explanation though.
> [@stevengj](#):
>
> Parameterized types are used heavily in Julia, and are often deeply nested ala `Dict{Int,Vector{Complex{Float64}}}`, so a compact (single-character bracket) ASCII symbol was crucial, and there aren’t many to choose from.
Block delimiter syntax doesn’t conflict with postfix — after all, `()` is used for both currently: `f()` and `(a; b)`. So `{a; b}` would be okay.
> [@stevengj](#):
>
> `begin/end` blocks are used much less densely — you rarely have multiple nested blocks on a single line! — and anyway we actually do have a shorthand `(a; b; c)` for `begin; a; b; c; end`.
However `()` is used much more densely than the others, namely in function calls and tuples. Moreover, `(a; b)` conflicts with what could have been a very nice syntax for the [FrankenTuple](https://github.com/ararslan/FrankenTuples.jl/) argument/parameter data structure.
> [@stevengj](#):
>
> There is also the fact that Julia’s surface syntax and keywords were (very loosely) influenced by Matlab, among other influences.
This seems a likely explanation given Matlab’s `end` syntax (though I don’t see a `begin` there).
---
### Author:  [@apo383](https://discourse.julialang.org/u/apo383)
#### Post date: [November 3, 2022, 8:59pm UTC](https://discourse.julialang.org/t/why-begin-end-instead-of-for-block-delimiter/89735/8 "2022-11-03T20:59:51Z")
> [@jar1](#):
>
> Why is that better?
I don’t recall seeing claims that this is better, it is merely different. I can’t say whether the devs were influenced by Python, but that’s another language that has rethought syntax and freed up curly braces for other things. If you stick around long enough in computing, you’ll see a variety of approaches to syntax, and which is “better” is difficult to resolve, and subject to change over time.
Personally, I like Julia’s syntax and currently prefer it over C style. But I prefer C over Pascal, not necessarily for any defensible reason. I can live both with and without {} blocks.
---
### Author:  [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [November 3, 2022, 9:05pm UTC](https://discourse.julialang.org/t/why-begin-end-instead-of-for-block-delimiter/89735/9 "2022-11-03T21:05:35Z")
> [@jar1](#):
>
> This seems a likely explanation given Matlab’s `end` syntax (though I don’t see a `begin` there).
There’s another thing I forgot: in the early days of Julia, `{a; b; c}` and `{a, b, c}` were syntax for what is now `Any[a; b; c]` or `Any[a, b, c]`, e.g. in Julia 0.3:
```julia
julia> {3,4,5}
3-element Array{Any,1}:
3
4
5
julia> {3;4;5}
3-element Array{Any,1}:
3
4
5
```
This was directly taken from Matlab’s [cell array](https://www.mathworks.com/help/matlab/cell-arrays.html) syntax. In Julia 0.4, this was deprecated in favor of `Any[...]` for literal arrays of arbitrary-type elements (which aren’t used that often anyway). As you say, this could have freed up the `{a; b; c}` syntax for blocks, but it would have been a big upheaval at that point, with not a huge benefit.
Now, we are free to to use `{a; b; c}` for a really cool new feature (if we can think of one) without breaking anything. It’s already available for people to use in macros for domain-specific languages because it parses:
```julia
julia> ex = Meta.parse("{a;b;c}")
:({a; b; c})
julia> dump(ex)
Expr
head: Symbol bracescat
args: Array{Any}((3,))
1: Symbol a
2: Symbol b
3: Symbol c
```
---
### Author:  [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [November 3, 2022, 9:11pm UTC](https://discourse.julialang.org/t/why-begin-end-instead-of-for-block-delimiter/89735/10 "2022-11-03T21:11:31Z")
> [@stevengj](#):
>
> Now, we are free to to use `{a; b; c}` for a really cool new feature (if we can think of one)
See also:
>
>
> The fate of the \`{}\` syntax has been debated in #7941, #7128, #2488, #6739 and m…any other threads that I cannot dig up at the moment. The current syntax is slated to change in 0.4. My suggestion was outlined by Jeff in #8470. Whatever we decide to do, this change makes it easier to transition to allowing \`\[a, b\]\` to be non-concatenating (#3737) and regularization of \`Dict\` syntax #8521.
>
> The parser should probably be changed to reject the \`{}\` array / dict syntax during the transition period. Would throwing an error be sufficient? This will be a hugely breaking change so I thought I would solicit some feedback on that.
>
>
> @jakebolewski had this very good idea today.
>
> Our tuple types are currently quit…e ugly since they are not distinguished from tuple values. This causes various problems in the system, such as whether to treat \`()\` as a type. We also need to specialize tuple representations (e.g. storing \`(Float64,Float64)\` as compactly as a \`Complex128\`), which means tuple types will need to contain extra layout information that tuple values do not have. This would also eliminate the need for a fancy predicate to test whether some tuple is a type.
>
> It would be quite easy to use \`Union{...}\` for union types, and then all types would be constructed with curly braces :+1:.
>
> This change also makes it easy to use \`(x, y...)\` for splatting in tuple construction (#4869), and \`{Int...}\` for varargs types.
>
> All current uses of \`{ }\` can be replaced with \`Any\[\]\` or \`(Any=\>Any)\[\]\`, so that syntax is effectively up for grabs. The wastefulness of the current \`{ }\` has been discussed elsewhere. I admit this proposal feels slightly wasteful as well, but it could be worth it for solving various problems in the type system and making type syntax highly consistent. On the whole, I am in favor of this idea.
---
### Author:  [@Mason](https://discourse.julialang.org/u/Mason)
#### Post date: [November 3, 2022, 11:54pm UTC](https://discourse.julialang.org/t/why-begin-end-instead-of-for-block-delimiter/89735/11 "2022-11-03T23:54:17Z")
If you want, you can use braces as block in macros.
```julia
macro b(expr)
expr.head == :bracescat || error("invalid block syntax, must write @b {...}")
expr.head = :block
esc(expr)
end
@b {
x = 1 + 1
y = 3 + 4
x + y
}
```
```julia
function in_to_eq(ex::Expr)
if ex.head == :call && ex.args[1] ∈ (:∈, :in)
Expr(:(=), ex.args[2:end]...)
else
ex
end
end
@eval macro $(Symbol("for"))(spec, body)
if body.head == :bracescat || body.head == :braces
body.head = :block
end
spec′ = if spec.head == :block
Expr(:block, in_to_eq.(spec.args)...)
else
in_to_eq(spec)
end
esc(Expr(:for, spec′, body))
end
```
```julia
@for x ∈ 1:3 {
@show x
}
#+end_src
#+RESULTS:
: x = 1
: x = 2
: x = 3
```
---
### Author:  [@jling](https://discourse.julialang.org/u/jling)
#### Post date: [November 4, 2022, 12:36am UTC](https://discourse.julialang.org/t/why-begin-end-instead-of-for-block-delimiter/89735/12 "2022-11-04T00:36:16Z")
> [@jar1](#):
>
> This seems a likely explanation given Matlab’s `end` syntax (though I don’t see a `begin` there).
Ruby and Lua both have `end` blocks btw, so it’s hardly a weird choice for Julia
---
### Author:  [@uniment](https://discourse.julialang.org/u/uniment)
#### Post date: [November 4, 2022, 4:26am UTC](https://discourse.julialang.org/t/why-begin-end-instead-of-for-block-delimiter/89735/13 "2022-11-04T04:26:53Z")
oooh juicy! Is there a [modern] thread to bounce ideas for `{...}`?
---
### Author:  [@jar1](https://discourse.julialang.org/u/jar1)
#### Post date: [November 4, 2022, 4:31am UTC](https://discourse.julialang.org/t/why-begin-end-instead-of-for-block-delimiter/89735/14 "2022-11-04T04:31:43Z")
I suspect block delimiter is the best possible meaning. `()` is so overloaded as to be unusable and `@mymacro {}` is so concise and flexible that any desired meaning would fit well in that format.
---
### Author:  [@uniment](https://discourse.julialang.org/u/uniment)
#### Post date: [November 5, 2022, 2:18am UTC](https://discourse.julialang.org/t/why-begin-end-instead-of-for-block-delimiter/89735/15 "2022-11-05T02:18:13Z")
we already have `begin` and `end` for block delimiting though; feels like there must be a more interesting use floating out there…
I like Julia’s use of `()`—it works unambiguously despite being used for all manner of things: evaluation precedence, function call, tuple, named tuple, and generator.
And then `[]` is pretty well-utilized for vectors, matrices, and the whole gamut of other arrays, as well as indexing.
Maybe `Dict`? It’s a built-in type that has no dedicated syntax. Maybe it deserves something? JavaScript uses `{}` for dynamic objects that organize into tree structures, which behave in many ways similarly to `Dict`, so this might make JavaScripters happy. Or maybe a `PropDict` (from PropDicts.jl) would be a bit nicer, with `{a=1, b=2}` being syntax sugar for `PropDict(:a=>1, :b=>2)`; then JSON could _almost_ be plugged in directly as Julia code.
Or, maybe `Set`? It’s tempting that set theory already uses curly braces for sets and for set builder notation, so maybe `{item1, item2, item3}` for `Set(item1, item2, item3)`. I wonder if it’d be interesting to make lazily evaluated (possibly infinite) sets, e.g. `evensquares = {x where y isa Int && x = y^2}`. I have zero insight into programmatic set manipulation, I’m just spitballing.
Or, for the functional language aficionados, maybe use it for the lazily evaluated `List` object from Lazy.jl… maybe `{1, 2, 3, ...}` for a list? (and assume it’s an arithmetic or geometric sequence, perhaps)
Or, considering that curly braces are already heavily used in Julia’s type system, perhaps there’s some sort of “type arithmetic” that can be done… I’m still trying to figure out how to _subtract_ a type, hah.
Or, maybe our machine learning friends can offer some ideas. Maybe it could be used as a data structure for neural nets, or maybe graphs more generally, who knows.
All I’m saying is, using `{...}` as a stand-in for `begin...end` seems wasteful. `{}` are such generally useful characters, to burn them on something that already has syntax would be a shame. (I remember as a kid how weird it felt to learn `{}` for block delimiting but eventually with practice coming to love it, and then many years later learning MatLab and feeling “hey, `end` feels fine too!”)
---
### Author:  [@cdawg](https://discourse.julialang.org/u/cdawg)
#### Post date: [November 5, 2022, 2:05pm UTC](https://discourse.julialang.org/t/why-begin-end-instead-of-for-block-delimiter/89735/16 "2022-11-05T14:05:55Z")
> [@uniment](#):
>
> Or, considering that curly braces are already heavily used in Julia’s type system, perhaps there’s some sort of “type arithmetic” that can be done… I’m still trying to figure out how to _subtract_ a type, hah.
Type arithmetic would be awesome! For statically sized objects especially, calculating the number of chunks needed in a static bit array, determining the number of arguments to a tuple parameter—Being able to define math inside type inference could maybe reduce the complexity of some of the more out of control parametric types (see the DifferentialEquations error messages) by appending compile-time information to a type…
maybe like
```julia
struct sbitarray{N, CType; nchunks} where {nchunks = cld(N,sizeof(CType)*8)}
chunks::Tuple{Varargs{Ctype,nchunks}}
end
```
but then you only see sbitarray{N, CType} for printing and the type tree (independent type variables vs. dependent type variables)
---
### Author:  [@mgkuhn](https://discourse.julialang.org/u/mgkuhn)
#### Post date: [November 7, 2022, 9:57am UTC](https://discourse.julialang.org/t/why-begin-end-instead-of-for-block-delimiter/89735/17 "2022-11-07T09:57:37Z")
I’m not sure C’s `{ }` notation is actually shorter in practice:
```julia
C: if (a < b) { c = a; a = b }
Julia: if a < b; c = a; a = b; end
```
---
### Author:  [@lawless-m](https://discourse.julialang.org/u/lawless-m)
#### Post date: [November 7, 2022, 10:06am UTC](https://discourse.julialang.org/t/why-begin-end-instead-of-for-block-delimiter/89735/18 "2022-11-07T10:06:14Z")
but you contrived that, it is 2 chars more!
```julia
if(x){y}
vs
if x;y;end
```
---
### Author:  [@Sukera](https://discourse.julialang.org/u/Sukera)
#### Post date: [November 7, 2022, 10:13am UTC](https://discourse.julialang.org/t/why-begin-end-instead-of-for-block-delimiter/89735/19 "2022-11-07T10:13:42Z")
> [@cdawg](#):
>
> Type arithmetic would be awesome! For statically sized objects especially, calculating the number of chunks needed in a static bit array, determining the number of arguments to a tuple parameter—Being able to define math inside type inference could maybe reduce the complexity of some of the more out of control parametric types (see the DifferentialEquations error messages) by appending compile-time information to a type…
See this issue for previous discussions and why that is not easy/already happens with constant propagation
>
>
> See \[this conversation\](https://github.com/JuliaLang/julia/discussions/44519) fo…r the motivation for this.
In particular,
> [@cdawg](#):
>
> Being able to define math inside type inference could maybe reduce the complexity of some of the more out of control parametric types
extending _type inference_ from the user-side means that just _loading_ a package can potentially mean having to recompile the compiler and also potentially invalidate _all code that was compiled with that compiler_. This is exactly counter to the recent push to reduce invalidations.
> [@cdawg](#):
>
> but then you only see sbitarray{N, CType} for printing and the type tree (independent type variables vs. dependent type variables)
Julia will not move to dependent typing in the foreseeable future.
---
### Author:  [@Palli](https://discourse.julialang.org/u/Palli)
#### Post date: [November 7, 2022, 10:28am UTC](https://discourse.julialang.org/t/why-begin-end-instead-of-for-block-delimiter/89735/20 "2022-11-07T10:28:22Z")
It’s not contrived since:
```julia
if(x){y}
vs.
x && y
vs. [not needed]
if x;y;end
```
[Next page](https://discourse.julialang.org/t/why-begin-end-instead-of-for-block-delimiter/89735.md?page=2)