# How are called in Julia terminology Int64, Float64,... vs Array{T,1}, Tuple{T1,T2,...}, Set{T},

**URL:** <https://discourse.julialang.org/t/how-are-called-in-julia-terminology-int64-float64-vs-array-t-1-tuple-t1-t2-set-t/21006>\
**Category:** General Usage\
**Created:** [February 20, 2019, 10:19am UTC](https://discourse.julialang.org/t/how-are-called-in-julia-terminology-int64-float64-vs-array-t-1-tuple-t1-t2-set-t/21006 "2019-02-20T10:19:17Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![sylvaticus](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sylvaticus/32/203883_2.png) [@sylvaticus](https://discourse.julialang.org/u/sylvaticus)\
**Post date:** [February 20, 2019, 10:19am UTC](https://discourse.julialang.org/t/how-are-called-in-julia-terminology-int64-float64-vs-array-t-1-tuple-t1-t2-set-t/21006/1 "2019-02-20T10:19:18Z")

</div>

Just to ask which is the correct terminology to differentiate Int64, Float64, Bool, Char, String (that I notices is not an Array of chars) on one side vs Array{T,N}, Tuple{T1,T2,…}, Set{T}, Dict{}…, and in general T1{T2} on the other side…

“primitive” vs “composite” ?  
“immutable” vs “mutable” (but then Tuple is immmutable) ?  
“simple” vs “container” ?

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [February 20, 2019, 10:34am UTC](https://discourse.julialang.org/t/how-are-called-in-julia-terminology-int64-float64-vs-array-t-1-tuple-t1-t2-set-t/21006/2 "2019-02-20T10:34:04Z")

</div>

Container is a good term. But note that the two sets are not disjoint, as stored elements can be containers themselves, eg

```julia
[[1, 2], [3, 4]]

```

Mutability is an orthogonal concept.

The terminology can become somewhat fuzzy. Eg `1:10` can behave like a container (`<: AbstractVector`), but strictly speaking does not “contain” the integers between `1` and `10`. But this does not matter, as the caller should not care.

---

<div class="post-metadata">

**Author:** ![pfitzseb](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pfitzseb/32/45566_2.png) [@pfitzseb](https://discourse.julialang.org/u/pfitzseb)\
**Post date:** [February 20, 2019, 10:36am UTC](https://discourse.julialang.org/t/how-are-called-in-julia-terminology-int64-float64-vs-array-t-1-tuple-t1-t2-set-t/21006/3 "2019-02-20T10:36:01Z")

</div>

Are you looking for [“parametric” vs “non-parametric” types](https://docs.julialang.org/en/v1.1/manual/types/#Parametric-Types-1)?

---

<div class="post-metadata">

**Author:** ![bennedich](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bennedich/32/4894_2.png) [@bennedich](https://discourse.julialang.org/u/bennedich)\
**Post date:** [February 20, 2019, 11:39am UTC](https://discourse.julialang.org/t/how-are-called-in-julia-terminology-int64-float64-vs-array-t-1-tuple-t1-t2-set-t/21006/4 "2019-02-20T11:39:50Z")

</div>

> [@sylvaticus](#):
>
> which is the correct terminology /…/ T1{T2} on the other side

This is indeed called _parametric types_.

(Although the examples you list (`Array`, `Set` etc) are also all “collection” or “container” types.)

---

<div class="post-metadata">

**Author:** ![sylvaticus](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sylvaticus/32/203883_2.png) [@sylvaticus](https://discourse.julialang.org/u/sylvaticus)\
**Post date:** [February 20, 2019, 12:20pm UTC](https://discourse.julialang.org/t/how-are-called-in-julia-terminology-int64-float64-vs-array-t-1-tuple-t1-t2-set-t/21006/5 "2019-02-20T12:20:26Z")

</div>

I think `container` or `collection` is the concept I was interested to, as I am trying to understand the difference between _name binding_, `copy()` and `deepcopy()`, although I realised I do not need to use this difference:

I would state:

In order to unnecessarily copying large amount of data, Julia by default copies only the memory address of objects, unless the programmer explicitly request a so-called “deep” copy. In detail:

_Equal sign (a=b)_

- performs a _name binding_, i.e. binds the entity (object) referenced by `b` also to the `a` identifier (variable name)
- it results that:
  - if `b` then rebinds to some other object, `a` remains referenced to the original object
  - if the object referenced by `b` mutates (i.e. it internally changes), so does (being the same object) those referenced by `a`

_a = copy(b)_

- create a new, “independent” copy of the object and bind it to `a`. This new object may however reference in turn other objects trough their memory address. In this case it is the memory address that is copied and not the referenced object itself.
- it results that:
  - if the referenced objects are rebind to some other objects, the new object referenced by `a` maintains the reference to the original objects
  - if the referenced objects mutate, so do (being the same objects) those referenced by the new object referenced by `a`

_a = deepcopy(b)_

- everything is deep copied recursively

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [February 20, 2019, 12:53pm UTC](https://discourse.julialang.org/t/how-are-called-in-julia-terminology-int64-float64-vs-array-t-1-tuple-t1-t2-set-t/21006/6 "2019-02-20T12:53:20Z")

</div>

> [@sylvaticus](#):
>
> Julia by default copies only the memory address of objects

This is a common misconception. What happens is that the language is free to copy or not copy objects for which the user cannot distinguish whether copying happened. This allows the compiler various optimizations.

You may be interested in past discussions like

> [@Where exactly memory copies happen in Julia code?](https://discourse.julialang.org/t/where-exactly-memory-copies-happen-in-julia-code/5595):
>
> I have a simple question about memory management in Julia code. Coming from a C++ background with all that [rvalue reference](http://thbecker.net/articles/rvalue_references/section_01.html) madness and move semantics stuff, I got my brain damaged, and I am having a hard time trying to reason about memory management again in other languages. Consider the following cases: Case 1 I have an immutable struct that requires a decent amount of memory (e.g. mesh with vertices, edges, triangles). By using composition, I define other concepts (e.g. path): abstract ty…

> [@Assignment and argument passing semantics](https://discourse.julialang.org/t/assignment-and-argument-passing-semantics/17034):
>
> This is a short summary based on what I understood from documentation, and [this long thread](https://discourse.julialang.org/t/variable-binding-re-assignment-argument-passing-let-scope/16840) , without mixing in (much of) scope rules, or any implementation details. I will appreciate if somebody could check it’s validity. Given that expr is either an expression evaluating to (returning) an object, or a literal object, either mutable or immutable, and not just a name ; and f(y) = do\_with(y) then: x= expr makes the name/variable x bind to a new object (with new “reference” hence n…

> [@Why mutable structs are allocated on the heap?](https://discourse.julialang.org/t/why-mutable-structs-are-allocated-on-the-heap/12992):
>
> From [https://docs.julialang.org/en/latest/manual/types/#Mutable-Composite-Types-1:](https://docs.julialang.org/en/latest/manual/types/#Mutable-Composite-Types-1:) In order to support mutation, such objects are generally allocated on the heap, and have stable memory addresses. If I define: mutable struct MyT x::Int end and then use MyT inside a function, such as: function f(x::Int) q = MyT(x); q.x += 1 return q.x end I would expect q to be allocated on the stack, because it is a local variable that does not change type and MyT is isbits. But it is not: @btime f(1)…

but the bottom line is that deliberately leaving this unspecified and hidden from the user in normal circumstances is an important feature, and can be exploited by using immutables.