DEV Community: Depa Reddy

Demystifying Scala 3 Macros: A Deep Dive with Quoting and Splicing

Depa Reddy — Sun, 07 Dec 2025 18:48:00 +0000

Welcome to the world of compile-time metaprogramming in Scala 3! Macros can seem like magic, but they are built on a powerful and elegant system of Quoting and Splicing. Today, we're going to dissect a practical and elegant macro that converts any case class into a Map[String, Any]. By the end of this article, you'll understand not just what this macro does, but how it works, right down to the low-level reflection concepts that power it.

Here is the code we will be exploring:

package com.dev24.macros

import scala.quoted.*

object ToMapMacro {
  // The user-facing, inline method
  extension [A](inline a: A) inline def toMap: Map[String, Any] = ${ toMapImpl('a) }

  // The implementation that runs at compile time
  def toMapImpl[A: Type](instance: Expr[A])(using Quotes): Expr[Map[String, Any]] = {
    import quotes.reflect.*

    // 1. Get the type and symbol of A
    val tpe = TypeRepr.of[A]
    val sym = tpe.typeSymbol

    // 2. Get the list of case class fields
    val fields: List[Symbol] =
      if (sym.isClassDef) sym.caseFields.toList
      else Nil

    // 3. For each field, generate a quoted (String, Any) tuple
    val mapEntries: List[Expr[(String, Any)]] = fields.map { field =>
      val fieldNameExpr = Expr(field.name)
      val fieldAccess = Select(instance.asTerm, field)
      val fieldValueExpr = fieldAccess.asExprOf[Any]
      '{ ($fieldNameExpr, $fieldValueExpr) }
    }

    // 4. Assemble the final Map from the list of tuples
    '{ Map(${Varargs(mapEntries)}*) }
  }
}

Let's break this down piece by piece.

Part 1: The Gateway to Metaprogramming - The inline Method

extension [A](inline a: A) inline def toMap: Map[String, Any] 
= ${ toMapImpl('a) }

This is the method the user will call. It's designed to look and feel like a regular method, but it's anything but.

extension [A]: This is just modern Scala syntax to add a method to any type A. It's syntactic sugar and makes the call site clean: myCaseClass.toMap.
inline a: A: The inline keyword is the trigger. It tells the Scala compiler, "Do not execute this method at runtime. Instead, when you see a call to this method, replace it with the result of the code on the right-hand side during compilation."
${ ... }: This is the Splice operator. It's the bridge from the "normal" code world to the "macro" world. The code inside the splice is executed by the compiler as it builds your program.
toMapImpl('a): This is the call to our macro implementation.
- toMapImpl: The function that will generate the code.
- 'a: This is the Quote operator (an apostrophe). It takes the value a and lifts it into the compiler's world as a representation of the code that produced a. This is not the runtime value of a; it is an Abstract Syntax Tree (AST) node representing the expression a. We call this a quoted expression. Its type is Expr[A]

In short: When the compiler sees person.toMap, it pauses compilation, calls toMapImpl with a quoted representation of the person expression, gets back a new piece of code (a quoted Map), and splices that new code directly into the program where person.toMap used to be.

Part 2: The Engine Room **- **The Macro Implementation

def toMapImpl[A: Type](instance: Expr[A])(using Quotes)
: Expr[Map[String, Any]]

This is where the real work happens. This function runs inside the compiler during the compilation phase.

A: Type: This is a Context Bound. It's a request for a Type[A] instance to be available. Type[A] is a "type tag." It's the quoted representation of the type A itself (e.g., Person, not an instance of Person). This is how the macro knows what class it's working with.
instance: Expr[A]: This is the quoted expression we passed in with 'a. It's the AST for the value being converted (e.g., the AST for Person("Alice", 30)).
(using Quotes): This is a Context Parameter. Quotes is the macro's toolbox. It provides access to all the reflection and metaprogramming utilities. It's the entry point to the compiler's internal APIs.
: Expr[Map[String, Any]]: This is the return type. Crucially, the macro does not return a Map. It returns a quoted expression that, when compiled and run, will produce a Map. This is the fundamental contract of a macro: generate code, don't compute runtime values.

Low-Level Reflection: import quotes.reflect.*

To do the heavy lifting of inspecting the class structure, we need to go deeper than the high-level Quotes API provides. import quotes.reflect.* gives us access to the compiler's core reflection types.

TypeRepr: A rich, internal representation of a type. It's more detailed than Type.
Symbol: The most fundamental concept. A Symbol is a unique name for any declaration in Scala: a class, a trait, an object, a method, a field, a type parameter, etc. Think of it as the ultimate "key" in the compiler's symbol table.
Term: A general representation of an expression or statement in the AST. An Expr is a type-safe wrapper around a Term.

Step 1: Inspecting the Type

val tpe = TypeRepr.of[A]
val sym = tpe.typeSymbol

TypeRepr.of[A]: We use our Type[A] evidence to get the full, rich TypeRepr for A. Represents a type (e.g., User, String, List[Int]). It's the "what is its structure?"

This line is about getting a handle on the type itself.

Line 1: val tpe = TypeRepr.of[A]

[A]: This is a type parameter. The code must be inside a context where A is known, such as a generic method (def myMethod[A]: ...) or a generic class (class MyClass[A]).
TypeRepr: This is the central class in Scala 3's reflection API for representing types. A TypeRepr is the compiler's internal, rich description of a type. It can tell you everything about the type's structure.
.of[...]: This is a summoning method. It asks the compiler: "Give me your internal TypeRepr object for the type I specify here." This operation happens entirely at compile time.

What tpe contains:
If A is List[String], tpe is a TypeRepr that knows:

Its base type is scala.collection.immutable.List.
It has one type argument, which is scala.Predef.String.
It's a concrete, applied type (not a generic type constructor like List on its own).

If A is just Int, tpe is a TypeRepr that represents the scala.Int type.

** tpe.typeSymbol**: From the type representation, we get its primary Symbol. If A is Person, sym is the Symbol for the Person class definition itself. Symbol Represents a declaration or name (e.g., the name of a class User, a method getName, or a field age). It's the "what is it called?" and "where was it defined?".

Line 2: val sym = tpe.typeSymbol

This line is about finding the definition or declaration that created the type.

tpe: This is the TypeRepr we got from the first line.
.typeSymbol: This method is called on a TypeRepr. It navigates from the type to the symbol that declared it.
Symbol: A Symbol in Scala 3 reflection represents a named declaration in your source code. This could be a class, trait, object, method, val, var, or type parameter. It's the "nameplate" of the entity.

What sym contains:

If tpe represents List[String], then sym is the Symbol for the declaration of class List in the Scala library. It has forgotten about the [String] part.

If tpe represents a case class User(name: String), then sym is the Symbol for class User

Step 2: Finding the Fields

val fields: List[Symbol] =
  if (sym.isClassDef) sym.caseFields.toList
  else Nil

sym.isClassDef: We check if the symbol represents a class. This is a safety measure to ensure we don't try to get fields from a type like Int or String.
sym.caseFields: This is a powerful helper method on a class Symbol. It returns a List[Symbol] representing the public constructor parameters of the case class. For case class Person(name: String, age: Int), this will be a list containing the symbols for name and age.

Step 3: Generating the Map Entries (The Core Loop)

This is the heart of the macro, where quoting and splicing dance together.

val mapEntries: List[Expr[(String, Any)]] = fields.map { field =>
  val fieldNameExpr = Expr(field.name)
  val fieldAccess = Select(instance.asTerm, field)
  val fieldValueExpr = fieldAccess.asExprOf[Any]
  '{ ($fieldNameExpr, $fieldValueExpr) }
}

We are iterating over each field Symbol to create a quoted tuple ("fieldName", fieldValue).

val fieldNameExpr = Expr(field.name):
- field.name gives us the actual string name of the field (e.g., "name").
- Expr(...) is a helper that quotes a value. It takes a runtime value (the string "name") and creates a quoted expression representing that value's literal code. So Expr("name") produces the AST for the string literal "name".
val fieldAccess = Select(instance.asTerm, field):
- This is pure, low-level AST construction.
- instance.asTerm: We unwrap our type-safe Expr[A] to get the raw Term AST node.
- Select(..., ...): This is a constructor for a field access AST node. It's equivalent to writing the code instance.field. The first argument is the "qualifier" (the object we're accessing the field on), and the second is the Symbol of the field to access. This creates the AST for person.name.
val fieldValueExpr = fieldAccess.asExprOf[Any]
- We take the raw Term AST for person.name and wrap it back up into a type-safe Expr. We cast it to Any because a Map[String, Any] can hold any value type.
{ ($fieldNameExpr, $fieldValueExpr) }: This is the masterpiece.
- The outer '{ ... } is a Quote. It means: "Do not execute the code inside me now. Instead, construct an AST representing the code inside me."
- The inner $fieldNameExpr and $fieldValueExpr are Splices. They mean: "Take the quoted expression I have in this variable and splice it into the code I am currently quoting."
- So, if fieldNameExpr is the AST for "name" and fieldValueExpr is the AST for person.name, this single line builds the AST for the tuple expression ("name", person.name).

The map function returns a List[Expr[(String, Any)]], which is a list of AST nodes, one for each (key, value) pair in our desired map.

Step 4: Assembling the Final Map

'{ Map(${Varargs(mapEntries)}*) }

This is the final step, where we assemble all the tuple ASTs into a single Map AST.

'{ ... }: Once again, a Quote to say "generate the code for..."
Map(...): We're generating a call to the Map.apply factory method.
${Varargs(mapEntries)}*: This is a special splice.
- mapEntries is our List[Expr[(String, Any)]].
- Varargs(...) is a helper that takes a list of quoted expressions and prepares them to be used as a variable argument list. It bundles them into a single Expr[Seq[T]].
- The splice ${...} injects this generated sequence of expressions into the Map call.
- The ***** is part of the generated code, not the macro code. It's the syntax for splatting a sequence into varargs

So, this final line generates the complete AST for: Map(("name", person.name), ("age", person.age), ...).

Putting It All Together: A Full Example

Let's trace Person("Alice", 30).toMap.

Call Site: The compiler sees Person("Alice", 30).toMap.
Inline Invocation: Because toMap is inline, it calls toMapImpl.
Parameters:
- instance is the quoted code '{ Person("Alice", 30) }.
- A is Person.
Inside toMapImpl:
- fields becomes a list of the Symbols for name and age.
- For name:
  - fieldNameExpr becomes '{ "name" }.
  - fieldAccess becomes the AST for Select(Person("Alice", 30), name_symbol).
  - fieldValueExpr becomes '{ Person("Alice", 30).name }.
  - The map produces the quoted tuple '{ ("name", Person("Alice", 30).name) }.
- For age:
  - The map produces the quoted tuple '{ ("age", Person("Alice", 30).age) }.
mapEntries is now a list containing these two quoted tuples.
Final Code Generation: The last line '{ Map(${Varargs(mapEntries)}*) } produces the final quoted code:
'{ Map(("name", Person("Alice", 30).name), ("age", Person("Alice", 30).age)) }
Splicing Back: The compiler takes this result and splices it back into the user's code, replacing the original .toMap call.
Final Compiled Code: The program now effectively contains:

Map(("name", "Alice"), ("age", 30))

The magic is complete. The boilerplate is gone, the runtime overhead is zero, and the code is perfectly type-safe.

the full source can be found in below gist:
https://gist.github.com/depareddy/06b9f12afc73de3bce71a72bee4d44eb

Deep Dive into Scala 3 Macros: Building a Custom String Interpolator

Depa Reddy — Sun, 02 Nov 2025 13:12:00 +0000

This blog post explores the powerful macro system in Scala 3 through a practical example: a custom string interpolator that adds debug information to interpolated values. We'll break down the code and explain the concepts behind it, giving you the knowledge to create your own macros.

Before we dissect the code, let's cover the basics. If macros sound intimidating, think of them as "meta-programming" tools that let your code think about itself. In Scala 3, macros use Tasty, Scala's internal representation (short for "Typed Abstract Syntax Trees"—a blueprint of your code that the compiler understands and manipulates).

What are macros? Normal code runs when your program executes (runtime). Macro code runs during compilation (when Scala turns your .scala files into runnable bytecode). They can analyze your code, change it, or generate new code on the fly. For example, a macro might see t"Hello $name" and rewrite it to optimized bytecode before the program starts.

Introduction to String Interpolation in Scala

String interpolation in Scala allows embedding expressions directly into string literals. Scala 3 provides several built-in interpolators:

s"Hello $name": Simple interpolation
f"Hello $name%s": Formatted interpolation
raw"Hello\n$name": Raw interpolation
When you write s"Hello $name", the compiler transforms it into:

StringContext("Hello ", "").s(name)

This transformation opens the door to custom interpolators, which we'll explore next.

Understanding the Code Structure

Let's break down our custom interpolator code:

package com.dev24.macros

import scala.quoted.*
import scala.util.*

We start with the necessary imports, particularly scala.quoted.* which is essential for working with macros in Scala 3.

Runtime Helper Methods
Our implementation includes two runtime helper methods:

Runtime Helper Methods
Our implementation includes two runtime helper methods:

buildTaggedString

def buildTaggedString(parts: Array[String], args: Any*): String =
  val taggedArgs = args.map(arg => s"[DEBUG] ${arg.toString}")
  val result = new StringBuilder
  var i = 0
  result.append(parts(0))
  for j <- 0 until args.length do
    result.append(taggedArgs(j))
    result.append(parts(j + 1))
  result.toString

This method:

Takes an array of string parts (the literal parts of the interpolated string)
Takes variable arguments (the expressions to be interpolated)
Wraps each argument with "[DEBUG]" prefix
Constructs the final string by alternating parts and tagged arguments

buildTaggedStringFromContext

def buildTaggedStringFromContext(sc: StringContext, args: Seq[Any]): String =
  val taggedArgs = args.map(arg => s"[DEBUG] ${arg.toString}")
  val parts = sc.parts.map(_.toUpperCase).toArray
  val result = new StringBuilder
  result.append(parts(0))
  for j <- 0 until args.length do
    result.append(taggedArgs(j))
    result.append(parts(j + 1))
  result.toString

This is similar to the previous method but:

Takes a StringContext directly (which contains the parts)
Converts parts to uppercase
Used as a fallback when compile-time analysis isn't possible

The Extension Method

extension (sc: StringContext)
  transparent inline def t(args: Any*): String =
    ${ tMacro('sc, 'args) }

scala
This defines an extension method on StringContext:

transparent inline indicates this is an inline method that will be expanded at compile time
The method takes variable arguments
${ tMacro('sc, 'args) } is the macro expansion syntax, calling the tMacro function with the StringContext and arguments as quoted expressions

The Macro Implementation

def tMacro(sc: Expr[StringContext], args: Expr[Seq[Any]])(using Quotes): Expr[String] =
  import quotes.reflect.*

  sc match
    case '{ StringContext(${Varargs(partExprs)}*) } =>
      // Try to extract literal parts
      val partsOpt: Seq[Option[String]] = partExprs.map { expr =>
        expr.asTerm match
          case Literal(StringConstant(str)) => Some(str)
          case _ => None
      }

      // If all parts are literal and args are Varargs, do compile-time path
      if partsOpt.forall(_.isDefined) then
        args match
          case Varargs(argExprs) =>
            val parts = partsOpt.map(_.get)
            val processed = parts.map(_.toUpperCase)
            val processedPartsExpr = Expr.ofSeq(processed.map(Expr(_)))
            '{ buildTaggedString($processedPartsExpr.toArray, ${Varargs(argExprs)}*) }
          case _ =>
            // args not Varargs at compile time -> runtime fallback
            '{ buildTaggedStringFromContext($sc, $args) }
      else
        // parts not all literals -> runtime fallback
        '{ buildTaggedStringFromContext($sc, $args) }

    case _ =>
      // sc not a StringContext literal -> runtime fallback
      '{ buildTaggedStringFromContext($sc, $args) }

This is the core macro implementation. Let's break it down:

Function Signature

Takes an Expr[StringContext] (quoted expression of StringContext)
Takes an Expr[Seq[Any]] (quoted expression of the arguments)
Returns an Expr[String] (quoted expression of the result)
Requires a Quotes context for macro operations
Pattern Matching on StringContext

case '{ StringContext(${Varargs(partExprs)}*) } =>

This matches a StringContext with varargs of part expressions, extracting the literal parts of the interpolated string.

Extracting Literal Parts

val partsOpt: Seq[Option[String]] = partExprs.map { expr =>
  expr.asTerm match
    case Literal(StringConstant(str)) => Some(str)
    case _ => None
}

For each part expression, it tries to extract the literal string value:

expr.asTerm converts the expression to a term

Literal(StringConstant(str)) matches a literal string constant

If not a literal, returns None

Compile-time Path

If all parts are literals and args are varargs, it processes at compile time:

val parts = partsOpt.map(_.get)
val processed = parts.map(_.toUpperCase)
val processedPartsExpr = Expr.ofSeq(processed.map(Expr(_)))
'{ buildTaggedString($processedPartsExpr.toArray, ${Varargs(argExprs)}*) }

This:

Converts parts to uppercase
Creates a new expression that calls buildTaggedString with the processed parts and original arguments

Runtime Fallback

If parts aren't all literals or args aren't varargs, it falls back to runtime processing:

'{ buildTaggedStringFromContext($sc, $args) }

Key Concepts in Scala 3 Macros

Quotes and Splices

Quotes and splices are the fundamental building blocks of Scala 3 macros:

Quotes ('{...}): Capture code as data
Splices (${...}): Insert code into quotes
In our example:

transparent inline def t(args: Any*): String =
  ${ tMacro('sc, 'args) }

scala
The 'sc and 'args are quotes, and ${ tMacro(...) } is a splice that inserts the result of the macro.

Transparent Inline Methods

transparent inline methods are a key feature for macros in Scala 3:

inline: The method call is replaced with the method body at compile time
transparent: The compiler can see through the method to infer more precise types

This enables the macro to generate code that's type-checked in the context where it's used.

Compile-time vs Runtime Processing

Doing work at compile time has several advantages:

Performance: The work is done once during compilation, not every time the code runs
**Type safety: **Errors can be caught at compile time
Optimization: The compiler can optimize the generated code

In our example, when the string parts are known at compile time, we can process them immediately and generate optimized code.

Example Usage

object LoggerExample extends App {
  import com.dev24.macros.CustomInterpolator._
  val name = "Alice"
  val age = 30
  val msg = t"Hello $name, you are $age years old!"
  println(msg)
}

This demonstrates using the custom interpolator:

Imports the interpolator
Defines some variables
Uses the t interpolator to create a tagged string
Prints the result
The output would be:

HELLO [DEBUG] Alice, YOU ARE [DEBUG] 30 YEARS OLD!

Practical Applications of Custom Interpolators and Macros

Custom interpolators with macros have many practical applications:

Type-safe SQL: Prevent SQL injection by validating queries at compile time
Configuration: Validate configuration files at compile time
Logging: Add metadata to log messages automatically
Internationalization: Validate that all translation keys exist
Code generation: Generate boilerplate code based on annotations

Our example demonstrates a logging interpolator that adds debug tags to interpolated values.

Conclusion

This code showcases the power of Scala 3's macro system through a custom string interpolator. It demonstrates how to:

Define an extension method on StringContext
Implement a macro that analyzes code at compile time
Fall back to runtime processing when necessary
Generate optimized code when possible

The macro system in Scala 3 is more approachable and safer than in Scala 2, making it a powerful tool for metaprogramming and code generation. By understanding these concepts, you can create your own macros to optimize your code, improve type safety, and reduce boilerplate.

Whether you're building a type-safe DSL, optimizing performance-critical code, or simply reducing boilerplate, Scala 3 macros provide a powerful and elegant solution.

full source code can be found here:

Blog Post: Demystifying ZIO's Dependency Injection: A Practical Guide

Depa Reddy — Sat, 01 Nov 2025 14:58:13 +0000

Introduction: The Problem of "Wiring" an Application

In any non-trivial application, different parts need to talk to each other. A UserService might need a Database connection and an Emailer. A Database might need a Configuration object. This network of dependencies is often called "the application graph" or "the wiring."

How do we manage this?

Manual new-ing? new UserService(new Database(new Config()), new Emailer()). This gets messy fast and is hard to change.
A Framework like Spring? This uses reflection and can be "magical," but sometimes you want compile-time guarantees and a more functional approach. This is where ZIO shines. ZIO provides a powerful, purely functional, and compile-time safe way to manage dependencies using a feature called ZIO Layers. In this post, we'll build a simple application to demonstrate how it works.

**The Goal: **A Simple User Registration Flow
Our application will do one thing:

Receive a User.
"Insert" that user into a "database" (we'll just print to the console).
Send a notification email to that user (again, just printing to the console). Let's look at the code and unpack the concepts piece by piece.

Part 1: The Building Blocks - Our Domain Models
First, we need some simple data structures. These are just plain Scala case classes with no ZIO-specific magic.

// In package com.dev24
case class User(name: String, email: String)
case class Config(tableName: String)

User: Represents a user in our system.
Config: Represents configuration data. Here, it just holds the name of our database table.
These are our pure data models. They are simple, immutable, and easy to understand.

Part 2: Defining Capabilities with traits (The Service Interfaces)

In ZIO, a "service" is defined by its public API, which is typically a trait. This trait describes what a service can do, not how it does it. This separation is key for modularity and testing.

The UserEmailer Service

// In package com.dev24
import zio.*
import java.io.IOException

trait UserEmailer:
  def notify(user: User, message: String): ZIO[Console, IOException, Unit]

Let's dissect the notify method signature: ZIO[Console, IOException, Unit]. This is a ZIO effect, and its type parameters are its superpower:

R (Requirement Type): Console
- This is the dependency. It means that to execute this notify effect, we need an implementation of the Console service available in our environment. Console is a built-in ZIO service for interacting with... well, the console.
E (Error Type): IOException
- This is the type of error that can fail the effect. If something goes wrong while trying to print, it might result in an IOException.
A (Success Type): Unit
- This is the type of the value returned on success. We're just performing a side-effect (printing), so we don't need to return a meaningful value. Unit signifies "no value."

So, notify is a description of a computation that says: "To run me, you need to give me a Console. I might fail with an IOException, and if I succeed, I'll give you nothing (Unit)."

The UserDb Service

// In package com.dev24
import zio.*
import java.io.IOException

trait UserDb:
  def insert(user: User): ZIO[Config & Console & UserEmailer, IOException, Unit]

This is where it gets more interesting. Look at the R type: Config & Console & UserEmailer.

The & (Intersection Type): This means the insert method requires all three of these services to be present in the environment to run. It needs the Config to get the table name, the Console to print the "insert" message, and the UserEmailer to send the notification.

This is the heart of ZIO's dependency management. Dependencies are declared explicitly in the function signature, making them impossible to forget at compile time.

Part 3: Creating Implementations with ZLayer (The Blueprints)

A trait is just an interface. We need concrete implementations. In ZIO, an implementation of a service is provided by a ZLayer.

Think of a ZLayer as a recipe or a blueprint for building a service. It describes:

What service it builds (the "output").
What services it needs to build it (the "input" or dependencies).

The UserEmailer.live Layer

object UserEmailer:
  lazy val live: ULayer[UserEmailer] =
    ZLayer.succeed(
      new:
        override def notify(user: User, message: String): ZIO[Console, IOException, Unit] =
          ZIO.serviceWithZIO(_.printLine(s"[User emailer] Sending '$message' to ${user.email}"))
    )

object UserEmailer: We use a companion object to hold the implementations of our service. This is a common Scala pattern.
live: ULayer[UserEmailer]:
- live is a conventional name for the production implementation of a service.
- ULayer[UserEmailer] is the type. Layer[R, A] means "a layer that requires R to build A". ULayer[A] is just an alias for Layer[Any, A], meaning this layer has no dependencies. It can build a UserEmailer out of thin air.
ZLayer.succeed(...): This is the simplest way to create a layer. It takes a pre-built instance of your service and wraps it in a layer. Since our UserEmailer doesn't need any complex setup, this is perfect.
object UserEmailer: We use a companion object to hold the implementations of our service. This is a common Scala pattern.
- live: ULayer[UserEmailer]:
- live is a conventional name for the production implementation of a service.
ULayer[UserEmailer] is the type. Layer[R, A] means "a layer that requires R to build A". ULayer[A] is just an alias for Layer[Any, A], meaning this layer has no dependencies. It can build a UserEmailer out of thin air.
ZLayer.succeed(...): This is the simplest way to create a layer. It takes a pre-built instance of your service and wraps it in a layer. Since our UserEmailer doesn't need any complex setup, this is perfect.
new: ...: We are creating an anonymous class that implements the UserEmailer trait.
ZIO.serviceWithZIO(_.printLine(...)): This is a ZIO helper.
It's shorthand for : Get the Console service from the environment (ZIO.service[Console]).Use its printLine method.

The result of printLine is a ZIO[..., IOException, Unit], which is exactly what our notify method needs to return. We are creating an anonymous class that implements the UserEmailer trait.

ZIO.serviceWithZIO(_.printLine(...)): This is a ZIO helper. It's shorthand for:

1.Get the Console service from the environment (ZIO.service[Console]).
2.Use its printLine method.
3.The result of printLine is a ZIO[..., IOException, Unit], which is exactly what our notify method needs to return.

The UserDb.live Layer

// In package com.dev24
object UserDb:
  lazy val live: ULayer[UserDb] = // Wait, no dependencies? We'll see...
    ZLayer.succeed(
      new:
        override def insert(user: User): ZIO[Config & Console & UserEmailer, IOException, Unit] =
          for
            tableName <- ZIO.environmentWith[Config](_.get.tableName)
            _ <-
              ZIO.serviceWithZIO[Console](_.printLine(s"[Database] insert into $tableName values ('${user.email}')"))
            _ <- ZIO.serviceWithZIO[UserEmailer](_.notify(user, "Message"))
          yield ()
    )

This looks similar, but let's focus on the implementation of insert.

for { ... } yield (): This is ZIO's version of a for-comprehension, used to sequence effects.
tableName <- ZIO.environmentWithConfig: This is another way to access a service from the environment. It pulls out the entire Config object and lets us access its tableName field.
_ <- ZIO.serviceWithZIOUserEmailer): Here, we are using another service! We get the UserEmailer from the environment and call its notify method.

Crucial Point: Notice that UserDb.live is also a ULayer[UserDb]. This seems contradictory, right? The insert method requires dependencies, but the UserDb layer itself doesn't.

This is a key concept: A layer's dependencies are for its construction, not for its usage.
Creating a UserDb instance (the new part) doesn't require a Config or Console. But calling methods on that instance does. The dependencies are deferred to the method calls, which is exactly what we want.

Part 4: Assembling and Running the Application (Main)

Now we have all the pieces: our interfaces (traits) and our blueprints (ZLayers). The final step is to build the application and run it.

// In package com.dev24
import zio.*

object Main extends ZIOAppDefault:

  // 1. Define the user we want to insert
  lazy val kamil = User("d", "d@dev24.in")

  // 2. Define the main logic of our application
  val appLogic: ZIO[UserDb, IOException, Unit] =
    ZIO.serviceWithZIO[UserDb](_.insert(kamil))

  // 3. Assemble the environment (the wiring)
  lazy val env =
    ZLayer.succeed(ConsoleLive) ++ // Provide the live Console implementation
    UserEmailer.live ++           // Provide our UserEmailer implementation
    UserDb.live ++                // Provide our UserDb implementation
    ZLayer.succeed(Config("table-x")) // Provide our Config instance

  // 4. Run the logic with the provided environment
  override def run: Task[Unit] =
    appLogic.provideLayer(env)

Let's break down the Main object.

1.appLogic: This is the core business logic of our application, described as a ZIO effect. It says: "I need a UserDb service, and I will call its insert method with kamil." Its type is ZIO[UserDb, IOException, Unit], meaning it requires UserDb and can fail with IOException.

2.env: This is where the magic happens. We are building our complete application environment.

** ZLayer.succeed(ConsoleLive):** Console is a special ZIO service. We need to provide its "live" implementation, which actually interacts with the system console.
** ZLayer.succeed(Config("table-x")):** We create a layer from our simple Config case class instance.
** ++ (The Horizontal Composition Operator):** This operator combines layers. It's like stacking blueprints. It tells ZIO: "Here are all the services available in my application." ZIO is smart enough to analyze the dependencies and figure out the correct construction order. For example, it knows that UserDb needs Config, so it will ensure Config is built before UserDb.

3.run: Task[Unit]: This is the entry point for our ZIOAppDefault.

appLogic.provideLayer(env): This is the final, crucial step. We take our appLogic (which needs a UserDb) and we give it a complete blueprint (env) for building one.
What happens here? ZIO analyzes appLogic and sees it needs UserDb. It looks at env and finds the UserDb.live layer. It then builds the UserDb service. While building, it sees that the methods on UserDb need Config, Console, and UserEmailer. It finds those in the env as well. It builds everything, wires it all together, and finally executes the insert method.

When you run this, the output will be:

[Database] insert into table-x values ('d@dev24.in')
[User emailer] Sending 'Message' to d@dev24.in

Conclusion: Why This Approach is Powerful

Type-Safe Dependency Injection: The Scala compiler guarantees that all dependencies are met. If you forget to provide Config in your env, your code will not compile. No more runtime
NullPointerExceptions from missing dependencies.

Testability: This is a massive win. To test UserDb, you can provide a mock UserEmailer layer that doesn't actually send emails. You can provide a fake Config. Your UserDb code doesn't change at all; you just give it a different environment to run in.

Modularity and Reusability: Services are completely decoupled. UserEmailer has no idea UserDb exists. You can reuse UserEmailer in any other part of your application.

Explicitness: There is no magic. Every dependency a function needs is declared right in its type signature. The code is self-documenting.

This simple example demonstrates the foundational pattern for building robust, modular, and testable applications with ZIO. You define capabilities with traits, provide implementations with ZLayer, and wire them all together at the application's entry point.

full source code can be found below

State Monad

Depa Reddy — Sun, 20 Jul 2025 09:25:52 +0000

this below article assume some prior knowledge in scala and monads.

The State Monad is a concept from functional programming that allows for stateful computations to be represented in a pure functional way

The State Monad addresses this challenge by allowing functions to carry state along with them.

The key idea is to represent state as a function that takes an initial state and returns a new state along with a result.

Key Concepts of the State Monad

*State Representation: *
The State Monad represents a computation that carries some state.
It can be thought of as a function that takes an initial state and returns a value along with a new state.

*Type Signature: *
The type signature of a State Monad can be represented as State s,a = s -> (a,s): Here s is the type of the state, and a is the type of the result.

Basic Operations:

get: Retrieves the current state.
put: Updates the state to a new value.
modify: Applies a function to the current state to produce a new state.
Composing State Computations: The State Monad allows for the composition of stateful computations using the flatMap (or bind) operation. This enables chaining multiple stateful operations together.

1. State Monad Definition

case class State[S, A](run: S => (S, A)) {
  // Execute the state computation and return the final state
  def exec(s: S): S = run(s)._1

  // Evaluate the state computation and return the result
  def eval(s: S): A = run(s)._2
}

Case Class: State is defined as a case class that takes two type parameters: S (the type of the state) and A (the type of the result).

Run Method: The run method is a function that takes an initial state of type S and returns a tuple containing the new state of type S and a result of type A.

exec Method: This method executes the state computation and returns the final state after running the computation.

eval Method: This method evaluates the state computation and returns the result of type A.

2. Companion Object for State

object State {
  // Create a State that replaces the current state with a new state
  def put[S](ns: S): State[S, Unit] = State(s => (ns, ()))

  // Create a State that retrieves the current state
  def get[S]: State[S, S] = State(s => (s, s))

  // Create a State that modifies the current state using a function
  def modify[S](fx: S => S): State[S, Unit] = State(s => (fx(s), ()))
}

put Method: This method creates a State that replaces the current state with a new state ns. The result type is Unit because it doesn't return any meaningful value.

get Method: This method creates a State that retrieves the current state. It returns the current state as both the new state and the result.

modify Method: This method creates a State that modifies the current state using a provided function fx. It applies fx to the current state and returns the modified state.

3. Functor Type Class

trait Functor[F[_]] {
  def fmap[A, B](fa: F[A])(f: A => B): F[B]
}

Functor Trait: This trait defines a type class for functors, which are types that can be mapped over. It has a method fmap that takes a functor fa containing a value of type A and a function f that transforms A into B. It returns a functor containing a value of type B.

4. Functor Instance for State

object Functor {
  // Functor instance for State using a type lambda
  given [S]: Functor[[A] =>> State[S, A]] with {
    override def fmap[A, B](a: State[S, A])(fx: A => B): State[S, B] = State { s =>
      val (newState, value) = a.run(s)
      (newState, fx(value))
    }
  }

Functor Instance: This provides an instance of the Functor type class for the State monad. The given keyword is used to define an implicit instance.
fmap Implementation: The fmap method is implemented to apply the function fx to the result of the state computation while preserving the state.

5. Monad Type Class

abstract class Monad[M[_]](using functor: Functor[M]) {
  def pure[A](a: A): M[A]
  def flatMap[A, B](a: M[A])(fx: A => M[B]): M[B]
}

Monad Trait: This abstract class defines a type class for monads, which are types that support chaining operations. It requires an implicit Functor instance.

pure Method: This method lifts a value of type A into the monad M.

flatMap Method: This method allows for chaining operations by taking a monadic value a and a function fx that returns a new monadic value.

6. Monad Instance for State

`object StateInstance {
  given [S]: Monad[[A] =>> State[S, A]] with {
    override def pure[A](a: A): State[S, A] = State(s => (s, a))

    override def flatMap[A, B](a: State[S, A])(fx: A => State[S, B]): State[S, B] = State { s =>
      val (newState, value) = a.run(s)
      fx(value).run(newState)
    }
  }
}`

Monad Instance: This provides an instance of the Monad type class for the State monad.

pure Implementation: The pure method creates a State that returns the value a while keeping the state unchanged.

flatMap Implementation: The flatMap method allows chaining stateful computations. It runs the initial state computation, retrieves the new state and value, and then applies the function fx to the value, running the resulting state computation with the new state.

7. Extension Methods for State

extension [S, A](state: State[S, A]) {
  // Map a function over the result of a State
  infix def map[B](f: A => B)(using functor: Functor[[A] =>> State[S, A]]): State[S, B] = 
    functor.fmap(state)(f)

  infix def flatMap[B](f: A => State[S, B])(using monad: Monad[[A] =>> State[S, A]]): State[S, B] = 
    monad.flatMap(state)(f)  
}

Extension Methods: These methods add map and flatMap to the State class, allowing for more convenient usage of the State monad.
map Method: This method allows you to apply a function f to the result of a State computation.
flatMap Method: This method allows you to chain stateful computations using a function that returns a new State.

8. Extension Method to Lift a Value into State

extension A {
def pureState[S]: State[S, A] = State(s => (s, a))
}

pureState Method: This extension method allows you to lift a value a into a State monad, creating a stateful computation that returns a while keeping the state unchanged.

9. Example Usage

object StateExample {
  import com.example.Functor.given
  // import com.example.StateInstance.given

  type StringState[A] = State[String, A]

  def main(args: Array[String]): Unit = {
    given Monad[StringState] = StateInstance.given_Monad_State[String]

    val s = for {
      x <- 10.pureState[String] 
      os <- State.get[String]
      y <- 20.pureState[String]  
      _ <- State.put(os + " boom")
      z <- 30.pureState[String] 
      _ <- State.get[String].flatMap { ns => State.put(ns + " baam") }
    } yield { x + y + z }

    val (s3, r3) = s.run("hello")
    println(s"Example 3 - State: $s3, Result: $r3")
  }
}

StateExample Breakdown

Here’s the relevant part of the StateExample code again for reference:

Step-by-Step Explanation

Step 1: x <- 10.pureState[String]

This line lifts the value 10 into the State monad. The state remains unchanged at this point.
The result of this operation is that x will hold the value 10.

Step 2: os <- State.get[String]

The get operation retrieves the current state.
At this point, the initial state is "hello" (the argument passed to s.run("hello")).
The result of this operation is that os will hold the value "hello".

Step 3: y <- 20.pureState[String]

Similar to Step 1, this line lifts the value 20 into the State monad.
The state is still unchanged at this point.
The result of this operation is that y will hold the value 20.

Step 4: _ <- State.put(os + " boom")

The put operation replaces the current state with a new state. Here, it takes the value of os (which is "hello") and appends " boom" to it.
The new state becomes "hello boom".
This operation does not return a value (hence the underscore _), but it modifies the state.

Step 5: z <- 30.pureState[String]

This line lifts the value 30 into the State monad.
The state is still "hello boom" at this point.
The result of this operation is that z will hold the value 30.

Step 6: _ <- State.get[String].flatMap { ns => State.put(ns + " baam") }

First, State.get[String] retrieves the current state, which is now "hello boom".
The result of this get operation is that ns will hold the value "hello boom".
The flatMap method is then used to chain another operation. It takes the value of ns and appends " baam" to it, creating a new state of "hello boom baam".
The put operation replaces the current state with this new state.
Again, this operation does not return a value (hence the underscore _).

Final Result Calculation

After all these steps, the final result of the for comprehension is calculated:

Final Result Calculation
After all these steps, the final result of the for comprehension is calculated:

yield { x + y + z }

Here, x is 10, y is 20, and z is 30.
The final result is .
Summary of State Changes
Initial State: "hello"
After Step 2 (get): State remains "hello", os is "hello".
After Step 4 (put): State changes to "hello boom".
After Step 6 (get and put): State changes to "hello boom baam".

Final Output

When the state computation is run with the initial state "hello":
val (s3, r3) = s.run("hello")

s3 will hold the final state, which is "hello boom baam".
r3 will hold the result of the computation, which is 60.

The output will be:
Example 3 - State: hello boom baam, Result: 60

the full gist can be found at
[https://gist.github.com/depareddy/a0bfb88b9cdfa627395cefcbe0563a5e]

Exploring JSON Encoding in Scala: The Role of Macros and Derived Encoders

Depa Reddy — Sat, 15 Mar 2025 10:12:19 +0000

the entire source code user here can be found at below gist.
https://gist.github.com/depareddy/ce6f1500af400f69752beb5a9da05bbf

An encoder is like a helper that takes case class turns it into this special code (JSON format).case class in scala can defined like below.

case class Person(name: String, age: Int)

In our code, we have a special helper called JsonEncoder:
JsonEncoder Trait: The JsonEncoder trait defines a type class for encoding values into JSON strings:

trait JsonEncoder[T] {
  def encode(value: T): String
}

This trait allows for polymorphic behavior, enabling different types to be encoded in a consistent manner.

Primitive Type Encoders: Implicit encoders for primitive types are defined using given:


given stringEncoder: JsonEncoder[String] with
      def encode(value: String): String = s""""$value""""

    given intEncoder: JsonEncoder[Int] with
      def encode(value: Int): String = value.toString

    given booleanEncoder: JsonEncoder[Boolean] with
      def encode(value: Boolean): String = value.toString

List Encoder: A generic encoder for lists is provided, which recursively uses the element encoder:

given listEncoder[T](using encoder: JsonEncoder[T]): JsonEncoder[List[T]] with
      def encode(list: List[T]): String = 
        list.map(encoder.encode).mkString("[", ", ", "]")

inline for Compile-Time Resolution

What it does: Forces the compiler to evaluate expressions or patterns at compile time instead of runtime.
inline: This keyword indicates that the method can be inlined by the compiler, which can lead to performance optimizations. It allows the compiler to replace calls to this method with the method's body at compile time.

Let's break down the below given instance in detail, focusing on how it works to automatically generate JSON encoders for case classes in Scala 3. This part of the code is crucial for the functionality of the JSON encoding mechanism.

inline given derived[T](using m: Mirror.Of[T]): JsonEncoder[T] = new JsonEncoder[T] {
  def encode(value: T): String = {
    inline m match {
      case p: Mirror.ProductOf[T] => 
        val labels = summonLabels[p.MirroredElemLabels]
        println(s"labels:$labels")
        val encoders = summonEncoders[p.MirroredElemTypes]
        val values = value.asInstanceOf[Product].productIterator.toList
        val encodedFields = (labels, encoders, values).zipped.map {
          (label, encoder, value) =>
            s""""$label": ${encoder.asInstanceOf[JsonEncoder[Any]].encode(value)}"""
        }
        s"{${encodedFields.mkString(", ")}}"
      case _ => throw new IllegalArgumentException(s"Unsupported type: ${m.toString}")
    }
  }
}

The derived method automates the creation of type class instances (e.g., JsonEncoder[Person]) for case classes/sealed traits by leveraging compile-time metaprogramming.

The Compiler Calls derived
When you write
val perJson = encode(per) // Requires JsonEncoder[Person]
The compiler:
Looks for a given JsonEncoder[Person] in scope.
If none exists, it tries to derive one using the above derived method

1)Inline Given Instance:

inline given derived[T] (using m: Mirror.Of[T]): JsonEncoder[T]

Inline Given Instance:
This defines an implicit instance of JsonEncoder[T] for any type T that has a corresponding Mirror.
using m: Mirror.Of[T]: This means that the method requires an implicit Mirror for type T. The Mirror provides reflection capabilities to inspect the structure of the case class.
The Mirror.Of[T] type provides compile-time metadata about T (e.g., field names/types for case classes).
Mirror.Of[T] is a type class automatically generated by the Scala 3 compiler for case classes/sealed traits.

Is it a case class (product) or sealed trait (sum)?
it tells What are the field names and types (for case classes)?
similarly What are the subtypes (for sealed traits)?

The compiler generates:

Mirror.ProductOf[Person] {
type MirroredElemLabels = ("name", "age")
type MirroredElemTypes = (String, Int)
}

inline match on m ensures the compiler checks if T is a case class (product type) or a sum type (e.g., sealed trait) during compilation.
Without inline, this check would happen at runtime, leading to errors or inefficiency.

inline for Recursive Type-Level Computations
What it does: Unrolls recursion over type-level tuples (e.g., field labels/types) at compile time.
**
2) Summoning Labels:**

val labels = summonLabels[p.MirroredElemLabels]

p.MirroredElemLabels is a type-level representation of the names of the fields in the case class T. The summonLabels method retrieves these names as a list of strings.
This allows us to know what keys to use in the JSON output.

    // Helper to summon field labels
    private inline def summonLabels[T <: Tuple]: List[String] = inline erasedValue[T] match {
      case _: EmptyTuple => Nil
      case _: (head *: tail) => constValue[head].toString :: summonLabels[tail]
    }

summonLabels iterates over the type-level tuple of field labels (e.g., ("name", "age") for Person case class).
inline ensures the compiler recursively resolves each label to a String and builds a List[String] during compilation.
Without inline, the recursion would fail because type-level tuples exist only at compile time.

erasedValue and Type Safety

erasedValue[T] Creates a "fake" value of type T that exists only at compile time.This is necessary because in Scala, pattern matching typically works on values, not types. By using erasedValue, the compiler can inspect the structure of T.

The compiler pretends to create a runtime value of type T (e.g., ("name", "age")), even though T is a type.
This "fake" value is used to pattern-match on the structure of T.

The compiler inspects the structure of T (e.g., is it a tuple?).
For a tuple T = ("name", "age"):
Match head *: tail, where head = "name", tail = ("age").
Extract head as a value using constValuehead.
Recurse on tail to process "age".

For Person, the compiler:
Materializes T = ("name", "age") via erasedValue[T].
Matches head *: tail to decompose the tuple.
Extracts "name" and "age" using constValue.
Returns List("name", "age").

3) Summoning Encoders:

val encoders = summonEncoders[p.MirroredElemTypes]

Similar to labels, p.MirroredElemTypes provides the types of the fields in the case class. The summonEncoders method retrieves the corresponding JsonEncoder instances for each field type.
This is crucial for encoding each field correctly based on its type.

 // Helper to summon encoders for each field type
    private inline def summonEncoders[T <: Tuple]: List[JsonEncoder[_]] = 
      inline erasedValue[T] match {
        case _: EmptyTuple => Nil
        case _: (t *: ts) => summonInline[JsonEncoder[t]] :: summonEncoders[ts]
      }

Usage:

val encoder: JsonEncoder[String] =summonInline[JsonEncoder[String]]
Retrieves the JsonEncoder[String] instance at compile time.
If no instance exists, compilation fails.

Recursively summons encoders for each type in a tuple T.
Example: For T = (String, Int), it returns List(JsonEncoder[String], JsonEncoder[Int]).

SummonEncoders uses summonInline to fetch encoders for String and Int.If an encoder for String or Int is missing, compilation fails immediately.

Why Use summonInline Over summon?
Guaranteed Compile-Time Resolution:
summon might resolve instances at runtime in generic contexts, but summonInline forces resolution during compilation.
Integration with inline:Required for code generation in inline methods (e.g., deriving JSON encoders for case classes).

Example: Deriving a JSON Encoder
// Derive encoder for Person given JsonEncoder[Person] with { def encode(p: Person): String = { val labels = summonLabels[Person.derived.MirroredElemLabels] // ("name", "age") val encoders = summonEncoders[Person.derived.MirroredElemTypes] // (JsonEncoder[String], JsonEncoder[Int]) // Use labels/encoders to generate JSON } }

4) Extracting Values:

val values = value.asInstanceOf[Product].productIterator.toList

The value is cast to Product, which is the base trait for all case classes. The productIterator method returns an iterator over the fields of the case class.

The toList method converts this iterator into a list of values, which corresponds to the fields of the case class.

5) Encoding Fields:

val encodedFields = (labels, encoders, values).zipped.map { (label, encoder, value) => s""""$label": ${encoder.asInstanceOf[JsonEncoder[Any]].encode(value)}""" }

The zipped method combines the three lists: labels, encoders, and values into tuples. Each tuple contains a label, an encoder, and a value.
The map function iterates over these tuples, using the encoder to encode each value and formatting it as a JSON key-value pair.
The result is a list of strings representing the encoded fields.

5) Constructing the JSON Object:

s"{${encodedFields.mkString(", ")}}"

Finally, the encoded fields are joined together with commas and wrapped in curly braces to form a valid JSON object.

6) Full Derivation Flow

