[Feature] Support for user-defined types

[algoritmist]

Problem description.
Bash is quite useful in sequential data processing until there are complex data structures
Solution
We can improve this in Amber by adding user-defined types that will be converted by compiler to a format compatible with tools like sort, tee and awk. For example

struct TimeStamp{
    hours: Int
    minutes: Int
    seconds: Int
}

struct Coords{
    x: Float
    y: Float
    s: TimeStamp
}

let t1 = {12, 18, 50} : TimeStamp
let c1 = {50.0, 30.2, t1} : Coords

Converts to:

Coords.x  Coords.y  Coords.TimeStamp.hours  Coords.TimeStamp.minutes  Coords.TimeStamp.seconds
50.0      30.2      12                      18                        50

Using a list of UserTypes we can define some data processing functions that will be converted to sequence of bash commands behind the scene.

let t2 = {12, 43, 10} : TimeStamp
let c2 = {40.0, 50.1, t2} : Coords
let coordsArr = [c1, c2]

Lets find the coord with max X coordinate

let coord = max(Coords.x, coordsArr)

Will be converted to

echo "data in format above" | sort -n | tail -1

Alternatives
This issue suggests another way of solving the problem, though I think sequential data processing will be a more common usage in Amber. That's why I would like to propose this format for user-defined types

[b1ek]

what do you think this should compile to?

let t2 = {12, 43, 10} : TimeStamp

also probably a duplicate of #66 and #80 as you mentioned

[algoritmist]

what do you think this should compile to?

let t2 = {12, 43, 10} : TimeStamp

My initial thought was to compile it to a String and treat it in a CSV-like way, but I see it doesn't work well when defining c2

TimeStamp.hours  TimeStamp.minutes  TimeStamp.seconds
12               43                 10

We could drop the header and use it only when necessary (with a function show_header() for example). More exactly t2 will compile to "12\t43\t\10". c2 will be "40.0\t50.1\t12\t43\t\10". Using the separator \t we can convert values from Struct to String representation and vise versa. Of course there will be more tricky strings, so we can probably use some CSV parser to handle them.

also probably a duplicate of #66 and #80 as you mentioned
The dictionary mentioned in #66 doesn't take types into account, my idea is to introduce a type system that will allow for compile-type checks.

Ιnitially I've missed the #66 while looking for same issues. I see there are some problems in handling custom data structures. My idea was more about the type system rather than the actual representation