Standard library

[emil14]

Stdlib is a set of packages, maybe organized into some hierarchy. And like any package those packages consist of exported and unexported entities like types, messages and components.

One of the most important things to consider is what components must be present? We can call such components "operators" (non-technical term).

[emil14]

Locker

[emil14]

Operators

• +
• -
• *
• /
• %
• !
• &
• <-
• ^

+

• bool
• int - adding like in go
• float - adding like in go
• str - concatenation like in go
• list - appending like in go with variadil args
• dict - merging (righest arg is strongest)
• struct

-

• bool
• int
• float
• str
• list
• dict
• struct

*

• bool
• int
• float
• str
• list
• dict
• struct

/

• bool
• int
• float
• str
• list
• dict
• struct

[emil14]

https://ru.wikipedia.org/wiki/%D0%A2%D0%B0%D0%B1%D0%BB%D0%B8%D1%86%D0%B0_%D0%BC%D0%B0%D1%82%D0%B5%D0%BC%D0%B0%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D1%85_%D1%81%D0%B8%D0%BC%D0%B2%D0%BE%D0%BB%D0%BE%D0%B2

can be used as an inspiration

[emil14]

Builders (constructors)

Array

Arrport based

f<t, y [2]t> (els[] t) (arr y)

Steam based (batcher)

f<t, y [2]t> (el t) (arr y) # sends array any time enough elements arrived

Record

f<t {}> (...t) (rec t)

Vec

f<t> (v substeam<t>) (vec<t>)

Arr-port based solution also possible (but may not be very useful)

Map

Naive

Might be problem with sync stuff

f<k,v> (a k, b v) map<k,v>

Rec-based

f<k,v> (pair {k,v}) map<k,v>