Request an Encoder:

encode(Person("Alice", 25)) // Requires JsonEncoder[Person]

1) Compiler Searches for JsonEncoder[Person]:
2) Checks implicit/given instances in scope.
3) Falls back to JsonEncoder.derived if none found.
4) Compiler Derives the Encoder:
5) Generates a Mirror.Of[Person].
6) Calls derived[Person] with the Mirror instance.
7) Uses inline to detect Person is a product type (case class).
8) Recursively resolves field labels ("name", "age") and types (String, Int).
9) Summons JsonEncoder[String] and JsonEncoder[Int] at compile time.
10) Generates code to serialize Person as {"name": "value", "age": 21}.

Implementing a Generic Foldable Type Class in Scala with List and Tuple Instances

Depa Reddy — Sun, 09 Feb 2025 17:47:15 +0000

In this short tutorial we will implement A Generic Foldable Type Class in Scala: From Lists to Custom Tuple Types.We will cover key concepts such as type lambdas, type classes, type class instances, and extension methods.full code can be found at this gist FoldableInstances.scala

Type lambdas in code

Type lambdas in Scala are a way to define anonymous type-level functions. They allow you to create new types on the fly by applying transformations to existing types.
This is particularly useful when working with higher-kinded types (types that take other types as parameters, like List, Option, or Either).

