Skip to main content

Ternary Condition Case Study

Suppose you want to add a ternary condition to the language.

This is the exact kind of request that tests whether you are thinking in a Morph way or in a core-first way.

The Wrong Approach​

Do not start with:

  • editing core parser code as the feature owner
  • adding semantic handling directly in core
  • inserting a one-off lowering branch into core code

That may look faster, but it breaks the ownership model.

The Right Questions​

Ask these in order:

  1. Which package should own ternary expression syntax?
  2. Should that feature live inside an existing package or a new package?
  3. Can the current framework express the required syntax, sema, and lowering hooks?
  4. If not, which framework capability must be widened?

Only step 4 justifies framework work.

Likely Implementation Shape​

A package-owned ternary feature would usually need:

  • syntax ownership
  • semantic ownership
  • lowering ownership
  • maybe route or runtime considerations, depending on the design

That work should stay together in package space.

If The Framework Is Missing A Hook​

This is the one acceptable reason to touch core framework code:

  • the parser hook model cannot express the syntax shape
  • the semantic feature interface is too narrow
  • the lowering interface lacks a required construct

In that case:

  1. widen the framework or SDK generically
  2. implement ternary as a package-owned feature using the new capability

Do not make core the owner of ternary itself.

The General Lesson​

The ternary example is not special.

The same reasoning applies to:

  • new operators
  • new types
  • new runtime capabilities
  • new build targets

Feature ownership stays in packages. Framework code only widens the generic surface that packages consume.

Next Steps​