Import styles

add comes from use lib_demo::add; sub and get_pi arrive via the list. Both forms work together in the same file.

// Feature: qualified access vs. imported name — when to use each

// Syntax: `lib::foo()` (qualified) vs. `foo()` (after `use`)

// When to use:

//   - qualified: module is large and names are generic

//     (e.g. `time::now`, `math::sqrt`); makes origin clear

//   - imported: name is unique and used a lot; reduces noise


mod lib_demo

// Imports only `add` — uses `add(...)` directly.

use lib_demo::add

// SKIP: `use lib_demo` alone (for qualified access elsewhere in

// the file) is rejected by the loader. Pull every name explicitly.

use lib_demo::{sub, get_pi}

fn main() {
  // Imported: call directly.

  let s = add(10, 5)
  print("add direct = {s}")

  // expected: add direct = 15


  let d = sub(10, 5)
  print("sub = {d}")

  // expected: sub = 5


  print("pi = {get_pi()}")
  // expected: pi = 3.14159

}

use lib_demo::greet (single) and use lib_demo::{add, sub, VERSION} (list) coexist without conflict.

// Feature: import from more than one module in the same file

// Syntax: multiple `mod` + `use` declarations at the top

// When to use: real programs almost always combine several modules;

// declare each `mod` once at the entry-point and use them at call sites.


// Loads both files alongside: `lib_demo.zolo` and

// `multi-file/helpers.zolo` (the latter we would reference via a

// relative path embedded in the multi-file folder example). Here we

// just re-use lib_demo.


mod lib_demo

// You can mix forms (single + list). The bare `use lib_demo` form

// for qualified access is currently rejected by the loader; pull

// the constant explicitly instead.

use lib_demo::greet  // single

use lib_demo::{add, sub, VERSION}  // list


fn main() {
  greet("multi")

  // expected: Hello, multi!


  print("add = {add(2, 3)}")
  print("sub = {sub(7, 4)}")
  print("VERSION = {VERSION}")
  // expected:

  // add = 5

  // sub = 3

  // VERSION = 1.0.0

}

For user .zolo modules, prefer the list {a, b, c}. Reserve the wildcard ::* for native plugins (winit, wgpu, binary...).

// Feature: tradeoffs between `use foo::*`, list, and qualification

// Syntax: three variants — side-by-side comparison

// When to use: see the guide below for each scenario.


// === Scenario 1: many names from the same module, all from a plugin ===

// Native-plugin import -> wildcard via `use plugin` is OK and idiomatic.

//

//     use plugin winit::*

//     use plugin wgpu::*

//

// === Scenario 2: you need a few specific functions ===

// Named list -> shows exactly what is in use.

//

//     use lib_demo::{add, sub, greet}

//

// === Scenario 3: rare use, or names may collide ===

// Qualified access -> keeps origin explicit.

//

//     use lib_demo

//     ...

//     lib_demo::add(1, 2)


mod lib_demo

// Mixing strategies in a single file. Bare `use lib_demo` (for

// qualified access elsewhere) is rejected by the current loader,

// so pull the occasional name explicitly too.

use lib_demo::greet  // called several times -> direct import

use lib_demo::add  // occasional, but still imported by name


fn main() {
  // Good: direct name (frequent use).

  greet("alice")
  greet("bob")
  greet("carol")

  // expected:

  // Hello, alice!

  // Hello, bob!

  // Hello, carol!


  let s = add(2, 3)
  print("sum = {s}")
  // expected: sum = 5

}