The syntax for a type lambda in Scala is

type TypeLambda = [Param1, Param2, ...] =>> ResultType

Type Alias: TupleMy2

TupleMy2 is defined as:

type TupleMy2 = [X] =>> (X, X)

This means:

TupleMy2 is a type-level function that takes a single type parameter X.
It produces a tuple type (X, X) where both elements of the tuple are of type X.
For example:

If X is Int, then TupleMy2[Int] is (Int, Int).

If X is String, then TupleMy2[String] is (String, String).

This allows us to generalize folding operations over both lists and tuples.

Defining the Foldable Type Class

Type classes are a powerful and flexible feature in Scala that allow you to define generic behavior that can be applied to different types without modifying those types

In below provided code, the Foldable trait is a type class that abstracts the concept of "foldability" for different data structures.

Foldable is a type class parameterized by a higher-kinded type C[_]

In this example, Foldable is a type class that defines a method foldr for that types must implement to be considered "foldable."

trait Foldable[C[_]]:
  def foldr[A, B](xs: C[A])(init: B)(fx: (A, B) => B): B

Create Type Class Instances

Now, we can create instances of the Foldable type class for different types:

In scala The given keyword helps define type class instances that the compiler can inject automatically.

Here we creates type class instance for specific types (List and TupleMy2)

