aboutsummaryrefslogtreecommitdiff
path: root/documentation/tour/modules.sloth
diff options
context:
space:
mode:
Diffstat (limited to 'documentation/tour/modules.sloth')
-rw-r--r--documentation/tour/modules.sloth82
1 files changed, 82 insertions, 0 deletions
diff --git a/documentation/tour/modules.sloth b/documentation/tour/modules.sloth
new file mode 100644
index 0000000..b91261e
--- /dev/null
+++ b/documentation/tour/modules.sloth
@@ -0,0 +1,82 @@
+# Sloth projects are managed completely within their source code. While this
+# without a doubt has its downsides it is generally nice as to distribute small
+# sloth scripts you only need to distribute the sloth file. No more trying to
+# run a script only to find out you need to install multiple 3rd party packages.
+#
+# As a result of this there needs to be a way in sloth itself to specify
+# dependencies, and this is done with the `use extern` statement.
+#
+# So long as a version is specified and the repository is canopy this is safe
+# without a lock file because all packages published on canopy are required to
+# specify versions for all dependencies, can not override already published
+# versions and can only depend on other packages inside of canopy.
+use extern "http";
+use extern "http" as web;
+use extern "http:1.0.27";
+use extern "canopy://http:1.0.27"; # Explicitly specify `canopy` protocol.
+
+# While it is recommended that you only depend on packages from canopy, you can
+# use packages from 3rd party sources using git (over https), ftp or https. When
+# doing so however you are required to provide a module name with `as`.
+#
+# Versions can only be specified when using `sloth` or `git`
+use extern "git://github.com/CatDevz/AdventOfCode.git" as spookylib;
+use extern "ftp://codyq.dev/libs/spookylib.sloth" as spookylib;
+use extern "https://codyq.dev/libs/spookylib.sloth" as spookylib;
+
+# In sloth files will automatically become modules. Files named `mod.sloth` will
+# become the module for the directory. If you have a project with multiple files
+# the root module will be `mod.sloth`. Anything exposed in this can just strait up
+# be used.
+#
+# If no `mod.sloth` exists, for example when running single file scripts, it will
+# be trated as if there is one but its empty.
+
+# /mod.sloth
+pub fn fib(n: i32) -> i32 {
+ match n {
+ 0 | 1 => n,
+ _ => fib(n - 1) + fib(n - 2),
+ }
+}
+
+# /foo.sloth
+use fib; # TODO:
+
+fib(5); # Works because everything inside of mod.sloth is fair game
+
+# This means if you want an extern library to be available in every module you just
+# need to add a `pub(pkg) use extern "lib"`
+
+# In order to use modules or members of modules without quantifying the entire
+# path you must include them using a `use` statement.
+use foo::bar;
+
+# Sloth will use your root module (the one used as your entrypoint) for imports.
+# In order to import from modules relative to your own you must prefix the use
+# with a `::`
+use ::from::relative;
+
+# If you would live to traverse up the module tree you can use the `super`
+# psudo-module.
+use
+
+# TODO:
+# Sloth will automatically turn files relative to your own and directories
+# relative to your own with a `mod.sloth` into modules. In order to traverse
+# up the module tree you can use the `super` psudo-module.
+use super::a;
+use super::b;
+
+use std::rand::random;
+use std::uuid;
+
+use spookylib::spook;
+use http::{get, post};
+use web::Client as WebClient;
+
+# If you would like to export a module you can use the `pub` keyword, unlike
+# other times when the pub keyword is used however sloth will by default only
+# publish it to `pkg`
+pub use parse;
+pub use blog;