Why does EK9 reject non-aggregate types in certain contexts?

← Code Quality · Ref: Q830

EK9 distinguishes between aggregate types (class, record, component, trait, service) and non-aggregate types (function, program). Some operations require aggregate types.

AGGREGATE TYPES

Types that have properties, methods, and operators:

  class, record, component, trait, service, enumeration

NON-AGGREGATE TYPES

Callable units without properties:

  function, program

WHERE AGGREGATES ARE REQUIRED

- Stream sort: the items being sorted must be aggregate types with comparison operators
- Type extensions: extends requires an aggregate
- Property access: only aggregates have properties

COMMON MISTAKE

Passing a function reference where an aggregate instance is expected:

  cat [myFunction] | sort > result   // ERROR if sorting functions

See Q97 for class vs record. See Q126 for stream reference.

Example

defines module qa.quality.aggregate.type

  defines function

    getAlpha()
      <- rtn <- "alpha"

  defines program

    AggregateTypeDemo()
      stdout <- Stdout()

      collection <- List() of String

      // === CORRECT: sort strings (aggregate type with <=> operator) ===
      cat ["alpha", "beta"] | sort > collection

      require collection?
      stdout.println("Sorted collection")

Common mistakes

E04060 — Stream sort requires aggregate types with comparison operators. Function references are not aggregates and cannot be sorted. See ek9 -h E04060 for details.

Incorrect:

      cat [getAlpha] | sort > collection

Correct:

      cat ["alpha", "beta"] | sort > collection

Coming from another language?

Java: everything is a class (functions are objects). Python: functions are objects with attributes. Rust: functions and closures are distinct from structs. Go: functions have no methods. EK9: clear separation — aggregates have properties and operators, functions are pure callables.

Keywords: E04060, record, stream, aggregate, sort, type, class, function