Each instance provides a concrete implementation of foldr
Instances are named (listFoldable, tuple2Foldable) but names are optional

given listFoldable: Foldable[List] with
  override def foldr[A, B](xs: List[A])(init: B)(fx: (A, B) => B): B =
    xs.foldRight(init)(fx)

given tuple2Foldable: Foldable[TupleMy2] with
  override def foldr[A, B](xs: TupleMy2[A])(init: B)(fx: (A, B) => B): B =
    fx(xs._1, fx(xs._2, init))

List Instance:Uses List's built-in foldRight to implement foldr.
Example: List(1, 2, 3).foldRight(0)(_ + _) sums the elements.

Tuple Instance:For a tuple (a, b), applies fx to b and init first, then to a and the result.
Example: ("a", "g").foldRight("init")(_ + _) produces "initga".

Extension Methods: FoldableOps

The extension keyword is used to define an extension method. This allows you to add methods to existing types without modifying their source code.
its purpose is to add a foldRight method to any type with a Foldable instance.

object FoldableOps:
  extension [C[_], A](xs: C[A])(using foldable: Foldable[C])
    def foldRight[B](init: B)(fx: (A, B) => B) =
      summon[Foldable[C]].foldr(xs)(init)(fx)`

Components of the Extension Method

Extension Method Definition: The syntax extension [C[_], A](xs: C[A]) indicates that this extension method applies to any type constructor C that takes one type parameter (like List, Option, etc.) and to any type A.
Using Clause: The (using foldable: Foldable[C]) part indicates that this method requires an implicit Foldable[C] instance to be available in the scope. This is crucial because the method relies on the foldr implementation provided by the Foldable type class.
Method Implementation: The method foldRight[B](init: B)(fx: (A, B) => B) takes two parameters: init: The initial value of type B for the fold operation. fx: A function that takes an element of type A and an accumulator of type B, returning a new accumulator of type B. Inside the method, summon[Foldable[C]] is called to retrieve the implicit Foldable[C] instance. This instance is then used to call the foldr method, passing in the collection xs, the initial value init, and the folding function fx.

How It Works in Practice:

// For List
List("a", "b").foldRight("init")(_ + _)

// For Tuple
("a", "g").foldRight("init")(_ + _)

When you call foldRight on a List or TupleMy2, Scala will automatically look for an appropriate Foldable instance based on the type of the collection:

For List("a", "b"), the compiler finds the listFoldable instance because List is a type that has a Foldable instance defined.
For stringTuple, which is of type TupleMy2[String], the compiler finds the tuple2Foldable instance.then it Injects the instance implicitly into the foldRight call.

Brings all given instances from FoldableInstances into scope,like this.Required for the compiler to find the instances during implicit resolution

import com.example.FoldableInstances.given

Extension Method Execution:

summon[Foldable[List]].foldr(List("a", "b", "c", "d"))("init")((x, acc) => acc + x)`

The foldRight method is executed, and the compiler translates the call to summon[Foldable[C]] retrieves the instance from implicit scope.The foldr method of the listFoldable instance is called, performing the fold operation

Test Code

Folding a List

val list = List("a", "b", "c", "d").foldRight("init")((x, a) => a + x)
println("list" + list) // Output: "listinitdcba"

Behavior: Folds the list from right to left, appending elements to init.

Steps:

Start with "init".
Process "d" → "initd".
Process "c" → "initdc".
Process "b" → "initdcb".
Process "a" → "initdcba".
Folding a Tuple

Behavior: Folds the tuple ("a", "g") from right to left.

Steps:

Start with "init".
Process "g" → "initg".
Process "a" → "initga".

Key Flow

Define Type Class: Foldable trait with required operations
Provide Instances: Implementations for specific types using given
Import Instances: Make instances available in current scope
Use via Extension: Call methods that require the type class instance
Compiler Resolution: Automatically selects correct instance based on type

. Key Concepts

Type Classes: Foldable abstracts folding logic for different containers.
Higher-Kinded Types: C[_] generalizes over types like List and TupleMy2.
Type Lambdas: TupleMy2 is defined as a type-level function for tuples.
Extension Methods: Enable syntax like container.foldRight(... )