Basic types can be one-of:
bool: internally an enum.int: integer number. x bits of precision by default.
+int: integer number. x bits of precision by default.
uint: same as int, but unsigned for more precision.i8, i16, i32, i64, i128: specified integer sizeu8, u16, u32, u64, u128: specified integer sizei[\d+], u[\d+]: arbitrarily sized integersfloat: floating-point number.
@@ -194,19 +193,19 @@
f32, f64: specified float sizesdecimal: precision decimal number.
+decimal: precision decimal number.
dec32, dec64, dec128: specified decimal sizesbyte: an alias to u8.char: a distinct alias to u32. For working with Unicode. str: a string type. mutable. internally a byte-array: externally a char-array.void: an internal type designating the absence of a value. often elided. never: a type that denotes functions that do not return. distinct from returning nothing. char: an alias to u32. For working with Unicode.str: a string type. mutable. packed: internally a byte-array, externally a char-array.void: an internal type designating the absence of a value. often elided.never: a type that denotes functions that do not return. distinct from returning nothing.bool and int/uint/float and siblings (and subsequently byte and char) are all considered primitive types and are always copied (unless passed as mutable). More on when parameters are passed by value vs. passed by reference can be found in the memory management document.
Primitive types combine with str, void, and never to form basic types. void and never will rarely be referenced by name: instead, the absence of a type typically implicitly denotes one or the other. Still, having a name is helpful in some situations.
Primitive types, alongside str, void, and never, form basic types. void and never will rarely be referenced by name: instead, the absence of a type typically implicitly denotes one or the other. Still, having a name is helpful in some situations.
todo
They are also quite complicated. Puck has full support for Unicode and wishes to be intuitive, performant, and safe, as all languages wish to be. Strings present a problem that much effort has been expended on in (primarily) Swift and Rust to solve.
Abstract types, broadly speaking, are types described by their behavior rather than their implementation. They are more commonly know as abstract data types: which is confusingly similar to "algebraic data types", another term for the advanced types they are built out of under the hood. We refer to them here as "abstract types" to mitigate some confusion.
+Abstract types, broadly speaking, are types described by their behavior rather than their implementation. They are more commonly know as abstract data types: which is confusingly similar to "algebraic data types", another term for the advanced types they are built out of under the hood. We refer to them here as "abstract types" to mitigate some confusion.
Iterable types can be one-of:
array[S, T]: Fixed-size arrays. Can only contain one type T. Of a fixed size S and cannot grow/shrink, but can mutate. Initialized in-place with [a, b, c].list[T]: Dynamic arrays. Can only contain one type T. May grow/shrink dynamically. Initialized in-place with [a, b, c]. (this is the same as arrays!) slice[T]: Slices. Used to represent a "view" into some sequence of elements of type T. Cannot be directly constructed: they are unsized. Cannot grow/shrink, but their elements may be accessed and mutated. As they are underlyingly a reference to an array or list, they must not outlive the data they reference: this is non-trivial, and so slices interact in complex ways with the memory management system. str: Strings. Described above. They are alternatively treated as either list[byte] or list[char], depending on who's asking. Initialized in-place with "abc".array[T, size]: Fixed-size arrays. Can only contain one type T. Of a fixed size size and cannot grow/shrink, but can mutate. Initialized in-place with [a, b, c].list[T]: Dynamic arrays. Can only contain one type T. May grow/shrink dynamically. Initialized in-place with [a, b, c]. (this is the same as arrays!)slice[T]: Slices. Used to represent a "view" into some sequence of elements of type T. Cannot be directly constructed: they are unsized. Cannot grow/shrink, but their elements may be accessed and mutated. As they are underlyingly a reference to an array or list, they must not outlive the data they reference: this is non-trivial, and so slices interact in complex ways with the memory management system.str: Strings. Described above. They are alternatively treated as either list[byte] or list[char], depending on who's asking. Initialized in-place with "abc".These iterable types are commonly used, and bits and pieces of compiler magic are used here and there (mostly around initialization, and ownership) to ease use. All of these types are some sort of sequence: and implement the Iter interface, and so can be iterated (hence the name).
Parameter types can be one-of:
func foo(a: mut str): Marks a parameter as mutable (parameters are immutable by default). Passed as a ref if not one already.func foo(a: static str): Denotes a parameter whose value must be known at compile-time. Useful in macros, and with when for writing generic code.func foo(a: const str): Denotes a parameter whose value must be known at compile-time. Useful in macros, and with when for writing generic code.func foo[T](a: list[T], b: T): The standard implementation of generics, where a parameter's exact type is not listed, and instead statically dispatched based on usage.func foo(a: str | int | float): A basic implementation of generics, where a parameter can be one-of several listed types. The only allowed operations on such parameters are those shared by each type. Makes for particularly straightforward monomorphization. func foo(a: (int, int) -> int): First-class functions. All functions are first class - function declarations implicitly have this type, and may be bound in variable declarations. However, the function type is only terribly useful as a parameter type.func foo(a: slice[...]): Slices of existing lists, strings, and arrays. Generic over length. These are references under the hood, may be either immutable or mutable (with mut), and interact non-trivially with Puck's ownership system.func foo(a: Stack[int]): Implicit typeclasses. More in the interfaces section.
+func foo(a: Stack[int]): Implicit typeclasses. More in the classes section.
type Stack[T] = interface[push(mut Self, T); pop(mut Self): T]Several of these parameter types - specifically, slices, functions, and interfaces - share a common trait: they are not sized. The exact size of the type is not generally known until compilation - and in some cases, not even during compilation! As the size is not always rigorously known, problems arise when attempting to construct these parameter types or compose them with other types: and so this is disallowed. They may still be used with indirection, however - detailed in the section on reference types.
Functions can take a generic type, that is, be defined for a number of types at once:
-func add[T](a: list[T], b: T) =
- return a.add(b)
+# fully generic. monomorphizes based on usage.
+func add[T](a: list[T], b: T) = a.push(b)
-func length[T](a: T) =
- return a.len # monomorphizes based on usage.
- # lots of things use .len, but only a few called by this do.
- # throws a warning if exported for lack of specitivity.
+# constrained generics. restricts possible operations to the intersection
+# of defined methods on each type.
+func length[T](a: str | list[T]) =
+ a.len # both strings and lists have a `len` method
-func length(a: str | list) =
- return a.len
+# alternative formulation: place the constraint on a generic parameter.
+# this ensures both a and b are of the *same* type.
+func add[T: int | float](a: T, b: T) = a + b
-The syntax for generics is func, ident, followed by the names of the generic parameters in brackets [T, U, V], followed by the function's parameters (which may then refer to the generic types).
-Generics are replaced with concrete types at compile time (monomorphization) based on their usage in function calls within the main function body.
+The syntax for generics is func, ident, followed by the names of the generic parameters in brackets [T, U, V], followed by the function's parameters (which may then refer to the generic types). Generics are replaced with concrete types at compile time (monomorphization) based on their usage in function calls within the main function body.
Constrained generics have two syntaxes: the constraint can be defined directly on a parameter, leaving off the [T] box, or it may be defined within the box as [T: int | float] for easy reuse in the parameters.
-Other constructions like modules and type declarations themselves may also be generic.
+Other constructions like type declarations themselves may also be generic over types. In the future, modules also may be generic: whether that is to be over types or over other modules is to be determined.
Reference Types
-Types are typically constructed by value on the stack. That is, without any level of indirection: and so type declarations that recursively refer to one another, or involve unsized types (notably including parameter types), would not be allowed. However, Puck provides two avenues for indirection.
+Types are typically constructed by value on the stack. That is, without any level of indirection: and so type declarations that recursively refer to one another, or involve unsized types (notably including parameter types), would not be allowed. However, Puck provides several avenues for indirection.
Reference types can be one-of:
-ref T: An automatically-managed reference to type T. This is a pointer of size uint (native).ptr T: A manually-managed pointer to type T. (very) unsafe. The compiler will yell at you.ref T: An owned reference to a type T. This is a pointer of size uint (native).refc T: A reference-counted reference to a type T. This allows escaping the borrow checker.ptr T: A manually-managed pointer to a type T. (very) unsafe. The compiler will yell at you.
type BinaryTree = ref struct
left: BinaryTree
right: BinaryTree
-type AbstractTree[T] = interface
+type AbstractTree[T] = class
func left(self: Self): Option[AbstractTree[T]]
func right(self: Self): Option[AbstractTree[T]]
func data(self: Self): T
@@ -311,57 +311,61 @@ type UnsafeTree = struct
right: ptr UnsafeTree
The ref prefix may be placed at the top level of type declarations, or inside on a field of a structural type. ref types may often be more efficient when dealing with large data structures. They also provide for the usage of unsized types (functions, interfaces, slices) within type declarations.
-The compiler abstracts over ref types to provide optimization for reference counts: and so a distinction between Rc/Arc/Box is not needed. Furthermore, access implicitly dereferences (with address access available via .addr), and so a * dereference operator is also not needed. Much care has been given to make references efficient and safe, and so ptr should be avoided if at all possible. The compiler will yell at you if you use it (or any other unsafe features).
-The implementation of ref is delved into in further detail in the memory management document.
+The compiler abstracts over ref types to provide optimization for reference counts: and so a distinction between Rc/Arc/Box is not needed. Furthermore, access implicitly dereferences (with address access available via .addr), and so a * dereference operator is also not needed.
+Much care has been given to make references efficient and safe, and so ptr should be avoided if at all possible. They are only usable inside functions explicitly marked with #[safe].
+The implementations of reference types are delved into in further detail in the memory management document.
Advanced Types
-The type keyword is used to declare aliases to custom data types. These types are algebraic: they function by composition. Algebraic data types can be one-of:
+The type keyword is used to declare aliases to custom data types. These types are algebraic: they function by composition. Such algebraic data types can be one-of:
struct: An unordered, named collection of types. May have default values.tuple: An ordered collection of types. Optionally named.enum: Ordinal labels, that may hold values. Their default values are their ordinality.union: Powerful matchable tagged unions a la Rust. Sum types.interface: Implicit typeclasses. User-defined duck typing.class: Implicit type classes. User-defined duck typing.
-There also exist distinct types: while type declarations define an alias to an existing or new type, distinct types define a type that must be explicitly converted to/from. This is useful for having some level of separation from the implicit interfaces that abound.
+All functions defined on the original type carry over. If this is not desired, the newtype paradigm is preferred: declaring a single-field struct and copying function declarations over.
+Types may be explicitly to and from via the Coerce and Convert classes and provided from and to functions.
structs
Structs are an unordered collection of named types.
-They are declared with struct[identifier: Type, ...] and initialized with brackets: {field: "value", another: 500}.
-type LinkedNode[T] = struct
- previous, next: Option[ref LinkedNode[T]]
+They are declared with struct[identifier: Type, ...] and initialized with brackets: { field = "value", another = 500}. Structs are structural: while the type system is fundamentally nominal, and different type declarations are treated as distinct, a struct object initialized with {} is usable in any context that expects a struct with the same fields.
+type LinkedNode[T] = ref struct
+ previous: Option[LinkedNode[T]]
+ next: Option[LinkedNode[T]]
data: T
-let node = {
- previous: None, next: None
- data: 413
+let node = { # inferred type: LinkedNode[int], from prints_data call
+ previous = None, next = None
+ data = 413
}
func pretty_print(node: LinkedNode[int]) =
print node.data
- if node.next of Some(node):
+ if node.next of Some(node) then
node.pretty_print()
# structural typing!
prints_data(node)
-Structs are structural and so structs composed entirely of fields with the same signature (identical in name and type) are considered equivalent.
-This is part of a broader structural trend in the type system, and is discussed in detail in the section on subtyping.
tuples
Tuples are an ordered collection of either named and/or unnamed types.
-They are declared with tuple[Type, identifier: Type, ...] and initialized with parentheses: (413, "hello", value: 40000). Syntax sugar allows for them to be declared with () as well.
-They are exclusively ordered - named types within tuples are just syntax sugar for positional access. Passing a fully unnamed tuple into a context that expects a tuple with a named parameter is allowed so long as the types line up in order.
+They are declared with tuple[Type, identifier: Type, ...] and initialized with parentheses: (413, "hello", value: 40000). Syntactic sugar allows for them to be declared with () as well.
+They are exclusively ordered - named types within tuples are just syntactic sugar for positional access. Passing a fully unnamed tuple into a context that expects a tuple with a named parameter is allowed (so long as the types line up).
let grouping = (1, 2, 3)
-func foo: tuple[string, string] = ("hello", "world")
+func foo: tuple[str, str] = ("hello", "world")
+dbg grouping.foo # prints '("hello", "world")'
+
+func bar(a: (str, str)) = a.1
+dbg grouping.bar # prints '"world"'
-Tuples are particularly useful for "on-the-fly" types. Creating type aliases to tuples is discouraged - structs are generally a better choice for custom type declarations.
+Tuples are particularly useful for "on-the-fly" types. Creating type declarations to tuples is discouraged - structs are generally a better choice, as they are fully named, support default values, and may have their layout optimized by the compiler.
enums
Enums are ordinal labels that may have associated values.
-They are declared with enum[Label, AnotherLabel = 4, ...] and are never initialized (their values are known statically).
-Enums may be accessed directly by their label, and are ordinal and iterable regardless of their associated value. They are useful in collecting large numbers of "magic values", that would otherwise be constants.
+They are declared with enum[Label, AnotherLabel = 4, ...] and are never initialized (their values are known statically). Enums may be accessed directly by their label, and are ordinal and iterable regardless of their associated value. They are useful in collecting large numbers of "magic values" that would otherwise be constants.
type Keys = enum
Left, Right, Up, Down
- A = "a"
- B = "b"
+ A = "a"
+ B = "b"
In the case of an identifier conflict (with other enum labels, or types, or...) they must be prefixed with the name of their associated type (separated by a dot). This is standard for identifier conflicts: and is discussed in more detail in the modules document.
unions
@@ -387,83 +391,90 @@ type Expr = ref union
func eval(context: mut HashTable[Ident, Value], expr: Expr): Result[Value]
match expr
- of Literal(value): Okay(value)
- of Variable(ident):
- context.get(ident).err("Variable not in context")
- of Application(body, arg):
+ of Literal(value) then Okay(value)
+ of Variable(ident) then
+ context.get(ident).err("Variable not in context")
+ of Application(body, arg) then
if body of Abstraction(param, body as inner_body):
context.set(param, context.eval(arg)?) # from std.tables
context.eval(inner_body)
- else:
- Error("Expected Abstraction, found {}".fmt(body))
+ else
+ Error("Expected Abstraction, found {}".fmt(body))
of Conditional(condition, then_case, else_case):
- if context.eval(condition)? == "true":
+ if context.eval(condition)? == "true" then
context.eval(then_case)
else:
context.eval(else_case)
- of expr:
- Error("Invalid expression {}".fmt(expr))
+ of expr then
+ Error("Invalid expression {}".fmt(expr))
The match statement takes exclusively a list of of sub-expressions, and checks for exhaustivity. The expr of Type(binding) syntax can be reused as a conditional, in if statements and elsewhere.
The of operator is similar to the is operator in that it queries type equality, returning a boolean. However, unbound identifiers within of expressions are bound to appropriate values (if matched) and injected into the scope. This allows for succinct handling of union types in situations where match is overkill.
-Each branch of a match expression can also have a guard: an arbitrary conditional that must be met in order for it to match. Guards are written as where cond and immediately follow the last pattern in an of branch, preceding the colon.
-interfaces
-Interfaces can be thought of as analogous to Rust's traits, without explicit impl blocks and without need for the derive macro. Types that have functions fulfilling the interface requirements implicitly implement the associated interface.
-The interface type is composed of a list of function signatures that refer to the special type Self that must exist for a type to be valid. The special type Self is replaced with the concrete type at compile time in order to typecheck. They are declared with interface[signature, ...].
-type Stack[T] = interface
+Each branch of a match expression can also have a guard: an arbitrary conditional that must be met in order for it to match. Guards are written as where cond and immediately follow the last pattern in an of branch, preceding then.
+classes
+Classes can be thought of as analogous to Rust's traits: without explicit impl blocks and without need for the derive macro. Types that have functions defined on them fulfilling the class requirements implicitly implement the associated class.
+The class type is composed of a list of function signatures that refer to the special type Self that must exist for a type to be valid. The special type Self is replaced with the concrete type at compile time in order to typecheck. They are declared with class[signature, ...].
+type Stack[T] = class
push(self: mut Self, val: T)
pop(self: mut Self): T
- peek(self: Self): T
+ peek(self: lent Self): lent T
func takes_any_stack(stack: Stack[int]) =
- # only stack.push, stack.pop, and stack.peek are available methods
+ # only stack.push, stack.pop, and stack.peek are available, regardless of the concrete type passed
-Differing from Rust, Haskell, and many others, there is no explicit impl block. If there exist functions for a type that satisfy all of an interface's signatures, it is considered to match and the interface typechecks. This may seem strange and ambiguous - but again, static typing and uniform function call syntax help make this a more reasonable design. The purpose of explicit impl blocks in ex. Rust is three-fold: to provide a limited form of uniform function call syntax; to explicitly group together associated code; and to disambiguate. UFCS provides for the first, the module system provides for the second, and the third is proposed to not matter.
-Interfaces cannot be constructed because they are unsized. They serve purely as a list of valid operations on a type within a context: no information about their memory layout is relevant. The concrete type fulfilling an interface is known at compile time, however, and so there are no issues surrounding interfaces as parameters, just when attempted to be used as (part of) a concrete type. They can be used as part of a concrete type with indirection, however: type Foo = struct[a: int, b: ref interface[...]] is perfectly valid.
-Interfaces also cannot extend or rely upon other interfaces in any way. There is no concept of an interface extending an interface. There is no concept of a parameter satisfying two interfaces. In the author's experience, while such constructions are powerful, they are also an immense source of complexity, leading to less-than-useful interface hierarchies seen in languages like Java, and yes, Rust.
-Instead, if one wishes to form an interface that also satisfies another interface, they must include all of the other interface's associated functions within the new interface. Given that interfaces overwhelmingly only have a handful of associated functions, and if you're using more than one interface you really should be using a concrete type, the hope is that this will provide explicitness.
-
-Interfaces compose with modules to offer fine grained access control.
-
-type aliases and distinct types
-Any type can be declared as an alias to a type simply by assigning it to such. All functions defined on the original type carry over, and functions expecting one type may receive the other with no issues.
-type Float = float
+Differing from Rust, Haskell, and many others, there is no explicit impl block. If there exist functions for a type that satisfy all of a class's signatures, it is considered to match and the class typechecks. This may seem strange and ambiguous - but again, static typing and uniform function call syntax help make this a more reasonable design. The purpose of explicit impl blocks in ex. Rust is three-fold: to provide a limited form of uniform function call syntax; to explicitly group together associated code; and to disambiguate. UFCS provides for the first, the module system provides for the second, and type-based disambiguation provides for the third, with such information exposed to the user via the language server protocol.
+type Set[T] = class
+ in(lent Self, T): bool
+ add(mut Self, T)
+ remove(mut Self, T): Option[T]
+
+type Foo = struct
+ a: int
+ b: ref Set[int] # indirection: now perfectly valid
-It is no more than an alias. When explicit conversion between types is desired and functions carrying over is undesired, distinct types may be used.
-type MyFloat = distinct float
-let foo: MyFloat = MyFloat(192.68)
+Classes cannot be constructed, as they are unsized. They serve purely as a list of valid operations on a type: no information about their memory layout is relevant. The concrete type fulfilling a class is known at compile time, however, and so there are no issues surrounding the use of classes as parameters, just when attempted to be used as (part of) a concrete type in ex. a struct. They can be used with indirection, however: as references are sized (consisting of a memory address).
+## The Display class. Any type implementing `str` is printable.
+## Any type that is Display must necessarily also implement Debug.
+pub type Display = class
+ str(Self): str
+ dbg(Self): str
+
+## The Debug class. Broadly implemented for every type with compiler magic.
+## Types can (and should) override the generic implementations.
+pub type Debug = class
+ dbg(Self): str
-Types then must be explicitly converted via constructors.
+Classes also cannot extend or rely upon other classes in any way, nor is there any concept of a parameter satisfying two classes. In the author's experience, while such constructions are powerful, they are also an immense source of complexity, leading to less-than-useful hierarchies seen in languages like Java, and yes, Rust. Instead, if one wishes to form an class that also satisfies another class, they must name a new class that explicitly includes all of the other class's associated functions. Given that classes in Puck overwhelmingly only have a small handful of associated functions, and if you're using more than one class you really should be using a concrete type: the hope is that this will provide for explicitness and reduce complexity.
+Classes compose well with modules to offer fine grained access control.
Errata
default values
Puck does not have any concept of null: all values must be initialized.
-But always explicitly initializing types is syntactically verbose, and so most types have an associated "default value".
+But always explicitly initializing types is syntactically verbose, and so most types have an associated "default value".
Default values:
bool: falseint, uint, etc: 0float, etc: 0.0char: '\0'str: ""str: ""void, never: unconstructablearray[T], list[T]: []set[T], table[T, U]: {}tuple[T, U, ...]: (default values of its fields)struct[T, U, ...]: {default values of its fields}enum[One, Two, ...]: <first label>enum[One, Two, ...]: disallowedunion[T, U, ...]: disallowedslice[T], func: disallowedref, ptr: disallowedref, refc, ptr: disallowed
-For unions, slices, references, and pointers, this is a bit trickier. They all have no reasonable "default" for these types aside from null.
+
For unions, slices, references, and pointers, this is a bit trickier. They all have no reasonable "default" for these types aside from null.
Instead of giving in, the compiler instead disallows any non-initializations or other cases in which a default value would be inserted.
todo: consider user-defined defaults (ex. structs)
signatures and overloading
-Puck supports overloading - that is, there may exist multiple functions, or multiple types, or multiple modules, so long as they have the same signature.
-The signature of a function / type / module is important. Interfaces, among other constructs, depend on the user having some understanding of what the compiler considers to be a signature.
-So, it is stated here explicitly:
+Puck supports overloading - that is, there may exist multiple functions, or multiple types, or multiple modules, with the same name - so long as they have a different signature.
+The signature of a function/type/module is important. Classes, among other constructs, depend on the user having some understanding of what the compiler considers to be a signature. So we state it here explicitly:
-- The signature of a function is its name and the types of each of its parameters, in order. Optional parameters are ignored. Generic parameters are ???
+
- The signature of a function is its name and the types of each of its parameters, in order, ignoring optional parameters. Generic parameters are ???
- ex. ...
@@ -475,62 +486,8 @@ So, it is stated here explicitly:
- The signature of a module is just its name. This may change in the future.
-subtyping
+structural subtyping
Mention of subtyping has been on occasion in contexts surrounding structural type systems, particularly the section on distinct types, but no explicit description of what the subtyping rules are have been given.
-Subtyping is the implicit conversion of compatible types, usually in a one-way direction. The following types are implicitly convertible:
-
-uint ==> intint ==> floatuint ==> floatstring ==> list[char] (the opposite no, use pack)array[T; n] ==> list[T]struct[a: T, b: U, ...] ==> struct[a: T, b: U]union[A: T, B: U] ==> union[A: T, B: U, ...]
-inheritance
-Puck is not an object-oriented language. Idiomatic design patterns in object-oriented languages are harder to accomplish and not idiomatic here.
-But, Puck has a number of features that somewhat support the object-oriented paradigm, including:
-
-- uniform function call syntax
-- structural typing / subtyping
-- interfaces
-
-type Building = struct
- size: struct[length, width: uint]
- color: enum[Red, Blue, Green]
- location: tuple[longitude, latitude: float]
-
-type House = struct
- size: struct[length, width: uint]
- color: enum[Red, Blue, Green]
- location: tuple[longitude, latitude: float]
- occupant: str
-
-func init(_: type[House]): House =
- { size: {length, width: 500}, color: Red
- location: (0.0, 0.0), occupant: "Barry" }
-
-func address(building: Building): str =
- let number = int(building.location.0 / building.location.1).abs
- let street = "Logan Lane"
- return number.str & " " & street
-
-# subtyping! methods!
-print House.init().address()
-
-func address(house: House): str =
- let number = int(house.location.0 - house.location.1).abs
- let street = "Logan Lane"
- return number.str & " " & street
-
-# overriding! (will warn)
-print address(House.init())
-
-# abstract types! inheritance!
-type Addressable = interface for Building
- func address(self: Self)
-
-These features may compose into code that closely resembles its object-oriented counterpart. But make no mistake! Puck is static first and functional somewhere in there: dynamic dispatch and the like are not accessible (currently).
@@ -561,22 +518,6 @@ type Addressable = interface for Building
-
-
--
cgit v1.2.3-70-g09d2